17:00:54 RRSAgent has joined #tagmem 17:00:54 logging to http://www.w3.org/2006/05/09-tagmem-irc 17:01:00 meeting: TAG telcon 17:01:01 zakim, [IBMCambridge] is me 17:01:01 +noah; got it 17:01:05 ->http://www.w3.org/2001/tag/2006/05/02-minutes.html 17:01:11 Vincent has joined #tagmem 17:01:12 chair: vincent 17:01:24 scribe: Henry S Thompson 17:01:29 scribenick: ht 17:01:54 +Vincent 17:02:05 zakim, please call ht-781 17:02:05 ok, ht; the call is being made 17:02:41 zakim, please call ht-781 17:02:41 ok, ht; the call is being made 17:03:00 zakim, disconnect ht 17:03:00 sorry, ht, I do not see a party named 'ht' 17:03:47 zakim, please call ht-781 17:03:47 ok, ht; the call is being made 17:04:36 tlr, you are welcome to join on the phone 17:05:00 +TimBL 17:05:07 May be the discussion on the State finding may be of interest to you 17:05:20 timbl_ has joined #tagmem 17:05:23 Zakim, who is on the phone? 17:05:23 On the phone I see Raman, noah, DanC (muted), Norm, Vincent, TimBL 17:05:34 zakim, please call ht-781 17:05:34 ok, ht; the call is being made 17:05:43 +DOrchard 17:05:58 Fortunately, HT has a girl^H^H^H^Hphone number in every port 17:06:13 :-) 17:06:24 +Thomas 17:06:48 +HT 17:06:48 dorchard has joined #tagmem 17:07:13 zakim, who is on the call? 17:07:13 On the phone I see Raman, noah, DanC (muted), Norm, Vincent, TimBL, DOrchard, Thomas (muted), HT 17:07:58 Topic: Admin 17:08:06 Next telcon 16 May 17:08:26 I seem to be available 16 May 17:08:48 VQ: Regrets from DO, HST 17:09:25 ... TVR will scribe 17:09:53 NM: Regrets for 23 May 17:10:23 ah. IRW2006 23 May. yup, that's where I'll be. 17:10:24 VQ: Who else knows their situation that day? 17:11:04 TBL: I'm at a workshop with Henry that day 17:11:14 HST: So I am also engaged 17:11:41 s/NM: Regrets/NM: At risk/ 17:11:58 DO: I'm still off that week 17:12:27 VQ: May not be available 23 May either myself -- that call is clearly at risk, will confirm next week whether we cancel or not 17:12:56 (http://www.w3.org/2006/05/02-tagmem-minutes.html seems to have a member-only stylesheet ?) 17:12:58 VQ: Minutes from last telcon: http://www.w3.org/2006/05/02-tagmem-minutes.html 17:13:08 Thanks Norm, for making that change I requested. 17:13:11 NW: I made the change NM requested and checked them back in 17:13:44 http://www.w3.org/2001/tag/2006/05/02-minutes.html 17:14:09 (http://www.w3.org/2001/tag/2006/05/02-minutes.html is white ; better; says draft) 17:14:33 http://www.w3.org/2001/tag/2006/05/02-minutes.html close enough for me. 17:14:53 VQ: Those minutes -- http://www.w3.org/2001/tag/2006/05/02-minutes.html -- now approved 17:15:48 Topic: Agenda for June f2f 17:15:59 VQ: We need a good long session on security 17:16:26 ... Suggestion to invite Thomas Roessler by 'phone, and ??, in person 17:16:41 ... Plan to have that discussion on Tuesday, the second day 17:16:44 s/??/Ben Adida/ 17:17:12 tlr, Tues OK for you? 17:17:54 VQ: We'll start in the morning for the benefit of TLR calling in from Europe 17:18:02 DC: Date is 13 June 17:18:21 TLR: I've put that afternoon (European time) in my diary 17:18:44 VQ: Since we have Ben coming, I expect we'll carry on into the afternoon 17:18:55 TLR: I'll excuse myself at some point 17:19:10 VQ: NW, can we have a phone in the meeting room? 17:19:38 NW: Yes, provided we can get Zakim to call us -- I'll find out the number and get it in the zakim db 17:19:49 DC: I can bring a Vonage box if necessary 17:20:08 (ndw, did you see my request to add net info to http://www.w3.org/2001/tag/2006/06/12-logistics.html ? ) 17:20:17 ACTION: NW to check with venue hosts, fallback to DC/Vonage if no phone 17:21:08 TBL, NW: Coordinating wrt rides to/from the meeting for those flying in to Logan 17:21:30 s/NW: Coord/NM: Coord/ 17:22:06 DO: Coming in to Hartford (BDL) 17:22:57 NM: Will check if I can carry everyone (DO, HST, TVR, NM, TBL) 17:23:58 + Bubbles! 17:24:12 :) 17:26:08 VQ: DC, access control on the agenda? 17:26:19 DC: Maybe, we'll see 17:26:25 Topic: State finding 17:26:42 http://www.w3.org/2001/tag/doc/state.html 17:26:52 VQ: NW, have you reviewed this? 17:26:56 NW: No, sorry 17:27:10 VQ: ER was supposed to also, but not here 17:27:20 q+ 17:27:44 DO: I will be absent for two weeks . . . how about agenda item for 30 May? 17:27:56 NM: When was last major change? 17:28:03 DO: 19 April 17:28:35 NM: Much improved from previous version 17:28:38 ack danc 17:29:28 DC: This is a big topic area. . .talk about my.yahoo.com? 17:29:30 DO: No 17:30:11 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 17:30:27 q+ 17:30:28 DO: Didn't cover that as such, but [scribe missed] 17:30:44 DC: Connects with TVR' s concern 17:30:54 ... TLR, you look at this? 17:30:59 TLR: No 17:31:10 DC: Because there's login state stuff 17:31:23 DO: There's a bank account example 17:31:42 ... Section 8, session state, has this 17:32:01 TBL: You show different ways of doing it 17:32:07 ... Do you conclude which is best? 17:32:44 DO: No, give the tradeoffs, but do point out most apps don't do any of this, but use cookies 17:33:21 TBL: So the impact on URIs -- if you bookmark it, with sessionid=5, and come back to it, you get Timed Out. 17:34:11 indeed, "session id timed out" is evil. let's please say so. 17:35:09 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 17:35:22 DO: I didn't cover that option, no 17:35:54 HST only ever bookmarks the login page of his banks, because nothing else ever works 17:36:12 DO: I covered the URL rewriting case, and the various examples including rewriting URIs including session ids. 17:36:34 TBL: Moving around in a secure site, timeout shouldn't lose all your 'state', re-authenticating should allow you to continue 17:36:47 q+ to mention shopping 17:37:20 Goal: Reauthentication should not affect the transaction of navigation sequence. 17:37:21 DO: So I should be more specific about what good app. design is in this regard, along the lines above 17:37:43 ... I touched on that, but should do more 17:37:52 ack timbl 17:38:27 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" 17:38:57 (pls do cut to the chase; be more controversial.) 17:39:04 DO: As it stands it's not judgemental, rather a discussion of what the features of the alternative approaches are 17:39:11 q- 17:39:57 HST: PLH wasn't complaining about lack of judgement 17:40:10 DC: I think more hard judgements are a good idea 17:40:19 (I think the non-judgemental style makes the relevant points hard to find.) 17:41:00 TBL: A few 'blue boxes' [best practices, etc.] are a good idea, maybe use one for what we're discussing 17:41:24 ... Then there's the security issue 17:42:03 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 17:42:22 ack DanC 17:42:22 DanC, you wanted to look at the state finding from a couple audiences: access control/javascript sandbox, @@, and @@ 17:42:22 ack danc 17:42:28 ... ER scanned all the examples in that regard 17:43:06 DC: Javascript/Sandbox [?] stuff is buzzing in this area 17:43:23 ... We can't cover everything, of course 17:43:57 q? 17:43:58 Subtitle? 17:44:03 ... What's in the title matters: JS and Access Control; URIs vs. Cookies; Mobile and Content Targetting 17:44:26 ack ht 17:44:26 ht, you wanted to mention shopping 17:45:11 (usability tends to correlate to risk profiles, yeah.) 17:45:28 The bank is a hair from losing me as a customer 17:45:38 q+ 17:45:45 ... Another way to be clearer is to take stronger positions 17:45:55 q- 17:46:40 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 17:46:49 DC: I did leave my bank over this issue 17:47:03 By the way, Dave, if a session ID is a very large random number then the example should give one. 17:47:03 HST: Folks like us are in the minority for the banks 17:47:26 Topic: Single URI, Multiple content 17:47:36 http://lists.w3.org/Archives/Member/tag/2006May/0011.html 17:47:54 TVR: What kind of ground rules should we recommend 17:48:16 ... Wrt when you should keep the same URI, but ship different content based on header info 17:48:34 ... E.g. weather site sending different stuff to a mobile device 17:49:20 ... 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" 17:49:52 ... Search engine bots tell sites they are bots, and get stuff to index on that basis 17:50:21 ... These two things don't work together, because the search results will _not_ be what the mobile user sees 17:50:53 ... Search engines sending lots of different UA strings seems like a very fragile way to go 17:51:10 q+ 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 17:51:15 ... Maybe the current approach for natural language difference is a good model 17:51:32 ... There's a generic URL, which is the _only_ one you have to index 17:51:32 q+ 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 is important to use both techniques. -- it is still important to send device independent information for storing and printing etc wioll want that. 17:52:28 ... 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 17:52:55 (hmm... mobile best practices is in last call, again... I wonder if it covers this...) 17:53:09 ... Not clear whether the problem will be for mobile or desktop down the road, because maybe there will be _more_ mobile browsers than desktop 17:53:16 q+ 17:53:31 ack noah 17:53:31 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 17:53:41 ... So core of proposal is that the generic URI always has the shared content 17:53:58 (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." ) 17:54:06 NM: Agree with a lot of this, it's timely and we should say something about it 17:54:31 (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) 17:55:18 ... Should emphasise that when you name your resources, if you think people will be tempted to try alternative UA strings, be very careful 17:55:24 q+ to ask NM for clarification 17:55:49 ack timbl 17:55:49 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 17:55:52 ... is important to use both techniques. -- it is still important to send device independent information for storing and printing etc wioll want that. 17:56:52 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 17:57:42 (yeah, much more common is that there will be 2 or 3 representations of a page: desktop, handheld-rich, and handheld-poor/SMS) 17:57:51 ... Extreme personalisation may be hard to describe, but the 90% case (multiple languages, large/small screen, all having the same information) should be easier 17:58:20 ... And the metadata can make clear that archiving only one (and which one) will be enough 17:58:37 -Thomas 17:58:53 ("guidelines on URI space" rings the issue 40 bell) 17:58:55 TVR: So some advice about how to organise your URI space to minimise the problem (c.f. NM's comment) 17:59:35 ( http://www.w3.org/2001/tag/issues.html#URIGoodPractice-40 ) 17:59:41 ... Bots had it simple at first -- .html yes, .cgi no 17:59:56 (not clear that issue 40 is distinguishable from issue 42. 1/2 ;-) 18:00:01 ... But now so much is generated on demand, that has broken down 18:00:38 ack danc 18:00:45 ... This aspect of WebArch could stand to be emphasised 18:01:55 DC: The MWPB doc does say something close to what TVR was saying 18:02:13 s/MWPB/MWBP/ 18:02:35 ... We should consider commenting on this, they have a good group and a lot of visibility 18:03:07 TVR: Yes, say something there, but say something at the broader TAG level about organising your URI space 18:03:27 DC: We do have issue 40, better to try that than 42, which is too open-ended 18:03:30 ack ht 18:03:30 ht, you wanted to ask NM for clarification 18:04:48 HST: I don't understand how choice of resource name influences others to use multiple UA strings or not 18:04:53 (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/ ) 18:05:03 NM: Consider personal info, VCard style 18:05:23 ... Gearing up to do this, presuming different content for small vs large screen 18:05:32 ... These are related, not quite the same 18:05:49 ... I could use two different URIs, one for each 18:06:27 ... Search engines won't benefit from probing with different UA strings, because each resource has different content 18:06:54 ... But TVR points out the benefits of having a generic URI 18:07:00 q+ 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 18:07:57 ... But once we _have_ a single URI which produces different content based on UA string, then the problem arises 18:08:30 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 18:09:05 ... Provided they are discoverable from the _normal_ hyperstructure of the Web 18:09:40 ack DanC 18:09:40 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 18:09:53 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. 18:10:43 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. 18:10:48 DC: Language negotiation, wikipedia is struggling with having multiple domain names for the different languages, so they can't use conneg 18:11:40 q+ to try to summarise 18:12:20 DC: The wiki folk assumed more difference would arise between the different language definitions than actually did in practice 18:12:57 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 18:13:37 TVR: The canonical /generic document need not be in English -- it's the one that was authored originally 18:13:51 (yes, it's for the reasons VQ gives that wikipedia chose separate domans. 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) 18:14:05 300,000,000 m/s vs 300.000.000 m/s also 18:14:17 VQ: The question is who will make the translation 18:14:24 but the information is the same, timbl, you can write it both ways on the page and everybody will get it. 18:14:30 TVR: Not the right starting point 18:15:16 TBL: W3C actually similar case -- home page and docs are translated, some events aren't 18:16:13 ... I had an interesting pblm when I tried to do the right thing with Cool URIs -- by adding .es version, I got angry mail from someone in Spain saying "don't force me to the spanish version, I want to read the original" 18:16:48 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. 18:16:56 TVR: Right, not always right to remove control of what the user sees from the user 18:17:23 TBL: Adding the metadata helps 18:17:40 ack ht 18:17:40 ht, you wanted to try to summarise 18:20:19 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 18:20:23 q+ to distinguish crawler links from visible links 18:20:43 TVR: Yes, that difference was there, but I think the two positions can be reconciled 18:21:04 ... E.g. if the metadata is ed from the , it can be done 18:21:28 ... If that becomes the convention of the Web, then the crawlers will get smart and follow them 18:21:49 TBL: I think I discussed this in DesignIssues/Generic, maybe. . . 18:22:05 http://www.w3.org/DesignIssues/Generic 18:22:09 ... But it's not clear how to get this rolling 18:22:18 DC: You do it, get two friends, . .. . 18:22:29 ... when you get up to the 1000s, the bots will notice 18:22:31 ack noah 18:22:31 noah, you wanted to distinguish crawler links from visible links 18:23:11 NM: Visual distinction between a link I can click on, and a link a crawler can find but I can't see 18:23:27 ... I don't know how the tradeoffs would work in the mobile case 18:23:53 q+ to clarify ... I woruld support metadat over visible links 18:23:53 ... Not clear that the Spanish use case and the Mobile use case admit to the same solution -- and that maybe invisible links help 18:24:21 TVR: Sometimes visible, sometimes invisible is also a use case 18:24:41 ... So put them in link tags, and let the UA decide when to show them 18:25:07 ... Versus css-hidden tags 18:25:16 ... No big difference at the 5000-foot level 18:25:30 ack timbl 18:25:30 timbl_, you wanted to clarify ... I woruld support metadat over visible links 18:25:53 Noah would also like a minute at the end to give news on Boston/Amherst travel arrangements 18:26:10 ok, noah 18:26:19 (metadata is only good enough if there's support in UAs.0 18:26:20 ) 18:26:26 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 18:26:40 HST +1 to DanC's comment 18:26:58 q+ 18:27:07 ack danc 18:27:22 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 18:27:47 DC: You've got a content-type / media-type action pending. ... 18:28:23 TVR: I'm focussed on the topic at hand this month, prefer to do it first 18:28:46 (it's mildly inconvinenient, for me, to have draft findings without issue numbers.) 18:28:59 VQ: I hear TVR offering to be editor for a document here, we support him to try to draft something here 18:29:34 ... Timetable? 18:29:44 TVR: Rough first draft for f2f 18:30:19 (I'm happy to have misc actions etc. tracked under issue 42) 18:30:32 VQ: We have a problem with this topic, and the state finding, that there is no issue number for them 18:31:09 DC: We need a group decision to add issues to the issues list, with number _and_ name 18:31:31 NM: Discuss names for these by email 18:31:58 -DOrchard 18:33:58 -HT 18:33:59 TAG_Weekly()12:30PM has ended 18:34:01 Attendees were Raman, DanC, Norm, noah, Vincent, TimBL, DOrchard, Thomas, HT 18:35:43 Present: Tim Berners-Lee, Dan Connolly, Noah Mendelsohn, David Orchard, Vincent Quint, TV Raman, Henry S. Thompson, Norm Walsh, Thomas Roessler (observer, in part) 18:35:54 RRSAgent, please draft minutes 18:35:54 I have made the request to generate http://www.w3.org/2006/05/09-tagmem-minutes.html ht 18:36:14 RRSAgent, make logs team-visible 18:36:20 zakim, bye 18:36:20 Zakim has left #tagmem 18:36:26 rrsagent, bye 18:36:26 I see 1 open action item saved in http://www.w3.org/2006/05/09-tagmem-actions.rdf : 18:36:26 ACTION: NW to check with venue hosts, fallback to DC/Vonage if no phone [1] 18:36:26 recorded in http://www.w3.org/2006/05/09-tagmem-irc#T17-20-17