See also: IRC log
<Vincent> tlr, you are welcome to join on the phone
<Vincent> May be the discussion on the State finding may be of interest to you
Next telcon 16 May
<DanC> I seem to be available 16 May
VQ: Regrets from DO, HST
... TVR will scribe
NM: At risk for 23 May
<DanC> ah. IRW2006 23 May. yup, that's where I'll be.
VQ: Who else knows their situation that day?
TBL: I'm at a workshop with Henry that day
HST: So I am also engaged
DO: I'm still off that week
VQ: May not be available 23 May either myself -- that call is clearly at risk, will confirm next week whether we cancel or not
NW: I made the change NM requested and checked them back in
<noah> Thanks Norm, for making that change I requested.
<DanC> http://www.w3.org/2001/tag/2006/05/02-minutes.html close enough for me.
VQ: Those minutes -- http://www.w3.org/2001/tag/2006/05/02-minutes.html -- now approved
VQ: We need a good long session
... Suggestion to invite Thomas Roessler by 'phone, and Ben Adida, in person
... Plan to have that discussion on Tuesday, the second day
<DanC> tlr, Tues OK for you?
VQ: We'll start in the morning for the benefit of TLR calling in from Europe
DC: Date is 13 June
TLR: I've put that afternoon (European time) in my diary
VQ: Since we have Ben coming, I expect we'll carry on into the afternoon
TLR: I'll excuse myself at some point
VQ: NW, can we have a phone in the meeting room?
NW: Yes, provided we can get Zakim to call us -- I'll find out the number and get it in the zakim db
DC: I can bring a Vonage box if necessary
<DanC> (ndw, did you see my request to add net info to http://www.w3.org/2001/tag/2006/06/12-logistics.html ? )
<scribe> ACTION: NW to check with venue hosts, fallback to DC/Vonage if no phone [recorded in http://www.w3.org/2006/05/09-tagmem-minutes.html#action01]
TBL, NM: Coordinating wrt rides to/from the meeting for those flying in to Logan
DO: Coming in to Hartford (BDL)
NM: Will check if I can carry everyone (DO, HST, TVR+Bubbles, NM, TBL, VQ)
VQ: DC, access control on the agenda?
DC: Maybe, we'll see
VQ: NW, have you reviewed this?
NW: No, sorry
VQ: ER was supposed to also, but not here
DO: I will be absent for two weeks . . . how about agenda item for 30 May?
NM: When was last major change?
DO: 19 April
NM: Much improved from previous version
DC: This is a big topic area. . .talk about my.yahoo.com?
DC: If I bookmark my.yahoo.com showing latest (KC) Royals win, send it to my friend, he doesn't see what I see unless he's got the Royals registered as his favourite team
DO: Didn't cover that as such, but [scribe missed]
DC: Connects with TVR' s
... TLR, you look at this?
DC: Because there's login state stuff
DO: There's a bank account
... Section 8, session state, has this
TBL: You show different ways of
... Do you conclude which is best?
TBL: So the impact on URIs -- if you bookmark it, with sessionid=5, and come back to it, you get Timed Out.
<DanC> indeed, "session id timed out" is evil. let's please say so.
TBL: Two choices: BankOfAmerica says -- you lose, and sends you to the homepage; BritAirways requires re-authorisation, but then does send you where you were trying to go
DO: I didn't cover that option, no
HST only ever bookmarks the login page of his banks, because nothing else ever works
<dorchard> DO: I covered the URL rewriting case, and the various examples including rewriting URIs including session ids.
TBL: Moving around in a secure site, timeout shouldn't lose all your 'state', re-authenticating should allow you to continue
<timbl_> Goal: Reauthentication should not affect the transaction of navigation sequence.
DO: So I should be more specific
about what good app. design is in this regard, along the lines
... I touched on that, but should do more
<DanC> (pls do cut to the chase; be more controversial.)
DO: As it stands it's not judgemental, rather a discussion of what the features of the alternative approaches are
HST: PLH wasn't complaining about lack of judgement
DC: I think more hard judgements are a good idea
<DanC> (I think the non-judgemental style makes the relevant points hard to find.)
TBL: A few 'blue boxes' [best
practices, etc.] are a good idea, maybe use one for what we're
... Then there's the security issue
DO: One reason people put stuff in the message body rather than the URI itself is precisely for security -- in the message SSL will cover it
DO: ER scanned all the examples with regard to security
is buzzing in this area
... We can't cover everything, of course
DC: What's in the title matters: JS and Access Control; URIs vs. Cookies; Mobile and Content Targetting
<Zakim> ht, you wanted to mention shopping
DC: Another way to be clearer is to take stronger positions
HST: Note that where there's stronger commercial pressure, shopping sites, e.g. Amazon, Buy.com, do much better with bookmarking and/or resumption after timeout and reauth, because failure to do so has a real impact on sales
<DanC> (usability tends to correlate to risk profiles, yeah.)
<timbl_> The bank is a hair from losing me as a customer
DC: I did leave my bank over this issue
<timbl_> By the way, Dave, if a session ID is a very large random number then the example should give one.
HST: Folks like us are in the minority for the banks
TVR: What kind of ground rules
should we recommend
... Wrt when you should keep the same URI, but ship different content based on header info
... E.g. weather site sending different stuff to a mobile device
... Where this breaks down is that mobile providers are saying "to get the right stuff from me, send the following as your user agent string"
... Search engine bots tell sites they are bots, and get stuff to index on that basis
... These two things don't work together, because the search results will not be what the mobile user sees
... Search engines sending lots of different UA strings seems like a very fragile way to go
... Maybe the current approach for natural language difference is a good model
... There's a generic URL, which is the only one you have to index
... If you tell your UA to ask for a particular language, then you'll get the right language version, but you can send the generic URI to a different language user and the right thing will happen
<DanC> (hmm... mobile best practices is in last call, again... I wonder if it covers this...)
TVR: Not clear whether the problem will be for mobile or desktop down the road, because maybe there will be more mobile browsers than desktop
<Zakim> noah, you wanted to suggest (a) yes there's an issue (b) the criteria for the right answer are right there in the way Raman explains the use case
TVR: So core of proposal is that the generic URI always has the shared content
<DanC> (I think mobile bp does cover this. http://www.w3.org/TR/mobile-bp/#tc "Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices." )
NM: Agree with a lot of this, it's timely and we should say something about it
<DanC> (seems to me the mobile BP WG is ahead of us, and we should provide input to what they're writing, rather than write our own)
NM: Should emphasise that when you name your resources, if you think people will be tempted to try alternative UA strings, be very careful
<Zakim> timbl_, you wanted to suggest that part of the andwer for bots especially is publishing metatdat about the relationships beteween the various things available, (b) to say tht it
TBL: Pointers to metadata are crucial, so you can put, at the related URI you are told about, info about the relationships between all the different versions
<DanC> (yeah, much more common is that there will be 2 or 3 representations of a page: desktop, handheld-rich, and handheld-poor/SMS)
TBL: Extreme personalisation may
be hard to describe, but the 90% case (multiple languages,
large/small screen, all having the same information) should be
... And the metadata can make clear that archiving only one (and which one) will be enough
<DanC> ("guidelines on URI space" rings the issue 40 bell)
TVR: So some advice about how to organise your URI space to minimise the problem (c.f. NM's comment)
TVR: Bots had it simple at first -- .html yes, cgi-bin no
<DanC> (not clear that issue 40 is distinguishable from issue 42. 1/2 ;-)
TVR: But now so much is generated
on demand, that has broken down
... This aspect of WebArch could stand to be emphasised
DC: The MWBP doc does say
something close to what TVR was saying
... We should consider commenting on this, they have a good group and a lot of visibility
TVR: Yes, say something there, but say something at the broader TAG level about organising your URI space
DC: We do have issue 40, better to try that than 42, which is too open-ended
<Zakim> ht, you wanted to ask NM for clarification
HST: I don't understand how choice of resource name influences others to use multiple UA strings or not
<DanC> (well, /french/press-release1 is prolly worse than /press-release1.fr . wikipedia is learning this the hard way. W3C learned it the hard way with /Team/ and /Member/ and /Public/ )
NM: Consider personal info, VCard
... Gearing up to do this, presuming different content for small vs large screen
... These are related, not quite the same
... I could use two different URIs, one for each
... Search engines won't benefit from probing with different UA strings, because each resource has different content
... But TVR points out the benefits of having a generic URI
... But once we have a single URI which produces different content based on UA string, then the problem arises
TVR: The problem arises if that's
the only URI, as long as every view has its own URI as well
as the generic URI, the problem will be mitigated
... Provided they are discoverable from the normal hyperstructure of the Web
<noah> Right, so there are in fact conflicting requirements: (a) I want one URI, to handle the situations where I want to send Tim a single link and he decides how to browse (b) I want separate URIs, so the user agent string won't become a de-facto part of the name and (c) I would prefer not to assign both generic and specific names to what is more or less the same resource, because I have to manage those names and their relationship.
<noah> I do think we should do a finding and tell a story, but we should acknowledge going in that any answer is likely to be a compromise.
DC: Language negotiation,
wikipedia is struggling with having multiple domain names for
the different languages, so they can't use conneg
... The wiki folk assumed more difference would arise between the different language definitions than actually did in practice
VQ: There is a page in the French wikipedia a page for every village and town in France -- not clear it makes sense for that to be forced into English
TVR: The canonical /generic document need not be in English -- it's the one that was authored originally
<DanC> (yes, it's for the reasons VQ gives that wikipedia chose separate domains but that turns out to completely prohibit conneg, whereas if they had done the URIs the other way, that wouldn't require that they do conneg. though... hmm... it might interact poorly with wiki naming)
<timbl_> 300,000,000 m/s vs 300.000.000 m/s also
VQ: The question is who will make the translation
<DanC> but the information is the same, timbl, you can write it both ways on the page and everybody will get it.
TVR: Not the right starting point
TBL: W3C actually similar case --
home page and docs are translated, some events aren't
... I had an interesting pblm when I tried to do the right thing with Cool URIs -- by adding .es version for conneg, I got angry mail from someone in Spain saying "don't force me to the spanish version, I want to read the original, just put a button at the bottom if there's a Spanish translation available."
<dorchard> reminds me of the same discussion in GEB. The dostoevsky (I think) used Letters for streets to protect people. But russians could figure out the streets. So should a translation use letters or street names? But that misses the whole perspective of what was going on. Maybe Dickens is the best translation.
TVR: Right, not always right to remove control of what the user sees from the user
TBL: Adding the metadata helps
<Zakim> ht, you wanted to try to summarise
HST: So TBL and TVR not quite saying the same thing -- TVR says generic, plus specialised, with ordinary hyperlinks from the generic one, so the search engine's normal behaviour will find them, whereas TBL was suggesting that connection might be in metadata
TVR: Yes, that difference was
there, but I think the two positions can be reconciled
... E.g. if the metadata is <link>ed from the <head>, it can be done
... If that becomes the convention of the Web, then the crawlers will get smart and follow them
TBL: I think I discussed this in DesignIssues/Generic, maybe. . .
TBL: But it's not clear how to get this rolling
DC: You do it, get two friends, .
... when you get up to the 1000s, the bots will notice
<Zakim> noah, you wanted to distinguish crawler links from visible links
NM: Visual distinction between a
link I can click on, and a link a crawler can find but I can't
... I don't know how the tradeoffs would work in the mobile case
... Not clear that the Spanish use case and the Mobile use case admit to the same solution -- and that maybe invisible links help
TVR: Sometimes visible, sometimes
invisible is also a use case
... So put them in link tags, and let the UA decide when to show them
... Versus css-hidden <A> tags
... No big difference at the 5000-foot level
<Zakim> timbl_, you wanted to clarify ... I woruld support metadat over visible links
<noah> Noah would also like a minute at the end to give news on Boston/Amherst travel arrangements
<Vincent> ok, noah
<DanC> (metadata is only good enough if there's support in UAs.)
TBL: I agree TVR and I are not far apart -- I'd prefer for these to be in the metadata, not wanting the spanish example to be taken as a preference for visible links
HST +1 to DanC's comment
TVR: For the future -- something quite bounded in scope, without exposing us to problems long-term, that people will find helpful in addressing this problem
DC: You've got a content-type / media-type action pending. ...
TVR: I'm focussed on the topic at hand this month, prefer to do it first
<DanC> (it's mildly inconvinenient, for me, to have draft findings without issue numbers.)
VQ: I hear TVR offering to be
editor for a document here, we support him to try to draft
TVR: Rough first draft for f2f
<DanC> (I'm happy to have misc actions etc. tracked under issue 42)
VQ: We have a problem with this topic, and the state finding, that there is no issue number for them
DC: We need a group decision to add issues to the issues list, with number and name
NM: Discuss names for these by email