W3C

Technical Architecture Group Teleconference

18 Feb 2010

Agenda

See also: IRC log

Attendees

Present
Raman, DanC, Jonathan_Rees, Ashok_Malhotra, noah, John_Kemp, htt, Larry
Regrets
Dan_Appelquist, Tim_Berners-Lee
Chair
noah
Scribe
DanC

Contents


<trackbot> Date: 18 February 2010

<scribe> scribe: DanC

Convene, review agenda

+1 approve http://www.w3.org/2001/tag/2010/02/11-minutes

<jar> +1 approve

RESOLVED to approve http://www.w3.org/2001/tag/2010/02/11-minutes

NM points out a few admin items (see agenda)

JAR: ftf prep material due date?

action-391?

<trackbot> ACTION-391 -- Noah Mendelsohn to prepare March 2010 ftf agenda -- due 2010-03-08 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/391

<jar> agenda input by the 8th, reading material the 15th

ACTION-391: reading material due 15 March

<trackbot> ACTION-391 Prepare March 2010 ftf agenda notes added

action-332?

<trackbot> ACTION-332 -- Dan Connolly to note that the HTML 5 spec has a proposed design for mixing in SVG and MathML, which is said to be the scope of IsSUE-33 mixedUIXMLNamespace-33 -- due 2010-02-25 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2001/tag/group/track/actions/332

DanC notes the agenda is due at T-2 weeks, 10 March.

version indicators, esp in HTML 5

issue-41?

<trackbot> ISSUE-41 -- What are good practices for designing extensible languages and for handling versioning? -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/issues/41

<noah> Actually, the topic is specifically Larry's proposal

action-388?

<trackbot> ACTION-388 -- Jonathan Rees to take a look at LMM's doctype/versioning proposal http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html -- due 2010-02-11 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2001/tag/group/track/actions/388

close action-388

<trackbot> ACTION-388 Take a look at LMM's doctype/versioning proposal http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html closed

NM notes "HTML WG chair has requested that the TAG and HTML WG coordinate scheduling of work on this"

(quoting from the agenda)

<noah> Larry email: http://lists.w3.org/Archives/Public/www-tag/2010Feb/0140.html

<noah> http://lists.w3.org/Archives/Public/www-tag/2010Feb/0143.html

<noah> DC: We already did polyglot documents to my satisfaction, and I believe Henry's, no?

<jar> nm: 1. Engage as TAG re polyglot docs?

LMM: while yes, part of the issue of polyglot documents has been dealt with...

<noah> LM: This would make more polylot docs

<noah> DC: I'm aware of that

LMM: there are documents that are conforming XHTML that have doctypes that the HTML 5 spec prohibits (or shuns)

<noah> LM: The browswers have to accept them, but not label them conforming

<Zakim> ht, you wanted to separate the two issues

HT: for [various?] reasons... I think the place to pursue this is around the media type, version indicator and conformant document issues

(polyglot document issue? help? is there actually such an issue?)

<jar> ht: Polyglot docs is a red herring in this discussion

<noah> From our agenda for today: This relates to Larry Masinter's HTML WG ACTION - 172, which is associated with HTML WG ISSUE - 4: HTML Versioning and DOCTYPEs and HTML WG ISSUE - 84: Should spec discourage use of "legacy" doctypes? (HTML WG chair has requested that the TAG and HTML WG coordinate scheduling of work on this)

<noah> DC: Is there a polyglot doc issue?

<noah> NM: On the TAG side or HTML?

<noah> DC: Either.\

<noah> ]

<noah> HT: It was an HTML issue, we discussed in Santa Clara, and Ian Hickson made a change.

-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8154 Make it clear that serving polyglot documents as text/htm...

http://lists.w3.org/Archives/Public/www-tag/2010Feb/0008.html

^ part of a thread on Backward-compatibility of text/html media type (ACTION-334, ACTION-364)

HT: last time I looked into this, what the HTML 5 spec said about MIME types and DTDs wasn't acceptable

<noah> HT: See my email at http://lists.w3.org/Archives/Public/www-tag/2010Feb/0008.html

action-364?

<trackbot> ACTION-364 -- Dan Connolly to ask HTML WG team contacts to make a change proposal re issue-53 mediatypereg informed by HT's analysis and today's discussion -- due 2010-02-18 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/364

HT: looking at the 15 Feb version, I see lots of changes w.r.t. last time I looked...

<noah> Dan, is the phrase "informed by HT's analysis" a reference to 2010Feb/0008?

<noah> HT: (looking at HTML spec) What happened to all the text that was there on DOCTYPEs a few weeks ago?

<noah> Can we have a link to the latest, please?

<noah> HT: Seems to have gone back to status quo ante.

HT: it seems to have gone back to "you can't have any[?] DOCTYPE"

from /html/wg/ I get to http://dev.w3.org/html5/spec/ dated 18 February 2010

<noah> Is it this section: http://dev.w3.org/html5/spec/syntax.html#the-doctype ?

-> http://dev.w3.org/html5/spec/syntax.html#the-doctype 8.1.1 The DOCTYPE

<noah> HT: Most of what I commented on is no longer here.

<noah> HT: Ah, where my email refered to 7.2.5.4, now reference 8.2.5.4

8.2.5.4 The "initial" insertion mode "obsolete permitted DOCTYPE"

<noah> HT: Looks like there has been at least some response to some of my comments. This could be a change for the better. I need to read it.

<noah> DC: Is this a description of conforming documents or browser behavior?

<noah> HT: That's the key question, as Noah also mentioned in (some email?)

pretty much all of 8.2 is in the "Highlight UA text" style

<noah> NM: I read 9.1 as saying XHMTL doctypes are not constrained.

<noah> HT: I >think< so.

<noah> LM: So, it's a polyglot issue.

<noah> DC: Not my Polyglot issue.

<noah> DC: OT

<noah> DC: It's about well formed.

<htt> http://lists.w3.org/Archives/Public/www-tag/2010Feb/0057.html is NM's message about conformant document

<masinter> how many well-formed XML/XHTML documents are also valid HTML?

<masinter> all? some? only those that use more than 17 elements?

DC: as long as I can write HTML 5 documents that are XML-well-formed, my requirements are met.

<noah> NM: Next steps?

action-364?

<trackbot> ACTION-364 -- Dan Connolly to ask HTML WG team contacts to make a change proposal re issue-53 mediatypereg informed by HT's analysis and today's discussion -- due 2010-02-18 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/364

<noah> DC: I have an action to get with team contacts

<noah> http://www.w3.org/html/wg/tracker/actions/172

(er... 172 is an action, not an issue)

("issue of document vs processor conformance"... that's not an acknowledged HTML WG issue, AFAIK)

<jar> n.b. Larry's proposal goes beyond the media type issue - tries to make a point about gratuitous incompatibility

noodling... "to the extent that the HTML versioning issue (4) overlaps with the media type issue (53) , we're still interested" where 53 is short for http://www.w3.org/html/wg/tracker/issues/53

NM: does setting expectations that we'll have something as a group around our ftf sound right?

HT: yes
... consider "there's a constellation of issues around the doctype, version indicators, and the media type ..."

LMM: I think that's coming at it from the wrong end... "there's some damage done to HTML and for [scribe lost track...

<jar> LMM: if something's bad for 3 reasons, we don't need to file 3 different issues one for each reason

LMM: dropping the DOCTYPE is bad for 3 reasons: (1) mime type (2) polyglot (3) ...

DC: "polyglot" doesn't work for me when talking about DOCTYPES. can we call it "XML workflows"

TVR: probably not effectively

LMM: dropping the DOCTYPE is bad for 3 reasons: (1) mime type (2) polyglot (3) definition of what conforms

perhaps "dropping the public and system identifier from the DOCTYPE..."

DanC: I think dropping the doctype is a good idea...

<htt> So, something such as "The current status of DOCTYPE statements, in the HTML and XHTML syntax sections, and in the HTML processor section, cause problems in at least four areas: the interpretation of the text/html media type; document workflows which use PUBLIC and/or SYSTEM identifiers; the general question of how to determine what the spec. says with respect to what are conformant documents; the use of DOCTYPEs as version identifiers

<htt> "The TAG is still working to pull together input in this area -- we hope to have something to say by the end of our March f2f

DanC: DOCTYPEs are wrong almost all the time. it's a waste of bytes; provided _dis_information most of the time

LMM: [could you help me record your reply, Larry?]

<htt> </>

<htt> I thought TV's observation about <!DOCTYPE HTML> is a good one: it's making the W3C's 1999 XHTML mistake all over again

LMM: ... a suggestion was to put the editor's notion of document type in a comment; that's non-sensical w.r.t. saving bytes

<htt> That is, just because we think we would all be better off if everyone used <!DOCTYPE HTML>, we shouldn't say "only that is allowed"

+1 something such as...

<jar> You mean: disallowing doctypes is like requiring end tags - both change good documents into bad ones?

<masinter> ah yes, that if you are concerned about DOCTYPE being a waste of bytes and useless to consumers: DOCTYPE on the web is probably leftover from a XML workflow that then turned into a HTML workflow, and by the time it hits the browser, sure it's useless, but doesn't mean it wasn't useful during the XML workflow, which is the workflow that needs to know what a valid document is anyway

<scribe> ACTION: Noah to update HTML WG co-chairs along the lines of ... DOCTYPE... workflow... media type.. [recorded in http://www.w3.org/2010/02/18-tagmem-minutes.html#action01]

<trackbot> Created ACTION-393 - Update HTML WG co-chairs along the lines of ... DOCTYPE... workflow... media type.. [on Noah Mendelsohn - due 2010-02-25].

changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case

action-278?

<trackbot> ACTION-278 -- Jonathan Rees to draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case -- due 2010-02-07 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2001/tag/group/track/actions/278

<jar> My cheat sheet for this action http://www.w3.org/2001/tag/2010/02/action-278-notes.txt

<masinter> It used to be that HTML spec was actually useful for XML workflows, and these kinds of changes, which didn't give significant value to the XML workflow use cases, were harmful to a community not well-represented

<noah> Proposal: http://lists.w3.org/Archives/Public/www-tag/2010Feb/0074.html

NM: Dan said something about "that doesn't look all that different from tyler's" ...
... a difference is: tyler's says "user agents MUST NOT ..." and I am careful to not say that

<noah> Actually, you said one bit of mine didn't look that different from one bit of his.

JAR: ... not sure I'm done thinking this thru... advocacy... [scribe fails to capture]

<jar> 2 cases: google calendar, csrf defense

NM: the problem I'm seeing is tyler is saying the web should have been carefully designed so that URIs are treated carefully and not spread... [scribe bandwidth exceeded]

TVR: this same argument was made against REST and use of params in the arg...
... people said "it's too fragile; don't call us if it breaks" but [now it's expected]

DanC: all tyler has said is "don't do things that the user hasn't asked you [the user agent] to do"

<noah> From Tyler:

<noah> A user-agent

<noah> MUST NOT disclose representations or URIs, unless either explicitly

<noah> instructed to do so by the user or as legitimately directed to by

<noah> presented content. Since the user may wish to keep this information

<noah> confidential, the user-agent must not assume it can be revealed to

<noah> third-parties.

DanC: all that says is "don't do things that the user hasn't told you to do"

<masinter> This would require software to not do things that used to be presumed valid. Imposing such requirements needs a stronger justification than this one use case.

<masinter> "Everything that isn't mandatory is forbidden" is a bad design rule.

NM: have I explictly told my web browser which parts of the disk to store my URLs?

<johnk> is it valid for a browser to automatically send the Referer HTTP header?

NM: I don't see that we have standing to say when a wide variety of software conforms, retrospectively

DanC: we can just observe that the community has this rule; when it's broken, people get pissed off

<noah> JAR: We could redraft.

NM: that's a big difference...

<noah> NM: That would be great. Who will do it?

<noah> Did JAR respond that he would? Didn't hear.

no

<noah> OK

we left it in "we should" state for now

<noah> OK

JAR: in the other case [scribe falls behind]

<jar> If the finding gives only grudging acceptance of unguessable URIs, that leaves the CSRF in the cold

JAR: to effectively defend against CSRF...
... you have to embrace the unguessable URI pattern

<noah> DC: For every page?

JAR: well, every page that involves authority...

<Zakim> noah, you wanted to talk about word unguessable

JAR: any page that may have confidential information a bit

NM: the main thing the finding is trying to say is not really about guessing a URI, but that by looking at a URI, you shouldn't be able to get confidential from it

<jar> If you believe unguessable URIs are important for defense, the finding needs to embrace them wholeheartedly, not grudgingly

JAR: I don't think anybody argues against that...

NM: but that's all the finding said...

<masinter> Is this right? HTTP has authentication methods, but using them is awkward. So people are looking for other ways of doing authentication, and one of those ways is suceptable to CSRF. Rather than trying to fix HTTP authentication, people are trying to patch this alternative so that it isn't as suceptable

JAR: the finding said "confidential"

[scribe isn't sure he's following well now]

it's not just awkwardness, masinter ; the HTTP auth mechanisms are still ambient authority [I think]

NM: [an example... taxes or something... scribe neglected to get it]
... so where do you see the disagreement?

JAR: (a) the finding says don't put confidential info in URIs (b) CSRF defense requires the use of unguessable URIs, i.e. confidential info in the URI (c) hence the finding argues against state-of-the-art defense against CSRF

LMM: picking up on somthing Roy F. said about origin...
... HTTP has authentication methods, but using them is awkward. So people are looking for other ways of doing authentication... e.g. not doing a username/password on every request...
... and one of the ones they've selected is vulnerable to CSRF...

<noah> NM: I tried to say: I agree that if you want URIs to be secret, it's probably good/essential that they be unguessable. But... I don't think the converse is true: there are lots of good reasons for making unguessable URIs that aren't otherwise secret. I.e. where the URIs don't have to be protected, but the mappings from things like bank account numbers need to be.

LMM: so perhaps we should step back and look at why we picked this method?

<noah> DC: Useful that you said "it was awkward to type uid/pwd on every request"

<noah> DC: If you did challenge/resp with password on every request, would it seal the CSRF hole?

<noah> JAR: Don't think so -- don't know.

<noah> DC: You'd ask for page, server would give nonce. (should have been in http...but anyway...maybe MD5 auth). You take the number and password, hash, and return.

<noah> JAR: How do I know password isn't wielded by attacker.

<noah> JK: You need an account with each site?

<johnk> JK: each *site* needs an "account" with each other site

<jar> i thought we agreed not to use the C-word...

<johnk> origin identifies, it doesn't authenticate

<johnk> with "secret unguessable URIs", the URI is a "bearer token" - the bearer of the URI is authorized, regardless of identity

<Ashok> +1 to JohnK

<johnk> can the bank allow a third-party site to ask the UA to send the cookie to the bank?

(set of notes? where?)

trackbot, status?

<johnk> ACTION - John to compare Noah and Tyler's proposals on this subject

<trackbot> Sorry, couldn't find user - -

<johnk> ACTION - johnk to compare Noah and Tyler's proposals on this subject

<trackbot> Sorry, couldn't find user - -

<noah> ACTION: John to compare Noah and Tyler's proposals on this subject [recorded in http://www.w3.org/2010/02/18-tagmem-minutes.html#action02]

<trackbot> Created ACTION-394 - Compare Noah and Tyler's proposals on this subject [on John Kemp - due 2010-02-25].

<noah> We are adjourned -- please start working on F2F input

Summary of Action Items

[NEW] ACTION: John to compare Noah and Tyler's proposals on this subject [recorded in http://www.w3.org/2010/02/18-tagmem-minutes.html#action02]
[NEW] ACTION: Noah to update HTML WG co-chairs along the lines of ... DOCTYPE... workflow... media type.. [recorded in http://www.w3.org/2010/02/18-tagmem-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/02/18 22:05:20 $