15:32:57 RRSAgent has joined #tagmem 15:32:57 logging to http://www.w3.org/2007/06/25-tagmem-irc 15:33:01 Zakim has joined #tagmem 15:33:07 zakim, this will be tag 15:33:07 ok, Norm; I see TAG_Weekly()12:00PM scheduled to start in 27 minutes 15:33:44 Meeting: Techical Architecture Group (TAG) 15:33:44 Date: 25 June 2007 15:33:44 Agenda: http://www.w3.org/2001/tag/tag-weekly 15:33:44 Chair: Stuart 15:33:44 Scribe: Norm 15:33:45 ScribeNick: Norm 15:36:01 Stuart has joined #tagmem 15:37:10 zakim, this will be TAG 15:37:10 ok, Stuart; I see TAG_Weekly()12:00PM scheduled to start in 23 minutes 15:55:09 Rhys has joined #tagmem 15:59:39 TAG_Weekly()12:00PM has now started 15:59:46 +Norm 16:00:09 +Rhys_Lewis 16:01:11 +??P14 16:01:26 zakim, ??P14 is Stuart 16:01:26 +Stuart; got it 16:02:50 zakim, who is here? 16:02:50 On the phone I see Norm, Rhys_Lewis, Stuart 16:02:51 On IRC I see Rhys, Stuart, Zakim, RRSAgent, Noah, Norm, ht 16:03:53 +Noah_Mendelsohn 16:04:08 +Raman 16:04:35 raman has joined #tagmem 16:05:08 zakim, who's on the phone? 16:05:08 On the phone I see Norm, Rhys_Lewis, Stuart, Noah_Mendelsohn, Raman 16:05:18 Present: Norm, Rhys, Stuart, Noah, Raman 16:05:23 Regrets: TimBL 16:05:28 Topic: Administrivia 16:05:32 Approve this agenda? 16:05:55 Stuart: Under any other business, I'd like proposals for agenda items for next week 16:06:00 zakim, please call ht-781 16:06:00 ok, ht; the call is being made 16:06:01 Accepted. 16:06:02 +Ht 16:06:11 Next telcon: 2 July 16:06:19 Present: Norm, Rhys, Stuart, Noah, Raman, Henry 16:06:25 Raman to scribe. 16:06:35 Noah and David give regrets for 2 July 16:06:44 +DOrchard 16:06:46 Topic: Approve minutes from 18 June 2007? 16:06:51 Accepted. 16:06:56 Present: Norm, Rhys, Stuart, Noah, Raman, Henry, David 16:07:00 dorchard has joined #tagmem 16:07:22 Topic: passwordsInTheClear-52 16:07:33 Stuart: What were the obstacles to making progress on this finding? 16:08:14 ...I'm not sure we have a date where Mary Ellen (IBM) can meet with us to discuss. 16:08:19 ...Could we meet on a day other than Monday? 16:08:42 Norm: I'm happy to, as long as I don't have a conflicting call. 16:08:44 +Ed_Rice 16:08:47 Please note that I am unavailable for the first two weeks of July, regardless of day. 16:08:50 Stuart: I've asked her to suggest an alternate time. 16:09:21 Welcome Ed 16:10:07 Henry: I haven't reviewed it recently, but I recall that the sticking point was that the finding suggested user agents do something they'd flatly refuse to do. 16:10:58 ...We wanted user agents to warn people when they send passwords over http. Then it became clear that there are secure JavaScript-based implementations that do use http. So it wasn't going to be acceptable to give warnings when they weren't necessary. 16:11:04 ...My memory is we got there and we stopped. 16:11:41 Ed: I think we discovered that Yahoo was downloading an encryption key within the JavaScript. So the warning would apply there when it wasn't true. 16:12:12 Raman: The other thing to do would be to drop the finding. 16:12:31 Henry: I don't agree. There was a lot of sentiment that we ought to be saying this. 16:13:17 David: Can we phrase it differently? Maybe saying that if the browser is aware that the password will be sent in the clear, because it's using standards, then the warning should be displayed. 16:13:29 ...That would narrow the scope, but... 16:13:53 Ed: How can you tell? In both cases, the standard password field is used, but in the JavaScript case it's encrypted before its sent. The browser can't tell. 16:14:40 Noah: Does Yahoo encrypt the password field in place. When I hit "submit" it runs some JavaScript and encrypts the field. Does the browser think I'm submitting a password 16:14:44 Henry/Ed: Yes 16:15:03 Stuart: So it's the JavaScript that does the posting. 16:15:06 Ed: Yes. 16:15:40 Noah: I've been lukewarm for a variety of reasons, but it's not clear to me that the problem Henry raised is real. 16:16:22 Norm: I think the browser really is submitting the form after the onSubmit, so the browser really can't tell. 16:16:25 Ed: Right. 16:17:07 Ed: We did find that the JavaScript technique used by Yahoo was vulnerable. 16:17:16 Stuart: I see four good practice notes 16:17:59 Noah: I think the good practice notes are pretty vague so it's hard to tell. 16:18:09 Noah: We're really saying "don't do anything that doesn't meet your needs" 16:18:59 Ed: I'm willing to tell servers that they should change. 16:19:37 Stuart: I interpreted the first good practice as simply meaning that the typed password shouldn't be displayed on the screen when you type it. 16:19:51 Noah: That's not what I thought. I thought it was about avoiding point 2. 16:20:15 FWIW I read it the way that Noah read it 16:21:04 Stuart: I think in the Yahoo case, you could argue that they've covered the first three points. 16:21:23 Henry: That's precisely the problem. The user agent can't tell that, so it's going to warn the user. 16:22:10 Raman: The other practice you see frequently is a clear text http: submission that's redirected to an https: URI. That's totally insecure too. 16:22:21 The concern I'm raising as that, even among the few of us on the phone, we're getting pretty different answers about what these practice notes mean. Stuart reads the first one as saying: don't prompt for PWs in a way that will display them on the screen. If that's what we mean, shouldn't we say it that way? 16:22:23 Stuart: Does anyone have ideas about how we make progress? 16:22:52 David: I thought there had been some suggestions for limiting scope, I thought it made sense to incorporate those suggestions. 16:22:59 FWIW, I read the same GPN as "don't send HTML and/or JavaScript to the client that would cause it to violate rule 2, I.e. to send the password back up in the clear." 16:23:05 ...I think these are statements that are worthy of being said. I really want to find a way to proceed. 16:23:18 Henry: I think we can proceed by removing the teeth. No longer put any onus on user agents. 16:23:29 Ed: But isn't the whole point to protect the user? 16:23:34 I'm fine saying either or both of those, but I think we should at least make sure that those sorts of ambiguities are removed from the GPN(s). 16:23:36 ...If we don't tell them, how are they going to know? 16:23:52 Stuart: Henry's point is we don't know how to tell. 16:24:04 David: Sure, but we could say something about the JavaScript case. 16:24:25 Raman: JavaScript is noise here, it's only a hook that latches on. 16:25:01 Ed: If you don't want to trigger the alarm, then don't call it a password field. 16:25:37 Henry: We could also leave all of the text as it is, but we make a footnote that says user agents can only reliably determine if a password is being sent in the clear if no scripts are used. 16:26:12 Raman: All that HTML garantees you with input type=password is that the characters you type won't be displayed. 16:26:30 Henry: Right, we're trying to get UAs to go one step further: warn users if the form is submitted in the clear. 16:26:42 Raman: Maybe we can say: things that aren't shown in the clear on the screen shouldn't be sent in the clear over the wire. 16:26:59 Henry: Right. Now how do we state this as an injunction that UAs can reasonably implement. 16:27:48 Norm: I also have some sympathy for the position that false negatives are safer than false positives. 16:28:20 Ed: A whole lot of login pages have all sorts of JavaScript so if you excluded this warning on pages with JavaScript you'd limit a lot of cases. 16:28:42 Henry: I'm only suggesting that onSubmit should be the trigger 16:28:55 Some discussion of when scripters usually do consistency checking. 16:29:04 DanC has joined #tagmem 16:29:07 Conclusion: yeah, maybe that won't fly. 16:29:34 Ed: I'd be happier just saying that some sites are doing it wrong...because you can decrypt (some of) the JavaScript attempts 16:29:52 Stuart: In principle they could have done it right with half of a public key. 16:30:25 Ed: It's hard to do it too strongly because the entire program that does the encryption has to be in the JavaScript. 16:30:37 Stuart: I'm saying that in principle it could have been done strongly. 16:31:04 Ed: If we have a password field, we ought to warn people when they may be used insecurely, that's my point. 16:31:16 Stuart: What's the objection? 16:31:18 Ed: The teeth. 16:31:34 Ed: Noah, you're arguing that in some places passing passwords in the clear is OK. 16:31:43 Noah: Yes, but that's not really my main concern. 16:32:01 ...Stuart and I read the first good practice note and came to different conclusions about what it meant. I think that's the problem. 16:32:48 ...Maybe we want to tell both stories. My real problem is that I think you can go two ways: one is to tell an extremely broad story that isn't very detailed; the other is to tell a more detailed story. But in that case, it's hard to get the details right. 16:32:55 ...I'm trying to see if we can find a middle ground. 16:33:09 ...But I've already said I won't belabor these concerns if I'm the only one who has them. 16:33:31 zakim, who is here? 16:33:31 On the phone I see Norm, Rhys_Lewis, Stuart, Noah_Mendelsohn, Raman, Ht, DOrchard, Ed_Rice 16:33:33 On IRC I see DanC, dorchard, raman, Rhys, Stuart, Zakim, RRSAgent, Noah, Norm, ht 16:34:35 Henry: Is this a viable finding as it is? Without the teeth? If we added more caveats about lightweight passwords. 16:34:36 Should we ask: is there any one GPN in this that's suitably unambiguous, and that we think would be really good advice to the community? 16:34:43 Is there a 2nd one? 16:34:49 Stir until done (or dead). 16:34:51 s/passwords./passwords? 16:35:29 Stuart: Straw poll: viable as it is, stripped of teeth, or with more caveats? 16:38:19 David: 1/3; Henry: 2/3; Noah: I'd like it be less ambiguous, but abstain; I think it's borderline worthy of publication; Norm: 3; Raman: I'm confused, I'm not sure the results are worthy of a finding 16:38:37 s/David:/-> David:/ 16:38:48 -> Stuart: I'd like to say something with teeth, but I'm not sure what that is. 16:39:20 q+ 16:39:37 Stuart: I think this gives me a better idea of what to tell Mary 16:39:51 To be clear, I'm not against doing work towards trying to publish, I'd just like to see the advice get clearer, and then I'd like to be sure that it's targeted at the real pain points or areas of practical risk. 16:40:04 Rhys: I don't have any of the history, I think it would be nice to say something, but the world wouldn't collapse if we didn't. 16:40:21 Stuart: Raman, can you remind me of the conversation you had with Mary? 16:40:42 Raman: She'd like the TAG to say something, she was disappointed that we hadn't made more progress, and asked if she could help. 16:40:55 Stuart: Ok, I'll write to her and see if we can schedule something. 16:41:04 Stuart: Ed, do you still want to be engaged? 16:41:14 Ed: Yes, I'd like to contribute if I can . 16:41:48 Some discussion of Ed's experiences discussing this with the IE developers. 16:42:00 -Ed_Rice 16:42:17 ACTION: Stuart to summarize discussion to Mary and make plans for further progress. 16:42:34 Topic: Review request for Enabling Read Access for Web Resources 16:42:48 Stuart: I don't have a huge amount of background or context to share. It's a pity Dan isn't here. 16:44:21 Noah: I think this is an attempt to put some declarative mechanisms behind what you see being done with xmlHttpRequest regarding who's allowed to pull down what content. 16:44:34 Rhys: They describe it as extending the browser sandbox. 16:44:39 Stuart: Anyone willing to take a review pass? 16:44:56 David: I've asked a couple of our security folks to take a look. 16:45:05 ...I'd like a little more time before committing to a review. 16:46:18 Norm: I'm interested, but I'm not sure I have enough real-world experience with the actual technologies involved. 16:46:28 Stuart: Should I leave it a week? 16:46:33 Yes, apparently 16:46:58 Topic: XMLVersioning-41 16:47:32 Discussing Noah's note at: http://lists.w3.org/Archives/Public/www-tag/2007Jun/0092 16:47:35 Stuart: I put Noah's message on the agenda. 16:47:44 Key points: 16:47:44 * IF the language completely ignores extension content, then defined/accept tells a powerful story. Each text in the accept set has an equivalent in the defined set. 16:47:44 * BUT: many languages we use all the time define important non-ignore generic semantics to extension content (e.g. it's stylable, it's scriptable). You can tell the difference between and even if HTML doesn't call them out. 16:47:44 * Using the PHTML+PCSS example, Tim claims that all documents, including with are in the defined set. So, it's not clear to me whether defined/accept offers usef 16:47:52 ...And some comments by Olivier Thereaux 16:47:58 * Using the PHTML+PCSS example, Tim claims that all documents, including with are in the defined set. So, it's not clear to me whether defined/accept offers useful insight into the versioning that happens if PHTML+PCSS version 2 were to define a particular semantic for . 16:48:05 Noah summarizes the bullets above 16:49:26 s/bullets above/bullets above and email thread/ 16:55:19 Stuart: One question: I keep tripping over whether or not people think the defined/accept sets are disjoint or overlapping. 16:55:52 David: I thought it was fairly clear that the accept set is a superset of the defined set. 16:56:10 Noah: I thought it was just the outer ring, the difference. 16:56:23 ...If that confusion remains, we need to settle on consistent terms pretty soon. 16:57:38 Henry: In the bulls-eye diagram, if the center, labeled A, and the ring around the center B, it's not clear if B *includes* A or not. 16:57:38 Anyway, we need to keep in mind that my email, and the summary above, is written as if accept set and define set are disjoint. I have no strong religion on which way we go, as long as it's made clear. 16:57:53 David: I thought that since we speak of superset and subset relationships it was clear. 16:58:07 Henry: I think that's right, but you also need a name for the ring, the set difference. 16:58:22 David: I've brought up the naming issue a couple of times, but we haven't settled on a name. 16:59:05 Noah: There are three interesting concepts: a document that's acceptable but not defined, a document that's defined, and a document that's ... SCRIBE MISSED 16:59:14 David: Accept minus defined or something like that. 16:59:35 Noah: We also have to note that different documents may have different notions 17:00:22 David: I think we should proceed to talk about what happens if banana gets defined. I think that really happens. 17:01:03 Noah: Do you buy the formulation that I ascribe to Tim: If I start with the combination of HTML+CSS and I have a banana, Tim says they're in the defined set because CSS can style them. 17:01:19 ...If every document is in the defined set, then I'm not sure this is going to help much. 17:01:38 David: I have to think a bit, but my intuition is to not put the banana in the defined set. 17:01:58 Noah: As long as you agree with Tim, and say it is in the defined set, then I get to come full circle pointing out that defined/accept don't work. 17:02:29 Noah: Or the other way is to say that you and Tim don't agree. Then I come back to not thinking that I'm hearing a consistent story. 17:02:51 Noah: The only consistent point is that the defined set is more-or-less what you're expecting. 17:03:04 Noah: I think we need clarity on this before we go much further. 17:03:22 David: I think I'll add what you've done to the terminology section and see how it falls out. 17:03:47 Noah: Where I'd like to go is: step 1, figure out the terminology for the three sets and rewrite what I wrote using that terminology. 17:03:57 ...I think we also need to decide if we care about the use case I proposed. 17:04:23 ...We could decide not to answer the question of HTML+CSS, but I think that would be unfortunate. 17:05:08 q+ 17:05:16 Noah: I think it might make sense to solve the general case first and then work on the special case. 17:05:19 raman has left #tagmem 17:05:21 ack me 17:05:29 ...It's crucial that you can style bananas differently than fish. 17:05:35 q+ 17:05:40 ...My intuition is that if we get that right, the ignore case might just fall out. 17:06:23 Stuart: I was looking at Noah's examples. Banana, particularly in this with-styling case, turns up in a couple of ways. 17:06:33 ...Sometimes as a tag with angle brackets and sometimes as free text in the styling. 17:06:50 ...I find myself wondering how much different these two cases are. 17:07:10 Noah: I've been pushing on the special case of markup too. I think we should just talk about strings first and treat markup as a special case. 17:07:50 Stuart: What I came to has the feeling that the style language is a bit of a meta language. It introduces new vocabulary. I wonder if the more generic thing is to look at languages that can introduce new vocabulary. 17:08:00 Well, maybe not "just" strings, but I have said I tnink there's value in thinking about the general text case early in the game. Still, there's a lot about markup and other regular tagged structures that's special and important for versioning, I think. 17:08:22 Stuart: We provide ourselves with factories for adding new vocabulary. 17:08:30 q? 17:08:33 ack Stuart 17:08:35 ack me 17:08:38 ack d 17:08:58 David: I really think that this is good. The issues around generality are exactly right. 17:09:40 ...If you're going to have a bare bones strategy, ignoring unknowns looks promising, but then you have to answer the question about what ignore means and what unknown means. 17:09:51 DO: We're on the issue of "just what do we mean by ignore"? 17:10:08 Yes, exactly Dave. 17:10:16 David: Ignore is basically shorthand for "don't break under validation" 17:10:31 ...If you get some extra stuff that you don't know about, the one restriction you have is that you can't break under validation. 17:10:42 Not sure I'd put it that way. I think the word "ignore" is very misleading for that. "Accept" is perfect for it. 17:10:42 ...So HTML ignores it, but retains it for styling. 17:10:55 I like: "Accept, but with a generic semantic." 17:11:37 David: It's really scoping the meaning to "don't fail validation". Once you've determined that something is unknown, you have to decide what to do with it. Early versions of HTML used to discard unknowns. 17:11:44 q? 17:11:59 q+ to say "ignore and retain is oxymoronic" 17:12:26 ...Now the DOM retains them. There are at least three flavors: ignore and discard subtree; ignore and retain subtree; ignore and preserve. 17:12:42 ack Noah 17:12:42 Noah, you wanted to say "ignore and retain is oxymoronic" 17:12:42 ...Two of these are in the finding, but the preserve case isn't really talked about that much. 17:13:20 Noah: I like the whole meat of where we're going, the problem I have is about talking about ignoring and maintaining. I think maybe we're trying to work to hard to preserve the word ignore. 17:13:25 "Must Accept Unknowns"? 17:13:43 ...Maybe "accept" is a better word. You want to accept the unknowns, you're not ignoring it. 17:14:01 ...I would suggest that "ignore" be reserved for the special case where there really is an equivalence with a document where it wasn't really there. 17:14:26 ...Comments and white space, for example, are often just ignored. 17:14:51 Noah: In the "outer ring" the question is, is there a completely equivalent document in the inner ring? 17:15:10 ...Let's find the words that really describe what we mean. 17:15:17 q? 17:15:31 q+ to ask Noah about his review coment 17:15:35 Stuart: What you're proposing then is that David work this into the terminology section. 17:15:53 David: Noah, you had a bunch of stuff written on pieces of paper, do I get those? 17:16:02 Noah: Yes, I'll try before I go on vacation for two weeks (in four days) 17:16:31 David: I've got vacation plans in late July through 13 August. 17:16:36 Noah: I'll try. 17:17:39 David: I want to get this done before I go on vacation 17:17:51 ACTION: David to update terminology section 17:18:23 Topic: Vacation scheduling 17:18:35 ACTION: David to update all 3 documents in versioning finding 17:18:38 Stuart: Thank you for filling in the form, but the database is down today. 17:19:08 Henry: Database updating today, wait until tomorrow. 17:19:15 Topic: Future directions 17:20:27 Stuart: We started this in Mountain View. Should we try to continue now? 17:20:35 David: Yes. 17:20:53 Stuart: So how do folks think Web 2.0 changes things? 17:21:04 David: We had an outline at Google, right? 17:21:09 http://www.w3.org/2001/tag/2007/05/webarch2-outline 17:21:35 David: I think we've touched on one of the things, the incredibly heavy use of JavaScript means that browsers don't have to rev so often. 17:22:02 Raman: You can view this as the browsers have essentially frozen. There's a turing complete language in the browser, so that's where all the development takes place. 17:22:07 Well, seems to me like a bit of hype around "Rule of Least Power" wouldn't hurt. 17:22:10 David: So then you look at the frameworks liek DoJo. 17:22:52 Raman: Everything is being implemented at the document level. What would this have looked like in '94? You probably wouldn't have something fundamental like httpRequest and Post. Scripters would have invented that themselves. 17:23:23 ...Because the GET and POST framework exists, that's what got used. But extending vocabularies aren't extending those frameworks anymore, it all depends on the particular libraries that you use. 17:23:50 q? 17:23:53 David: I think that this all had to happen in the order it did, you need the simplicity and rigor of the uniform interface and REST in order to provide a platform for the JavaScript. You needed the browser to be in every desktop. 17:23:59 ack dorchard 17:23:59 dorchard, you wanted to ask Noah about his review coment 17:24:07 q+ to say, what do we need beyond rule of least power? 17:24:17 David: People didn't have GUI desktops in '94. 17:24:33 ack noah 17:24:33 Noah, you wanted to say, what do we need beyond rule of least power? 17:24:54 Noah: I think this is interesting and important. But we already have findings that take a position on some of these issues. 17:25:25 ...The least power finding talks about some of these tradeoffs. Maybe part of what we want to do is refer to that. 17:25:40 ...We also have a finding that talks about using the HTTP verbs correctly. 17:26:14 Noah: Google maps is madly doing GETs and POSTS but you don't get a constantly updated URI. 17:26:49 ...I think we have some of the important pieces and findings already. How do we get people to have the right discussion about these issues with respect to Web 2.0. 17:27:09 Stuart: Does anything fundamentally change about the nature of a resource? 17:28:43 Raman: I think that has happened. The intermediate stages no longer have a URI; the apps are more RESTful than web services, the use URIs intelligently but they don't use it everywhere. 17:28:59 ...The app developer decides which parts of the state are exposed in URIs. The ones that aren't, just aren't available. 17:29:08 I agree that the Web 2.0 stuff is in many cases more RESTful than most Web services. In many cases, though, the user agent doesn't make it easy to show the user the continually changing URI for what they're looking at. 17:29:33 If the typical user can't get it, then he or she can't bookmark it, email it, etc. 17:30:03 Raman: In the early world, there was a clean 1:1 mapping between state and URI; now that's up to the app developer. 17:30:14 Noah: My personal feeling is that the value of URIs haven't changed. 17:30:35 Raman: I'm not sure there's a right or wrong, all we can do is list pros and cons. 17:30:56 Noah: Yeah, but that's true of the whole web arch, but we don't say that, we say SHOULD and MUST. 17:31:33 Noah: Being a sophisticated user, I know how to use the "bookmark this" link. I think the fraction of users that get it is probably low. I wonder if osme of that isn't matter of user agents just not making it easier to get continuous update. 17:31:44 s/isn't matter/isn't a matter/ 17:32:00 Noah: I think it's valuable to be able to mail the link. 17:33:10 ...It's worth addressing, I think. 17:33:14 Stuart: We're out of time. 17:33:20 Topic: Any other business. 17:33:31 Stuart: If you have items for next week's agenda, please send them to me. 17:33:36 Thanks and we're adjourned. 17:33:41 -DOrchard 17:33:42 -Rhys_Lewis 17:33:43 -Norm 17:33:44 -Ht 17:33:44 -Stuart 17:34:07 rrsagent, set logs world-visible 17:34:11 rrsagent, draft minutes 17:34:11 I have made the request to generate http://www.w3.org/2007/06/25-tagmem-minutes.html Norm 17:34:42 -Noah_Mendelsohn 17:35:18 Stuart has left #tagmem 17:39:10 Norm has joined #tagmem 17:39:43 disconnecting the lone participant, Raman, in TAG_Weekly()12:00PM 17:39:46 TAG_Weekly()12:00PM has ended 17:39:48 Attendees were Norm, Rhys_Lewis, Stuart, Noah_Mendelsohn, Raman, Ht, DOrchard, Ed_Rice 17:40:00 rrsagent, pointer? 17:40:00 See http://www.w3.org/2007/06/25-tagmem-irc#T17-40-00 17:41:13 trackbot-ng has joined #tagmem 17:41:19 Tracking ISSUEs and ACTIONs from http://www.w3.org/2001/tag/group/track/