- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 12 Oct 2009 11:47:11 -0500
- To: www-tag@w3.org
http://www.w3.org/2001/tag/2009/10/08-minutes.html
http://www.w3.org/2001/tag/2009/10/08-minutes
- DRAFT -
TAG Weekly
08 Oct 2009
[2]Agenda
[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
Attendees
Present
jar, noah, DanC, Ht, Masinter, Raman
Regrets
Ashok, Tim, JohnK
Chair
noah
Scribe
DanC
Contents
* [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
_________________________________________________________
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> [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
[15]http://www.w3.org/2009/10/08-tagmem-irc]
[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
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_> [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
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> [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
TAG
so RESOLVED.
<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]
[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
2009-10-15].
HTML
<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
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_> [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
application/xml
<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
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?
[27]http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/
[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
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 [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
[31]http://www.w3.org/2009/10/08-tagmem-irc]
[NEW] ACTION: Raman to read
[32]http://html5.digitalbazaar.com/specs/html5-epb.html and send
some notes to the TAG [recorded in
[33]http://www.w3.org/2009/10/08-tagmem-irc]
[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