See also: IRC log
<scribe> scribenick: noah
<scribe> scribe: Noah Mendelsohn
date: 28 August 2008
<DanC> +1 approve http://www.w3.org/2008/07/24-tagmem-minutes
SW: Proposal to approve minutes of 24 July 2008 at http://www.w3.org/2008/07/24-tagmem-minutes . Any objections?
Silence.
RESOLUTION: The minutes of 24 July 2008 at http://www.w3.org/2008/07/24-tagmem-minutes are approved.
SW: Next telecon will be in one week on 4 Sept.
DC: I can scribe.
NM: I am at risk for 4 Sept. In all day meetings. Will see if I can slip away.
SW: We have 4 requests for review: 1) content transformation guildlines, citing our work on generic resources. Anyone else noticed that request?
NW: I have not, but I will try and answer next week.
<Norm> ACTION: Norm to review "Content Transformation Guidelines" and suggest whether the TAG should provide an official comment [recorded in http://www.w3.org/2008/08/28-tagmem-irc]
<trackbot> Sorry, couldn't find user - Norm
SW: 2) CURIE syntax is in last call. They are aware of our prior comments, did not explicitly invite us, but are being very helpful in stretching the review period, etc. Anyone want to comment?
<DanC> (I looked at noah's comments; I don't recall anything critical)
NM: I sent a note on my own behalf at http://lists.w3.org/Archives/Public/www-tag/2008Aug/0006.html . Was to www-tag and some members of the CURIE group. Among the significant issues was whether CURIEs can be used in places where existing specifications call for URIs.
<jar> what about xml datatype specifications for curies?
<scribe> ACTION: Noah to coordinate response to CURIE last call (with help from Ashok) [recorded in http://www.w3.org/2008/08/28-tagmem-irc]
<trackbot> Created ACTION-170 - Coordinate response to CURIE last call (with help from Ashok) [on Noah Mendelsohn - due 2008-09-04].
SW: Note Henry has had interest in the past.
HT: I'll check syntax.
<jar> I will try to contribute to Noah's effort - I have had an exchange with the RDFa folks around CURIEs
<DanC> (does anybody know if RDFa ended up using CURIEs in href?)
SW: We need to think about contributing to discussions of Web Service activity recharterin
<DanC> ACTION: DanC to coordinate response regarding WS-* inquiry from PLH [recorded in http://www.w3.org/2008/08/28-tagmem-irc]
<trackbot> Created ACTION-171 - Coordinate response regarding WS-* inquiry from PLH [on Dan Connolly - due 2008-09-04].
<timbl> i will
SW: Who will be there?
<timbl> raman: yes
DO: No.
TBL: yes
HT: Thurs and Friday
TVR: Yes
NW: Yes
SKW: Trying to decide
AM: Yes
JAR: No
<DanC> DanC: yes
DC: Yes
<DanC> XHTML2 re CURIEs
TVR: The XHTML Group is meeting. Might be a chance to sync up on CURIE. I personally don't have concerns, but other TAG members may have concerns.
SW: If you know of other working groups with whom we should meet, please let me know.
SW: We have already decided that tagSoupIntegration-54 is a high priority, and we have at least tentatively proposed 1/2 of our time on that. At my request, Raman sketched a proposed agenda. We need to discuss that proposal. We also have a day and a half on other things.
DO: I would still like to finalize passwords in the clear and versioning compatibility strategies. Would hope to have drafts in a week or so.
<Zakim> jar, you wanted to say POWDER WG has asked me for my comments
JAR: (going back to previous discussion) Someone on the POWDER group asked me to look at their specs, which I think are in Last Call.
TVR: I don't see a TAG issue wrt/ POWDER.
<Zakim> noah, you wanted to mention self describing Web on agenda
NM: I'm hoping to publish Self-Describing Web after KC. At Bristol SDW was on the agenda, but nobody had read it. Norm and Stuart took actions to read over the summer. Norm's review seems to indicate that it's about ready to go, Stuart expects to read it soon. At least two issues are known to be outstanding:
... 1) The figure in the appendix needed cleanup, and Norm has taken a cut at that (thanks Norm!)
... 2) I believe the TAG asked in Bristol that I tell the RDFa follow your nose story as XHTML Media Type Spec -> XHTML Modularization -> XHTML Namespace Document (revised) -> RDFa. When I check the RFC for the XHTML media type (http://www.rfc-editor.org/rfc/rfc3236.txt ), it does not normatively reference M12N, though it does allude to it informally in passing. I have requested help from the TAG and others to figure out how best to proceed (see thread at http://lists.w3.org/Archives/Public/www-tag/2008Aug/0116.html ).
<timbl> Which specs -- rdfa?
<timbl> did you have a disconnect on,nm?
<DanC> (I don't understand the follow-your-nose story for RDFa yet either)
<timbl> Sometimes HTML behavior for RDF things is defined on XHTML and then doen in HTML by analogy
NM: I would be very grateful if some TAG members could look over the recent email thread on M12N and help me figure out where the story's gone wrong?
TVR: Regarding the F2F agenda for tag soup, I don't think we can address all of the key issues, so I picked 4 that I thought were clearly above the threshold regarding important. I think we also need to look at bigger issues. So, in the first 1 1/2 hours I propose that we address those broader question, and then address the 4 chosen issues in light of that, then wrap up in last session in context of big picture.
<Zakim> noah, you wanted to talk about Raman's draft for the agenda
NM: I think the community looks to the TAG to explain the Web's architecture and proper use. Right now it looks like HTML5 and XHTML (e.g. in mobile and ATOM) will coexist in the marketplace. Thus, goal we should consider is to explain to the community when to use one, when to use the other, how they interoperate, etc. If we can succeed in showing the community how to avoid that split, so much the better, but even if the architecture turns out to be messy we have an obligation to help users understand it. I think we should spend some time in the first session discussing goals like that, then make sure that the agenda for other sessions fits the goals. Discussion of the technical issues is important, but I'd be dissapointed if all we did was to noodle on selected technical issues.
TBL: Philippe le Hegaret is trying to focus in part on the social issues around this, and I think we need to do that too.
... I think that brainstorming about the rift in the community might be the biggest thing we could do.
<noah_> That's exactly what I was saying.
<Zakim> ht, you wanted to recall Raman's observation wrt Tim's point
TVR: I need to have my mind changed about the possibility that the XHTML track is in some sense dead.
HT: To some degree, +1.
<timbl> TimBL: The scoial issues here in the various communities are realuy impoprtant and we must understand them before we prevaracate technically.
HT: I think the question of "is there a saleable solution" as opposed to "is there a solution" is worth some of our time. It's worth noting that, while we didn't have much actual impact, is that we did some work on not just the technology but also the practicality of rolling out our preferred solution wrt ARIA.
SW: Should we rebuild the agenda?
TVR: Suggest we keep the agenda, but base the technical discussion on where we are coming out of the first session.
... I think it's critical that the F2F be effective on the social issues. We can start with that and go over to 2 hours if necessary, but I don't want it to fill the whole thing. We should roughly stick with it.
NM: We should take the agenda as tentative, but give ourselves permission to rearrange the schedule based on insights from the first session.
TVR: I'd go further -- if the first session doesn't yield clarity, we should punt on the rest.
TBL: From both the social and technical point of view, we want to understand the potential damage of each way of going forward. I would be happy to devote the time to prove that we can "fix the fork", which means diving deep to find and tackle the insuperable issues in achieving that.
SW: My inclination is to go ahead with the agenda more or less as Raman has suggested, with a degree of flexibility to adapt.
NM: That sounds fine to me.
TVR: Yes, as long as people understand that the proposal is not to first discuss high level issues and then to have a disconnected discussion of the technical bits.
SW: We had a catchup meetings with some of the XRI chairs. My perception is that they are quite happy with the nature of the dialog. They suggest focus on 4 topics:
SW: I think the ball was in their court to do the initial writing, but there's probably an implicit need for us to ramp up effort on URNS and registries.
HT: Have had some trouble cranking up on this. Will let you know later this week what I propose to do.
<DanC> (review what? )
SW: If we take the trouble to do this, it will help us to be sure that our perspective on the story is clearly articulated.
JAR: I will be glad to help Henry with his work in the area of URNs, registries, etc.
SW: Dave, I think are you done with your action items? There was also email discussion.
DO: I've been pretty much 'offline' over the summer, just getting back up to speed.
<DanC> http://www.ietf.org/internet-drafts/draft-ietf-httpbis-security-properties-02.txt
DC: Talked to Thomas Roessler. Ignoring the bits about digest, the finding seems to mostly say: "use SSL". I'm beginning to wonder why I pushed us to do this in the first place.
<noah_> I've always shared that reservation about that work in this space. It's not clear to me that we really know what we're trying to prohibit and when.
SW: Are we trying to address the concern that a naive user doesn't understand the risk, especially if the same password is used in multiple contexts?
DO: One concern from the security context WG has been to discourage pwds in the clear or even short pwds at all.
NM: Some time ago we talked about the many Web pages that are themselves not SSL-protected, but that use Javascript to encrypt passwords collected from those pages. Am I right that in the face of DNS cache polution, I could wind up giving my password to a malicious site?
<DanC> (yes, cache pollution increases the risk of phishing)
<DanC> (a great reference on DNS cache pollution: http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html )
DO: Sounds like a risk to me.
TVR: Classic man in the middle attack, what's surprising?
<DanC> (re man-in-the-middle, https's reliance on dns has always given me the willies. see http://www.waterken.com/dev/YURL/httpsy/ for a good idea, though it never got far.)
NM: Yes, but it's a very common idiom on the Web, and we didn't tell the story.
SW: Do we reset? Punt?
DO: No, I still believe in doing a finding that tells how to do secure interactions using pwds.
<jar> who was the original client for this finding?
DO: Experts like Dan know what to worry about; novices don't.
<noah_> Yes, Dan, but with HTTPS the certificate check should give you a crosscheck if the cache has been compromised. The problem is that, if the password prompt form is http: not https:, you don't get that protection.
DC: I think it comes down to recommending TLS, doesn't it?
NM: Are you saying TLS is the right answer, or just that we should [... scribe lost the end of this, sorry.]
DC: I think the interesting case is proxying.
NM: Gee, I'm suprised, I thought that was the problem case for TLS.
<Zakim> ht, you wanted to ask a silly question
HT: Every time we try to say MUST, we can't avoid the partially validity of peoples' arguments to the contrary. The thing that really kills it for me, is when the security folks said digest isn't good enough. My feeling is that digest seems so much better than today's common practice, I wonder if we should push back on that.
<DanC> (TLS is more available than digest, in lots of practical ways.)
HT: If we say what you shouldn't do, we need to say what you should. Problem is: what works for the security "geeks" isn't available in practice, and what's available in practice doesn't pass muster with the security folks.
<jar> answer to my question above: Mary Ellen Zurko of IBM.
<jar> how about a finding that says that We Are Stuck? more like an academic report - this is what we learned. (throwing this out as option in answer to stuart's question what should we do)
<DanC> Noah, if the bad guy can poison your DNS, he can fake the whole certificate path
DO: Intereseting, we could explore the question: promote digest, explaining its risks, vs. doing no finding at all. We could work with the security community on that.
<ht> I said, roughly, we could say to the security guys -- either we just say "DOn't use PW in the clear" and leave it at that, or we say nothing
<ht> If they said "nothing", then fine, we're done, no finding
TVR: Are documents like this suitable as TAG findings given that the issues keep changing? We could have frozen last year, and probably would not have anticipated the cache polution issue that Noah just mentioned.
<Ashok> How about renaming the finding to "How to do Secure Authentication"?
TVR: I feel somewhat the same about the versioning work, by the way. It has the characteristic that we keep finding new stories that need to be told.
DC: What are you recommending?
TVR: We should reconsider what a TAG finding is. Should allow ourselves to publish things that we know will change.
SW: They already are like that. The problem is articulating what we have consensus on right now.
<ht> "Don't send PW in the clear. ROT13 is only a bit better, Digest is quite a lot better, but, above all, DON'T send PW in the clear"
<ht> That's my candidate for the finding
DO: I think we need to reflect consensus in the moment, but I have no problem with either errata or major revisions later.
<jar> a "here is what we learned" memo is another possible alternative to "no finding" and "here is the truth"
SW: We'll revisit at the face to face.
<ht> jar++
<ht> Hold that thought, Jonathan!
SW: Dan, would you remind us of the motivation?
DC: E.g. in the latest IE8 beta there's the authoritative=true, and also the content type sniffing rules in HTML 5.
TBL: Looking for pointers.
HT: In the agenda
<timbl> "authoritative=true" is so sad in a way!
<timbl> http://www.w3.org/QA/2008/07/life_without_mime_type_sniffin
<jar> it should be "true=true"
HT: I learned some things preparing for today's call. Turns out the main issue, I hadn't noticed, is what you do with things that are served text/plain. The other thing I hadn't noticed is that many servers default to text/plain when they don't know what else to do.
TBL: Yes.
<DanC> (hmm... I'm not so sure text/plain is the main thing; I seem to recall hixie saying html5 always says to treat text/plain as text/plain.)
HT: I just didn't know that. Maybe everyone else has known this all along.
TVR: It's evolved over time. Servers started doing this, then browsers started sniffing.
TBL: In part came from trying to serve things like README files from Unix, and in that case text/plain is a good guess. Not serving any content-type seems like a plausible approach suggested by Roy Fielding
HT: You can do that only in newer Apache. On the broader issue, I see no consensus.
<timbl> http://www.w3.org/QA/2008/07/life_without_mime_type_sniffin
DC: I think our finding makes us look silly. We should perhaps update the finding to reflect the current state of the art.
<jar> yes
SW: Do we want to reopen contentTypeOverride-24 to potentially reconsider our position?
TBL: I'm happy to reopen it. I would not include the part about reconsidering our position.
SW: Didn't mean to imply we would be predisposed to change our position.
HT: Let's just reopen the issue. Period.
SW: Anyone opposed reopening the issue?
SILENCE.
SW: Abstain?
SILENCE.
RESOLUTION: Issue contentTypeOverride-24 is reopened.
<scribe> ACTION: Henry to craft a message to www-tag announcing reopening of contentTypeOverride-24 ( [recorded in http://www.w3.org/2008/08/28-tagmem-irc]
<trackbot> Created ACTION-172 - Craft a message to www-tag announcing reopenning of contentTypeOverride-24 ( [on Henry S. Thompson - due 2008-09-04].
SW: We are adjourned.