See also: IRC log
<jar> anybody home?
<noah> We're discussing comments on http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110930.html
<noah> Email from Ashok: http://lists.w3.org/Archives/Public/www-tag/2011Oct/0105.html
<noah> First comment email: http://lists.w3.org/Archives/Public/www-tag/2011Sep/0076.html
<noah> Björn Höhrmann writes in the email:
<noah> I saw &lquot;All media type specifications and registrations, especially for new types, must specify fragment identifier semantics&rquot; while scrolling through it. This kind of wording is misleading considering that the TAG has no authority over the requirements for media type registrations.
<jar> +1
<noah> We're working on a rewording...
<Ashok> How about if we add the words "This document recommends ..." at the start of the sentence?
<noah> hmmm....
<noah> Suggest a new section 6.0. Something like:
<noah> "In order to ground the semantics of fragment identifiers in applicable specifications, it is recommended that IETF media-type registration procedures be updated as suggested below."
<noah> Going on to next comment...from Jonathan...
<noah> http://lists.w3.org/Archives/Public/www-tag/2011Sep/0089.html
<Larry> IRI could reference both 3987 and 3987bis
<noah> Ashok: Agree on documenting abbreviations
<noah> Ashok: Agree that it's the HTML media type registration, not the HTML Recommendation
<noah> NM: Right, but the media type registration may delegate to the spec (channeling Tim, I think)
<jar> the problem with delegating # semantics to a format spec is that it doesn't have jurisdiction
<Larry> the HTML media type registration is in the HTML spec, as per W3C policy
<noah> NM: I assume the "editorial nit" is an editorial nit?
<jar> it has juris. if it says it does.
<jar> problem only comes if it defines fragid semantics but does not call itself the media type reg
<noah> Right.
<jar> i.e. the part of the format spec that says "a conforming document is ..." says nothing about conformance of documents of other media types that have fragids pointing in
<jar> pedantry.
<noah> NM: So, Ashok has gotten some informal advice (no quorum here). We'll expect a new draft, and will go for formal approval after nov. 15 (per Edinburgh resolution) unless we get more comments at TPAC
<noah> moving on to next topic.
<Larry> fragids and polyglot, and compound document formats
<trackbot> Date: 31 October 2011
Note: Qiuling is observer from Huawei.
[discussion on whether or not app cache manifest is actually comprised of URIs (it is)]
Henry: My argument is that part of the problem we are struggling with is: we believe that if something is a URI then we know everything we need to know about what it means. I think that's wrong.
... the ideology of early web specs came from e.g. roy fielding treating time-varried resources as first-class citizens. Resources vary over time. [NYTimes homepage changes all the time but is still the NYTimes homepage.]
... if I put up 5 pages of the form weather/city then it's reasonable to try weather/some-other-city and expect to get the weather for that city.
... under web architecture you have no grounds for complaint, but web site maintainer has violated a social contract.
... "indexical" is a word like "you" or "now" that can have multiple interpretations (but one meaning).
<Larry> quote from post: Look, this is not a scientific process of discovery -- "what is the meaning of a URI? Let's look at some use cases and discover..". This is a process of design; we're designing the protocol element URI (and IRI) and designing representation systems that carry meaning by using URIs. I'm saying that designing a system where meaning depends on external events is bad design. At best, Frege and Joyce might provide some
<Larry> additional frameworks for discussing the design choices, but I don't think they contribute even that
Henry: [presenting slides - which will be made available]
... [discussion on how use of names or identifiers depends on context]
... difference between referential and actionable context.
<Larry> "what this name refers to" => "what the utterers of the name intend for interpreters of the name to understand"
Henry: one reason to try to do this: there is a generalisation that covers a lot of use. By looking at it this way it becomes consistent. For example, contrast two local contexts, one using URI in an HREF (actionable), one using a URI in a RDF statement (referential)...
... for referential use, the fact that I could retrieve the document at the end of the URI is incidental to its use. For actionable, it's central to its use.
Hence, the 200 OK [response] should be more flexible.
Henry: So - 200 OK would no longer mean "here is a representation" - it would mean "here is a representation for the context"
<Larry> in particular, i want to argue against doing what Henry is proposing but to focus on design of RDF and related followon semantic web language contexts
Henry: What a URI in the first instance tells you is not what its referent is but how to get to its referent. What you get back may vary according the context in which you found the URI.
Tim: That would require magic.
Henry: One way to instantiate this would be to use mget (get metadata). [does not exist]
Larry: I don't like the direction you're going on how to fix this.
... we're engaged in design, not in discovery.
<Zakim> Larry, you wanted to agree with analysis but not the direction going
Henry: The way I would hope this to be taken: leading towards a question: suppose we want to use the web as it stands. I want to give advice that will work [within the constraints of current web technology]. We need a meta accept header. Accept-reflect, or accept-see-other...
Larry: I don't think that's the right advice.
Henry: I'm trying to explore a class of solutions like that...
<Larry> i'd rather see advice to create a new version of RDF which resolves the use/mention ambiguity explicitly
Henry: I don't think RDF is compositional.
<Zakim> noah, you wanted to say I don't like where this is headed for other reasons than Larry's
Noah: I expect that get representation of is different then getting metadata about...
<jar_> RDF is compositional and referentially transparent
Henry: Every URI has one meaning, but that doesn't tell you what a get should do.
<jar_> RDF takes URI meaning as an input
Tim: The architecture does tell you what a get should do.
<jar_> it's linked data practice that has to determine the interpretation
<jar_> and the problem is only that linked data practice is inconsistent
<Larry> i don't think the meaning of an assertion in RDF should depend on what HTTP servers return, I think that would be bad design of RDF
<jar_> and that's because there is no validation
<jar_> RDF does not work that way.
<jar_> RDF meaning depends on how its users decide to interpret URIs referentially
Henry: the problem is: 200 OK means "your requested use can be satisfied." It doesn't mean "your URI means something different than it did yesterday."
Tim: I feel a tremendous weight of previous discussions [on this topic] ... I've also got alarm bells ringing about a two-level solution.
... [parallel to DTD language to specify SGML doctypes
... ]
... Always prefer a 1-level design. Clean, consistent and complete.
... [speaking against using arguments from natural language]
<noah> nope, will try
Tim: [saying that objectors seem to be against use of # because it is 'messy']
Henry: The time-varying resource thing : believing that we know what we mean when we say http://guardian.co.uk - we are just fooling ourselves. You can't tell me anything at all about what that referent has to be for that to be true. We don't have any real understanding of what coherence condition there has to be on those conditions...
... we haven't drilled on that.
<jar_> I think there are two distinct attacks on RDF going on here. One based on actionability (HT), and one based on time (Larry)
Henry: I feel it is not unreasonable to say "I have these URIs, I want to issue gets, I know you are going to issue a 303 and I'm going to have to issue another GET. Can't we get that out of the way?" One approach might be to use accept-see-other: in your gets. Then from the server you can serve something different rather than a 303.
... what it means is: short-circuit the 303 referesh.
<jar_> or should I say the use of http: URIs in RDF
Tim: Yes. That's a piece of engineering we ought to do before the end of the afternoon.
<Larry> i would rather see use/mention/time disambiguation (like tdb) added to RDF
Henry: doing it with an accept header [is my proposal]
<Larry> i would not recommend people deploy difference in the deployed HTTP infrastructure; in particular, I dislike tying fixing this protocol to HTTP and its error codes
<jar_> did anyone read my web metadata memo? it was required reading for two f2fs. it addresses this in part
Tim: If you send the accept header then the server can say 200 but send back something else...
<Zakim> noah, you wanted to talk about HTTP
<Larry> read != absorb
[agreement to cut the chat]
<timbl> [the cat, not the discussion]
<Larry> i am opposed to tying semantic web meaning to the HTTP protocol at all
<timbl> timbl:
<jar_> ht, let's talk 3 relationships. 1. is representation of (what you GET), 2. is version of ( an info resource), 3. describes
Noah: the first thing is - can we agree that this not about what URIs identify or what their "definition" is... that can save us thrashing. The discussion is about http and how you can use it.
<jar_> ... you are connegging between 2 and 3
<jar_> yes, "identify" needs to be banned
<Zakim> Larry, you wanted to assert that the time-invarying meaning of http://guardian.co.uk is "attempt to use HTTP protocol to talk to host guardian.co.uk with path /"
Larry: I am strongly opposed to tying the semantics of RDF to http.
<jar_> (to whomever might be reading the irc log, I am not in the room, and nobody seems to be reading my IRC entries. they are for your amusement)
[discussion on the use-mention problem - and the fact that this discussion is not about it]
JAR: The key is figuring out how to state the problem. What's worked best for me is to avoid the loaded words. E.g. identify, resource, representation.
... I've been doing work about how the linked data community might use http URIs. This reorients the whole discussion.
<jar_> ht: not possible to dispense with URI identifying just one thing. Tim and Noah want to be able to say that
Tim: I am happy to switch to "referent" or any other word [if it helps].
Noah: Some of these words are used in the normative specifications.
<jar_> I have 3 docs in draft (in esw wiki)
<timbl> Tim: There is an antipattern in design of making a 1-level consistent system which almost works, and then to fix a remaining issue, adding a second level, a meta level of some sort. Problems this can get into trouble, sometimes by making, in the end meta-meta levels etc with no final solution, sometimes because there is actually no oil and water boundary between the two levels, sometimes because the second level just has its noew problems. the good pattern is:
<timbl> level, consistent and complete.
<jar_> 1. Requirements for change proposals. and a call
<timbl> HT: Tm and I asgree that we need to find a way to fix the 303 problem
Henry: We discussed: Exploring something like shortcut-303 as an accept header is worth doing...
<jar_> http://www.w3.org/wiki/HttpRange14Options
<ht> http://lists.w3.org/Archives/Public/www-archive/2011Oct/0034.html
JAR: I've tried to lay out what a change proposal could look like...
... in the document linked above.
... next steps are documented there.
<noah> ACTION: Noah to schedule followup discussion of http://www.w3.org/wiki/HttpRange14Options (per agreement in Santa Clara) [recorded in http://www.w3.org/2011/10/31-tagmem-irc]
<trackbot> Created ACTION-625 - Schedule followup discussion of http://www.w3.org/wiki/HttpRange14Options (per agreement in Santa Clara) [on Noah Mendelsohn - due 2011-11-07].
<noah> HT: We've been talking about section 5.3?
JAR: What you should look at is the wiki page. 5.3.
[break]
<ht> http://www.ltg.ed.ac.uk/~ht/wantOther.html
<jar_> larry, note that I put tdb: in the mix. attempting to keep all views represented - useful point of comparison
<Larry> I'd like some time to discuss the current state of work in IETF to get TAG input, participation, as it relates to TAG topics:
<Larry> - W3C and Registries (Happiana)
<Larry> - MIME and Web (Happiana, mime-sniff in websec)
<Larry> - Extensibility (IAB document)
<Larry> - IRI everywhere (IRI working group specs)
<Larry> (IETF groups are happiana, appsarea, websec, iri).
<Larry> Getting W3C/IETF liaison(s) to join us for some part of these would be great, as well as W3C staff involved in MIME registrations.
Larry: I made a list of things going on in IEFT relevant to things TAG was talking about.
<noah> Larry's list is in this e-mail: http://lists.w3.org/Archives/Public/www-tag/2011Oct/0104.html
Larry: there are probably more... Partly this was to talk about how the TAG could be effective in influencing IETF documents...
... we've had a lot of discussion about registries and their use. There was an ad-hoc task force working on making people happier with using IANA as a registry. Some of the proposals have to do with more transparency. It has been observed that there has been lots of misunderstandng of how the process works.
... in the TAG I was working on and this group has reviewed a draft on MIME and the Web. I got feedback from IETF participants that it wasn't helpful.
... some of the comments in that document were about MIME "sniffing" - so I've been working in that [ietf] group on the mime sniffing document.
... we've talked a lot about languages and versioning in the past. This has been a topic that has absorbed the tag. I see there is an IAB document about extensibility. Can you talk about that?
... and then - the TAG has had an issue open for a long time about IRIs - IRI everywhere. Making sure that W3C documents reference IRIs, etc...
... I would also add the URN topic because. There is a URN working group [in ietf].
[discussion on use of URNs]
Noah: We are having some activity on persistent URIs. This could be related to the same space as URNs.
Henry: We are going ahead work a workshop on the 8th of December in Bristol on persistent domain names - exploring the space of possible solutions ... addressing the issues entities such as national libraries have brought up about using URIs as references.
<stpeter> happiana
<Larry> happiana
<Larry> a) Reviewing and updating in general the processes around getting items into IANA registries, including media types and URI schemes. This work is ongoing https://www.ietf.org/mailman/listinfo/happiana; See http://www.w3.org/wiki/FriendlyRegistryProcess for one summary of issues, status, and possible resolutions.
stpeter: There's a bad UI to IANA... People outside the IEFT community don't know how they register things with IANA, etc... lots of things people have found confusing. Lots of people have said : let's just use a wiki. As a result, we've had discussions with IANA about how to improve the interface - e.g. better tracking tools [transparency of process].
... up to and including more polciy-related issues : what does registration mean? how much approval is there necessary?
... I tend towards the first-come-first-served side of things.
... I've been working on working on a ID encouraging people to not use X- things.
... working on this with Mark Nottingham and Dave Crocker.
Tim: I support this.
Noah: I like distributed extensibility - use namespaces - but some of that feels like X-.
... I'm not sure there are easy answers of how to get lots of people innovating.
Tim: in CSS, you've got -opera-roundedcorners-... -ie-roundedcornders-...
Larry: there is an activity in the IETF around improving accessibility and use of IANA as a registrar.
... we have a w3c process around using IANA as a registry...
plh: we do have a process for this...
Larry: I attempted on the happiana mailing list to raise a concern that it not sufficient to make registration easier. but that it is important to get the community to register things.
stpeter: Those two are probably connected.
Larry: We need to bring additional resources to get more things to be registered.
stpeter: I think there are 2 things - how can w3c work with iana, and also how does joe developer interact with iana?
... joe developer doesn't know how to get his URI scheme register somewhere...
... the guys who made up Skype: are doing it on the fly.
tim: Apple are doing this.
stpeter: it should not be so difficult to get this done (from a w3c-iana liaison perspective). How we reach the people out on the margin I'm not so sure.
Larry: there is a suggestion that the process for 3rd party registrations (so people could register things that they see).
stpeter: we could have a crack team
... We've been talking to IANA about making it easier...
<Larry> http://www.w3.org/wiki/FriendlyRegistryProcess
Tim: When it comes to mime types, is there a ticketing system?
stpeter: There is a ticketing system, it's just not visible (exposed).
... that's what we're talking about.
... IANA keeps track of things but no external visibility.
<stpeter> http://www.w3.org/wiki/FriendlyRegistries
Larry: Mark Nottingham put together a page about friendly registration process.
... what could to the TAG do that could help?
stpeter: Off the top of my head, I think it would be good to have a longer-term discussion. There are more policy issues here that it would be useful to chat through. The IESG members are sort of "in the way" here.
... it's slower than it has to be.
plh: sometimes I have groups who invent a new format and do not register the media type for the new format...
Tim: A rule in w3c is that all the info for the media type registration should be in the spec itself.
<Larry> http://tools.ietf.org/html/draft-freed-media-type-regs
stpeter: we need to deliver something that is more useful. Opening up the tracking system is the best first thing we can do . What happens after that, we can continue to explore.
Larry: the next topic which is related is mime sniffing.
stpeter: Mime sniffing has a long history. The widget spec references it. There has been some push back from IETFers.
<Larry> http://tools.ietf.org/html/draft-ietf-websec-mime-sniff
stpeter: it's more of an informational specification...
... should it just be limited to http? Should we talk more generally about mime sniffing in http and file: ? ...
Larry: a thumb-drive of files should be the Web as well...
Noah: When I deliver something through http - something served as text/plain and looks like xml with angle brackets but is not well formed. user agents that are correct display it as text. User agents that try to interpret it as xml will not work...
<Larry> thumb drive using file extensions? file: ? packaging? manifest? auxiliary content-type annotations?
Larry: another topic - google seems to be deploying an update to http - spdy. Is there an internet draft?
stpeter: no.
[some discussion on spdy]
<Larry> W3C had HTTP-NG work
[discussion on how much spdy is being used...]
Noah: it's all over SSL so that raises caching issues...
[discussion on IRIs]
Tim: should the TAG tell everyone writing a spec to use IRIs instead of URIs?
Larry: Maybe we should close this issue?
stpeter: we have the same thing in ietf with ipv6. It forces people to think about it.