W3C home > Mailing lists > Public > www-tag@w3.org > October 2009

minutes TAG weekly 8 Oct for review

From: Dan Connolly <connolly@w3.org>
Date: Mon, 12 Oct 2009 11:47:11 -0500
To: www-tag@w3.org
Message-Id: <1255366031.2666.3.camel@pav.lan>

                               - DRAFT -

                              TAG Weekly

08 Oct 2009


      [2] http://lists.w3.org/Archives/Public/www-tag/2009Oct/0006.html

   See also: [3]IRC log

      [3] http://www.w3.org/2009/10/08-tagmem-irc


          jar, noah, DanC, Ht, Masinter, Raman

          Ashok, Tim, JohnK




     * [4]Topics
         1. [5]Convene
         2. [6]Administrative item: TPAC scheduling
         3. [7]IRI news
         4. [8]Versioning update
         5. [9]User Privacy in Device APIs
         6. [10]HTML
         7. [11]HTML mime type
     * [12]Summary of Action Items


   NM: note agenda addition

   HT: regrets 15 Oct

   JAR: yes, I can scribe 15 Oct

   NM: we have regrets from Tim thru Dec

Administrative item: TPAC scheduling

   TVR: I have a conflict for Fri PM at TPAC

   NM: ok to move Mon TPAC meeting to PM?

   <DanC_> (did anybody hear/2nd NM's suggestion re Monday? I missed

   <masinter> no problem

   NM: OK we'll meet PM on Mon 2 Nov
   ... and we'll meet AM Fri 6 Nov

IRI news

   LM: there's a meeting Monday 12 Oct; I'll send info in email

Versioning update

   LM: 2 things...
   ... 1 I got jar's note on versioning formalism and that's helpful;
   we should plan to move forward on it
   ... 2 Manu Sporny, in preparing RDFa integration with HTML, took an
   interesting approach to refs between versioned specs...
   ... and I think the TAG should look at that

   <masinter> [13]http://html5.digitalbazaar.com/specs/html5-epb.html

     [13] http://html5.digitalbazaar.com/specs/html5-epb.html

   <masinter> Extended Processing Behavior in HTML5

   <masinter> A mechanism for specifying and extending user agent
   processing behavior.

   Editor's Draft 27 September 2009

   <masinter> but also @version attribute

   TVR: I've read some of the discussion... OK, I'll take a closer look

   <scribe> ACTION: Raman to read
   [14]http://html5.digitalbazaar.com/specs/html5-epb.html and send
   some notes to the TAG [recorded in

     [14] http://html5.digitalbazaar.com/specs/html5-epb.html
     [15] http://www.w3.org/2009/10/08-tagmem-irc

   <trackbot> Created ACTION-317 - Read
   [16]http://html5.digitalbazaar.com/specs/html5-epb.html and send
   some notes to the TAG [on T.V. Raman - due 2009-10-15].

     [16] http://html5.digitalbazaar.com/specs/html5-epb.html

   action-317 due 20 Oct

   <trackbot> ACTION-317 Read
   [17]http://html5.digitalbazaar.com/specs/html5-epb.html and send
   some notes to the TAG due date now 20 Oct

     [17] http://html5.digitalbazaar.com/specs/html5-epb.html

   LMM: Raman, if you'd look at what JAR and I are working on, that
   would be great

User Privacy in Device APIs

   <DanC_> [18]Action Re. Policy Note to DAP WG and others

     [18] http://lists.w3.org/Archives/Public/www-tag/2009Sep/0073.html

   NM: not clear what action this was related to; no matter...

   <masinter> +1 to send this

   <Zakim> noah, you wanted to say I like the reference to extension

   <masinter> Under "Draft TAG Note Re. User Policy", 2nd paragraph 2nd
   sentence is TAG advice to working group

   <noah> "It should

   <noah> be possible to include policy information in API calls "

   NM: I think it's important that we don't have to re-do some API, but
   you can negotiate extensions
   ... re "information"... doesn't seem to say [obligations...]

   <Zakim> DanC, you wanted to check that testing is mentioned with

   DanC: untested extensions are evil; see "Managing variability" in
   the QA spec guidelines

   <DanC_> [19]Managing variability in the QA spec guidelines

     [19] http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#variability

   NM: are you saying "you have to test the hook" or "you have to show
   the extension in use"?

   DC: to some extent, both; the latter is better but the former is

   NM: Tradeoff: if you have an extension point, it's partly so someone
   else can invent the extension. Then again, if geolocation goes out
   with no preferred embodiment of policy control, there will be a lot
   of unprotected access (which doesn't bother me personally, but may
   bother some others)

   <Zakim> jar, you wanted to note policy != security

   JAR: re "information", I think that word is OK...
   ... the approach here seems consistent with "information"

   <noah> What the note says now is "It should

   <noah> be possible to include policy information in API calls in a

   <noah> manner, perhaps using an extension mechanism.

   <noah> "

   LM: perhaps we could be more clear... this isn't about advising any
   one mechanism...
   ... but around prioritization

   <masinter> technical advice to director, staff, WG chairs, editors,
   etc. that the TAG believes specifically addressing these issues
   should be a requirement; don't want to specify mechanism
   ("instructions" vs "information")?

   LM: perhaps [para break wordsmithing]

   <Zakim> DanC, you wanted to discuss premature standardization

   <noah> I'd like to focus, after Dan, on "is this text OK"

   <Zakim> noah, you wanted to say, yeah, we don't know how to do it

   PROPOSED: that LMM edit lightly and send 2009Sep/0073 on behalf of
   the TAG

   <masinter> perhaps "It should be possible" to "The TAG encourages
   serious analysis of the possibility"

   <masinter> danc: do you like my rewording?

   <DanC_> sure.

   PROPOSED: that LMM edit lightly and Noah send 2009Sep/0073 to
   [whom?] on behalf of the TAG
   ... that LMM edit lightly as discussed 8 Oct and Noah send
   2009Sep/0073 to [whom?] on behalf of the TAG
   ... that LMM edit 2009Sep/0073 lightly as discussed 8 Oct and Noah
   send to [whom?] on behalf of the TAG

   <jar> [20]http://www.w3.org/2009/dap/

     [20] http://www.w3.org/2009/dap/

   <jar> Device APIs and Policy Working Group

   <noah> Device APIs and Policy Working Group

   TVR: there are perhaps several relevant WGs: device apis,
   geolocation, webapps, and to some extent HTML WG

   <DanC_> [21]Device APIs and Policy Working Group

     [21] http://www.w3.org/2009/dap/

   PROPOSED: that LMM edit 2009Sep/0073 lightly as discussed 8 Oct and
   Noah send to Device APIs and Policy Working Group on behalf of the


   <scribe> ACTION: Noah to send note to Device APIs and Policy (DAP)
   Working Group on behalf of the TAG [recorded in

     [22] http://www.w3.org/2009/10/08-tagmem-irc

   <trackbot> Created ACTION-318 - Send note to Device APIs and Policy
   (DAP) Working Group on behalf of the TAG [on Noah Mendelsohn - due


   <noah> [23]http://www.w3.org/2001/tag/2009/09/HTMLIssuesRevised.pdf

     [23] http://www.w3.org/2001/tag/2009/09/HTMLIssuesRevised.pdf

   LMM: the "explicit version indicators: doctypes, etc." topic
   motivates reading Manu's draft that I referred to earlier

   <masinter> and possibly scheduling some JAR+TVR+LMM discussion time

   <noah> explicit version indicators: doctypes, etc.

HTML mime type

   "Redefinition of HTML mime type" #3 from the FTF table

   LMM: I've seen people using MIME types for things they weren't
   designed for... in W3C specs and other groups
   ... perhaps some written advice is in order...
   ... originally, MIME was for email...
   ... the MIME type was some extra metadata that would tell the
   receiver what the sender's intent was...
   ... this also reads on MIME type sniffing
   ... so there's not much normative in a MIME type definition... some
   people say "if you have this content, you MUST serve it this way"...
   [which is bad?]
   ... if I serve an image [with a text MIME type? scribe got lost]
   ... so if you have a MIME type and you want to update the
   registration... to redefine things that used to mean one thing but
   as another, it doesn't make sense
   ... it doesn't make sense to say that old content no longer conforms

   <Zakim> DanC, you wanted to swap in TAG finding on TAG issue #1

   <noah> I think self-Describing Web Finiding is pertinent too

   <DanC_> [24]ISSUE-1 w3cMediaType-1 Should W3C WGs define their own
   media types?

     [24] http://www.w3.org/2001/tag/group/track/issues/1

   <DanC_> "State: PENDING REVIEW"

   <jar> the other use of mime types is in CN

   <masinter> the main thing was to get the W3C advice on updating MIME
   types to point to the policy on *updating* MIME registrations

   <DanC_> [25]Internet Media Type registration, consistency of use TAG
   Finding 30 April 2004

     [25] http://www.w3.org/2001/tag/2004/0430-mime

   <noah> That's an approved TAG finding.

   DanC: does that give the sort of advice you had in mind?

   LMM: I don't think it does, no...

   DanC: I'm not sure I understand your point about MIME types not
   being normative... surely it's a MUST NOT to send "<<" in

   <jar> a "should" has to be with respect to some written spec

   <masinter> or a MUST NOT as well

   <noah> [26]http://www.ietf.org/rfc/rfc2616.txt

     [26] http://www.ietf.org/rfc/rfc2616.txt

   <noah> 14.17 Content-Type

   <noah> The Content-Type entity-header field indicates the media type
   of the

   <noah> entity-body sent to the recipient or, in the case of the HEAD

   <noah> the media type that would have been sent had the request been
   a GET.

   <masinter> note there is no MUST there

   NM: in the HTTP case, it's pretty clear that there's a normative
   spec that says media types tell you the meaning of the octets in the

   <masinter> it says what the producer intended the receiver to

   indeed, there's no MUST, but it's clearly a normative constraint,
   right masinter ?

   <jar> +1 (to LM re scoping of compliance)

   <DanC_> but didnt' you say "media types are not normative", Larry?
   or did I mis-hear you?

   LMM: I think we speak of conformance of messages but it's really a
   short-hand for talking about conformance of senders

   <jar> noah is saying: An HTTP response whose entity-body begins <<
   is not a valid HTTP response.

   <jar> when the type is html.

   NM: no, there's also an objective sense that some sequences of bytes
   are not conforming HTTP messages

   LMM: there's nothing in the HTTP spec that says an HTTP server is
   non-conforming if it sends body octets that don't match the syntax
   give in the MIME type definition

   NM: [missed]

   LMM: let's look at the text/html case...
   ... in writing the HTML media type registration RFC, we tried to
   write a story about all the things that might be sent as text/html
   on the Web, not [missed/too fast]

   NM: meanwhile, the XML media type spec that pretty clearly says "if
   it's not well formed, it's broken"

   <masinter> if you talk about "legal", you need to say "in what

   <jar> lm is saying I think: The Content-type: text/html with content
   << HTTP response is conforming HTTP, and the entity may or may not
   conform to any of the wide variety of HTML specs, or one or more of
   the revisions of the text/html media type registration.

   <Zakim> noah, you wanted to say there is a lot normative in mime
   type as used on the Web per RFC 3986 (indirectly) and wrt/
   self-describing Web

   LM: when you say "legal" it makes me wonder "in what jurisdiction?"

   NM: there's an observable contradiction when the octets in the body
   don't match the media type spec

   JAR: LM's not alone here... I'm bothered by some of the things the
   TAG has said/written in this space

   <jar> whose idea was it to start both acronyms with HT.

   DC: LM, you might have meant two things 1) media types wishy/washy
   2) you can't change history

   LM: not the 1st. MIME types mean a lot... in order to communicate
   successfully, senders/receivers need to [follow the rules in the
   ... If the sender intentionally sends data that's not legal(?) per
   mime type, and receiver correctly discovers that, communication has

   <masinter> I think i'm working this out

   <masinter> there's no notion of "having HTML" vs "having XHTML" and
   then mandating what MUST or MUST NOT be used

   NM: did you mean "it's OK to send html as text/plain"? or "it's ok
   to send html as image/jpeg"?

   LMM: I'm still working this out... this conversation is helping...
   ... there's no notion of "having HTML" vs "having XHTML" and then
   mandating what MUST or MUST NOT be used
   ... if I have some bits, I have some bits... [hard to capture]

   <jar> option 2) (can't change history) is similar to what I was
   saying about persistence at the F2F. the public stakes a claim on
   the meaning of the media type string (or URI) that you can't ignore
   without being either rude or ignored.

   NM: that makes a lot of sense in the case where I'm an ISP and a
   customer uploaded foo.blort and I see a GET... indeed, [there's no
   spec that tells me what MIME type to use]

   <ht> I'm concerned with this issue, but didn't manage to engage
   tonight -- will review minutes and try to email

   <masinter> what does it mean to "have HTML" without knowing that you
   mean "text/html" and not "text/plain"

   NM: it seems to me, that given some bytes, the various specs give
   ... some media types are consistent with these bytes and some are

   DC: Larry may be responding to instruction in HTML 5 draft that
   XHTML must be sent as (??application/xhtml+xml")

   LMM: when we speak of "the intent of the sender" I have no
   problem... my problem is [hard to capture]

   NM: there's a conventional [standard] meaning to messages that we
   can speak of without appeal to intent of senders

   JAR: you have to be very careful with attribution... a tape recoder
   saying "fire! fire!" is different...

   NM: again, the self-describing web goes into such failure
   modes...http vs https...

   JAR: no, I'm talking about normal situations, not failure modes

   <masinter> there was another document on MIME types for html, forget
   where i saw it

   <DanC_> maybe this one, masinter?

     [27] http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/

   <masinter> yes

   <masinter> that one bothered me

   <DanC_> me too

   <masinter> [28]http://tools.ietf.org/html/bcp13#section-9

     [28] http://tools.ietf.org/html/bcp13#section-9

   <masinter> "Changes should be requested only when there are serious
   omissions or errors in the published specification. When review is
   required, a change request may be denied if it renders entities that
   were valid under the previous definition invalid under the new

   LMM: that NOTE-xhtml-media-types seems to get things backwards...
   ... and I note the BCP on MIME types

   <noah> Changes should be requested only when there are serious
   omissions or

   <noah> errors in the published specification.

   <noah> What a cool quote. We're done. The Web can't change. A lot
   less work for us.

   <noah> Time check: 3 mins to go

   DanC: this is news to me that the IETF BCP says " only when there
   are serious omissions or errors"; what about postscript level 2 to
   level 3?

   <jar> Web can change through growth into previously unoccupied
   space. Change through incompatibility is by definition a problem for
   existing content.

   LMM: the postscript case predates modern understanding, but I worked
   on PDF... we were careful to describe how PDF changes in the media
   type registration
   ... perhaps that's part of the advice the TAG should give on media
   ... when the postscript registration was current, there was
   discussion of a version param on the mime type; Keith Moore and/or
   Ned Freed argued that no, the media type is enough to look inside
   for a version indicator
   ... [something about global version indicators; send mail if that's
   important, please, larry]

   <masinter> turns into a use case for global version indicators: to
   disambiguate language versions among text/html

   DC: One of the nets of our discussion is that we're not happy about
   what HTML 5 says about the text/html media type, I.e. that it
   obsoletes all previous versions (retroatively changing
   interpretation of HTML 2 docs)
   ... Counter is that HTML 5 is close enough to way HTML 2 is
   practiced. I have some sympathy.

   <masinter> if the purpose of a MIME type is to tell the receiver
   what the sender meant, then retroactively defining the MIME type,
   even if compatibly, isn't helpful.

   <noah> Noah will schedule discussion of media type next week.

   <jar> I found this helpful too

   <scribe> ACTION: Noah to consider HTML media type issue for TPAC
   agenda(s) recorded in [29]http://www.w3.org/2009/10/08-tagmem-irc]

     [29] http://www.w3.org/2009/10/08-tagmem-irc

   <trackbot> Created ACTION-319 - Consider HTML media type issue for
   TPAC agenda(s) [on Noah Mendelsohn - due 2009-10-15].

Summary of Action Items

   [NEW] ACTION: Noah to consider HTML media type issue for TPAC
   agenda(s) recorded in [30]http://www.w3.org/2009/10/08-tagmem-irc]
   [NEW] ACTION: Noah to send note to Device APIs and Policy (DAP)
   Working Group on behalf of the TAG [recorded in
   [NEW] ACTION: Raman to read
   [32]http://html5.digitalbazaar.com/specs/html5-epb.html and send
   some notes to the TAG [recorded in

     [30] http://www.w3.org/2009/10/08-tagmem-irc
     [31] http://www.w3.org/2009/10/08-tagmem-irc
     [32] http://html5.digitalbazaar.com/specs/html5-epb.html
     [33] http://www.w3.org/2009/10/08-tagmem-irc

   [End of minutes]

    Minutes formatted by David Booth's [34]scribe.perl version 1.134
    ([35]CVS log)
    $Date: 2009/10/12 16:44:42 $

     [34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [35] 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 Monday, 12 October 2009 16:47:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:31 UTC