TAG telcon

9 May 2006

See also: IRC log


Tim Berners-Lee, Dan Connolly, Noah Mendelsohn, David Orchard, Vincent Quint, TV Raman, Henry S. Thompson, Norm Walsh, Thomas Roessler (observer, in part)
Ed Rice
Vincent Quint
Henry S Thompson


<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

Agenda for June f2f

VQ: We need a good long session on security
... 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

State finding


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?

DO: No

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 concern
... TLR, you look at this?


DC: Because there's login state stuff

DO: There's a bank account example
... Section 8, session state, has this

TBL: You show different ways of doing it
... Do you conclude which is best?

DO: No, give the tradeoffs, but do point out most apps don't do any of this, but use cookies

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 above
... I touched on that, but should do more

TBL: PLH looked at this, but didn't get what it was about -- something up front clarifying this is about "When to use URLs and when to use cookies"

<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 discussing
... 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

<Zakim> DanC, you wanted to look at the state finding from a couple audiences: access control/javascript sandbox, @@, and @@

DO: ER scanned all the examples with regard to security

DC: Javascript/Sandbox [?] stuff 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

<timbl_> Subtitle?

<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

Single URI, Multiple content


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 easier
... 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)

<DanC> ( http://www.w3.org/2001/tag/issues.html#URIGoodPractice-40 )

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 style
... 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

<Zakim> DanC, you wanted to note pain in wikipedia community around http://en.wikipedia.org/wiki/W3c vs http://fr.wikipedia.org/wiki/W3c as opposed to /wiki/W3c.en vs /wiki/W3c.fr

<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. . .

<timbl_> http://www.w3.org/DesignIssues/Generic

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 see
... 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 something here
... Timetable?

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

Summary of Action Items

[NEW] 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]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/05/09 19:01:35 $