See also: IRC log
trackbot, start meeting
<trackbot> Date: 12 August 2010
<scribe> scribenick: jar
RESOLUTION: approve http://www.w3.org/2001/tag/2010/07/15-tagmem-minutes
(discussion of agenda)
<Ashok> draft subject to further editing, hope to have it out in a week ... 45 participants across industry, around 43 position papers ... privacy icons idea ... may fail for the same reasons as P3P ... identify the parameters that users care most about and come up with machine readable things ... others vendors reluctant, but firefox eager to implement ... other thing: data that is gathered via API from the user, parallel to geopriv ... what secondary use, how long r
ashok: TLR on Tuesday said a workshop report will come out soon
... There's another privacy & data workshop coming up in October, somewhat different focus, W3C
note ACTION-455 remains open, we'll discuss when Dan A is around and report is out
<Ashok> Followup privacy workshop http://www.w3.org/2010/policy-ws/
noah: There's been some review and revision, any comments now?
noah: Propose to publish the report
RESOLUTION: Publish status report http://www.w3.org/2001/tag/2010/sum07
to be made fully public.
<noah> Previous discussion: http://www.w3.org/2001/tag/2010/06/24-minutes#item02
noah: We were supposed to talk about this on july 15
<noah> We are to discuss: http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html [email from Adam Barth]
noah: (in Larry's absence... hmm)
(everyone reading Adam's email)
<noah> The email from Adam Barth quotes Roy Fielding:
<noah> "Some people have proposed that most of that pre-processing be added
<noah> to the IRIbis spec, but I have seen no evidence to suggest that
<noah> such pre-processing is even remotely standardizable (it seems to
<noah> be different for every input context). If you can demonstrate or
<noah> get agreement on a single way to preprocess an input string, or at
<noah> least a few named processes (like single-ref and multi-ref), then
<noah> that would be useful.
<noah> ==end quote from Roy==
ht: Bullet number 2 "I object to HTML5 being blocked in the IRIbis working group..." - isn't this what Larry is trying to do in the IRIbis WG?
<ht> I'm ready to discuss, to the effect that we shouldn't discuss
<noah> NM: But that's offered just as rationale...then change proposal itself stands on its own, no?
<noah> HT: Not convinced...this seems fundamental to what LM et. al. are trying to do, no?
ht: I conclude we can't take this further without Larry, since the rationale depends crucially on the claim that IRIbis is holding things up, and we need to hear from him on that
noah: HTML is representative of a class of languages that will need this kind of processing - not unique
<noah> In effect, this change proposal urges the working group to adopt Roy's
noah: "In effect, this proposal urges the WG to adopt Roy's proposal" - what does this have to do with IRIbis?
ht: Roy's experience is directly contradicted by XML Core experience (system identifiers, LEIRIs, etc.) - there's quite a bit of commonality
<Zakim> ht, you wanted to disagree based on XML COre WG experience
ht: we discontinued work on a separate spec because IRIbis was willing to take it on... I think Roy's wrong
noah: Not sure the facts support what you [ht] say. The question is whether the place to specify common behavior is in IRI spec, [or someplace else]
<noah> Sure it defined what people type, to put it circularly, in the particular cases where someone's spec called for a string that was in fact a URI.
<timbl> People write?
<noah> What it does not do is outlaw the converse, I.e., for specs to call for strings that require processing to get to a URI.
<noah> (of course, there's usually at least UTF8 interpretation or some such)
ht: URI is only about what's in an HTTP request. Adam's claim seems to be that anything else needs to be in HTML5 spec
(scribe may have mangled that)
noah: Are we missing a window for constructive comments if we wait for Larry?
ht: Issue 56 is listed as open. Discussed 15 July. No apparent countdown.
<trackbot> ACTION-448 -- Noah Mendelsohn to schedule discussion of http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html on 26 August (followup to 24 June and 12 August discussion) -- due 2010-08-24 -- OPEN
noah: Nervous about this
<trackbot> ACTION-454 -- Daniel Appelquist to take lead in organizing possible Web apps architecture camp / workshop / openday -- due 2010-07-22 -- OPEN
waiting on Dan...
<trackbot> ACTION-452 -- Noah Mendelsohn to schedule, when Tim is available, discussion of redirection from A#B to C#D -- due 2010-08-17 -- OPEN
<noah> <timbl> ? GET A#B -> 307 C#D ??
<noah> JAR: We were confused in the minutes. It's wrong in the minutes (except in one place), and wrong in today's agenda.
jar: Meaning of A#B where A redirects to C#D
<timbl> ? GET A --> 307 C#D ??
jar: 307 C#D not allowed in 2616, but is allowed in HTTPbis
<timbl> in the LocatioN: field
<timbl> Why then did they change it?
<noah> JAR: In the location header, 307 C#D not allowed in 2616, but is allowed in HTTPbis
<Yves> GET /chapter2 => 301 /entirebook#chapter2
<noah> Is this the first precedent for fragment ids being part of an on-the-wire HTTP reference, as opposed to client-side only?
HT: The change to HTTPbis seems reasonable and meaningful -- if there's no # in the original URI(ref)
timbl: I'm surprised that this got changed, since all clients will have to be updated
HT: HTTPbis isn't final, I'm just saying why it is plausible
<timbl> The purl server will return this in practice
yves: Depends on media type, so if you have redirection [to C#D] media type will matter [?]
<Zakim> noah, you wanted to say seems somewhat antithetical to KISS
(scribe not getting what Yves is saying)
noah: Until now, the Location: header has been something you can do a GET on, right?
<timbl> No precedents already there
noah: Now we're going to have to distribute responsibility for resolution
<Yves> Yves: fragment processing depends on the media type, also the kind of fragment iss to take into account, absolute references, or relative references (like in xpointer), but the mechanism has to be defined somewhere
<noah> Well, as I said, if there is on precedent, then this is introducing architectural as well as code complexity. I basically always assumed that HTTP was oblivous to fragids.
<timbl> $ curl -I http://purl.org/dc/terms/title
<timbl> HTTP/1.1 302 Moved Temporarily
<timbl> Date: Thu, 12 Aug 2010 17:44:26 GMT
<timbl> Server: 1060 NetKernel v3.3 - Powered by Jetty
<timbl> Location: http://dublincore.org/2008/01/14/dcterms.rdf#title
<timbl> Content-Type: text/html; charset=iso-8859-1
<Yves> Location was absoluteURI, not relative ones
<noah> This violates RFC 2616?
So we're discussing what http://purl.org/dc/terms/title#zebra would mean
<noah> RFC 2616 is the current RFC.
<timbl> If in RDF you follow the latter thing you get a document which tells you about C#D
<timbl> The document C tells you about A
<timbl> This example does NOT work in Tabulator
noah: And what DC does violates 2616
<timbl> A 303 to C would have been perfect
jar: 303 Location: http://dublincore.org/2008/01/14/dcterms.rdf#title not permitted by 2616
<timbl> Location: http://dublincore.org/2008/01/14/dcterms.rdf
<timbl> would have been fine
<timbl> and then that document tells you about A#B
timbl: The new PURL software lets you do bulk 303 redirects
jar: Has it [the new software] been deployed at purl.org?
<noah> I just noticed that Paul Cotton is asking whether we have input on their distributed extensibility change proposal. Input closes within the next day or so.
<noah> We should briefly discuss that after we wrap this discussion.
timbl: I propose HTTPbis is wrong. We don't want clients to get confused.
... There is a perfectly good alternative for OCLC to use, namely 303
<Yves> Introducing fragment in Location is http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6
timbl: If HTTP Location: is going to change we need a very good reason
Yves: Best thing would be for me to track down discussion so far in HTTP mailing list
<Yves> another pointer http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103.html
<scribe> ACTION: Yves to locate past HTTP WG discussion on Location: A#B change, and make the TAG aware of it [recorded in http://www.w3.org/2010/08/12-tagmem-irc]
<trackbot> Created ACTION-456 - Locate past HTTP WG discussion on Location: A#B change, and make the TAG aware of it [on Yves Lafon - due 2010-08-19].
<timbl> ^ doc about how to change your PURL.
action-456 due 2010-08-17
<trackbot> ACTION-456 Locate past HTTP WG discussion on Location: A#B change, and make the TAG aware of it due date now 2010-08-17
noah: Deadline = tomorrow, from Paul Cotton
<noah> On 5 August I sent out: http://lists.w3.org/Archives/Public/www-tag/2010Aug/0002.html
<noah> No response.
<noah> Paul Cotton says input needed tomorrow, 13 August: http://lists.w3.org/Archives/Public/www-tag/2010Aug/0006.html
timbl: The call is for people inside the HTML WG to stand up for particular proposals, right?
ht: Of the 5 proposals, 2 were precursors, leaving 3 proposals, one of which is status quo. All 3 have champions.
<noah> Rob Ennals
<timbl> 4 obsoletes 1 and 2
ht: Proposals X and Y were put forward by Rob Ennals. 4 obsoletes 1 and 2.
<noah> #4 supercedes #1 and #2
<noah> All other proposals have advocates.
noah: Suggest: Thanks for soliciting input, our concern was that all proposals have advocates, and they seem to.
<noah> ACTION: Noah to respond to Paul Cotton indicating TAG awareness that all current proposals have advocates, and will therefore not be dropped. [recorded in http://www.w3.org/2010/08/12-tagmem-irc]
<trackbot> Created ACTION-457 - Respond to Paul Cotton indicating TAG awareness that all current proposals have advocates, and will therefore not be dropped. [on Noah Mendelsohn - due 2010-08-19].
<timbl> HTML and XML divergence
<timbl> Proposed new issue
<timbl> source document
<ht> Is the indefinite persistence of 'tag soup' HTML consistent with a sound architecture for the Web? If so, what changes, if any, to fundamental Web technologies are necessary to integrate 'tag soup' with SGML-valid HTML and well-formed XML?
<timbl> 54 is a subissue of the divergence isue
<noah> Title: Interoperability of HTML and XML
<noah> Product: HTML 5 Review
<noah> Shepherd: Tim?
<noah> Title: HTML and XML Divergence
<trackbot> ISSUE-66 -- The role of MIME in the Web Architecture -- open
<trackbot> ISSUE-67 -- HTML and XML Divergence -- raised
<Yves> related to http://www.w3.org/2001/tag/group/track/actions/428
<trackbot> ISSUE-41 -- What are good practices for designing extensible languages and for handling versioning? -- open
<trackbot> ISSUE-67 -- HTML and XML Divergence -- raised