See also: IRC log
<DanC_lap> scribenick: DanC_lap
Note future regrets: Raman (April 23) Tim (April 23rd)
NM: we're scheduled to meet again
23 Apr, 2 regrets...
... I have a conflict with agenda planning for next week; stay
tuned for agenda or cancellation notice
RESOLUTION: to meet again 23 Apr, ashok to scribe
RESOLUTION: to approve http://www.w3.org/2001/tag/2009/04/09-minutes 2009/04/12 12:18:55
NM: 2 apr minutes still in progress?
LMM: right
NM: POWDER stuff... next week?
DC: yes, I think so
<ht> http://www.w3.org/TR/hash-in-uri/
NM: on to "Progress report on publication of Usage Patterns For Client-Side URL parameters working draft."
HT: it's published.
RESOLUTION: to thank Raman, HT for successful publication of /TR/hash-in-url
<ht> s/hash-in-url/hash-in/uri
NM: though the issue name is "XML
Versioning" we've discussed versioning of non-XML languages as
well; I'd like to just leave that be for now... till the ftf,
perhaps...
... I've been [...help? ...] 2 things: (1) [help2] and (2) ...
HTTP header [help3]
... ... origin header, or do you want to let that go?
LMM: no, I don't want to let that [origin] go...
<masinter> issues around extensibility of HTTP and the methods used to extend it
<masinter> origin header, content-type sniffing, etc.
<scribe> ACTION: Noah to follow up with Larry around extensibility of HTTP and the methods used to extend it [recorded in http://www.w3.org/2009/04/16-tagmem-minutes.html#action01]
<trackbot> Created ACTION-258 - Follow up with Larry around extensibility of HTTP and the methods used to extend it [on Noah Mendelsohn - due 2009-04-23].
LMM: today in the HTML WG
teleconference, I asked what people thought would be
useful...
... [something about a document by jar]
... a summary: if you have readers and writers, there are 2
kinds of extensibility:
... (1) current readers to work with future writers and (2)
current writers to work with future readers [or was it the
other way around. we called these backward and forward
compatibility in earlier drafts]
<noah> Larry was talking about the versioning formalism from JAR
LMM: history of HTML includes quirksmode, CSS, [missed some?]
<timbl> Interoperability in the sense that the behavior of existing code given unexpected input.
<noah> The formalism I was thinking of is in http://lists.w3.org/Archives/Public/www-tag/2008May/0155.html
LMM: ... it seems to several HTML WG members incl. Chris W. that such an analysis would help as background for HTML WG decision-making in the area of versioning
NM: I liked some of the stuff in Sam Ruby's recent item (http://intertwingly.net/blog/2009/04/08/HTML-Reunification ) ...
<ht> platform features vs. language features
<ht> http://intertwingly.net/blog/2009/04/08/HTML-Reunification
"the idea of extensibility into two parts: extending the platform vs. extending the language. "
<Zakim> noah, you wanted to talk a bit about Sam Ruby's note
<Zakim> DanC_lap, you wanted to make an obligatory comment about release of confidential info
HT: I think Sam's proposal is
interesting...
... there are parts that don't appeal to me, but those are
HTML-specific...
... his claim that [help4?] bleeds thru is (a) symmetric and
(b) inevitable...
... this is the problem of HTML tag soup syntax leaking into
SVG etc.; I'm not sure that's correct on a number of
fronts.
... I think the "platform features vs. language features"
distinction is useful
<noah> I think Henry is saying that some people believe that, e.g. SVG, in TAG soup can't be automatically extracted for use by XML tools
HT: none of what he [Sam] writes touches on forward vs backward compatibility at all
<noah> scribenick: noah
LM: No, we mostly solicited
discussion of general extensibility, but want to ground in real
experience
... HTML does it
<DanC_lap> 3=who?
<masinter> think the issue of "strict XML in SVG" embedded in "loose parsing rules in HTML" is indeed a good example of a versioning issue
<masinter> put it into the framework of versioning
NM: Can Larry, John, and Jonathan start working on details, since you agreed to work together last week
JAR: I posted a related use case. (will paste URI below) It's about OWL datatype mapping. Ashok answered.
<masinter> liked Jonathan's example as another use case, but want to make sure we actually answer HTML-WG issues specifically
action 241?
<trackbot> Sorry, bad ACTION syntax
<masinter> action-241?
<trackbot> ACTION-241 -- Larry Masinter to review TAG versioning situation and report back to TAG and HTML -- due 2009-04-09 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/241
<jar_> http://w3.org/mid/760bcb2a0904160518k573399f0s795a4a7a2d65cb38@mail.gmail.com
<masinter> suggest doing this on www-tag this week
<ht> Hmm -- XML Schema 1.1 allows "extension datatypes" which have exactly the problem JAR points to in his reply to Ashok, and some of us were not happy about allowing that . . .
<DanC_lap> scribenick: DanC_lap
<noah> suggest perhaps the action should specifically include effort to apply general versioning principles to HTML and maybe to JAR's use cases too
<scribe> ACTION: Larry kick off discussion of versioning principles to apply to HTML, engage jonathan and henry. [recorded in http://www.w3.org/2009/04/16-tagmem-minutes.html#action02]
<trackbot> Created ACTION-259 - Kick off discussion of versioning principles to apply to HTML, engage jonathan and henry. [on Larry Masinter - due 2009-04-23].
<jar_> . ACTION: Jonathan review and post the email exchange he had with Larry on versioning about 1-2 months ago
<scribe> ACTION: Jonathan review and post the email exchange he had with Larry on versioning about 1-2 months ago [recorded in http://www.w3.org/2009/04/16-tagmem-minutes.html#action03]
<trackbot> Created ACTION-260 - Review and post the email exchange he had with Larry on versioning about 1-2 months ago [on Jonathan Rees - due 2009-04-23].
<noah> scribenick: noah
<DanC_lap> 9 jan draft http://ietfreport.isoc.org/idref/draft-abarth-mime-sniff/
DC: We had a meeting in San
Francisco. Subject of discussion is http://ietfreport.isoc.org/idref/draft-abarth-mime-sniff/
dated 09-Jan-2009. Larry seems to be following more closely
than I am.
... My goal is to have community consensus reflected both in
the spec and in widely deployed code.
<jar_> DC said: a test suite would be nice.
DC: There's a page from SF in the ESWiki
<masinter> http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/
<DanC_lap> sfo meeting pg: http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009
<masinter> see "PROPOSAL: content sniffing [#155]" thread
<DanC_lap> "Action Item: Lisa to review the current draft. "
DC: See http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009, 3rd item under Agenda in the wiki says "Action Item: Lisa to review the current draft. " Do we know if the review has happened?
<DanC_lap> msg from lisa re sniffing http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0065.html
LM: She's aware of the issue, but I don't know whether she reviewed the draft.
<DanC_lap> Lisa's review seems to be : http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0063.html
DC: Dan reads a lot of links and
says "this seems to be her review"
... Lisa seems to have given the ball back to Adam Barth and
the HTTP working group. Do we know whether Mark Nottingham is
OK coordinating this discussion?
LM: He seems to be.
DC: Do we know if software provides (Mozilla, MS, Apple, etc.) are engaged?
<DanC_lap> aha... mnot has added an HTTP WG issue, #155. http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0114.html
LM: Looking at April-June postings I see Eran, Ian Hickson, Anne van Kesteren (sp?), etc., so there's at least some engagement, yes.
<DanC_lap> ACTION-233?
<trackbot> ACTION-233 -- Larry Masinter to report back from IETF/HTML liason meeting in March regarding MIME type override -- due 2009-03-11 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/233
DC: Regarding soliciting TAG reviews.... I am optimistic that Mark Nottingham and the WG will come up with an answer acceptable to me. Tim, can you think of example test cases that would verify that?
TBL: There's the question of the draft, and a separate question of overall direction. Working groups should try to lead toward cleaner answers, and I'm not happy this is going toward a cleaner answer.
DC: Have you read this draft?
TBL: I think so.
DC: Which principle?
TBL: One should put pressure to ... (do it right?)
DC: Larry said there is engagement from the browser community.
LM: I see participation. I don't know that browser vendors agree with the direction and/or will implement.
<ht> http://www.w3.org/2001/tag/doc/mime-respect-20060412
<jar_> Dan wanted browser community engagement. But Tim was saying we should engage the content management system vendors. Those are different
LM: I suggest we check with Lisa & Mark and also with some browser vendors to get a sense of where this is going.
TBL: The question is whether the
TAG should at all endorse content sniffing.
... We could put energy into getting servers to meet the
original HTTP specification.
DC: I'm OK with that, but I want
the specs to agree with what people do. I'm willing to push on
the spec or the system.
... My use case is: a bug tracking system with XML and I want
to see it as text.
<masinter> wonder if this fits into the versioning framework?
<DanC_lap> it's not far, masinter
<DanC_lap> (yes, everything fits in versioning. versioning is computer-science-complete)
NM: My favorite variant of the use case is a bug tracking system with poorly formed XML as text/plain. Doesn't show at all.
LM: In some ways can be considered as a versioning question, if you believe that the media-types should have changed to match the content.
<ht> http://www.w3.org/2009/04/IMG_5179_s.JPG
<ht> http://www.w3.org/2001/tag/doc/mime-respect-20060412
DC: So, a next step is to follow up with Mark and Lisa
<ht> s/http://www.w3.org/2009/04/IMG_5179_s.JPG//
DC: Larry, will you followup with Mark and Lisa
<scribe> ACTION: Larry to followup with Mark Nottingham and Lisa D. regarding Adam Barth's sniffing draft [recorded in http://www.w3.org/2009/04/16-tagmem-minutes.html#action04]
<trackbot> Created ACTION-261 - Followup with Mark Nottingham and Lisa D. regarding Adam Barth's sniffing draft [on Larry Masinter - due 2009-04-23].
<Zakim> ht, you wanted to ask DanC about what the fate of our existing finding should be
HT: We do have a finding. It's one we reviewed and re-endorsed a few years ago. It's the authoritative metadata finding http://www.w3.org/2001/tag/doc/mime-respect-20060412 , and it has no place for what's in the Barth draft.
DC: Yes, that's why I reopened the issue.
HT: Yes, but I didn't hear you suggest what to do about the finding.
DC: Thought I did, can do it gain.
HT: (Scribe missed something). The scope of the Barth document is now smaller than it was. It would pass your text/plain test. It is not documenting what browsers do today. So, as best I can tell, it's misleading to say that this "documents the way things are".
<Zakim> DanC_lap, you wanted to suggest the "XML view source" case as something to track and to remind HT that we re-opened issue 24 and to note the XML-view-source test case/use case is
HT: The direction suggested is neither where things are nor what we suggested in the finding.
DC: We should see what the draft says about the XML view source case.
<ht> I read the draft as saying the View Source case would be handled correctly, i.e., the <-brackets would show
LM: Julian Reschke is another person was should contact
DC: Our finding has neither convinved those writing the sniffing draft to do differently, nor to get browser vendors to change what they do, so in that sense it's been ineffective
<jar_> how about promoting to rec?
LM: Would it be reasonable to ask some of the participants why this finding isn't helpful?
<Zakim> ht, you wanted to observe that the draft appears to address only a small set of cases. . .
<ht> We need to track down Hixie's original posting on why "Authoritative Metadata" doesn't work
<DanC_lap> oh.. ok...
<DanC_lap> (1) binary... image...
<DanC_lap> (2) RSS feeds...
<DanC_lap> scribenick: DanC_lap
HT: Barth's 9 Jan draft seems to
address just a few narrow cases... and is at risk of having to
be updated every six months if it's to be any ongoing use
... (1) binary data that are images...
... (2) RSS feeds served as text\html
<Zakim> noah, you wanted to talk about effectiveness of finding
HT: ... common cause... this doesn't represent the status quo eitherand will take work to get adoption
NM: on the effectiveness of
findings...
... it's usually indirect. Occasionally we have direct comments
on a WD, but more often it's indirect... [scribe struggles to
paraphrase]
LMM: so we have a finding and a situation; we think the finding applies to the finding but it's not clear to some that it does; would a note about the connection between the finding and the situation help?
<Zakim> timbl, you wanted to discuss ways forward.
<timbl> It is not juts a question of laying out an intellectual argument, itt is a question of whether to fight for the change, like commenting on this document and talking to apache
<ht> I note that the internet draft addresses some cases which the finding doesn't cover, and it says some uncomfortable things, e.g. extension-based strategies for HTTP-delivered resources are ruled out
<ht> ... another example of where we could try to make common cause
TimBL: there are more options than just leaving the finding alone or changing our argument; perhaps changing apache is the thing to do...
<Zakim> DanC_lap, you wanted to say no; ppl agree that the finding applies; they just don't find it compelling based on global cost/benefit analysis and to say HTTP and URIs are IETF
<noah> DC: Ot
<noah> DC: It's good news that this is being discussed in the HTTP WG
<Zakim> jar_, you wanted to say that going for 'W3C recommendation' would be a way to find out whether W3C agrees, and if so record that fact
DanC: [something about W3C and IETF venues]
NM: I think the suggestion to make something a W3C REC was re the authoritative metadata finding, not the sniffing draft
<ht> I also note that I read the internet draft as never leading to 'text/plain' being treated as text/html or text/xml or application/xml
<masinter> do we need a W3C/IETF coordination finding/recommendation, perhaps jointly with process issues?
DC: yes, I agree that peer review is important here...
LMM: there are coordination/architecture issues between W3C and the IETF...
<ht> It only provides for treating 'text/plain' as various image types, or application/{pdf,postscript}, based on the usual magic strings
<jar_> I didn't want to comment on this particular idea, just to advance the idea that peer review (in this case, the review required to go to W3C rec) has a lot of value, if we want to advance a document or issue
<ht> So although DanC's View Source of (broken) XML example will work, a corresponding View Source of broken PDF or Postscript example would _not_ work
<noah> DC: I hope we don't have to do a back ceremonial attack on the IETF / W3C overlap. Every chair is responsible for making sure that groups stay within charter, and do suitable coordination with other standards groups, etc. I hope that's already policy of the culture. Chairs do need help with this.
<noah> LM: This came up with the origin headers.
<noah> DC: Yes, and sniffing, and voice ML, etc.
<noah> TBL: Put TAG finding through IETF track?
<noah> DC: Interesting.
TimBL: how about putting the authoritative metadata finding thru the IETF standards track?
<Zakim> timbl, you wanted to ask about moving it to the IETF track
<ht> WooHoo, what a good idea -- let's get a BCP for servers wrt Content-Type going!
LM: another case is IETF geopriv and W3C geolocation API...
<jar_> What TimBL just said would be consistent with what I was trying to say about raising the level of review. Peer review can happen in either organization.
<Zakim> noah, you wanted to talk about finding on standards track
LM: the IETF geopriv had developed policy and the W3C geolocation API took a different tack
<Zakim> timbl, you wanted to suggest geopriv i son the table for the tag
[1:12pm] DanC_lap: TimBL: how about putting the authoritative metadata finding thru the IETF standards track?
NM: how does that work? in parallel?
TimBL: yes, in parallel; any conflicts would become apparent in the course of review
<masinter> brief idea: add reference from HTTP spec to the TAG finding
that reference isn't already there? odd.
<masinter> no need to "put it through the IETF process" as a separate document, perhaps confirm normative reference
HT: a BCP on server behaviour w.r.t. content type is one idea... re getting apache changed.
[I think apache has been changed, fwiw.]
<masinter> BCP on web server implementation?
<timbl> Or maybwe we should write Aopache code
<masinter> it's a problem with default configuration
<masinter> ... of apache
prefer to adjourn
<ht> Code will always founder on the configuration rock
<timbl> No, it will not.
<ht> A BCP that said "Thou shalt always allow local specification of Content Type" and "thou shalt not default to text/plain" would go a long way
<timbl> :)
ADJOURN.
<timbl> :-P
<timbl> text/plain; really
<timbl> ooops
<timbl> s/pllain/plain/
<timbl> s/realy/really/
