See also: IRC log
<dorchard> scribenick: dorchard
<scribe> scribe: dorchard
<ht> Call: TAG telcon
<scribe> Chair: Stuart Williams
<timbl_> DanC_lap? Tag?
RESOLUTION: minutes of Jan 31st 2008 approved
RESOLUTION: next telcon Feb 14th
Noah, HT, Ashok regrets for March 6th
<Noah> I also note that the current time came up as least objectionable.
much discussion of the scheduling
<jar> i thought about suggesting this too (different times on alternate weeks)
<ht> What about two one-hour calls?
<Norm> This is starting to consume a lot of time, I propose that Stuart run the survey again looking for two 1 hour slots
<daveorchard> scribe: daveorchard
<scribe> scribenick: daveorchard
I think we ought to couple the wbs survey with some online surveys to win facebook scratch 'n win points.
skw: Ashok will be flexible in the current slot, same for raman.
... as a group we'll commit to reviewing if it is unworkable for Ashok
RESOLUTION: keep time slot as is
discussion about how to send comments to oasis, email list vs web form.
ashok: supposedly there is a form
noah: why don't you look for the form, and if you find it, send our message in.
skw: comments are probably broader than the single document
... and we might do a review of the document collection
ht: I'll be looking into this
daveorchard: this finding is about passwords in the clear, not passwords in general
danc: the editor has considered this, i'm fine with moving on.
latest version is http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080124.html
<Noah> Looks to me like the latest undiffed is http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080124.html. The metadata in the diff URI above seems to confirm that. Right?
<Norm> ScribeNick: Norm
DO: Ashok, I think you'd be expanding the scope to talk about alternatives to passwords.
DO: I'd prefer to keep this just about passwords.
Dave describes some of the history.
DO: I'm hoping we can just do a few things and call it finished, not make it bigger.
... I think we're close to consensus on the message that's embodied in the current finding.
JR: Given that we don't know who's going to read it, perhaps a phrase or sentence in the abstract could point out that there are other alternatives.
General sounds of agreement
DO: "Note that there are technologies other than passwords for enabling the transmission of secure informaton"
<Zakim> jar, you wanted to suggest a compromise
<Noah> OK, I think the contents to http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html and http://www.w3.org/2001/tag/doc/passwordsInTheClear are now correct.
<Noah> ...and that makes the link from the list of Draft TAG Findings work too.
Stuart: My comments were mostly editorial, I'm happy to leave them to Dave's discretion.
DO: Sorry, I didn't get to them yet.
SW: With respect to the paragraph about digest authentication and salted hashes, I wasn't sure what it was trying to tell me. That might be a technical comment.
DO: I thought that was just a note of warning: digest does require that both parties have access to the same value.
... Maybe there needs to be some tie in there.
SW quotes the paragraph.
SW: I can't tell if the last part of that paragraph is a good thing or a bad thing.
DO: I think it's saying that if you come along afterwards, and you've got the password stored, and you want to talk to someone else, you can't extract the password again. Both parties have to agree up front.
... I'll check with Hal and add a sentence for clarification.
DC: I know the history. As written it sounded just written to me. Most UNIX systems store the password salted and encrypted. That's not compatible with the digest algorithm and that was a big deployment problem.
... In the digest algorithm, the server actually has to have the password.
Some additional discussion
DC: Maybe it'd be simpler to say that many systems store salted, encrypted password and those just can't be used with digest authentication.
<daveorchard> Many systems store passwords as a salted hash and it is not possible to use such passwords in digest
SW: That'd be fine, now I understand the point.
NM: I don't think it's the passwords you can't use. I think it's that it's not possible for the server to compute the digest if its passwords are stored as salted hashes.
DO: And it can't go either way, it can't digest or undigest.
SW: I had one more technical comment. On section 3, the last paragraph repeats advice and examples from section 2. I suggest deleting them, though that might make the document end abruptly.
... There's also a SHOULD good practice with some explanation about why it's a SHOULD.
... Instead, you could say "User agents MUST mask passwords with respect to their current modality"
DO: The problem is that one of our examples from the face-to-face, the Apple Wifi access I think, you have a little toggle that let's you display or not display. That works for long passwords, for example.
SW: I'm not wedded to it, I was just trying to get to something stronger than SHOULD. But I'm not going to die in a ditch for it.
DO: This is about soliciting the password, that's not quite the same as transmitting it in the clear.
... I could tie them together...
SW: I thought you were repeating the same example, but you're telling me there's a subtle difference.
DO: They're completely different in that sense.
SW: Perhaps I should have noticed that, but I didn't. Broadly, I'm happy for you to just respond how you see fit.
DO: We should solicit feedback from the security folks, what about the HTTP WG at the IETF.
SW: And HTML5, given that we're talking about form fields?
DO: And the encryption folks. Any other suggestions?
NW: That covers the folks I can think of.
<scribe> ACTION: orchard to revise the finding and publish it directly, unless he feels the need for more review before publication [recorded in http://www.w3.org/2008/02/07-tagmem-irc]
<trackbot-ng> Created ACTION-99 - Revise the finding and publish it directly, unless he feels the need for more review before publication [on David Orchard - due 2008-02-14].
<timbl_> trackbot-ng, who is here?
<scribe> ScribeNick: daveorchard
<timbl_> trackbot-ng, status?
<DanC_lap> close action-89
<trackbot-ng> ACTION-89 Note the old submission about logout button under passwordsInTheClear closed
<trackbot-ng> ACTION-25 -- T.V. Raman to summarize history of DTD/namespace/mimetype version practice, including XHTML, SOAP, and XSLT. -- due 2008-01-31 -- OPEN
planning on doing action 25 in time for reading before f2f
<Zakim> DanC_lap, you wanted to propose to witdraw the uri testing idea
ht: action 33 will hopefully be done in time for f2f
<trackbot-ng> ACTION-55 -- Dan Connolly to work with SKW on a few paragraphs of thinking around a URI testing group (IG/WG/XG?) -- due 2008-01-24 -- OPEN
<DanC_lap> close action-55
<trackbot-ng> ACTION-55 Work with SKW on a few paragraphs of thinking around a URI testing group (IG/WG/XG?) closed
<trackbot-ng> ACTION-95 -- Dan Connolly to ask SWEO working group for one week extension for review of their document -- due 2008-01-24 -- CLOSED
<trackbot-ng> ACTION-93 -- Henry S. Thompson to review EXI WDs since 20 Dec -- due 2008-01-17 -- OPEN
norm: will do 38 in time for f2f
<trackbot-ng> ACTION-92 -- Tim Berners-Lee to consider whether or not he wants to post an issue re: POWDER/rules -- due 2007-12-20 -- OPEN
ht: on 73, xhtml wg said we're going to next state in November, and then nothing happened,and then they went to next state yesterday
<DanC_lap> (norm, the db has you overdue on review of curies; my vague memory says otherwise)
<DanC_lap> close action-73
<trackbot-ng> ACTION-73 Contact the XHTML 2 WG about the fact that the TAG has been experimenting with modularisation closed
<Noah> Speaking of actions that are not quite overdue, the long-promised draft of self-describing Web is likely to be out within the next day or two.
<Noah> Should give plenty of opportunity for people to read it for the F2F.
skw: there is also a view that shows actions soon to be completed..
<scribe> agenda: Vancouver F2F Agenda Request for Agenda Items
<Zakim> Noah, you wanted to say that after we're done with the versioning thread, I'd like to mention that a self-describing Web draft should be out within a couple of days
dorchard: I like versioning, urnsregistries, web app state, web arch vol 2
noah: self-describing web draft coming out.
<DanC_lap> if the TAG is considering discussing state foo, my input is: yes please let's, and let's look at the "offline applications and data synchronization" HTML WG requirements issue <http://www.w3.org/html/wg/tracker/issues/16> while we're at it
raman: will produce something for application-state-60
<Stuart> As understand it raman will generate material for webApplicationState-60 in advance of the F2F.
noah: what about dave's work on state?
<DanC_lap> Noah, I don't know the relationship between the HTML WG state work and Dave's drafts; that's why I want ftf discussion.
<Stuart> In the earlier conversation Dave and I thought we were talking about ACTION-25 and Raman thought we were talking about ACTION-91.
<Stuart> I believe that we have already agreed to close ACTION-25 with reference to Norm's bog article on implit namespaces.
<Stuart> close action-25
<trackbot-ng> ACTION-25 summarize history of DTD/namespace/mimetype version practice, including XHTML, SOAP, and XSLT. closed
does norm's blog cover all of action 25?
raman: offline gives you the possibility of doing asynch other than xmlhttprequest
... asynch ala email
noah: if you step back far enough and look at offline systems
... the webby systems seem to have assymetric state, where the state lives in the web
... vs systems like Notes where the client has fully featured state.
skw: jar, can we bring aswww to table?
skw: I'll add that to the f2f agenda
tbl: wonder how long awwsw should be separate and when to surface
<DanC_lap> (a 5 to 10 minute present-only update on AWWSW would work for me.)
jar: the kinds of confusions we have are interesting
I'm interested in this, and would be glad to hear about confusions, 30, 60 mins or more.
<DanC_lap> (I'm happy to spend 3 days in AWWSW ;-)
(I wonder when the TAG will become WWSWAG?) :-)
<Norm> The best way to get from YVR to the Opus is a cab, right?