RESOLUTION: The minutes from 17 April 2008 at http://www.w3.org/2001/tag/2008/04/17-tagmem-minutes are accepted
SW: Henry, can you scribe next week?
HT: Yes, but will have to leave somewhat early.
SW: Propose we meet 8 May, any regrets?
SW: We have received responses to our comments. They have a new working draft out and are planning to go to last call soon. Maybe we pick up with our comments when they go to last call?
HT: I did review their responses, and I felt that they might have done more to directly engage the substance behind our comments. I read between the lines that they do see these being used in at least most places URIs are allowed. I agree, we should respond, if at all, when they go to last call.
DC: I generally feel that delaying comments to last call is to be avoided if we can comment before last call.
HT: I infer they're going to Last Call within a couple of days.
SW: They have fixed some of the errors we commented on.
HT: Yes, and they acted on some of our minor comments. I'm not happy that they continue to support the use of unprefixed CURIEs.
<DanC> "The final decision fell to the current syntax because" hmm... no pointer to decision record.
SW: I guess we've discussed as much as we should now, and we'll look out for their last call.
<DanC> (I would have liked to swap in one specific example of curie syntax that we're commenting about; unprefixed curies sounds like one to look at closely)
SW: We sent some comments on how to resolve XRIs. Both Norm and I had actions to review the response from the XRI group. I did a review, but don't think Norm got to it. Should we withdraw Norm's action?
NW: I saw your earlier proposal to withdraw and have stopped working on this.
<DanC> close ACTION-124
<trackbot-ng> ACTION-124 Review XRI response to our questions closed
SW: We'll withdraw Norm's action. I think the most important response we didn't get was on whether they plan to register xri: as a URI scheme.
HT: I haven't been watching their calendar, but did check their public mailing list week. I believe they've decided to go their equivalent of Last Call. So, I think that "this hole is dry". I think their response on the first question was exceptionally detailed, but I read it as netting out to "yes", plus a defense of the merits of HTTP caching.
DC: Henry, are you suggesting we're done or we should keep talking?
HT: Suggesting done with XRIs, continue focus on URNS and Registries.
DC: XRIs are still out there. Remind me why we engaged in the first place?
HT: We thought it was an important example of a situation where just using http: would be better. Their spec. has gotten much more complete during the past 18 months. I suggest that the finding will be the place to give further advice.
DC: It will say: "XRI doesn't follow our advice?
HT: We'll have to decide whether that's the appropriate thing to say.
SW: But XRI isn't a URI scheme (yet).
HT: But it looks like, dances, like, etc.
<DanC> (I think the most recent time XRI crossed my radar was w.r.t. OAuth... searching...)
SW: But their structured syntax goes beyond what can be expressed in URIs.
HT: So do IRIs. They have a story about how to map them.
TBL: I think they are effectively being used as URIs, whether they strictly match the syntax or not.
AM: They spell out that the value space is URIs. It is explicitly a different syntax for URIs.
<Zakim> DanC, you wanted to note the example of <XRDS xmlns="xri://$xrds"> in http://oauth.net/discovery/
DC: It's being used in the oauth spec. xrds is something like eXtensible Resource Discovery. oauth is a sort of Kerberos-like thing that substitutes for, e.g. your Google password.
HT: Haven't noticed it.
DC: This deals especially with the situation where, e.g., some 2nd sites wants your Flickr password so that it can add value to you Flickr photos. Actually, I'm not quite sure it's specifically Kerberos-like, may just be redirects.
NW: They seem to be emphasizing deployment through oauth, open-id, etc.
DC: Not sure how much XRIs in OpenID is widely deployed.
SW: We'll come back to URNs and Registries at the F2F. Hmm. David's still not here, let's turn to Tag Soup.
(David Orchard joins the call)
SW: Henry, do we want to talk about namespace support in browsers?
HT: Yes, at some point.
SW: I thought we were close to consensus, but seem to have stepped back a bit.
HT: I was opposed to seeing another extensibility mechanism that didn't use namespaces, and that introduced a near equivalent using hyphens. So, I spent some time the past 3 weeks figuring out how this came to be. First I discovered that there were flaws in some of the test cases that motivated the ARIA group's thinkings. In some cases, they mistakenly concluded that certain browsers would have trouble with colons. I wrote some new test cases suggesting that the tradeoffs were much closer to a wash. Since then, I've been trying to get as thorough analysis of the cost/benefits of various choices as I could. I'm working on a document, but it's not ready for public review.
<ht> elt[a:b] is not a valid CSS for any IE browser
HT: elt[a:b] is not a valid CSS for any IE browser
SW: I would like to wrap this up by our F2F, if not before.
HT: I agree. I hope to bring something out by Wed.
TBL: I think it would be good for Henry to be in touch with the concerned people in the Aria community.
HT: I'm already communicating with them regularly. I have some impression that the HTML-5 folks are somewhat unhappy for a different reason, I.e. that they don't want to support the ":" at all.
TBL: They don't want to absorb Aria?
HT: No, not that they don't want Aria at all. The current Aria draft has a hybrid approach: you use ":" and real XML namespaces when XML is being used, and - otherwise. The HTML 5-involved people that I've spoken with don't want to see the ":"/namespaces option at all.
<Zakim> ht, you wanted to discuss (for the record) the impact of existing ARIA implementations
HT: Some suggestions have been made about separating the extensibility question from the Aria question, but I'm not sure that we can. Responding to Noah's concern that there are existing implementations of Aria. I think that remains somewhat murky. I don't think implementations need to support Aria at the syntactic level at all. They need to route Aria state and properties through the accessibility APIs.
<noah_> (Noah is confused: if you don't understand xmlns:, then how do you even known that Aria is being used at all if ":" is employed?)
HT: So, I'm not quite convinced that the implications of the current investment in implementations is clear. Answering Noah's question from IRC: Aria conformance requires user agents to do things through the accessibility apis, regardless of syntax.
NM: Let's sort it out in email.
<DanC> (I think HT is saying that the dev cost of switching from - to : is small, though I think the interface-change-cost is higher; changing the way authors write them)
AM: I was about to write an email saying pretty much what Noah said in his (I.e. we should be sensitive to the implementation investment), and I started asking myself: why do we notice these concerns so late?
<noah_> Dan...that may be true, but I would have thought that binding the prefixes through xmlns: is in some sense nontrivial.
TBL: I thought the WG had decided to take out the option of allowing ":".
HT: I'm not aware of such a change. I base that not just on the specification but also on the emails we've exchanged with Michael Cooper and Al Gilman
TBL: Henry, you've said you can't live with "-".
HT: That seems to me to have a heavy cost. So far, I'm not convinced the benefits outweight the cost. I'm still working on it. If the TAG says they want to wrap up, I'll step out of the way, but gee, this is only the first working draft that we're responding to, right? I think it's reasonable to spend weeks or even small numbers of months getting this right. We as W3C have tried to say many times that we will not let premature implementations dictate architectural choices.
DC: Well, we actually try to take all market factors into consideration.
TBL: Yes, we try to give a lot of weight to people who actually implement. Assume for the moment is that the proposal is in fact to have "aria-" everywhere in the HTML namespace.
HT: It gets added to the SVG namespace, the forms namespace, possibly MathML, and maybe others. The reason they did the hybrid design is that they knew it wasn't tractable to ask SVG to extend in that way.
<DanC> (I don't think FBML will need it; that's not hypertext markup, but yes, aria-* is proposed for svg/mathml/xforms)
HT: I would like more information, which I'm working on getting, on what the actual degree of impact on existing implementations would be.
SW: Why are CSS selectors important in this?
<Zakim> DanC, you wanted to note aria-* is not normative in current drafts; "This is not a conformance requirement, but a request to enhance compatibility." --
DC: The 4 Feb. Aria has a section I'd like you to look at. See: http://www.w3.org/TR/2008/WD-wai-aria-20080204/#implementation
TBL: This is the first working draft?
DC: Well, but there were precursor drafts that were later sliced into different pieces.
<DanC> 1st was sep 2006 http://www.w3.org/TR/2006/WD-aria-role-20060926/
DC: WAI roles went back to Sept. 2006
HT: But it didn't have this problem?
DC: It didn't?
TBL: A different and perhaps worse problem. They originally had an ordered set of tokens in the class field. First of all, class is already unordered. I suggested they use attributes and this is the result.
DC: From that "To support compatibility with future versions of ARIA, attribute names beginning with 'aria-' should be treated as reserved in host languages likely to use ARIA. This is not a conformance requirement, but a request to enhance compatibility."
<DanC> " Timeline for the Dynamic Accessible Web Content Roadmap "
DC: Tim challenged them to tell the story of how this all plays out. I think they did at: http://www.w3.org/TR/wai-aria-roadmap/ .
HT: The very first paragraphs says that they're doing this two ways.
DC: You won't find aria- in current drafts.
HT: The test material in the roadmap is full of aria-.
NM: So they don't quite in the current draft say "use aria-role", but the roadmap and test cases clearly imply that's where they're going.?
HT: Yes, right.
<DanC> 1st example I find in the primer is <div role="menu"> http://www.w3.org/TR/2008/WD-wai-aria-primer-20080204/
HT: They do ask us to look at the primer, and that widely uses aria-.
<DanC> a... indeed... <div role="menu" aria-haspopup="true">
HT: Search, e.g. for aria-haspopup.
SW: Where is this taking us to?
DC: I thought I could convince myself that aria- wasn't in current drafts, but Henry shakes my confidence.
SW: Put it down for a week?
TBL: Henry will continue his investigation?
<DanC> (hmm... above that aria-haspopup example it says "To pull in this information we again use namepaces to extend XHTML. " Color me befuddled and perflexed.)
HT: Yes, more fact finding next week. I think I'm getting close to the truth on what works with ":" I will publish by next Wed. regardless of the condition it's in.
TBL: That's fine.
<timbl> We have lost audio from DavidO
SW: Dave, you did a rewrite. Did you ask those who had commented earlier whether they were happy with the changes?
<DanC> DO: no, haven't gotten back to the commentors; wanted to check with the TAG 1st
DO: No, I didn't have consensus from the TAG that this represented our opinions.
<ht> Hal Lockhart++
DO: What I did in the rewrite was roughly what we talked about. I had an action item to talk to security folks about digest. Instead, I spoke to Hal Lockhart, who was very helpful. I changed SHOULD NOT send passwords in the clear to MUST NOT. I also added some warning flags around digest. I understand the dictionary attacks much better, and why nonces don't help this (because they're transmitted in the message.) Man in the middle can also degrade quality of service from digest to effectively basic. I did not go as far as the security folks want in saying MUST NOT use digest. I still think it's better than basic. I think security is all about tradeoffs. Just saying "Use SSL" is too simple and not in all scenarios appropriate. I also added a warning about incorrect use of SSL, alerting to need for forms themselves to use SSL. I'm glad to send it along to the security context WG if the TAG gives me instruction to do so. Also, my action has been superceded.
<ht> DanC, everyone -- I finally found the WAI PF document which has the test pointers: http://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/
<Stuart> close ACTION-134
<trackbot-ng> ACTION-134 Ask security context about the exact breakage of digest closed
<Zakim> noah, you wanted to ask implications of current Aria text. and to ask question about strong passwords.
<Stuart> close ACTION-135
<trackbot-ng> ACTION-135 Make the change to passwords MUST NOT be sent in the clear closed
<ht> That ARIA Practices document is full of aria-, with some aaa: as well
<DanC> (not to mention div/@role)
<DanC> (I don't see the test pointers yet, though)
<DanC> (ah... Reference 9: HTML tree -> http://www.mozilla.org/access/dhtml/tree )
NM: Is digest vulnerable if your password is not subject to dictionary attacks?
DO: No, I think it's strong in that case.
<timbl> I would note you can build a system whcih rejects weak passwords.
NM: Then why isn't the advice: "Digest is vulnerable in the (all too common) case where passwords are subject to dictionary attacks. Digest passwords must be suitable chosen, and digest should only be used in situations where the strength of the passwords can be assured."
<DanC> trackbot-ng, status
<scribe> ACTION: David to revise passwords in clear finding to discuss strong passwords with digest auth.
<trackbot-ng> Created ACTION-138 - Revise passwords in clear finding to discuss strong passwords with digest auth. [on David Orchard - due 2008-05-08].
<scribe> ACTION: Noah to review Dave's redraft of passwords in the clear (dealing with digest auth and strong passwords)
<trackbot-ng> Created ACTION-139 - Review Dave's redraft of passwords in the clear (dealing with digest auth and strong passwords) [on Noah Mendelsohn - due 2008-05-08].
DO: I've gotten four sets of feedback. Would like to revise the drafts, have them ready for review before F2F, and spend F2F time going over the changes. I could have a revision ready around 12-13 of May. Is that too late?
NW: If I can print before getting on the plane.
<DanC> 12 may is much better than 13 may
NM: Tight but I'll try, at least for Chapter 2. Also, everyone please plan time for review of a new draft of the Self-describing Web finding around the same time.
<scribe> ACTION: David to revise strategies part of XML Versioning finding by 13 May 2008
<trackbot-ng> Created ACTION-140 - Revise strategies part of XML Versioning finding by 13 May 2008 [on David Orchard - due 2008-05-08].
SW: Bristol agenda items urgently sought -- today's call is adjourned.