TAG 18 Feb teleconference minutes for review

http://www.w3.org/2010/02/18-tagmem-minutes.html


              Technical Architecture Group Teleconference

18 Feb 2010

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0139.html

   See also: [3]IRC log

      [3] http://www.w3.org/2010/02/18-tagmem-irc

Attendees

   Present
          Raman, DanC, Jonathan_Rees, Ashok_Malhotra, noah, John_Kemp,
          htt, Larry

   Regrets
          Dan_Appelquist, Tim_Berners-Lee

   Chair
          noah

   Scribe
          DanC

Contents

     * [4]Topics
         1. [5]Convene, review agenda
         2. [6]version indicators, esp in HTML 5
         3. [7]changes to 2.7 of Metadata in URIs to cover the "Google
            Calendar" case
     * [8]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 18 February 2010

   <scribe> scribe: DanC

Convene, review agenda

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

      [9] http://www.w3.org/2001/tag/2010/02/11-minutes

   <jar> +1 approve

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

     [10] 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> [11]http://www.w3.org/2001/tag/group/track/actions/391

     [11] 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> [12]http://www.w3.org/2001/tag/group/track/actions/332

     [12] 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> [13]http://www.w3.org/2001/tag/group/track/issues/41

     [13] 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
   [14]http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.htm
   l -- due 2010-02-11 -- PENDINGREVIEW

     [14] http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html

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

     [15] 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
   [16]http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.htm
   l closed

     [16] http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html

   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:
   [17]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0140.html

     [17] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0140.html

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

     [18] 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.

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

     [19] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8154

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

     [20] 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
   [21]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0008.html

     [21] 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> [22]http://www.w3.org/2001/tag/group/track/actions/364

     [22] 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 [23]http://dev.w3.org/html5/spec/ dated 18
   February 2010

     [23] http://dev.w3.org/html5/spec/

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

     [24] http://dev.w3.org/html5/spec/syntax.html#the-doctype

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

     [25] http://dev.w3.org/html5/spec/syntax.html#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>
   [26]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0057.html is
   NM's message about conformant document

     [26] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0057.html

   <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> [27]http://www.w3.org/2001/tag/group/track/actions/364

     [27] http://www.w3.org/2001/tag/group/track/actions/364

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

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

     [28] 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
   [29]http://www.w3.org/html/wg/tracker/issues/53

     [29] 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
   [30]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> [31]http://www.w3.org/2001/tag/group/track/actions/278

     [31] http://www.w3.org/2001/tag/group/track/actions/278

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

     [32] 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:
   [33]http://lists.w3.org/Archives/Public/www-tag/2010Feb/0074.html

     [33] 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
   [34]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
   [35]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
   [36]http://www.w3.org/2010/02/18-tagmem-minutes.html#action01]

   [End of minutes]
     _________________________________________________________


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

     [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [38] http://dev.w3.org/cvsweb/2002/scribe/


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Thursday, 18 February 2010 22:07:42 UTC