See also: IRC log
[Two updates for agenda: sessions likely on Javascript security and Distributed extensibility]
AM: Hoping for drafts from Mark N. and Eren to start from. New draft has arrived from Mark N., "?? well-known URIs" [ref?]. Apparently a replacement for the site-meta draft, quite short. JAR likes LM's suggestion that we work on a whitepaper surveying the state of play wrt metadata
<DanC_lap> (I didn't get the impression that the well-known URIs draft was a replacement for site-meta)
<noahm> Well, Dan, the title certainly makes it sound different. I haven't read it yet. Do we have a link?
JAR: I took an action [ACTION-282] to draft a document in this area, which got closed for lack of action but I'm willing to resurrect this because I expect to have some time available not just formats and transport, but also life-cycle
<DanC_lap> action-281?
<trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62) -- due 2009-08-01 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/281
<noahm> ACTION-281 Due 30 Oct
<trackbot> ACTION-281 Keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62) due date now 30 Oct
<noahm> action-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on metadata architecture. -- due 2009-08-31 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/282
<noahm> Action 282 was reopened by editing the record, now has note stating: Reopened at Sept 2009 F2F because Jonathan says he is doing a draft after all. Expected to cover both access and formats (and maybe more).
<noahm> The action numbered 282 is now due Oct 13
JR: Next step will be a draft
LM: I'll be happy to contribute effort
<DanC_lap> action-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on metadata architecture. -- due 2009-10-13 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/282
<noahm> Preparing for call with Mark Nottingham and Lisa Dusseault, which will be in about 30 mins
DC: My starting point is the example of serving XML as text/plain, because you want to show the angle brackets but if you have various magic strings near the beginning, browsers will treat it as HTML anyway. Ian Hickson fought this for 10 years, then gave up and wrote a description of it (sniffing) into the HTML 5 spec. This was queried as it wasn't HTML, but rather HTTP. So Adam Barth took the relevant bit out and wrote it up as an Internet Draft. Not clear where this draft is heading. Both groups (HTML WG and HTTP bis WG) have closed their issues on this
NM: What are Lisa and Mark's roles?
DC: Mark is chair of HTTP bis WG, Lisa is relevant IETF Area Director. Should we leave the unsatisfactory status quo in place, or try to expose the unsatisfactory nature of the resolution?
LM: This is a kind of error-recovery issue. Browsers are trying to accommodate users who have tried to publish HTML, but are getting it served as text/plain, or who are publishing images with the wrong mime type, typically through no fault of their own
JR: But it's an odd kind of error -- it's undetectable. I've been burned by precisely DC's example
NM: Example here: http://www.hoahdemo.com/rte/Metadata/broken_text.xml
<noahm> (I may or may not leave that content up there for the long term...it's a page I put together mostly for my own use, but it's fine for everyone to try it.)
LM: Hixie is just documenting a compromise position wrt what the browsers are doing already
<DanC_lap> (Fielding gives a colorful history of the sniffing issue. I wonder whether to bring it up orally. http://lists.w3.org/Archives/Public/public-html/2008Jul/0038.html )
HT: My understanding is a bit different from what Dan said. I started out believing we had a problem. I said in my notes "shouldn't the fact that Adam Barth's draft is incompatible with RFC 2616" at least be acknowledged in the HTML spec. But, if I "follow my nose" from HTML issue 5 I get to this message
<ht> http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0473.html
<DanC_lap> (I don't think 5 is the right number)
<DanC_lap> relevant HTML WG issue is http://www.w3.org/html/wg/tracker/issues/28
HT: In that, Mark Nottingham says that sniffing does not conflict with RFC 2616. That issue is closed, but it's not quite clear from Tracker what logic was used to close it.
DC: We discussed this before, and you agreed.
<ht> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155
HT: For HTTPBis, it's issue 155, which appears to say that "provided user controls are in place, sniffing will be allowed."
<DanC_lap> "HST: OK, thanks for clarifying, I understand better now" -- http://www.w3.org/2001/tag/2009/09/10-tagmem-minutes.html
HT: Seems to contradict Dan's saying that a user surveying pertinent specs won't discover the problem. I think if HTTPbis goes this way, we'll have to revisit the authoritative metadata finding.
DC: Would like to see what Henry is referring to.
HT: From HTTP bis issue 155:
HT: The language should be updated to reflect this reality, without unduly encouraging the use of sniffing except where necessary. Ideally, it will be done in such a way that:
* Does not require sniffing for all uses of HTTP (i.e., a particular implementation and/or user can "opt in" to the use of a sniffing algorithm), since this is most commonly a problem for the browser case, and
* Specifically allows a user and/or content provider to opt out of the use of sniffing in a particular interaction, and
* Promotes interoperability (i.e., if two implementations sniff, they will do so in the same way).
DC: But they didn't do that.
DC: Looking at ticket 155. . .
<noahm> Note proposal 8 weeks ago:
<noahm> Proposal from HTTP WG meeting: remove the sentence:
<noahm> "Note that neither the interpretation of the data type of a message nor the behaviors caused by it are defined by HTTP; this potentially includes examination of the content to override any indicated type ("sniffing")."
NM: It appear that the HTTP bis WG has in fact done that deletion
<masinter> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-07
NM: looking at section 3.2.1 in current draft having difficulties
<DanC_lap> http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07#section-3.2.1 perhaps?
<DanC_lap> "Note that neither the interpretation of the data type of a message nor the behaviors caused by it are defined by HTTP; this potentially includes examination of the content to override any indicated type ("sniffing")."
DC: Not clear if this has been removed
<Zakim> noahm, you wanted to ask about functions vs. specs
NM: Two issues for the TAG:
... 1) How strong do we feel about this?
... 2) What does and should the specs say?
<DanC_lap> (so indeed, it'll be handy to have Mark help us navigate their issues list and tell us what the status of this issue is.)
NM: We all agree that in the real world this shouldn't be necessary. But how can the TAG be helpful given the exigencies of the real world where it is?
DC: I think the Authoritative Metadata should be revised. RF said "over my dead body" wrt that proposal some years ago
<noahm> http://www.w3.org/2001/tag/doc/mime-respect
HT: No, I remember the exchange: the TAG's position is (was) don't do that. period.
TBL: The architectural rule is "don't do it"
TBL: That's still the right architectural decision, and when it's not observed there's damage
<Zakim> timbl, you wanted to wonder about a practical solution being to involve the user and keep a per-site kludge list like for "bad" certificates.
TBL: You could address this by browsers have a way to record user preference to see some 'text/plain' as appl/xml then you could generalise to "should I always treat text/plain from [this site] as appl/xml?"
LM: But there's no point in writing a spec. if browser makers won't attend -- true or false?. I haven't been able to rebut this
TBL: For example, wrt certificates, we argued for years to improve things, and they finally moved. We could find out what the facts are, and if we made a proposal which helped the browsers, they might find it helpful
LM: So, we could say we don't want W3C to publish a spec. which encourages sniffing
DC: Not without showing a way out of the current local minimum. Could we build an extension which illustrated TBL's suggestion?
HST: Depends on whether there's a hook in Mozilla for this case?
DC: Or we could ask for a hook -- that's easier than asking for a change in the UI
[Lisa Dusseault and Mark Nottingham join the meeting via the 'phone]
NM: Thanks for joining us to discuss sniffing. Our starting point is that architecturally sniffing is bad, but maybe there's a case for at least documenting the workarounds for the practical difficulties caused by misleading media types
MN: Our issue 155 is about sniffing
MN: we came to consensus that HTTP should get out of the business of ruling out sniffing and just say that Content-type: is for users to indicate what they think, but not say "don't sniff". So don't encourage it, and certainly not require it, but stop making it non-conformant to do it. Then there can be a draft such as Adam Barth's. There was discussion about including something in the HTTP bis draft itself on how to sniff, but we didn't go there
NM: Stable now? Anyone pushing back?
HT: The last decision we see recorded on your issue 155 seemed to be to remove the text.
MN: I believe it's stable
HST: But you appear to have removed the spec. which allows it
<DanC_lap> "nothing in the HTTP spec that says you can't". so the spec is silent on it.
MN: But there's nothing which rules it out -- we pulled that text because some people thought it went too far towards encouraging sniffing
LD: We've told Adam Barth that to take his work forward, he would need to either: 1) Form a WG around this topic to take it forward; 2) Get it encorporated in the HTTP bis draft (although MN has declined to do this for the time being); 3) Get an Area Director to sponsor its publication as an Informational [RFC]
NM: Could HTML 5 reference an Informational normatively?
LD: That's a complex question of how W3C and IETF processes interact. . .
LM: We're still dancing around the question of what the right behaviour is wrt the fact that deployed software does error recovery which is heading for being embedded in standards. I'd like to avoid having this stuff ping-pong between W3C and IETF
TBL: I put myself on the queue to say I would like a name for a clean HTTP. If there's sniffing in it, call it something other than HTTP -- HTTP_unclean. We should continue to promote the clean version
NM: Do you want the difference in-band in the requests?
TBL: No
DC: Wrt ping-pong, when one org's group starts overlapping with the other's, there has to be interaction at least we got the overlap area broken out into its own draft but the HTTP bis WG has decided to be silent about this. So the question has become whether to reabsorb the AB draft, or sight it as Informational
LD: I don't know about your process, but we have an explicit mechanism in our process for referencing an Informational
DC: You can do it unless someone complains
LM: It's like referencing a Note -- can you do that normatively?
HST: Yes
DC: Unless someone complains and it's upheld
<noahm> [John Kemp arrives]
MN: We were asked to confirm that HTTP bis doesn't conflict with sniffing, and we decided to accept that. At the moment we're waiting to see where AB's draft goes. It's not strictly speaking in our charter to incorporate it. But we could revisit that if we needed to -- might require agreement from Lisa. Wrt HTTP_Unclean, we should come up with a browser profile for HTTP usage, which said "use [this URI cleanup] and [this sniffing] specs in this way". So it would be a separate profile, rather than forking the HTTP spec itself
TBL: So documenting a set of willful violations would be a good thing?
MN: We're coming to the conclusion that it's not a violation
<Zakim> masinter, you wanted to ask whether there have been other cases where stuff has bounced over the boundary between application semantics and protocol semantics
MN: Remember WSI -- they built profiles by combining other specs -- HTML 5 should be a spec. for a language, and a story about browser behaviour should be told elsewhere, in a similar way to the WSI stuff
LM: HTTP defines the protocol and what it means, and the browser spec. specifies how it uses the protocol, with some wrapping/post- and pre- processing. E.g. "HTTP says this is 'text/plain', but in such-and-such a case, you should ignore that and use ... instead" is there another example of this?
MN: Content-type and Content-encoding
LM: That's for browsers -- any other applications -- using SIP (?) for instance?
MN: Not aware of any. . .
LD: There is some precedence for one IETF spec. saying "MUST" which overrides a "MUST NOT" in another spec.
LM: What about CRLF in mime vs in HTTP -- HTTP overrode that to match current practice
MN: Yes, header length and header wrapping minutiae -- HTTP is not a mime protocol but its a mime-like protocol. . . .
HT: Part of the TAG history, is that when we last discussed this issue, in the context of our "Authoritative Metdata" findin", we decided not to change it. The finding thus continues to say that authoritative metadata is binding. We believe that finding author [editor?] Roy Fielding's view is that changing this would be "over his dead body". Seems like people are feeling "worn down". I think I know what Roy would say. But...
MN: Hard to answer
<Zakim> lisa, you wanted to try to sum up current consensus
MN: We did pull that text we talked about, because it was too explilcit -- "not in our spec.", what they do in their own specs is on their back
LD: We are doing more reality-based protocol design, less policing. Maybe this means lots of health warnings. So e.g. Geopriv clients shouldn't accept 'text/plain'....
MN: The concerns haven't been so much around purity, as around the viability of this as a long-term solution
<timbl> Go not gently into that good night -- but fight, fight against the dying of the light. [From Dylan Thomas Do not go gentle into that good night]
LD: Having a real document setting out how it can be done reasonably well changed the debate
TBL: But it's harmful, it makes things break -- we can't forget that. If you intentionally serve some XHTML as text/plain, as an example, it's just broken if that isn't displayed as such
<noahm> Example that breaks browsers that sniff: http://www.noahdemo.com/rte/Metadata/broken_text.xml
TBL: there are also potential security holes. It makes specs more complicated. It's important to describe the system which works as the architecture specifies
<noahm> The example is meant to illustrate a bug reporting system, in which the desire is to show the user buggy XML as text/plain.
TBL: and separate out the accommodations. I'd like a browser to prompt me before using sniffing to decide how to render, so I can decide whether I want this done for this site
NM: Positive steps?
TBL: I like the idea of a browser profile -- put all the kludges and fixups there. But I don't want HTTP to include a sniffing section
NM: So the current HTTP spec. is OK by being silent?
TBL: I'd prefer it to point out the damage the comes from sniffing, but also reference the AB draft
<HST:> HST thinks "Your foot, your gun, your bullet"
LD: Yes, we are trying to work that way
NM: If the TAG were to undertake to produce a finding or a REC of the form "Here are guidelines for using internet protocols and formats such as HTTP and media types and ... in a style which meets the needs of the browsing community" which would either explain how or point to e.g. AB's draft on how to do this, and point out the pros and cons is that what you had in mind TBL, and should the TAG do it?
<masinter> I like this: MIME types, URIs, HTTP protocol, maybe other IETF BCPs?
TBL: I think it should happen elsewhere
NM: More to do with LD and MN?
HST: No
NM: MN and LD, anything more?
LD: Better coming from the community
NM: Thank you very much for joining us
<lisa> thanks that was useful to me too
[LD and MN leave the call]
<DanC_lap> some clues on mozilla hooks re media types: http://brh.numbera.com/blog/2009/02/24/jsonview-view-json-documents-in-firefox/
[adjourned for break until 1105]
[resuming]
NM: Agenda discussion -- more on sniffing, or. . .
DC: Sniffing, maybe. How to clean up metadata:. List of legacy sites. Treat as text/plain option (extension). Opera already has a list of sites which it patches CSS for or some such. There is a FF extension which allows JSON to be viewed instead of 'Save As...' so maybe there could be a generic show as text/plain extension
NM: What about an 'i really mean it' media type header?
HST: Microsoft tried it, didn't they?
TBL: I thought that would have been fine, yes
HST: How does the user indicate to turn that on
TBL: It's turned on by default for new sites
NM: [an untarring example?]
<masinter> example was whether web hosting sites provision servers by installing (untarring) old blog software that had bug that images were served as text/plain
JK: Suppose the user maliciously serves javascript as text/plain, Adam Barth says this is a security hole
DC: This hole requires sniffing for the privilege escalation to happen
NM: But if you had a switch that said "don't do that", there's not escalation
DC: [draws and speaks to a timeline]
HST: Does or does not AB's draft mandate leaving explicit text/plain alone?
[WG reviews the AB draft: http://tools.ietf.org/html/draft-abarth-mime-sniff-01]
JK: OK, explicit text/plain must be left alone
DC: So that's FF behaviour, not IE
<jkemp> (section 3 of AB draft, Web Pages, step 3)
NM: What about images served as text/plain
HST: I think that's caught as binary by the algorithm
[WG goes back to the draft]
TBL: It's not the format that's safe/unsafe, it's what you do with it. Safari is confused about this. I think this is worth saying
LM: I can see no motivation for ever sniffing postscript or pdf. I believe that Adobe folks thought this wasn't important to sniff if it did happen. What's the use case? Or for XML?
TBL: Because stuff is served with no Content-Type?
NM: It's plausible to me that there's PDF being served with no Content-Type
DC: The goal is to get to the point where if you mislabel your content you will have to fix it. The new idea is to bake the list of sites which need to be sniffed into the browsers
LM: If for the only things mislabelled at a site wouldn't give any clear benefit to users if they were sniffed, then they don't need to be on the list
HST: How's it going for IE8 wrt conformance opt-out?
DC: I understand this includes a baked-in list of known-need-fixing sites
TBL: I support this
HST: It's an important precedent for shipping strict and allowing exceptions to be logged
<Zakim> timbl, you wanted to note that the browser can generate the lists before it starts using it, if you allow a bit of feedback.
<masinter> i think we should push back on sniffing, that there needs to be a clear user benefit to someone for sniffing, that it isn't enough that there's some content that browsers currently sniff, it actually has to be shown to be important
TBL: The list of legacy sites can grow in a distributed fashion
DC: Lots of cleverness possible here
<masinter> I don't think we should rely on the wisdom of browser implementors to have actually done the thing that is best for their users, some browser "error correction" behavior might have been speculative
NM: What about the "i mean it" flag?
DC: We don't know what the facts are. . .
NM: DC, next step?
DC: Ask Microsoft to do this?. Seems to me this would work
LM: I have come to wanting to push back on the sniffing draft as being speculative that is, codifying what browsers do, minus escalation. A lot of these may have been speculative patchup by a browser implementor but assuming that all of these are actually in users' interests is dubious. Maybe they were just generalising unnecessarily. We need to see clear user benefit before we endorse this, line by line
HST: Isn't sniffing PDF when you have the 'unknown type' case a user benefit?
LM: No -- I think unknown should always take you to application/octet-stream, and users have to choose to ignore or save. Then it's their choice to try it as PDF
NM: Maybe it would be good to find out if the current algorithm is desirable wrt user benefit, but independently of that, documenting what current practice is is useful
<masinter> i am opposed to mandating (rather than describing) behavior that has no clear user advantage, especially where that behavior is at odds with other specifications
NM: What the TAG should be doing is documenting what is or isn't good about that, and how it's architecturally good or not
LM: I think the clear priority of the [HTML] WG is to match reality, and that's not what users need, but what browsers do there's some correlation, but it's not perfect the pressure to ship is sometimes primary
<jkemp> if there is the opportunity to do something clever without negatively impacting security, I think we should leave that possibility open
NM: Disruption to users is presumably high on the WG's list, we have to be careful
<masinter> i wasn't arguing this on "architectural purity" grounds, but on "must have clear user benefit"
HST: Note that contrary to what LM implied, the AB draft goes beyond just documenting what browsers do, by ruling out priviledge escalation. . .
DC: LM actually acknowledged that security concerns had led to some changes
HST: OK, sorry, missed that
TBL: There have been strong statements from the HTML WG that browsers that don't do sniffing suffer in the marketplace maybe everybody has converged, so there can't be any hard evidence
<Zakim> masinter, you wanted to say that NM was arguing against a strawman
TBL: by maybe it can have gone to far
LM: I'm not saying that some sniffing doesn't have user benefit but that not all of the draft stands up to that test. For example sniffing postscript is pointless, given that most browsers won't do anything with the information anyway
<DanC_lap> (timbl re "treat as text/plain", fyi, LeeF just told me about http://www.spasche.net/openinbrowser/ which seems to support that.)
NM: But that would compromise vendors ability to say "This version is backwards compatible with last years", full stop. and not by cases.
<DanC_lap> ("This extension won't be useful anymore once Bug 57342 and Bug 258012 have been implemented.")
NM: what next?
DC: 1.5 hours on Friday to write a blog post about Hixie's draft?
<noahm> close ACTION-257
<trackbot> ACTION-257 invite Mark Not or Lisa D to revisit progress in IETF/HTML liaison on content sniffing closed
DC: What about updating authoritative metadata?
HT: Shouldn't that wait on seeing what httpBis says?
HST: I heard TBL say things which suggest we should push back on the current state of the HTTP bis draft. Because it doesn't say "Don't do that: sniffing breaks things"
NM: [ proposes update to Self-describing Web, because it assumes Authoritative Metadata]
DC: +1
<DanC_lap> (what Noah is saying is what I have in mind. We don't change the architecture, but we do FYI: widely deployed practice diverges in the following ways...)
<noahm> Right. I would change SDW to say: the chain of specifications holds only insofar as you act on the authoritative metadata. That said, if sniffing goes ahead, users should be warned that they may sometimes be shown information inferred from sniffing, that such information is not in all cases traceable to the SDW chain of specs, and thus is to some degree suspect.
DC: I don't think we should change the fundamental conclusion of Auth. Metadata, but we should clarify that the world hasn't agreed 100%
<jkemp> here's a diff of the changes to HTTPbis for sniffing: http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/155.2.diff
NM: I think we can be confident that some justification for browsers continuing to sniff will be forthcoming so let's go ahead and explore updating those two findings
<scribe> ACTION: John to propose updates to Authoritative Metadata and Self-Describing Web to acknowledge the reality of sniffing, due 2009-10-20 [recorded in http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01]
<trackbot> Created ACTION-308 - Propose updates to Authoritative Metadata and Self-Describing Web to acknowledge the reality of sniffing, due 2009-10-20 [on John Kemp - due 2009-10-01].
HST: Are we happy with the state of the HTTP bis draft wrt sniffing?
<DanC_lap> jkemp, are you confident that diff is after the WG decision that mnot informed us of?
[pause to find authoritative draft of IETF bis part 3]
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07
NM: Do we believe they are still planning further changes to the draft at that URI, or is it likely to come out in the current form?
HT: Seems like more changes coming.
NM: OK, then I think it's premature for us to plan a response.
<ht> http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html
<ht> That URI does identify the text after the edit we have been discussing, to remove the final paragraph of 3.2.1
<DanC_lap> (remind me where the remaining sniffing text is? it doesn't use the word "sniff")
JK: Another important change, is that an 'if-and-only-if' was removed from the no-content-type case
trackbot, status?
<scribe> ACTION: Henry S. to bring back proposed TAG pushback on sniffing and HTTP bis draft http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html, or his recommendation that we leave it alone [recorded in http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02]
<trackbot> Created ACTION-309 - HST to bring back proposed TAG pushback on sniffing and HTTP bis draft http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html, or his recommendation that we leave it alone [on Henry S. Thompson - due 2009-10-01].
[adjourned until 1345 for lunch]
[resuming]
<DanC_lap> js sec, plenary, writing session, what got booted...
<DanC_lap> again, on ECMA foo: Archived-At: <http://www.w3.org/mid/4ABB67E8.4080408@intertwingly.net>
<noahm> ACTION: Noah to check with Sam Ruby on ECMA/W3C activities at TPAC [recorded in http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03]
<trackbot> Created ACTION-310 - Check with Sam Ruby on ECMA/W3C activities at TPAC [on Noah Mendelsohn - due 2009-10-01].
<jar> http://www.w3.org/TR/WebIDL/
<DanC_lap> also note work on a WebIDL checker http://lists.w3.org/Archives/Public/spec-prod/2009JulSep/0000.html
<DanC_lap> scribenick: DanC_lap
agenda order is 1, 6, 2
agenda order is 1, 3, 6, 2
action-284?
<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web Application ( http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ) outline with as many sentences as he can -- due 2009-09-15 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/284
updated outline: http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921
discussion of level of interest, expertise, etc. ...
<masinter> +q to look for areas where this isn't just "good CS", i.e., things that make this web architecture vs. architecture
discussion of parallels with work on WebArch v1
<Zakim> masinter, you wanted to look for areas where this isn't just "good CS", i.e., things that make this web architecture vs. architecture
JAR: I touched on that in "Goals: Network effects, overall user experience (not just at your site), robustness, enabling automation. You should read this document if and only if you care about these objectives."
LMM: the 2 I can think of are: relationship beetween the static/document web and the semantic
web and the application web the google maps URI for something was a good example. [of ...?
scribe might have missed a bit]
... 2) trust. in AWWW [webarch v1] there's discussion of authority
and ownership, which is a sort of trust model...
HST concerned he's missed some of the scribe log -- RRSAgent wasn't watching -- we seem to drop into the middle of the web sockets topic http://jkemp.net/tag/hybi.html -- DanC, do you have local copy?
<masinter> if I'm running web sockets and i'm talking to someone i know is running web sockets, that's the simplest method, we'll just talk websockets
LMM: e.g. it might be used to get stock quotes, but not by a RESTful GET on a stock price resource.
<masinter> but if you're over port 80 and you're in a hotel and it is noon, port 80 request might get intercepted and the hotel ask you to log in and pay for another day's internet access
LMM: no links, bookmarks, etc. ... like web services
HT asked for a motivating example in order to get context for [which question? scribe lost the train of thought]. We go back to slide 1... IM, multiplayer gaming... TBL suggests collaborative spreadsheets
HT: years ago Richard Tobin and I did this sort of thing in a RESTful way... with URIs for the interesting things...
JK: yes, people do these things over HTTP, in a RESTful way, but they run into issues... proxies buffer multiple events into one response another: the 2 connection limit from RFC2616 [which LMM points out has been relaxed in HTTPbis]...
LMM: the reasons for that 2 connection limit are historical; it's been replaced by "do the right thing"
JK: 3) the UPGRADE header is not passed along by proxies
DC: huh? how did UPGRADE come up in a list of issues re RESTful access?
<Zakim> DanC_lap, you wanted to ask LMM more about IETF status of hybi wiki and to note the presentation I saw at the SFO IETF convinced me you need 2 HTTP connections
HT: Why do Bayeux and BOSH need to use Upgrade: ?
DC: I saw a presentation on several of these. One was from Jabber XMPP suggested best design is two connections.
NM: To avoid deadlock?
DC: Maybe, or might have been Javascript issues. Anyway, Websockets is only one connection.. Larry, you said are we aware of hybi, and we said yet. Then you said something about working group. Is there a working group?
LM: There was BOF and discussion of proposed charter
DC: on hybi... when is it likely to be an IETF WG?
LMM: at the Nov IETF meeting in Hiroshima... the charter wrangling issue is whether a "2 browsers" constraint should go in the charter as to why this shold be a WG... it's to get the middle of the network.. proxies... cisco... to acknowledge this as legitimate to address reliability issues
<masinter> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00974.html
NM: what I wonder if what the TAG should do is... consider this story...
<jkemp> http://trac.tools.ietf.org/bof/trac/wiki/HyBi a good resource
NM: [something about self description or not. scribe is lost.] media types... following links... content negotiation to use same URI for RDF and HTML representations so that's motivation for traditional RESTful access...
<jkemp> Note:
<jkemp> A sentiment has been expressed that perhaps the HyBi group should not try to pick a specific "winner" with regards to selecting a single bidirectional protocol. Instead the group could examine issues that exist for using the HTTP upgrade mechanism to upgrade to an arbitrary bidirectional protocol and produce recommendations for HTTP clients, servers, proxies and gateways that would allow various protocols to be used, to evolved and to compete for wide support.
<jkemp> from HyBi wiki
NM: however, sometimes [this other pattern?] is more appropriate. the trade-offs are...
JAR: I expect this advice is already known by the relevant communities
<DC:> [it's not at all clear to me that what websockets is for is written down anyplace mere mortals should be expect to find]
TBL: even in non-RESTful cases, self-description is nice... e.g. SMTP "explain"
NM: it's not clear to me that the community knows this stuff. I get questions about how to think about such things. That's the main value I get out of TAG findings
AM: in the Web Services world, there are at least a couple specs that tell you how to do this: WS-notification, WS-eventing... those are significantly more complicated; they have: subscribe, timeout, unsubscribe... pub/sub
JK: I think this is much lower layer
AM: transport layer?
JK: yes
HT: NM, when you asked about the TAG's feelings on RESTful access... I'm surprised you didn't mention the use of GET for something that can do things
TBL:'UPGRADE' is a get-out-of-jail-free card -- it means the semantics of the request are changed
HST Ah, ok
<timbl> GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample
<jkemp> ^sample is from http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-43
TBL: historically, I thought of UPGRADE for switching to X windows... but are there other uses of UPGRADE?
JK: HTTPS
<jkemp> (^sample is from)
<jkemp> http://www.ietf.org/rfc/rfc2817.txt
<masinter> Presently HttpCore provides support for HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies as specified in the RFC 2817. However, HttpCore currently does not support 'Upgrade' / 101 (Switching Protocols) handshaking, which does not seem as widely used by the common HTTP agents and servers as HTTP CONNECT.
<masinter> http://issues.apache.org/jira/browse/HTTPCORE-158
<masinter> ISA Server does not support the Upgrade header. If a client sends a request containing this header, it is ignored by ISA Server. Both client and server will use standard protocols.
<masinter> http://technet.microsoft.com/en-us/library/cc302548.aspx
<ht> http://issues.apache.org/jira/browse/HTTPCLIENT-751
JK: The hybi activity seems to have started to document best practices, because of perception that straight HTTP isn't meeting the need.
<ht> 2008-02-11: "AFAIK, we're not supporting upgrade of a plain HTTP connection to HTTPS. We only support dedicated https: connections so far. HttpClient 4.0 should be flexible enough to add support for protocol upgrades. "
<ht> http://markmail.org/message/5zhsaxe3bnbd7cee
JK: Additionally, the W3C Websocket work has been sent to IETF, but there are others in IETF hybi who believe that websockets isn't the best way to meet the need.
JAR: If there's this much activity, it sounds like maybe we should table this for now.
JK: There's good stuff on their wiki.
DC: When the IETF is working on a charter, think to do is not to wait.
JAR: Sounds like materials are there.
DC: Can't say.
LMM: if we like the idea of best practices work, we could give that input now
JK: there are other proposals...
DC: I learned today about the message-oriented framing. That was useful, thanks.. Use cases on first slide and issues was also helpful, as was learning about status of WG. So, this was what I had in mind.
<scribe> scribenick: DanC_
NM: when we hear about other mechanisms... has the implementation train already left the station?
LMM: no... there's quite spirited discussion among representatives from Opera, XMPP, Linden labs....
NM: but about browsers...
JK: I think there has been little, but it's starting.
NM: Net, net, would people retune e.g. Firefox impl?
DC: Yes.
<masinter> http://www.ietf.org/mail-archive/web/hybi/current/msg00559.html
HT: does the hybi wiki cite this among others?
JK: yes
<ht> http://trac.tools.ietf.org/bof/trac/wiki/HyBi
<masinter> http://trac.tools.ietf.org/bof/trac/wiki
<masinter> http://www.faqs.org/rfcs/rfc2324.html
<masinter> XXXX is based on HTTP. This is because HTTP is everywhere. It could not be so pervasive without being good. Therefore, HTTP is good. If you want good coffee, XXXX needs to be good. To make XXXX good, it is good to base XXXX on HTTP.
[adjourn for break]
[resume from break]
HT: I hope to hear from LMM about the upcoming [Hybi] BOF
LMM: we could consider this a liaison activity... we expect ... [pronoun overload; which "they"?]
<masinter> I'm intending to be at IETF meeting and hope to attend HyBi BOF, but I don't have a commitment to do so, although I'm interested in the topic personally.
TBL: seems to me people are doing roughly the right thing; I'd be more motivated to act if it looked like they were doing something wrong
LMM: it's encouraging that W3C working groups are taking protocol work to IETF
action-301?
<trackbot> ACTION-301 -- John Kemp to review websocket protocol/api motivation and brief TAG at Sep ftf -- due 2009-09-24 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/301
close action-301
<trackbot> ACTION-301 Review websocket protocol/api motivation and brief TAG at Sep ftf closed
DanC: how about a similar session on web storage apis? Maybe I'll twist arms in a break...
<ht> http://www.ltg.ed.ac.uk/~ht/tag_persist/
action-33?
<trackbot> ACTION-33 -- Henry S. Thompson to revise naming challenges story in response to Dec 2008 F2F discussion -- due 2009-09-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/33
HST presents "Forever is a long time: Real persistence for the Web"
HT: with that, on to JAR's suggestion...
JAR: so take any competent repository administrator or librarian... they're dealing with all sorts of strings, whether they start with http: or doi: or otherwise... and on behalf of their users, they keep track of what these things mean they're going to build or buy or find a resolver... one choice of providers is ICANN/HTTP/DNS ... this pattern will hold regardless of which URI scheme they are using
<masinter> need to be careful to talk about the service provider for name resolution and the guarantee for being the authoritative service for resolving the name
JAR: suppose the repository manager believes me when I say "you can use HTTP URIs"... they'll be in the same situation as with urn: or other syntactic forms, they'll be in the same position of build/buy/find a resolver... could be a database, proxy, alternate DNS, etc.
<masinter> I think i really understand this now and i'm frustrated at not being able to explain it
<masinter> http://larry.masinter.net/duri.html
<masinter> is one proposed solution
JAR: so if they find some other resolver, they're doing something that's not sanctioned by Web architecture; not using ICANN/DNS/http
[fixing a bug in ICANN/DNS/http doesn't seem like something "not sanctioned by Web architecture"]
<masinter> the obtainer of a name gets a "name", but implicitly they get some kind of service guarantee from a name service provider, that for the period they have purchased, the name service provider will tell other people that the name they are using means what the original name obtainer meant
<masinter> the discussion Henry and JAR tell confuses who gets the name, who makes the service guarantee, and who is looking up the name and obtains the name resolution
<Zakim> DanC_lap, you wanted to offer that w3.org falling into the hands of bad guys is analagous to a linnean animal name morphing into a trademark for some megacorp
<masinter> using the "wayback" machine leaves open the question of how far back you go
<masinter> AWWW looks at "meaning" from the wrong end of the telescope. Meaning can't change based on operational behavior
DC: Not clear why the hypothesised situation would break WebArch
<masinter> if you get a linnean name, you get something from an organization that offers a long-term name resolution service
<noahm> ... Over time browsers would migrate to new URIs for W3 namespaces
LM: another attempt to explain what I've tried many times... when you get a name, you think you're getting something. But what you're really doing is entering into an agreement with a provider who offers the service of resolving a name
<masinter> http://larry.masinter.net/duri.html
LMM: [... trust me as an authority]. the urn: scheme delegates that to [one place] and http: delegates via ICANN/DNS/etc. one idea I've put some work into is to add a timestamp to a URI... duri means what that URI meant in the given date the current practice in academic citations for web pages is to note the date of access
<DanC> (the authority for the Linnaean names is the peer-reviewed academic community)
<DanC> (which was once one of the few people would could get things published.)
<jkemp> authority is not noted in the name itself
HT: well, let's please get back to evaluating the AWWW story about naming and authority
NM: perhaps we should push harder on having some DNS names where persistence is more guaranteed. e.g. a new root
<masinter> good papers in http://www.isr.uci.edu/events/twist/twist99/
HT: the "more persistent DNS names" idea is good, but making the domain name/owner binding stronger doesn't amount to a guarantee that it's perfectly strong
<Zakim> timbl1, you wanted to say one can always make a different resolver for http uris so long as it doesn't misrepresent -- so long as it doesn't give wrong data, where right data is
NM: [missed some subtlety about the stronger DNS idea]
<masinter> AWWW is wrong because http://www.w3.org/anything means "open HTTP connection to www.w3.org and ask it about "/anything". If you want something else you need "tdb", it's not optional
<masinter> and it doesn't matter how much you wish anything else
<noahm> I was noodling on the possibility that the guarantee would be such that W3C or anyone else "owning" a DNS name would have complete control over lines of succession for it.
TBL: JAR, there are lots of times when people know what an http URI name means without doing an http lookup; that's fine as long as it's not inconsistent with what you'd get if you did a lookup
<Zakim> timbl2, you wanted to suggest that extreme scenarious make bad design. Extreme situations occur with other things -- librraies with species in can get hacked, and specifically
<masinter> the leap of faith needs to be explicit
JAR: I'm talking about people using resolvers that are inconsistent with what you'd get with a lookup; e.g. OpenDNS resolves DNS names that normal DNS doesn't
TBL: starting with a screw case doesn't make for a good argument. The case of W3C losing w3.org is uninteresting.
TBL: The Commerce Department will take domain names by eminent domain
TBL: HT started by saying the Linnaean name system works great, but of course somebody could replace all the books in the library to screw it up.
<Zakim> timbl3, you wanted to say that in fact in a less wildy extreme scenario, in fact there is n serious value in pursuing more persistent domain names which the TAG could follow up
<masinter> 'meaning' is a verb, not a noun. a URI producer 'means' something and a URI consumer attempts to discover what the URI producer meant. To define 'meaning' as a noun in AWWW confuses these things. We're asking producers to have faith that http: URIs to mean what they want to mean, in order that future consumers can readily discover their meaning.
<DanC> (HT, recall that I pointed out that the URI would slowly degrade if the divergence between the software and the server at w3.org disagreed.)
<noahm> (DanC, I'm not so sure -- why? Everything would continue to work if both browsers and users continued to use it as the NS URI)
<DanC> (because people would not want to be associated with what the bad guys publish there)
<jar> timbl: New TLD for use e.g. for persistent http:
<noahm> ACTION Noah to schedule discussion of a persistent domain name policy promotion
<trackbot> Created ACTION-311 - Schedule discussion of a persistent domain name policy promotion [on Noah Mendelsohn - due 2009-10-01].
<DanC> ("permanent names" is a category error. as LMM points out, the request is for "permanent services" which is clearly absurd.)
<Zakim> timbl4, you wanted to point out that this is a question of trust, and trust has a lot of Not Invented Here to it, and many people will trust something when and only when they have been seriously
TBL: the actual case in the lifesci community is about trust... somehow they trust the LSI committe but not ICANN...
<masinter> http://www.isr.uci.edu/events/twist/twist99/ "problems URIs don't solve"
TBL: maybe if they'd been on the ICANN committee they'd trust them more... or if they'd been involved in HTTP [ESPEAKINGTOOFAST. bzzt.]
LMM: I think AWWW/webarch is wrong because it makes an implicit leap of faith which needs to be explicit...
<timbl> You can by the way bind the persistence not to an organization but to content (or meaning if you can define that)
LMM: the step of opening up a connection is implicit... and this leads to contradictory conclusions
<DanC> (it spells out that stuff a few sections lower)
<jar> there are no guarantees
LMM: if I write a URI in a book, and [something changes] it doesn't change the meaning of the book. Permanent names don't solve the problem that they're hoped to solve... financial failures etc. ... you come to the conclusion... that alternatives are no better than http
LMM: and in cases like doi and [missed], they're in a commercial position that we're in no position to argue down
<DanC> (lmm, sorry, I'm afraid I mangled what you said)
<Zakim> jkemp, you wanted to note that Linnaean names don't contain an authority
JK: Linnaean names have the feature that resolution isn't part of the name... I can use google...
<jkemp> neither resolution nor (any statement about) authority are included in Linnaean names
<jar> actually careful biologists will specify the last name of the author of the authoritative publication...
<masinter> implicitly 'search' becomes the naming system; it's a problem with folksonomies
<DanC> huh? resolution is involved any time anybody utters a Linnaean names and hopes somebody to understand
<Zakim> DanC_lap, you wanted to note persistence guarantees mostly come from either $$/lawers or rich social networks/communities
DC: The way you get persistence is either by protecting it with $$$ or with a large distributed community. IETF is a good example. Persistent names is a category error, not persistence names, but persistence services and persistent services are absurd. Endowed publication is a great idea
TBL: UK gives special status to e.g. the National Trust -- you can't get their land off them w/o an act of Parliament
HT: yes, Tim, you're right, hard cases make bad law... but certain constiuencies are obligated to consider the hard cases... these scholarly edition communities and lifescience identifiers communities can't avoid it this (2.2.2.1. URI ownership) is all webarch says about how URIs get their meaning
DanC: no, there's another section on how to resolve URIs
HT: but that says nothing about meaning
<jar> I think how to resolve is not the issue
DanC: see the intro, on the relationship between representations, URIs, and resources
<jar> (discussion of authority. is there a bug in awww. disagreement.)
LMM: I disagree that the owner determines the meaning of the URI...
<noahm> LMM: A URI does not lose its meaning because a service provider fails to deliver on their contractual obligation
<noahm> (HST, e.g. with respect to resolving the domain name part)
JK: You can type the URI into google
DC: Consider the way phone numbers work -- if you stop paying for your phone, its number will eventually get recycled to call someone else
<Zakim> jar, you wanted to talk about GBIF WG solution
LMM: It should say that if the ISP misbehaves the meaning of a URI doens't change. Tim: When we define a protocol, we say that if everyone obeys these rules, these are the good properties which result. We don't address normally what happens if you don't obey the rules.
<Zakim> masinter, you wanted to give some references to twist99 talks and to disagree that the owner of the domain is the "authority" to determine what the URI "means"
jar: the GBIF task force on identifiers decided that http URIs can be considered persistent, with alternative resolution option as an insurance policy against domain name loss. is this approach consistent with AWWW and the RFCs?
<DanC_lap> [... and that little clause, even if it never happens, allows these communities to buy in.]
<Zakim> DanC_lap, you wanted to note that IMGT allele names are being revised this year; things change; these communities deal
<jar> (noting that the GBIF folks tried out urns, and couldn't make them work... not necessarily through any fault of their own)
DC: You have to get people to use names to get them to mean anything. Speaking of hard cases the IMGT community are deciding to change all their names
JAR: They are ill-advised
<DanC_lap> ("the way"? it's an important way... a distinguished way... but not "the way")
<jar> noahm: usually you poke on something's URI to find out what it is, but this doesn't always work. you have to reverse engineer sometimes
NM: If I have a URI which identifies a webcam view of my back door. If someone else looks at it five nights running, they will legitimately conclude that my URI identifies a blank page
<jar> (LRDD would be the way you communicate what it's supposed to mean)
NM: The only definitive way to find what a URI means is to go to the owner and ask them
LM: No, that's just wrong -- AWWW is broken insofar as it says that
NM: [gives an example, scribe missed]
LM: Scenario 1: I give you a URI. Scenario 2: I give you a URI, but I tell you at the same time that the URI identifies a piece of paper, which I hand you. In scenario 2, the URI is useless
JAR: W3C specs are full of this -- they say "This URI means...." without any necessary correlation with what you get with GET
TBL: Do you mean, e.g., OWL spec says this that and the other are properties what's wrong with that?
LM: [put a document in a drawer -- scribe didn't catch]
DC: Can I assign meaning to numerals?
LM: You can't -- you can only tell me what you mean by them
JK: We've established community consensus that 23 comes after 22
DC: I give up
HT: I'd like to pick that up sometime
LMM: yes, I've been looking forward to this conversation
HT: Wrapping up... I'd like to come back to this sometime... I've heard some endorsement of the claim that webarch is incomplete/wrong on how URIs get and retain meaning...
NM: any other concluding remarks?
LMM: I think trust/belief are important... this conversation where Dan was getting frustrated... I think he was saying things that seemed obvious and I wasn't agreeing because he was leaving out subjects/objects.
<jar> dan likes the succession clause (see my comments above about GBIF)
DanC: my take-away is that this succession [sp?] clause is interesting... the fact that it allows people to get on with it seems great.
NM: the idea about more-permanent DNS names seems interesting... also, this idea that you can discover resource meaning by experiment... that it only sometimes works is interesting
action-33?
<trackbot> ACTION-33 -- Henry S. Thompson to revise naming challenges story in response to Dec 2008 F2F discussion -- due 2009-09-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/33
HT: I don't think this is higher priority than review of HTML, but I'd like to get back to it
<scribe> ACTION: jar to find a path thru the specs that I think contradicts Dan's reading of webarch [recorded in http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04]
<trackbot> Created ACTION-312 - Find a path thru the specs that I think contradicts Dan's reading of webarch [on Jonathan Rees - due 2009-10-01].
<jar> (the topic of how to find out what resource is meant has come up twice in this conversation, from noah and from ht - the idea that doing GETs is not adequate to find out what it is. ashhok and jar chant 'LRDD')
<jar> (and i think this orthogonal to the main conversation)
Adjourned until tomorrow