TAG Weekly

Convene

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 it)

<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> 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 http://html5.digitalbazaar.com/specs/html5-epb.html and send some notes to the TAG [recorded in http://www.w3.org/2009/10/08-tagmem-irc]

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

action-317 due 20 Oct

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

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

User Privacy in Device APIs

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

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 mechanisms

<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 extensions

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

<DanC_> Managing variability in the QA spec guidelines

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 essential

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 flexible

<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 yet

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> 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_> Device APIs and Policy Working Group

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 TAG

so RESOLVED.

<scribe> ACTION: Noah to send note to Device APIs and Policy (DAP) Working Group on behalf of the TAG [recorded in 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 2009-10-15].

HTML

<noah> 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 HTMLIssuesRevised.pdf

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_> ISSUE-1 w3cMediaType-1 Should W3C WGs define their own media types?

<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_> Internet Media Type registration, consistency of use TAG Finding 30 April 2004

<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 application/xml

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

<masinter> or a MUST NOT as well

<noah> 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 method,

<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 body.

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

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 jurisdiction"

<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 specs]
... If the sender intentionally sends data that's not legal(?) per mime type, and receiver correctly discovers that, communication has occurred

<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 options...
... some media types are consistent with these bytes and some are not

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? http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/

<masinter> yes

<masinter> that one bothered me

<DanC_> me too

<masinter> 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 definition."

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 types
... 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 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].