See also: IRC log
NM: note agenda addition
HT: regrets 15 Oct
JAR: yes, I can scribe 15 Oct
NM: we have regrets from Tim thru Dec
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
... and we'll meet AM Fri 6 Nov
LM: there's a meeting Monday 12 Oct; I'll send info in email
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> 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
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
... 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.
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?
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> 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
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
<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].
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.
"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
... 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_> "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
<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> 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
LMM: let's look at the text/html
... 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> that one bothered me
<DanC_> me too
<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].