16:15:10 <RRSAgent> RRSAgent has joined #tagmem
16:15:10 <RRSAgent> logging to http://www.w3.org/2010/10/19-tagmem-irc
16:15:12 <DKA> DKA has joined #tagmem
16:15:25 <jar_> agenda: http://www.w3.org/2001/tag/2010/10/19-agenda
16:15:33 <DKA> rrsagent, start meeting
16:15:33 <RRSAgent> I'm logging. I don't understand 'start meeting', DKA.  Try /msg RRSAgent help
16:15:39 <ht> trackbot, start meeting
16:15:41 <trackbot> RRSAgent, make logs public
16:15:41 <Zakim> Zakim has joined #tagmem
16:15:43 <trackbot> Zakim, this will be TAG
16:15:43 <Zakim> ok, trackbot; I see TAG_f2f()11:30AM scheduled to start 45 minutes ago
16:15:44 <trackbot> Meeting: Technical Architecture Group Teleconference
16:15:44 <trackbot> Date: 19 October 2010
16:15:53 <ht> scribenick: ht
16:15:58 <ht> scribe: Henry S. Thompson
16:16:07 <ht> chair: Noah Mendelsohn
16:16:43 <ht> agenda: http://www.w3.org/2001/tag/2010/10/19-agenda
16:17:07 <ht> Topic: Admin and agenda review
16:19:04 <ht> present: Dan Appelquist, Tim Berners-Lee, Yves Lafon, Ashok Malhotra, Larry Masinter, Noah Mendelsohn, T V Raman, Jonathan Rees, Henry S. Thompson
16:21:05 <ht> NM: Recap of time as chair---coming up on two years
16:21:21 <ht> ... Better focussed on issues coming from the community
16:21:41 <ht> ... Some noticeable impact, but other areas where we haven't managed to achieve much
16:22:06 <ht> ... Obvious structural problems with affecting HTML5, but we have made some impact there
16:22:25 <ht> ... But on WebApps, where we said we would focus, we haven't achieved much as I hoped we would
16:23:10 <ht> ... Our history was for producing findings, which moved rapidly (some of them) and ended up being well-crafted
16:23:19 <ht> ... but that has stopped, pretty much
16:23:57 <ht> ... Partly because we said we wouldn't do Findings, but haven't succeeded in replacing that focus
16:24:14 <ht> ... Some counter-examples, but mostly because we haven't been putting the work in
16:24:34 <ht> ... People should be putting more time in
16:24:58 <ht> ... It's  destructive for a group to say: Here's what we're going to do
16:25:05 <ht> ... and then not do it
16:25:24 <ht> ... I'd like to see us figure out what we can commit to realistically, and then do it
16:25:53 <ht> AM: I agree, I'm frustrated with the lack of feedback on what I have written
16:26:18 <ht> NM: Meta-discussion now, or . . .
16:26:31 <ht> TBL: A bit, before we shift to substance
16:26:55 <ht> ... I have put in less time over the last year, I'm hoping that's over and I'll be able to start contributing more
16:27:22 <ht> ... I've written about net neutrality and people being cut off from the web
16:27:29 <ht> ... which I'm passionate about
16:27:42 <ht> ... Passion is important to the TAG's motivation
16:28:02 <ht> TBL: Mime, URIs, yes, those are crucial
16:28:12 <ht> ... What is it about webapps that are crucial
16:29:04 <ht> TBL: I'm tasked with bringing back two TAG goals for the next six months to Jeff Jaffe
16:30:01 <ht> LM: The driver for anyone is "Who wants it" -- the fear of not meeting peoples interests is demotivating
16:30:29 <ht> LM: (to TBL) You and Jeff should drive us -- what should we be working on?
16:30:41 <ht> TBL: But goals for us don't come from management
16:31:03 <ht> ... Cracks in the architecture aren't noticed by management
16:31:29 <ht> NM: The webapps pblm is not that we've tried and found lack of substance, but we haven't tried (enough)
16:32:08 <ht> ... We need to locate, for example wrt Client-side storage, what the main points ought to be.
16:32:51 <ht> LM: I need to understand the whole area before I can identify the main points
16:33:50 <ht> LM: One role of W3C is to apply constraints/feed important viewpoints as policies into WG activities which they might not think or care about intrinsically
16:34:01 <noah> I also think we need to, not right away but early in the process, identify the few main points we want to make, and to whom.
16:34:09 <ht> LM: TAG findings, and the Arch Doc(s), are how we express those policies
16:34:17 <raman> raman has joined #tagmem
16:34:23 <ht> ... So our role is to articulate policies in a way that are actionable
16:34:38 <ht> TVR: It resonates, but it takes two hands to clap
16:35:16 <ht> ... But without respect from the WGs and the people outside the W3C who are driving the Web there's no leverage for what we do
16:35:22 <ht> ... and that respect has been lost
16:35:38 <ht> NM: Use cases are at the heart of establishing credibility
16:36:01 <ht> ... Saying "I have a principle" is less likely to have an impact than "I have a use case"
16:36:36 <ht> TBL: Getting the 'profile' attribute back is a clear example
16:37:07 <DKA> q+
16:37:19 <noah> I'll give this until 9:40, then on to storage
16:37:28 <ht> TVR: The successful cases are from the past, the new Web doesn't have simple axioms or examples that you can state
16:37:32 <Ashok> Ashok has joined #tagmem
16:38:12 <noah> ack next
16:38:16 <ht> ... The loss of community-level standing to speak by the W3C, not so much the TAG itself -- the TAG alone can't fix this
16:38:59 <ht> DKA: Wrt the W3C's role, my perspective is that in the geo-loc area, I see the W3C playing a leadership role and being successful
16:39:37 <ht> ... Also, when we ran the privacy workshop, we got people from across the eco-system, and the W3C's coordination role was recognised
16:39:50 <ht> ... We should try to build on that kind of example
16:40:12 <masinter> q+ to suggest we review this later in the meeting when we go to "next actions"
16:40:18 <ht> TVR: Just emphasising that TAG impact has to be based on W3C effectiveness
16:40:50 <masinter> W3C effectiveness can be improved by the TAG doing a better job
16:40:53 <ht> TBL: Let's decouple these -- the TAG should just do the work, and we'll work in other arenas to improve the impact of the W3C
16:41:00 <noah> +1 to Tim
16:41:21 <jar_> q?
16:41:26 <ht> TBL: Agree with NM (and JJ) that we need to pick our focus, and get to work
16:41:34 <noah> ack next
16:41:36 <Zakim> masinter, you wanted to suggest we review this later in the meeting when we go to "next actions"
16:41:57 <ht> LM: When we talk about next steps, remember that the TAG being effective also feeds into W3C effectiveness
16:42:08 <ht> ... bringing the broader community together
16:42:16 <ht> ... and expanding the horizons of the WGs
16:42:30 <masinter> q-
16:42:39 <ht> NM: Quality speaks for itself
16:43:03 <ht> ... I want to look at our work and be proud of it, on the basic of intrinsic merit
16:43:24 <ht> Topic: Web Applications: Client-side State
16:43:38 <ht> trackbot, Action-430?
16:43:38 <trackbot> Sorry, ht, I don't understand 'trackbot, Action-430?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
16:43:46 <ht> action-430?
16:43:46 <trackbot> ACTION-430 -- Ashok Malhotra to propose a plan for his contributions to section 5: Client-side state -- due 2010-09-09 -- OPEN
16:43:46 <trackbot> http://www.w3.org/2001/tag/group/track/actions/430
16:44:22 <ht> NM: Background is our commitment to build a webapps document
16:44:35 <ht> AM: Two documents: state and storage
16:44:49 <ht> NM: Oops, I missed that there were two documents
16:45:00 <ht> ... Let's start with storage, since it's linked from the agenda
16:46:05 <masinter> q+ to ask about IETF work on cookies https://datatracker.ietf.org/wg/httpstate/charter/, privacy issues, fragment identifiers ... (items missing that I thought would have been mentioned)
16:46:11 <ht> AM: Actually, I'll start with client-side state, which originated wrt Google Maps
16:46:19 <ht> NM: Changes since May?
16:46:40 <ht> AM: Feedback from NM, LM, JAR, and that was very helpful
16:47:07 <ht> ... In particular that not all states are reproduceable, only some, and I'm happy to take that on board
16:47:41 <masinter> q+ also to talk about the perspective of "document" as "application" and "fragment" as "document state"
16:47:45 <masinter> q?
16:48:58 <ht> NM: So apologies for not scheduling discussion on state
16:49:05 <ht> ... but not much change in that area?
16:49:09 <ht> AM: Right
16:49:39 <jar_> (No news on state since early summer.  The new draft is about storage, not state.  The action was about storage, and that's what Ashok wrote about, and what we're about to talk about.)
16:49:43 <ht> AM: I would like to have a partner to actively respond to me on this
16:49:57 <ht> DKA: I'lll take that on
16:50:07 <noah> . ACTION: Ashok to write finding on client-side storage, DanA to review
16:50:16 <noah> ACTION: Ashok to write finding on client-side storage, DanA to review
16:50:16 <trackbot> Created ACTION-475 - Write finding on client-side storage, DanA to review [on Ashok Malhotra - due 2010-10-26].
16:51:08 <ht> NM: Move to discussion of http://www.w3.org/2001/tag/2010/09/ClientSideStorage.html
16:51:17 <timbl> Ashok, what about evercookies? 
16:51:39 <masinter> q+ to ask about sandboxing and security issues as part of activity too
16:51:42 <timbl> I see the, now
16:52:22 <ht> DKA: AM mentions evercookies, this is the kind of thing which we should focus on, it got HTML5 on the front page of the NYT
16:52:26 <noah> q+ to ask about relationship between storage and privacy
16:52:43 <ht> ... We should try to move quickly here -- can we triage this area to get something out on this quickly?
16:52:55 <jar_> s/storage, and that's what Ashok wrote about/state, but Ashok wrote about storage/
16:53:19 <timbl> Note that the W3C privacy workshop and the whole new currentlness of privacy discussion in the communiyt
16:53:35 <timbl> q+ to talk about accoutability as a possible TAG finding
16:54:10 <ht> ack next
16:54:11 <Zakim> masinter, you wanted to ask about IETF work on cookies https://datatracker.ietf.org/wg/httpstate/charter/, privacy issues, fragment identifiers ... (items missing that I thought
16:54:16 <Zakim> ... would have been mentioned) and to talk about the perspective of "document" as "application" and "fragment" as "document state" and to ask about sandboxing and security issues
16:54:19 <Zakim> ... as part of activity too
16:54:50 <ht> LM: There is an IETF WG on HTTP state, cookies etc.
16:54:55 <timbl> http://tools.ietf.org/wg/httpstate/
16:55:03 <timbl> http://tools.ietf.org/wg/httpstate/draft-ietf-httpstate-cookie/
16:55:06 <ht> YL: the goal is to produce an interoperable spec. about cookies
16:55:19 <ht> ... both server and client
16:55:21 <noah> Noah needs to remind himself that ACTION-430 was about state, as in fwd/back stack, and this is storage, which is the new action-475
16:55:44 <masinter> q-
16:55:51 <timbl> q?
16:56:34 <ht> LM: What about sandboxing -- local storage is associated with a site, and there is some model about sandboxing and tainting -- that should be covered in more detail in this doc't
16:56:53 <ht> AM: Storage uses same-origin policy at the moment, subject to the same problems
16:57:28 <ht> LM: What is the problem in this space -- there's more than one approach to cross-site, how is that playing in this new area?  Exposing all that would be a good idea
16:57:45 <ht> AM: I borrowed stuff that JK had written about CORS and UMP, and included that
16:58:21 <ht> LM: Wrt privacy, the general operation of "clear all my stored information" was not in webarch, cookies weren't in webarch
16:58:33 <ht> TBL: There wasn't any local storage in WebArch
16:58:43 <noah> ack next
16:58:44 <Zakim> noah, you wanted to ask about relationship between storage and privacy
16:59:15 <ht> NM: This is a finding on storage, but we move quickly to privacy
16:59:32 <ht> ... We're failing to notice other things which are fundamental
16:59:59 <ht> ... cookies are one, we should start with that -- here's the pure Web, in its idealised form
17:00:32 <ht> ... First look at cookies, SQL stores, etc.  Are they antithetical to WebArch, or can they co-exist?
17:01:11 <ht> ... How do they relate to our existing story about WebArch -- does this e.g. compromise our ability to give URIs to things which can be distributed effectively?
17:01:21 <timbl> You have to say now that now cookies are defintely part o fth eweb arch -- and clioent-side storage and state in general -- we should not ask whee they are just bad.  We should define the two types of system, and give the properteis of each. 
17:01:23 <masinter> q+ to ask more questions
17:01:28 <masinter> more questions: whether this is 'storage' or 'caching'? is it an optimization or essential? Is there a web for devices without local storage? "public terminals", "embedded clients", ... what is are the requirements for how much storage there is, the possibility of malicious sites using up storage capabilities, ....?
17:01:40 <ht> NM:  What are the tradeoffs?  And only then move to privacy and security
17:01:44 <noah> ack next
17:01:46 <Zakim> timbl, you wanted to talk about accoutability as a possible TAG finding
17:02:38 <ht> TBL: Historical stories, maybe.  The first stateless story has been told.  So we should define two systems, with different protocols, and then look at how to use the new one effectively
17:02:53 <ht> s/define/recognise the existence of/
17:02:59 <noah> Should we walk through the document?
17:03:12 <ht> TBL: Privacy is really important and current, we've had all these workshops
17:03:26 <ht> ... Move from a world of access control to a world of accountability
17:03:50 <ht> ... Great talk by Hal Abelson at the last MIT Privacy workshop -- the five myths of privacy
17:03:58 <masinter> there's a leap between 'storage' to 'privacy' which really seems to be about sandboxing?
17:04:11 <noah> q?
17:04:14 <ht> TBL: Proposed changing the way we think dramatically
17:04:40 <noah> ack next
17:04:43 <Zakim> masinter, you wanted to ask more questions
17:05:06 <ht> LM: I'm confused about the question of at what point local storage moves beyond being a cache or an optimisation
17:05:29 <ht> ... Do you have to have local storage to be an agent at all?  Public terminals versus privately-confined ones
17:05:30 <noah> I like the public terminal point that Larry is making
17:05:44 <noah> Of course, offline operation is very important in some cases.
17:05:45 <ht> ... The stateless web had the advantage that local storage was not a requirement
17:06:05 <ht> LM: Is it legitimate to have a client the drops all cookies?
17:06:22 <ht> TVR: State rides on top of the stateless HTTP protocol
17:06:37 <ht> ... Some people say that's a hack, we should have had state in HTTP all along
17:06:46 <ht> ... Others say it's OK, it's good layering
17:07:22 <masinter> I don't think this is a moral issue or a question of "good" or "bad" design, the question is an architectural one, of whether there are categories
17:07:48 <ht> TVR: LM is right, in the process of layering we can no longer tell if a URI is basic (clean) or basic+ (cookies needed) or basic-super-plus (need SQL-storage)
17:07:54 <masinter> i would imagine an architectural requirement: web sites that use state should still work with clients that don't have state, although might be missing features
17:07:56 <noah> q+ to ask about doing it right
17:08:32 <masinter> q+ to explore some kinds of findings around state
17:08:47 <noah> Need to get link to Crest
17:08:58 <ht> AM: Roy Fielding sent us a pointer to a website about C-REST (Computational REST) -- a URL really points to a computation
17:09:08 <ht> ... but it doesn't spell out state manipulation
17:09:19 <masinter> http://www.erenkrantz.com/CREST/  ?
17:09:36 <ht> ... I thought you, TV, were talking about two or three classes, but I don't think you can separate them
17:09:54 <ht> TVR: I agree you can't separate them, but the question is is that a bug or a feature?
17:10:29 <ht> ... If you go to CNN with a completely clean browser, it takes you ages to actually get the news, because it requires you to answer various questions first
17:10:42 <ht> ... So a stateless client will always have that hassle
17:11:02 <noah> q+ ashok to talk about Evercookies
17:11:15 <DKA> q+ to make a point on where client-side storage fits into the "apps vs. web" debate currently playing out in the mobile indtsyr.
17:11:18 <ht> TVR: The old days of getting a bag of bits, from a disk or a CGI script, which get shown, has gone
17:11:34 <ht> ... Now that bag of bits is run again on the client, and that can iterate. . .
17:11:53 <ht> ... For example the CNN video page I mentioned in my # in URL document
17:11:55 <masinter> "document" <=> "application which displays document"
17:12:04 <jar_> (Re TV saying "you can't tell" whether the resource is stateless, or whether there's state involved: I muse that this may be the age-old argument of 'typeless' vs 'typeful' languages - do types get reflected in names; are they inferrable from context; or do you have to dive deeper to "tell" what something is like)
17:12:41 <masinter> q?
17:12:45 <noah> ack next
17:12:45 <ht> NM: Indeed how does the new document relate to the # in URI doc't?
17:12:46 <Zakim> noah, you wanted to ask about doing it right
17:13:36 <ht> NM: TVR said look, we had a stateless web, now this new stuff is happening, mostly it's good, but we need to be clear what's more and less good
17:13:53 <ht> ... There are some things which are pretty dangerous, paralllel to using GET to update state
17:14:26 <ht> ... Mostly we can set out the tradeoffs, so the consequences of e.g. using persistent local store, will be, both up and down
17:14:29 <masinter> What is it you have to do in order to build an application which works reasonably with many different kinds of devices, all with differing local storage capabilities? is that an architectural goal?
17:14:39 <noah> ack next
17:14:40 <Zakim> masinter, you wanted to explore some kinds of findings around state
17:14:58 <ht> NM: compare what we did with Cool URIs don't Change -- here's what goes wrong when they do
17:15:49 <ht> LM: Interoperability -- what does it mean?  Two things are interoperable if they work identically?  Or something 'works' on small handheld, and on a big desktop screen?
17:16:39 <ht> ... We're now looking at a range of UAs with respect to local storage capabilities.  The goal should be that the architecture makes clear where the scalability has to come
17:17:15 <ht> ... What are the principles that allow things to work with small or large storage, with any cookies/no cookies/no-cross-site cookies
17:17:28 <noah> ack next
17:17:29 <Zakim> ashok, you wanted to talk about Evercookies
17:17:31 <ht> JAR: Parallel to the accessiblity story
17:17:52 <ht> AM: People are very upset about Evercookies
17:18:04 <ht> ... Is this just one guy's hack, or has it become a Javascript hack?
17:18:21 <ht> NM: The guy himself did it to show how easy it was to be bad, as a warning
17:18:23 <masinter> proof of concept, but each of the methods are individually exploitable
17:18:36 <ht> ... But the black hats just say "thank you" and use it
17:18:49 <ht> TVR: [missed it]
17:18:59 <timbl> Yes, Larry -- there will be two parts to that, adapting diff cient side storage -- one i ssimp;ly mapping the different sorts of faclity (RDB, key/value etc, rdf, etc store) onto each other.  The other will be writing an ap to deal with very difering amounts of storage.
17:19:18 <timbl> The latter will be very tricky and difficult to generalize.
17:19:19 <ht> AM: Depressing, because it looks like an arms race, parallel to the virus situation
17:19:35 <timbl> (The former is till to an extent in procgress wiht various layers)
17:20:28 <ht> s/[missed it]/Evercookie shows how you can create a PNG file and get it back later, which may get deleted because unrecognised.  But then just use space-char-distribution in a README, which looks quite harmless/
17:20:50 <ht> NM: Right, so "clean local storage" is just undischargeable -- what is covered?
17:21:24 <ht> TBL: I wanted to watermark email to W3C forum so I could detect leaks. . .
17:21:49 <ht> TBL: Rather than get depressed, we need to take the switch to accountability here
17:22:02 <ht> AM: You can't stop people, but you can hold them accountable, is that it?
17:23:19 <ht> JAR: That's the way security works in the real world, per Butler Lampson, for instance bank security works by accountability, not literal security
17:23:43 <ht> LM: "Gates, guards and guns"
17:24:28 <ht> JAR: Hal A's TAMI project is relevant
17:24:31 <masinter> that's the decomposition of security mechanisms: locked doors that keep people out, monitors that discover when people intrude, and punishment to hold you accountable if you intrude 
17:25:37 <ht> TBL: [projects from Hal Abelson's "Seductive myths about privacy" slide deck]
17:25:42 <jar_> http://dig.csail.mit.edu/TAMI/  Transparent Accountable Datamining Initiative
17:28:03 <jar_> Also see http://www.bitsbook.com/ book _Blown to Bits: Life, Liberty, and Happiness after the Digital Explosion_ by Abelson et al
17:28:24 <masinter> AAAA  Authentication, Authorization, Accounting and Auditing
17:38:24 <masinter> q+ to ask about "information" boundaries
17:38:37 <masinter> you can use my birth date but not my age?
17:39:30 <DKA> q?
17:41:08 <ht> ht has joined #tagmem
17:41:22 <ht> AM: Yes, I have what I need
17:41:30 <ht> NM: Due date?
17:41:45 <masinter> about how to decouple storage finding from privacy
17:42:07 <ht> NM: Back to storage, we'll pick up on privacy tomorrow morning
17:42:13 <noah> http://www.w3.org/2001/tag/2010/10/19-agenda.html#privacy
17:42:15 <timbl> q+
17:42:25 <ht> ack next
17:42:26 <Zakim> DKA, you wanted to make a point on where client-side storage fits into the "apps vs. web" debate currently playing out in the mobile indtsyr.
17:42:31 <noah> ack next
17:42:32 <Zakim> masinter, you wanted to ask about "information" boundaries
17:43:07 <ht> DKA: Client-side storage hugely important in the mobile industry -- apps vs. web is a hot topic
17:43:23 <ht> ... Received wisdom is building apps is great
17:43:41 <ht> ... this isn't consistent with the web-as-a-platform perspective
17:43:55 <timbl> q+ to point out re client-side state the problem of referring to a thing and a veiw of that thing, or a thing and an app which can treat the thing, and th eissue o getting therese things ebtween aps -- e.g. location (address book to TomTom, choice of map)  (date/time) Things of all sort (Tabulator jviews).
17:44:04 <ht> ... This means client-side storage is important to support intermittment connectivity
17:44:55 <ht> TVR: Huge confusion about "what is a web application" -- web application vs. client application is just a marketing distinction
17:45:16 <ht> ... Lots of so-called client apps are actually web-reliant
17:45:18 <masinter> apps vs. web is an interesting discussion.... what is in an 'app' that isn't in the web, besides local storage? "installation", different security model, installation of preferences
17:45:27 <masinter> q?
17:45:44 <ht> NM: But I can't run them on my Palm
17:45:47 <masinter> q+ to talk about apps vs. web
17:46:01 <ht> TVR: That's just the old write-once-run-anywhere myth
17:46:20 <ht> ... I don't want to limit web-apps to those which just run in the browser
17:46:29 <ht> [general uproar]
17:46:38 <ht> TBL: It's an important difference
17:46:43 <ht> TVR: It's a continuum
17:47:19 <ht> TBL: "Don't build a client app, build a webapp" is my litany these days, because you can link to it, because it _will_ run anywhere
17:47:44 <ht> LM: The technology used is orthogonal
17:47:47 <ht> TVR: My point
17:48:01 <ht> LM: There is a differerence between an app and something on the web
17:48:05 <noah> There is also a difference of openness and ubiquity.
17:48:15 <ht> ... An app can assume permanent storage until it's uninstalled
17:48:25 <ht> s/web/there's a big security difference/
17:48:41 <ht> LM: An app can install a preferences dialogue
17:48:46 <noah> If I send a link to what Tim calls an application, it will with high probability work wherevery you are.  Not true of Android, Flash, iPhone etc. even if heavily using Web protocols under the cover.
17:48:53 <ht> TVR: Over time they are merging -- the distinction is only in your head
17:49:02 <ht> TBL: One has a URI and the other doesn't
17:49:07 <Ashok> Ashok has joined #tagmem
17:49:23 <ht> TVR: I can write an android app which jumps in and out of the browser
17:49:29 <jar_> timbl: What do you mean they're merging? One has a URI and the other doesn't
17:49:30 <ht> TBL: URI is itunes: ?
17:49:40 <ht> TVR: No, http:
17:49:50 <masinter> applications can use web, invoke web, etc. can they limit web access to some sites or restrict ?
17:50:00 <ht> TVR: Pandora is a good example
17:50:25 <masinter> q+ to propose that we define what a "web application" is, in a way that helps clarify this
17:50:31 <ht> TVR: If the message is it's all URIs, bookmarkable, run on any browser -- yes, that's still there
17:50:43 <ht> ... but the app universe is much less clear
17:50:44 <timbl> q?
17:51:06 <ht> DKA: I wasn't trying to say that people shouldn't write native apps
17:51:27 <ht> ... But the client-side storage is relevant in a decision about whether to write a native app or a web app
17:51:35 <ht> s/storage/storage provision/
17:51:49 <ht> ... There are other differentiators, but this is an important one
17:51:56 <ht> s/this/client-side storage/
17:52:02 <masinter> i think "installation" and "preferences" are other elements
17:52:22 <ht> ... So if we're trying to bolster web-as-platform, we need to support client-side storage
17:52:36 <ht> ack next
17:52:38 <Zakim> timbl, you wanted to point out re client-side state the problem of referring to a thing and a veiw of that thing, or a thing and an app which can treat the thing, and th eissue o
17:52:43 <Zakim> ... getting therese things ebtween aps -- e.g. location (address book to TomTom, choice of map)  (date/time) Things of all sort (Tabulator jviews).
17:52:59 <ht> TBL: There's a pattern which leads to grief:  When we want the world to be represented by one URI
17:53:11 <ht> ... but in fact it's represented by two
17:53:24 <ht> ... Maybe we can fix this for two, even if we can't for N
17:53:46 <ht> TBL: I'm looking at a location on ???, and I want to drag it to OpenStreetMap
17:53:47 <masinter> and a different security model.  Perhaps applications could be designed such that applications also produce URIs so they can transition between app <==> webapp, if they're built on the same technology
17:53:48 <jar_> "in the browser" is an implementation detail.  what are the essential aspects of the app / web app distinction  from the point of view of issues that are observable to users?
17:54:17 <ht> TBL: I can't as a user take "this website" and make it view "this location"
17:54:36 <ht> [scribe is getting lost]
17:54:36 <masinter> what Tim is talking about is orthogonal -- can pieces of application 'state' be abstracted enough that they can be shared between applications.... vcard, map locations, etc.
17:55:40 <ht> TBL: Multi-dimensional reality about my interests in e.g. people -- sometimes I want them-as-located, sometimes them-as-issue-owner
17:56:36 <ht> ... Maybe this is pushing us towards multiple-view-supporting URIs -- separate dimensions, in other words -- what object do I have in view, and what application do I want to apply to it?
17:56:50 <ht> [again, scribe lost]
17:57:16 <masinter> Tim wants application / web application designers to use common abstractions for common concepts (users, locations, telephones, ....) in a way that those abstractions can be shared between applications
17:57:23 <ht> TBL: for sanity, the user shouldn't have to live in a world where the thing and the view/facet/use are conflated into a single URI
17:57:23 <masinter> (to propose)
17:57:33 <ht> ... we need to untangle those things
17:58:03 <ht> TVR: But then we need a universal way of identifying, e.g. locations
17:58:37 <noah> ack next
17:58:38 <ht> TBL: URI of vcard or homepage can be a person-identifier
17:58:39 <Zakim> masinter, you wanted to talk about apps vs. web and to propose that we define what a "web application" is, in a way that helps clarify this
17:58:44 <Ashok> Thre is a project called OKKAM which will give URI to loactions -- among other things
17:59:20 <ht> LM: Native apps vs. webapps -- bring different things to the table for the developer . As NM said, starts with the installation story
17:59:30 <noah> zakim, close the queue
17:59:30 <Zakim> ok, noah, the speaker queue is closed
18:00:23 <ht> ... There is a natural desire to get a URI which links to an application _in a state_ .  Perfectly possible to have a native app which generates URIs for its states, even if it's not "a web-only" app
18:00:58 <ht> LM: That's a separate discussion from the one about what's needed for sharing across applications -- that's harder
18:02:09 <ht> [NM: Short break]
18:06:55 <noahm> noahm has joined #tagmem
18:09:31 <noah> noah has joined #tagmem
18:11:58 <noahm> noahm has joined #tagmem
18:15:46 <noah> noah has joined #tagmem
18:18:17 <noahm> noahm has joined #tagmem
18:19:43 <ht> Resuming
18:19:46 <ht> Topic: ISSUE-54 (TagSoupIntegration-54): HTML / XML Unification
18:20:10 <ht> NM: Detailed discussion in June at the last f2f about this
18:20:42 <ht> ... Suggested that TBL, with help from the TAG, might try to pull an effort together to tackle the HTML/XML convergence problem
18:21:29 <ht> ... JJ has encouraged TBL to discuss this in public at TPAC
18:21:44 <ht> ... TBL hesitant unless there is progress to report
18:21:53 <ht> TBL: This was at TVR's instigation
18:22:27 <ht> ... There has been pushback from HTML people saying "Nothing's going to change in HTML land, nothing's going to change in XMLland, so no point"
18:22:50 <ht> ... I got management support to create a task force
18:23:06 <ht> ... If we are convinced that it has a very very crucial role to play, let's do it
18:23:16 <masinter> What are the requirements for which XML was designed which are not in HTML, and which communities need those requirements?  Extensibility, modularity, small footprint....  don't think we can ignore those communities
18:23:27 <ht> ... But if we think there's no choice but to have two stacks, let's not do it
18:23:33 <masinter> q+ to talk about communities & requirements
18:23:55 <ht> TVR: The recognition of two stacks seems like one side to being a victory to one side
18:24:21 <ht> ... because if it goes forward, there's a real risk that [the XML] stack will atrophy and die
18:24:48 <masinter> I don't think the model of "two stacks" makes sense, describes the reality
18:25:04 <ht> TVR: I don't think the two-stack story has a future
18:25:33 <ht> ... For XML to play a role on the browser-driven web, XML has to have a place in the text/html media type
18:25:43 <ht> ... We have to find a way to sell the value of the XML tool chain
18:26:08 <ht> ... Because the last mile is broken, the whole XML pipeline story is at risk
18:26:10 <timbl> q+
18:26:31 <timbl> Zakim, open the queue
18:26:31 <Zakim> ok, timbl, the speaker queue is open
18:27:17 <ht> LM: XML was designed to meet some communities' requirements, neither the communities nor the requirements have gone away
18:27:25 <timbl> q+ to say but in fact thHTML isn't the last mile any more, webapps is more than a mile and where a lot of th eprocessing happens.
18:27:36 <ht> ... So maybe XHTML was going wrong, so we needed a course correction
18:28:00 <ht> ... But that doesn't mean that we can't bring those original requirements back to the table
18:28:15 <jar_> q+ to (a) suggest postmortem (b) ask about viewing html as a serialization for xml
18:28:34 <ht> LM: Those requirements: a small, clear, consistent language with not surprises, and modularity, extensibility, ???
18:28:58 <ht> ... Not shared by the main driving force of the Web, but a big proportion of the W3C membership
18:29:20 <noah> noah has joined #tagmem
18:29:52 <ht> ... Someone argued that polyglot didn't matter, but a member (a client) said "that's all I had" -- and they wanted not just the last mile, but to roundtrip -- to take their website and push it _into_ a pipeline
18:30:03 <ht> LM: We have to bring that community with us
18:30:37 <noahm> noahm has joined #tagmem
18:30:50 <ht> LM: The ebooks /epub standards uses XHTML
18:31:05 <Yves> http://en.wikipedia.org/wiki/EPUB
18:31:09 <ht> LVR: And the Diasy XML manifest
18:31:18 <ht> s/Diasy/Daisy/
18:31:28 <ht> s/???/archivable/
18:32:06 <Ashok> rrsagent, pointer
18:32:06 <RRSAgent> See http://www.w3.org/2010/10/19-tagmem-irc#T18-32-06
18:33:09 <ht> LM: The requirement for books is in part archivability, for which a smaller more constrained language is not 
18:33:19 <ht> ... a luxury, but a real value
18:33:35 <ht> TBL: So we mustn't leave the polyglot community behind
18:33:43 <ht> HST: More than that, the all-XML community
18:34:16 <ht> TBL: The HTML community will say that this represents too small a part of the Web for us to care
18:34:54 <ht> But it represents a much larger percentage of W3C's membership
18:35:11 <ht> q+ to deprecate arguments based on counting
18:35:34 <masinter> (a) "leading the web to its full potential" means not looking backward but forward... what interoperabilities can we enable? 
18:35:57 <masinter> (b) there are too many web sites that claim they are xhtml compliant
18:36:00 <ht> TVR: I don't think the numbers game matters, or trying to 'prove' to the HTML people that they should care about XML on the Web
18:36:15 <ht> ... What I do care about is that the XML ecosystem is preserved
18:36:55 <ht> ... The W3C has created a very valuable collection of tools, where XML is at the heart, and sold it to the membership
18:37:15 <ht> ... In particular, to be able to serve the results of their pipelines onto the Web
18:37:36 <ht> TBL: So protect and defend polyglot -- what are the other requirements
18:38:02 <ht> TBL: So what other things go into the terms for taskforce
18:38:12 <ht> s/taskforce/taskforce?/
18:38:21 <ht> TVR: Distributed extensibility
18:38:37 <ht> NM: The charter of any taskforce should take a clear stand on the HTML5 Last Call
18:38:45 <ht> ... after which it might not change much
18:39:07 <ht> NM: So are we asking the TF to take responsibility for making HTML5 right for polyglot etc.
18:39:22 <ht> ... _or_ is it focussed on life after HTML5
18:39:22 <jar_> q?
18:39:33 <masinter> q+ to disagree with Noah and agree with Raman
18:39:45 <ht> TVR: No win either way -- too late for Last Call, too soon for post-HTML5
18:40:11 <masinter> task force should focus on long-term requirements, but be encouraged to make short-term recommendations
18:40:12 <ht> TVR: The claim is that HTML5 is continually evolving, we can utilise that to get improvements done
18:41:23 <ht> YL: The main difference in the XML stack is the extensibility that is both pervasive and easily handled, whereas in the HTML stack, largely driven by the browser implementors, extensibility is a problem to be circumscribed and worked around
18:41:50 <ht> s/difference/difference is that/
18:42:06 <noah> noah has joined #tagmem
18:42:42 <ht> TVR: The extensibility argument has been made before many times, but on the implementation side it has been hard about turning new tags into new behaviour
18:42:55 <ht> ... whereas on the HTML side the addition of new behaviour is quite easy
18:43:24 <ht> TVR: Making a raman:person element and move it around and work with it is very important
18:43:54 <ht> ... but so is my ability to write <div class="person>.... and get lots of leverage wrt appearance and behaviour from that
18:44:43 <ht> LM: There is more to XML than extensibility.  Did we lose the value of the XML cleanup because of the pushback on extensibility
18:45:02 <ht> s/extensibility/extensibility?/
18:45:34 <noah> noah has joined #tagmem
18:45:39 <ht> ... We've lost the conservative sender part of the duality -- for general web use maybe that's not so important, but for interoperability with the rest of the world it may matter a lot
18:45:45 <noah> zakim, who is here?
18:45:45 <Zakim> TAG_f2f()11:30AM has not yet started, noah
18:45:46 <Zakim> On IRC I see noah, Ashok, ht, raman, Zakim, DKA, RRSAgent, masinter, timbl, jar_, jar, trackbot, Yves
18:46:01 <noah> q?
18:46:37 <ht> LM: Here's a requirement (clean specification of clean sublanguage), here's the XML ability to support that, here's what HTML doesn't give it to us
18:46:52 <ht> q+ ht2 to underline the vulnerability of xslt in the browswer
18:47:08 <DKA> q?
18:47:20 <ht> ack next
18:47:23 <Zakim> timbl, you wanted to say but in fact thHTML isn't the last mile any more, webapps is more than a mile and where a lot of th eprocessing happens.
18:48:16 <ht> TBL: HTML isn't the last mile any more, but the newer architecture involves much more computation client-side, which means its the client that needs both XML and HTML parsers
18:48:22 <masinter> but the client side deals with the DOM? XML dom vs. HTML dom independent of linearization?
18:48:44 <ht> ... So the client is (via Javascript)  looking at a tagsoup-originating DOM and XML from XMLHttpRequest
18:49:15 <masinter> other requirements, how to apply to HTML: XML digital signatures, EXI....
18:49:24 <ht> ... Which pushes the question of where full HTML parser is required into lots of obscure places
18:49:27 <timbl> q?
18:49:34 <noah> q?
18:49:40 <noah> ack next
18:49:41 <Zakim> jar_, you wanted to (a) suggest postmortem (b) ask about viewing html as a serialization for xml
18:50:06 <ht> TVR: Webkit and maybe Gecko do have tidy functionality, in that they can serialize their DOMs
18:50:48 <noah> q+ to say post-mortem isn't good enough
18:51:04 <masinter> which other XML standards & applications ... how do we apply them to HTML?
18:51:15 <ht> JAR: The taskforce could look at doing a postmortem -- the current situation is evidently unprecedented in its nature -- how did we get here, so at least we understand how to avoid it another time
18:51:50 <ht> ... LM mentioned that we lost the recognition of the value of conservative to produce/liberal to accept -- how did that happen?
18:51:54 <noah> ack next
18:51:56 <Zakim> ht, you wanted to deprecate arguments based on counting
18:52:10 <ht> ... So, as a preliminary, how did this happen?
18:52:17 <masinter> http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5  good perspective
18:52:18 <ht> ack next
18:52:19 <Zakim> masinter, you wanted to disagree with Noah and agree with Raman
18:52:40 <noah> ack ht2
18:52:40 <Zakim> ht2, you wanted to underline the vulnerability of xslt in the browswer
18:53:12 <DKA> +1 to the idea of a dispassionate postmortem.
18:54:35 <jar_> HT: we risk losing all the advantages of XSLT
18:54:39 <raman> JAR's suggestion of learning from the mistakes of the past is a good one, and I was hoping that would happen by constituting the task force to have the right people in it. Writing  the wikipedia history article however should not be the task force's job
18:55:04 <masinter> -1 I think *doing* a retrospective view as a document is not itself a good  charter goal
18:55:19 <noah> q?
18:55:37 <ht> s/advantages of XSLT/advantages of client-side XSLT in the browser/
18:55:53 <ht> LM: I think the post-mortem is not a good charter goal
18:56:15 <ht> ... That's already been done, see e.g. the Tim Bray/Ian Hickson exchange [ref?]
18:56:40 <masinter>  http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5
18:56:44 <ht> LM: I'd like to focus on getting back to the requirements for re-unification
18:57:06 <ht> [tbl reviews the whiteboard -- photograph to come]
18:57:22 <masinter> signatures, EXI.... 
18:58:07 <jar_> Maybe I haven't read the right things. For me I haven't seen an explanation of what was deeply different in this situation that caused the classical process (professional organization, working groups, etc.) to fail. If we don't understand this we'll just repeat the past.
18:58:34 <ht> TVR: Lost the ability to look at a web page and derive an API for it
18:58:51 <ht> ... a value of XForms which has been lost
18:58:53 <masinter> 'screen scraping' wins
18:59:22 <masinter> "extensibility" actually needs to be put into a context where extensions aren't mandatory for 'browsers'.... e.g., using (X)HTML in help systems which might have addtional extensions, which aren't browser extensions. Building other applications that integrate HTML
19:00:01 <ht> YL: The other direction -- Error recovery is better defined for HTML5
19:00:17 <ht> NM: Suspended until 1305
19:00:31 <masinter> error handling should be defined for particular applicaiton types, rather than assumed that what's appropriate for 'browser' is also appropriate for other applications
19:59:14 <DKA> DKA has joined #tagmem
20:02:17 <noah> noah has joined #tagmem
20:03:10 <masinter`> masinter` has joined #tagmem
20:03:28 <jar_> jar_ has joined #tagmem
20:05:26 <Zakim> TAG_f2f()11:30AM has now started
20:05:32 <Zakim> + +1.650.214.aaaa
20:05:54 <noah> zakim +aaaa has F2FRoom
20:06:01 <noah> zakim, +aaaa has F2FRoom
20:06:01 <Zakim> sorry, noah, I do not recognize a party named '+aaaa'
20:06:05 <noah> zakim, aaaa has F2FRoom
20:06:05 <Zakim> +F2FRoom; got it
20:10:01 <timbl> timbl has joined #tagmem
20:10:43 <DKA> Scribe: Dan
20:10:47 <DKA> ScribeNick: DKA
20:16:10 <ht> ht has joined #tagmem
20:16:19 <ht> zakim, code?
20:16:19 <Zakim> the conference code is 0824 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), ht
20:16:49 <Norm> Norm has joined #tagmem
20:17:04 <Zakim> +Norm
20:17:44 <DKA> Topic: Generic Fragment ID Processing
20:17:47 <DKA> issue-39?
20:17:47 <trackbot> ISSUE-39 -- Meaning of URIs in RDF documents -- open
20:17:47 <trackbot> http://www.w3.org/2001/tag/group/track/issues/39
20:17:54 <Ashok> Ashok has joined #tagmem
20:18:20 <DKA> Noah: we had a discussion around generic processing of fragment identifiers in http bis.
20:18:37 <DKA> ... the specification depended on an interpretation of frag ids that differed...
20:19:16 <DKA> ... the TAG decided that on balance the least damaging thing to do would be to write a letter to the http working group asking for it to be removed from bis.
20:19:23 <noah> http://www.w3.org/2001/tag/2010/10/19-agenda.html#generic
20:19:35 <noah> q?
20:19:39 <DKA> ... links there to the proposal, etc...
20:19:39 <noah> q-
20:19:44 <DKA> q?
20:19:44 <noah> q-
20:21:03 <DKA> Henry: In a superficial reading... insofar as there is any official definition, there are no official definition of "ID-ness".
20:21:38 <DKA> ... bad news - xpointer spec says barenames are resolved to IDs and defines IDs in 3 ways...
20:21:40 <masinter`> q+ to ask if there's a better definition of "fragment identifiers"
20:21:51 <masinter`> i mean, what is a 'fragment'
20:22:44 <DKA> ... 3 ways to find out what an element's id - one from the DTD, one if there is an xml-schema, and one if "you just know.'
20:23:10 <DKA> ... somebody could write an x-pointer processor that "just knows" that RDF IDs are IDs.
20:23:27 <noah> q+ to remind that rdf+xml is, at least in principle, not the only media type of interest
20:23:37 <DKA> Norm: yes you could do that but it would be [not good.]
20:23:56 <DKA> Henry: therefore we do not need to ask for a change in bis.
20:24:08 <masinter`> q?
20:24:11 <noah> q- Yves
20:24:13 <DKA> TV: Should we write this down as guidance to others who might think there is a problem?
20:24:14 <noah> ack next
20:24:15 <Zakim> masinter`, you wanted to ask if there's a better definition of "fragment identifiers"
20:25:01 <jar_> (I think Norm said something closer to 'not very smart' than to 'not good'.)
20:25:08 <DKA> larry: I've been thinking about fragments and what is a fragment, especially in web applications. Documents vs. applications. Is a document a kind of application where the application is "show me this document"?
20:25:25 <timbl> q?
20:25:34 <timbl> q+ not orthoginal crazy 
20:25:38 <Norm> q+ to say that I don't mean that by fragids
20:25:57 <noah> q- noah
20:26:00 <noah> q+ to remind that rdf+xml is, at least in principle, not the only media type of interest
20:26:04 <noah> q- noah
20:26:16 <noah> q+ to say that we may need health warnings on registration of new +xml media types
20:26:20 <DKA> tim: things which are not declarative are damaging - but if you determine state as "browser with something showing" then this interpretation of fragments makes sense.
20:26:53 <ht> s/In a superficial reading/Thanks to a prode from Jonathan Rees, investigation of the specs uncovered that on a superficial reading/
20:27:20 <DKA> larry: I like "speech acts" - where semantics is action - I communicate my state to you through speech. This speech act causes changes in state.
20:27:23 <noah> As chair, I'll say that I can't tell if this is a good use of time or a rathole.  Guidance would be welcome.
20:27:39 <DKA> tim: [disagrees]
20:27:46 <noah> ack next
20:27:47 <Zakim> Norm, you wanted to say that I don't mean that by fragids
20:28:32 <DKA> norm: for the applications I have in mind I consider fragids a way to reach into the document and get something out - to transclude it in an xproc pipeline, to count the number of characters, - not necessarily to display or change anything.
20:28:43 <DKA> ... i think this is contradictory to what larry said.
20:29:04 <DKA> larry: I don't think so - if you want to communicate a route from one mapping application to another it could be via a fragment identifer.
20:29:14 <noah> ack next
20:29:15 <Zakim> noah, you wanted to say that we may need health warnings on registration of new +xml media types
20:29:19 <DKA> norm: I think of it as a stake in the ground that I can navigate to.
20:30:04 <DKA> tim: it's important not to generalize too much about frag ids it's valuable to for RDF to use frag ids in a certain way - languages in the future might choose to use them in a different way.
20:30:09 <Norm> +1
20:31:04 <DKA> noah: I don't recall a health warning in the draft that those who register new media types need to be careful (about frag IDs).
20:31:59 <duerst> duerst has joined #tagmem
20:32:03 <DKA> ... it seems to me that it might be worth encouraging the editors to say "in the cases where the frag IDs supported by your media type overlap syntacticly with those provided by the generic then... [something]"
20:32:16 <DKA> tim: how do you grandfather conflict in RDF?
20:32:31 <DKA> Henry: there is no conflict with RDF.
20:33:04 <DKA> JAR: Do the specs say that when the frag ID when it's defined by XML ID has a certain meaning or do the specs say "when you see a frag id then it's defined by xml id"? There is a difference.
20:33:37 <jar_> http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html  section 5
20:34:12 <DKA> [disagreemnent on whether this conflicts with RDF]
20:34:24 <DKA> JAR: It conflicts with RDF.
20:34:54 <DKA> Harry: if your arbitrary foo+xml defines frag ids whose frag ids syntax overlaps with xml id then there's a conflict.
20:34:55 <jar_> "Conformant applications MUST interpret such fragment identifiers as designating that part of the retrieved representation specified by [XPointerFramework]"
20:35:26 <DKA> tim: either you want that behavior or you don't want that...
20:35:51 <DKA> harry: I want to know what conferment applications means - generic?
20:35:53 <jar_> "such fragment identifiers" means what?
20:36:15 <ht> and "conformant application" means what?
20:36:19 <ht> s/harry/henry/
20:36:31 <DKA> Noah: The way to distinguish generic - did you as author of the code follow a path informed by the rdf media type registration? [on whether tabulator is generic or specific]
20:36:48 <jar_> ... for RDF, the application CAN'T interpret it that way, because the fragid isn't an xml id...
20:36:49 <DKA> tim: no there is no code that looks up how to process things...
20:37:08 <DKA> s/harry/henry/
20:38:43 <DKA> tim: any attempt to look at that RDF document with xpointer processing is broken...
20:39:05 <DKA> tim: a test case would be a document that has both kinds of IDs...
20:39:36 <DKA> jar: that would be a bad file - it would cause the id to be interpreted in different ways depending on which spec you are following...
20:40:41 <DKA> noah: simple case: somebody decides : we like to use XML ids to manage our XML. Some of it happens to be RDF. The people who understand RDF....
20:41:20 <DKA> [heated discussion]
20:41:41 <DKA> jar: [writes example on whiteboard]
20:42:39 <DKA> rdf:ID = "a" -> Person ;  xml:id="b"
20:43:13 <DKA> jar: doesn't occur in nature because people don't put xml:ids in RDF docments.
20:43:19 <DKA> noah: Neither is there a spec ruling that out.
20:44:04 <noah> The example rdf:id="a" -> person rdf:id="b" -> element is NOT a problem
20:44:11 <noah> The example rdf:id="a" -> person rdf:id="a" -> element IS a problem
20:44:19 <Norm> I'm not sure it's *possible* to define things such that conflicts are impossible, and in practice I don't think they ever happen, so...I'm not sure if I feel like I should worry.
20:44:24 <noah> That's what Jonathan put on the board
20:44:32 <DKA> tim: fundamental principle: the semantics of a URI is context-free.
20:44:36 <noah> (Jonathan confirms I got that right).
20:44:51 <DKA> henry: you know that that's false - you can't tell what the semantics are until you know the media type of what the browser sends you.
20:44:54 <DKA> tim: no.
20:45:04 <DKA> jar: each representation delivers constraints...
20:45:16 <DKA> tim: if I say foo#a is interesting...
20:45:32 <DKA> henry: you can't say if that's coherent or not until you retrieve that URI...
20:46:54 <DKA> henry: [restating] what it means to be a generic processor is: you're only interested in constraints that come from a certain class of media types. "I am going to view these documents through a set of lenses consistent with only the 3023bis semantics..."
20:47:20 <jar_> a generic processor is only getting a subset of the whole theory of the fragid.  that's fine
20:47:48 <DKA> noah: on one hand you're talking about a generic piece of code - written as a generic processor - then a second piece of code written as an RDF processor sees the same code and interprets it differently. [Is that OK?]
20:48:50 <DKA> noah: if this exists in principle - I was worried about what I just described... that's why I think a health warning needs to be in [3023bis].
20:50:48 <noah> PROPOSED (by Noah) Registrations for media types of the form application/XXX+xml SHOULD NOT define semantics for fragments that would resolve in a manner that is inconsistent with the generic rules
20:51:34 <DKA> henry: we're saying - documents like this shouldn't be written...
20:51:56 <DKA> tim: which document - I've got two but I'm going to send you one of them based on my interpretation of your request...
20:52:00 <jar_> q?
20:53:04 <noahm> noahm has joined #tagmem
20:53:06 <DKA> henry: If it's an rdf processor and you give it the second document [on the board] it will have nothing to show you....
20:53:23 <noahm> noahm has joined #tagmem
20:53:27 <DKA> noah: 3023 does not currently give it that semantic...
20:54:04 <ht> q+ to ask Noah what he thinks of the SCD example
20:54:23 <noahm> Is it clear that we're to make mistakes?
20:54:23 <DKA> yves: how to process the fragments, based only on the mime type you get back. The purpose of 3023 bis is to say - if you don't know the semantic of the mimetype ... 
20:54:39 <DKA> yves: it's not a big issue. If you don't know RDF then you don't know RDF...
20:54:54 <DKA> tim: it's an issue because if you get something else displayed...
20:55:08 <DKA> yves: it's like displaying an image as text - you get some random bytes...
20:55:58 <jar_> tabulator can translate xml:id="a" into a set of RDF statements  (and would be 'authorized' to do so by 3023bis)
20:56:33 <Yves> my point is that using the defaulted behaviour, you know that you don't know the meaning of the fragment
20:56:45 <ht> only if that processor was doing reflection on a bit of XML as an object in the RDF, I think
20:57:09 <DKA> martin: I could imagine a piece of software that says "rdf / xml - ok I can do something with this as XML because I know XML and I know how to do something with RDF - so then I see #a so in one case I find an RDF ID so I go to the rdf processor or I could find an XML ID and go into XML processing... There could be inconsistent [behaviour]. I think a health warning could be a good thing.
20:58:10 <DKA> noah: [presents a proposal]
20:58:49 <noah> noah has joined #tagmem
20:59:15 <noah> noah has joined #tagmem
20:59:17 <DKA> Henry: [disagrees with noah's proposal]
20:59:32 <noah> Which was: 
20:59:32 <noah> PROPOSED (by Noah) Registrations for media types of the form application/XXX+xml SHOULD NOT define semantics for fragments that would resolve in a manner that is inconsistent with the generic rules
21:00:36 <noah> I clarified that "consistent" means, roughly: "if it resolves in a given document per the generic rules, then it resolves to the same thing per the specific media-type registration" (note that it's OK for it to resolve per the specific rules and fail to resolve per the generic)
21:00:38 <DKA> Henry: 6 or 8 years ago we were talking about scuds - schema components - how do you point to schema compontents? People said obvious thing would be to use a #name - that's a problem. so we put XML ids in the schema document - and you can use #foo to refer to them. It would work but it would be messy and confusing. 
21:01:10 <DKA> ... the fact that we were labelling an element but naming and underlying component seemed sensible... 
21:01:36 <DKA> ... [similarly] I don't have a problem with inconsistency across levels.
21:01:39 <jar_> ht:  The fragid names one thing, but identifies another.  No one was bothered by the pun.
21:02:05 <DKA> Noah: I'm talking about a health warning for the range of potential future media types that people might register.
21:02:06 <Norm> I think I agree. Inconsistency across levels doesn't bother me. I think.
21:02:47 <DKA> Henry: I'm not happy with [Noah's proposal] because I don't want to rule out the "pun."
21:03:32 <noah> noah has joined #tagmem
21:04:18 <ht> scribenick: ht
21:04:26 <Ashok> HT:  I withdraw ... not convincing people
21:04:26 <ht> NM: Objections to my proposal?
21:04:33 <ht> LM: Yes
21:04:55 <ht> HST: Not happy unless 'inconsistent' can be spelled out
21:05:01 <noah> I tried with:
21:05:03 <noah> I clarified that "consistent" means, roughly: "if it resolves in a given document per the generic rules, then it resolves to the same thing per the specific media-type registration" (note that it's OK for it to resolve per the specific rules and fail to resolve per the generic)
21:05:26 <noah> That help at all, Henry?
21:05:45 <ht> JAR: I guess we could try to converge on allowing the pun, but I think that would be inconsistent with past pronouncements
21:06:09 <ht> ... I would prefer something with a MUST
21:06:18 <ht> ... and I don't think any grandfathering would be needed
21:06:31 <timbl> timbl has joined #tagmem
21:06:41 <timbl> logger, popinter?
21:06:56 <noah> I think SHOULD is appropriate given the precedent of conneg;  that's another case in which the same fragid can resolve "inconsistently".  that's a SHOULD NOT.
21:07:10 <ht> JAR: I want to say something that rules out overriding XPointer
21:07:14 <noah> So, if it's a SHOULD NOT there, why be stronger here?
21:07:15 <DKA> Scribe: Dan
21:07:18 <DKA> ScribeNick: DKA
21:07:30 <masinter`> i don't think i can justify this, but i'm still not convinced about the benefit, and concerned about a "MUST" in a document that is policy not protocol
21:07:37 <ht> JAR: "If XPointner defines the fragid to designate something successfully, it cannot be overriden"
21:07:48 <ht> s/XPointner/XPointer/
21:08:03 <ht> TBL: I will disagree with anything that isn't crisp
21:08:07 <noah> I can certainly live with MUST NOT if you can get a formulation everyone likes.
21:08:14 <DKA> jar: xpointer does define the frag IDs...
21:08:19 <Norm> I'm with Larry, this boils down to policy at the spec level and MUST seems too restrictive
21:08:22 <noah> Can we wordsmith specific text that might garner consensus>
21:08:46 <noah> Henry, please type what people were agreeing with..
21:08:47 <DKA> jar: yes I agree with [what henry wrote]
21:09:00 <noah> My IRC missed it.
21:09:02 <masinter`> q+ to note that registration isn't mandatory, and more constraints on registration the more likely it is people just won't bother registering
21:09:10 <ht> JAR: xml:id means an element, no problem -- that's consistent with RDF
21:09:19 <ht> ack ht
21:09:19 <Zakim> ht, you wanted to ask Noah what he thinks of the SCD example
21:10:01 <DKA> henry: if there is an anchor that xpointer can identify then that's what it means...
21:10:08 <ht> scribenick: DKA
21:10:34 <noah> The chair is trying to get to the queue...with limited success.
21:10:34 <DKA> jar: if you want to be faithful in RDF then you need to get all of the alternative representations...
21:11:20 <DKA> henry: the clearest example: in an xml literal you can use xml ID...
21:11:34 <ht> s/xml ID/xml:id/
21:12:41 <DKA> norm: As long as the solution does not change 3023bis in ways that I previously said I objected to then I could live with almost anything...
21:13:07 <noah> q?
21:13:15 <jar_> +1 Henry's wording above "If XPointer defined the fragid to designate ..."  (the only other options are punning and grandfathering rdfxml)
21:13:28 <Norm> +1 to Larry on that point.
21:13:30 <duerst> q+ to say (to Tim) that there is no requirement on RDF processors to interpret any and all graph information in a rdf+xml document. As an example, an RDF processor may ignore stuff in namespaces it isn't interested in.
21:13:33 <Yves>  
21:13:35 <noah> q+ to talk about should vs. must
21:13:37 <Zakim> -Norm
21:14:19 <DKA> larry: I'm skeptical around must requirements in documents that establish processes...  Mime type registrations are not mandatory... we have a lot of unregistered mime types. The more barriers you add, the more impediments you put to registering things in the first place...
21:15:13 <duerst> q+ to suggest that the TAG make sure that the very old DTD for RDF gets removed/fixed/amended to be less confusing
21:15:23 <DKA> noah: the MUST is against registering a media type...
21:15:49 <DKA> tim: must is used in a protocol definition - if you obey the musts then you obey the protocol and you get a specific effect.
21:16:11 <jar_> q+ to answer Larry re "must" ... this is easy to fix... just say that certain fragids are defined according to xpointer
21:16:14 <timbl> Larry, MUST is used in the sennse of "if you do the things in MUST then you get the benefits o fthe protocol.
21:16:17 <DKA> larry: let's avoid the imperative text and just say what the consequences are...
21:16:31 <noah> ack next
21:16:32 <Zakim> masinter`, you wanted to note that registration isn't mandatory, and more constraints on registration the more likely it is people just won't bother registering
21:16:37 <noah> ack next
21:16:38 <Zakim> duerst, you wanted to say (to Tim) that there is no requirement on RDF processors to interpret any and all graph information in a rdf+xml document. As an example, an RDF processor
21:16:42 <Zakim> ... may ignore stuff in namespaces it isn't interested in. and to suggest that the TAG make sure that the very old DTD for RDF gets removed/fixed/amended to be less confusing
21:17:16 <DKA> martin: answering to Tim - he's worried that every RDF processor would need to do xpointer processing [if following Jonathan's proposal]. No...
21:17:51 <DKA> tim: when the publisher of the document has asserted a set of triplets - the intent of the document is the triples and only the triples.
21:17:59 <DKA> martin: if someone put in an XML ID...
21:18:04 <noah> I think the "consequence" is: "if you register a media type that provides for resolutions that are not consistent (in the sense above), then generic processors WILL resolve identifiers per the XML rules"
21:18:20 <DKA> tim: the XML ID has no significance...
21:18:34 <DKA> martin: if you open in in emacs xml mode...
21:18:48 <DKA> tim: then you are violating the architecture of the Web
21:19:06 <DKA> tim: it's clear that when someone clicks on a link...
21:19:14 <masinter`> noah, will they all? or just some of them?
21:19:42 <DKA> noah: with the plus syntax in 3023bis - it is called out specially...
21:20:24 <duerst> q+ to say that the TAG should wrap up and make sure work on 3023 starts again (currently, the official draft, http://tools.ietf.org/id/draft-murata-kohn-lilley-xml-03.txt (not http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html), is expired)
21:20:44 <DKA> tim: the +xml is to say to processors e.g. "you might run this through SAX..."
21:20:51 <masinter`> Some generic XML applications may treat documents labeled as application/XXX+xml using generic processing of fragment identifiers; this will result in inconsistent handling of fragments with those that have specific identification
21:21:40 <jar_> q?
21:21:40 <noah> q?
21:21:46 <noah> ack next
21:21:47 <Zakim> noah, you wanted to talk about should vs. must
21:21:50 <ht> q+ to ask about the XSLT case
21:22:09 <timbl> I challenge people to find any application which actually looks at the "+xml" in the media type -- so we can see what it does.
21:22:28 <noah> ack next
21:22:29 <Zakim> jar_, you wanted to answer Larry re "must" ... this is easy to fix... just say that certain fragids are defined according to xpointer
21:22:38 <masinter`> q+ to propose my alternative, "just describe the consequences"
21:22:42 <DKA> noah: I defended SHOULD - I find the fact that con-neg already produces inconsistent results ...
21:23:26 <noah> NM: What I said was, I think SHOULD would be consistent with the precedent of conneg, but I can live with either SHOULD or MUST if either generates consensus.
21:23:26 <DKA> jar: it's [3023] is already using MUST language - you can just make a statement that the frag IDs in this document are defined in the following way...
21:23:57 <noah> That's a MUST about what conforming processors do;  now we're considering a SHOULD vs. MUST on media type registrations.
21:23:57 <masinter`> if the applications don't look at the media type, they're not really interpreting the media type and don't have anything to do with 3023bis
21:24:08 <noah> q?
21:24:22 <DKA> jar: it sounds like we really are talking about three different proposals. tim was suggesting that rdf+xml should be grandfathered... 
21:24:33 <DKA> jar: that [should] satisfy norm.
21:24:52 <DKA> jar: henry's proposal won't break anything either.
21:25:03 <DKA> jar: we have 3 different positions...
21:25:14 <DKA> larry: I have a proposal.
21:25:37 <noah> ack next
21:25:38 <Zakim> duerst, you wanted to say that the TAG should wrap up and make sure work on 3023 starts again (currently, the official draft,
21:25:41 <Zakim> ... http://tools.ietf.org/id/draft-murata-kohn-lilley-xml-03.txt (not http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html), is expired)
21:25:43 <masinter`> if you define application/flub and application/flub+xml as exactly the same except for fragment identifier and you don't look at the MIME type
21:25:49 <noah> ack next
21:25:50 <Zakim> ht, you wanted to ask about the XSLT case
21:28:00 <DKA> henry: on what Tim said - none of the options we discussed mean you need to change tabulator... suppose xslt stylesheets were served with a +xml media type - the obligation to interpret frag ids generically applies to xslt processing, does this mean that every xslt processor writer needs to impleent xpointer? No unless they want to interpret xml ids...
21:29:17 <DKA> tim: an xslt processor runs xslt - if I have foo.xslt and I serve it as +xml - and I make a link to foo.xslt#bar and the xslt spec says nothing about semantics - your browser is obliged to show you #bar...
21:29:44 <masinter`> browsers are supposed to implement sniffing, also, which can't distinguish between application/flub and application/flub+xml
21:30:44 <noah> q?
21:32:04 <DKA> henry: it's not wrong for it to show me the rdf xml if there wasn't a hash...
21:32:28 <DKA> henry: so why shouldn't it show you the piece of the document marked by the frag id if there is a hash?
21:32:36 <DKA> tim: it should say "invalid xpointer"...
21:32:54 <noah> I think it's (Xpointer doesn't resolve, it's not syntactically invalid)
21:34:32 <noah> ack next
21:34:33 <Zakim> masinter`, you wanted to propose my alternative, "just describe the consequences"
21:34:39 <DKA> [discussion goes on with xml IDs in RDF, XML documents]
21:34:58 <noah> zakim, close the queue
21:34:58 <Zakim> ok, noah, the speaker queue is closed
21:35:52 <masinter`> NOTE: Some generic XML applications may treat documents labeled as
21:35:52 <masinter`>             application/XXX+xml using generic processing of fragment
21:35:52 <masinter`>             identifiers; this will result in inconsistent handling of
21:35:52 <masinter`>             fragments with those that have specific identification.
21:36:23 <DKA> larry: this is my proposal.
21:37:02 <masinter`> that is, just warn those registering MIME types of the consequence of defining inconsistent fragment identifier handling. No MUST, SHOULD....
21:37:05 <DKA> noah: [calls for all proposals]
21:37:33 <ht> JAR said "If XPointer defines the fragid to designate something successfully, it cannot be overriden"
21:37:56 <duerst> q+ maybe all proposals are ok; just let the 3023bis authors and the community figure out the details
21:38:06 <masinter`> i don't know what "overriden" means, and I think you'll have trouble deciding... as we did with rdf+xml
21:38:08 <noah> 1 = Larry's) NOTE: Some generic XML applications may treat documents labeled as application/XXX+xml using generic processing of fragment identifiers; this will result in inconsistent handling of fragments with those that have specific identification.
21:38:28 <duerst> q?
21:38:50 <jar_> If XPointer defines the fragid to be something (as opposed to error), that's what the fragid designates. Other fragids can be defined by +xml registrations.
21:39:15 <timbl> ^2
21:39:42 <masinter`> what happens if someone registers something that turns out to designate something else, then?
21:39:56 <timbl> 2 suffers from the problem that all RDF processors have to have a xpointer stage added 
21:40:19 <Yves> well generic processing use only a fixed subset of possible xpointer schemes
21:40:32 <noah> 3 Noah = Registrations for media types of the form application/XXX+xml SHOULD NOT define semantics for any fragment that would cause it to resolve, in a particular document, to something other than the result of the generic processing.
21:40:46 <masinter`> i mean, they define image/svg+xml#color=green to mean "select everything green"
21:40:48 <timbl> timbl has left #tagmem
21:40:52 <noah> If that becomes a MUST, rdf+xml must be grandfathered.
21:40:55 <timbl> timbl has joined #tagmem
21:41:13 <jar_> inconsistency in the specs, larry.
21:42:00 <duerst> maybe it's the java convention?
21:42:47 <timbl> When the mime type is *+xml, then the semantics of fragment identifiers are defined by the xpointer specification, except for application/rdf+xml where they are defined by the RDF specs.
21:42:55 <jar_> 4. (jar's reading of tim's mind) rdf+xml is exempt from the terms of 3023.  +xml only has the 3023 meaning if it is not rdf+xml.  ("grandfathering")
21:43:18 <timbl> logger, pointer?
21:43:49 <jar_> rrsagent, pointer?
21:43:49 <RRSAgent> See http://www.w3.org/2010/10/19-tagmem-irc#T21-43-49
21:43:55 <timbl> Tracker, can we make a vote?
21:44:02 <DKA> noah: this is not a binding tag vote - it is a fact-finding exercise. Please type into IRC which you like best, if there any you can't live with...
21:44:56 <duerst> any is okay, I'd prefer 2, but not strongly; I disagree with Tim that RDF processors would need additional implementation work.
21:45:15 <masinter`> I prefer 1, I only like 1, but... I'm not gonna lie down in front of any trucks
21:45:31 <masinter`> norm can do that for me
21:45:36 <chad> chad has joined #tagmem
21:46:39 <jar_> I'm OK with 1, 2, 4.  3 is a bit soft.  some preference for 1.
21:46:39 <ht> I like 2 best.  I can live with 1, 3 (with s/resolve/identify/), 4 and 4'
21:47:11 <noah> Like: 3 and 2, probably in that order.  OK with: Timbls "When the mime type is *+xml, then..."  Not happy with 1 or <jar_> 4
21:47:12 <timbl> live with 1,  can't live with 2,  No to 3, Like 4
21:47:22 <Ashok> I can live with 1
21:47:28 <Yves> I like 1 best. Can live with all the others.
21:47:53 <jar_> s/some preference for 1/some preference for 2/
21:47:55 <DKA> 1, 3, 4 are OK.
21:48:27 <DKA> (in order)
21:49:46 <jar_> (thinking aloud) 4 is tidy compared to 1, it says no more weird uses of fragids in other +xml types... might be cleaner guidance
21:49:56 <jar_> s/to 1/to 2/
21:54:07 <DKA> noah: we need someone to take an action to write a note "the TAG has reconsidered its previous action - a. we understand the need for generic XML processing so we are happy to have the text not removed b. we are [worried] about registration of future media types and recommend a warning be written along these lines "..."
21:55:07 <DKA> noah: only other alternative - if nobody drafts it - I will take an action to say that the TAG removes its concerns ...
21:56:29 <DKA> action rees to draft a short note to 3023bis editors reflecting the discussion / consensus...
21:56:30 <trackbot> Created ACTION-476 - Draft a short note to 3023bis editors reflecting the discussion / consensus... [on Jonathan Rees - due 2010-10-26].
21:57:38 <DKA> martin: somebody should tell somebody to fix that rdf xml dtd that got people confused...
21:57:49 <DKA> jar: we could put a comment at the top...
21:58:26 <DKA> jar: I could write a sentence and send it to Yves...
22:24:58 <masinter> masinter has joined #tagmem
22:25:23 <noah> noah has joined #tagmem
22:25:32 <jar_> jar_ has joined #tagmem
22:31:23 <DKA> Topic: IETF Draft on MIME and the Web
22:32:10 <DKA> http://tools.ietf.org/id/draft-masinter-mime-web-info-00.html
22:32:39 <DKA> Larry: I got some feedback that it wasn't about mime - or just about mime. It's not about all of mime.
22:32:59 <DKA> ... I've tried to give some context of web architecture - thinking back to how MIME was added to email.
22:33:22 <DKA> ... there were lots of document formats. How is it when you communicate from one to the other you tell someone what language it is.
22:33:52 <DKA> ... when you speak in natural language, you "sniff" - you sniff that I am speaking english. But computer languages you usually designate.
22:34:08 <DKA> ... so MIME was designed as a labelling system - for email.
22:34:59 <DKA> ... originally, HTTP didn't have content types - it only had html. Unless you wanted to send plain text.
22:35:29 <DKA> ... a popular system at the time was Gopher - it has code fields...
22:35:39 <DKA> ... single character mime type...
22:35:59 <DKA> ... and we had discussion about shouldn't we use the same labelling for file types.
22:38:31 <timbl> Zakim, who is here?
22:38:31 <Zakim> On the phone I see +1.650.214.aaaa
22:38:35 <Zakim> +1.650.214.aaaa has F2FRoom
22:38:37 <Zakim> On IRC I see jar_, noah, masinter, timbl, Ashok, ht, DKA, raman, Zakim, RRSAgent, jar, trackbot, Yves
22:38:42 <abarth> abarth has joined #tagmem
22:38:49 <abarth> hi
22:38:53 <Zakim> - +1.650.214.aaaa
22:38:54 <timbl> Zakim, F2FRoom now holds Adam
22:38:55 <Zakim> TAG_f2f()11:30AM has ended
22:38:55 <Zakim> Attendees were F2FRoom, Norm
22:38:57 <Zakim> sorry, timbl, I do not recognize a party named 'F2FRoom'
22:39:32 <noah> zakim, who is here?
22:39:32 <Zakim> apparently TAG_f2f()11:30AM has ended, noah
22:39:33 <Zakim> On IRC I see abarth, jar_, noah, masinter, timbl, Ashok, ht, DKA, raman, Zakim, RRSAgent, jar, trackbot, Yves
22:40:05 <DKA> ... I'll make a pass thru the document and go back and talk about what needs to happen - I'd rather this be a TAG document than a personal one.
22:40:57 <DKA> larry: section 2- history - about how mime added to the web the notion that it didn't predefine what kind of documents you could have... allowed adding image types, etc...
22:41:21 <DKA> ... original "distributed extensibility" - the file type was independent of the URL was independent of the protocol.
22:41:32 <DKA> ... same as for email.
22:42:07 <DKA> ... some problems - ways in which email delivery isn't the same as web delivery. In the Web there is a request and the response is interpreted in the context of the request.
22:42:40 <DKA> ... section 3.3 deserves some expansion...
22:43:10 <DKA> ... section 4 - other notes - [e.g. charsets]
22:44:19 <DKA> ... 4.3 polyglot documents - a single content type which can be delivered as more than one label. The same content delivered in different labels could mean the same thing but could also mean different things depending on the labels...
22:44:45 <DKA> abarth: Another word for polyglot that gets used a lot is "chameleon" .
22:45:51 <DKA> larry: [moving on] what is the purpose of the mine registry? [to enable interoperability around well-known media types] It's the out of band way in which messages are self-describing.
22:46:42 <DKA> ... but - languages evolve. I would like to distill the [previous] versioning discussion into something in this document...
22:47:09 <DKA> ... the registry points to a document, a specification, but also about what is being spoken "on the street."
22:48:10 <DKA> ... [lack of version numbering an issue]
22:48:45 <DKA> ... content negotiation and the use of mime types...  web architecture says how frag IDs are supposed to be interpreted but MIME type registration doesn't say anything about fragment identifiers...
22:49:20 <DKA> ... still some problems with how we're executing on MIME and belonging in this discussion is [information on] sniffing.
22:50:29 <DKA> ... section 6 is to lay out some specific recommendations - lay out the requirements for a charter for a working group to actually make the changes to the mime registry. It's a matter of staging so we agree on the problem space.
22:51:26 <DKA> noah: it's not clear to me how normatively media types registrations apply to file systems unless the file system chooses to adopt it.
22:51:52 <DKA> larry: in the web, people still pass around ftp: urls - I'm trying to lay out some things that need to be in the registry....
22:52:27 <DKA> ... [back to the document] ... 
22:52:41 <DKA> ... 6.2 - sniffing - 
22:55:56 <DKA> ... first part of the document lays out the history and some of the problems; then goes to recommendations... 
22:57:00 <DKA> tv: I would like to see - all the rules we would like to see for MIME on the web should be applied consistently to mail attachments. It's important for example for when you are displaying mail in a web browser.
22:57:28 <DKA> larry: part of the reason for pursuing this as an IETF document is to give it a position where the mail client implementers are participating in the discussion as well.
22:58:02 <DKA> adam: imagine someone invented a new image format called webP and they wanted to use this on the web - what would the lifecycle look like?
22:58:16 <DKA> larry: you register the type, you deploy viewers, ....
22:58:42 <DKA> adam: with regard to sniffing, do you think sniffers should sniff for the new mimetype or should we forbid sniffing of this new image type?
22:58:59 <DKA> ... trying to see how things will evolve beyond our messy world.
22:59:25 <DKA> larry: in a managed world, you don't guess that things are mislabeled unless in cases where they are frequently mislabeled.
23:00:37 <DKA> tim: should we put energy into making the Web work better compared to http?
23:00:55 <DKA> larry: it should also apply to a USB stick with web files on it...
23:01:54 <DKA> tim: the http system does have defined types for files - as opposed to other systems like the filesystem - should we spend our energy trying to encourage people to use http or how to use sniffing when everything fails?
23:02:08 <DKA> larry: don't see it as an eirher-or.
23:02:36 <DKA> ... we need to be clear about the current state of play and what needs to get fixed, but it's impossible to imaging a world where you never need to sniff.
23:02:55 <DKA> noah: you're talking about what  media type registration needs to say but FTP never refers to the media type...
23:03:36 <DKA> ... there are jpegs delivered through http with an explicit media type...
23:03:57 <DKA> ... if FTP doesn't use media types then it shouldn't talk about the media type registration 
23:04:12 <DKA> [imagine a spherical cow]
23:05:28 <DKA> noah: I imagine a world - a file format specification for jpeg - does not refer to the media type registration. Most file systems will refer to that - not to the media type registration.
23:06:17 <DKA> ... I imagine a media type as a second document. In your messy situation there are certain user agents who say "i cheat."
23:06:47 <DKA> larry: the registry is more than just a label.
23:07:18 <DKA> noah: it [partially] duplicates the file format spec...
23:07:34 <DKA> larry: the constituencies that need to know this information: 
23:07:53 <DKA> ... there are tool chains...
23:08:40 <DKA> ... the middleware of the web delivery chain - people who run web servers, people who run photo sites, virus scanners, content distribution sites...
23:09:04 <DKA> ... as consumers of file types, I want to put the information that the middleware people might need to know ...
23:09:23 <DKA> adam: the image resizer needs to know when the request is flying by needs to know it's jpeg...
23:10:11 <DKA> adam: the jpeg case - you have a browser that's going to take jpegs and pngs ... suppose there is a response labelled as txt and the image resizer doesn't resize it - and it arrives at the browser not resized...
23:11:03 <DKA> noah: there are parts of the architecture where it's a clean approach. We need to proceed carefully. The system will be more robust - be more "follow your nose" [if it follows the rules...]
23:12:08 <DKA> larry: this document - does not propose any changes to how implementations work today. the goal is to move the place in where what we are implementing today is described in a way in which the changes we are making as the web evolves are [easier / more sensible]
23:12:45 <DKA> adam: [is the way you guess going to change in the future? - paraphrased by henry]
23:12:56 <jar_> larry: I think there will always be workflows in which you'll have to guess the type
23:13:04 <DKA> larry: there will be new filetypes.
23:13:34 <ht> but will there be new filetypes which need to be the result of sniffing
23:14:07 <DKA> larry: I certainly would like to avoid having content that is labelled with syntactically correct labels being interpreted as something else without strong evidence that mislabelling is [prevalent].
23:14:22 <DKA> larry: if receivers refuse to sniff then senders will not mislabel.
23:14:39 <DKA> larry: it has been the case that if you get market leaders to not sniff new types then people will test their conent.
23:15:15 <DKA> adam: this is the prisoner's dilemma - think about video example.
23:15:45 <DKA> larry: I think this dilemma belongs in section 3. Establishing what the problem is - 
23:16:09 <DKA> ... what is the mechanism by which sniffing can be avoided?
23:16:16 <duerst> duerst has joined #tagmem
23:16:34 <DKA> adam: think about ie9 - they are making progress...
23:17:42 <DKA> larry: precedent - I remember when we tried to introduce the host header into http - it was going to be required to send the host header, nobody wanted to do it, but apache got configured to pop up an error when you didn't send a host header, and within 4 months the browsers all changed...
23:18:16 <DKA> ... the people who wanted to host header were the big hosting companies... there was a financial incentive [to deploying this version of apache].
23:18:21 <DKA> #webhistory
23:18:45 <DKA> larry: if we can [do something similar we can encourage people] to fix their implementaitons.
23:19:10 <DKA> adam: I tried to figure this out from a game theory perspective...
23:19:38 <DKA> larry: some people - e.g. the firewall vendors - are going to sniff.
23:19:57 <DKA> adam: they are going to sniff in the same way the browsers are going to sniff...
23:20:12 <DKA> larry: every piece of content is possibly a level upgrade ...
23:20:52 <DKA> adam: there is the file in linux with all the magic numbers for file types... We looked at how is this different from the browsers and could construct attacks based on this...
23:21:38 <DKA> noah: you could imagine a firewall that silently blocks stuff - there can be false positives on sniffing... It's good to realize that.
23:22:08 <DKA> adam: sniffing could be perfectly predictable - if everyone agrees on what algorithm to use.
23:22:31 <DKA> tim: it could be predictable but it's not always going to be right.
23:22:47 <DKA> larry: there is no logical path to come from where we are to where everyone agrees on sniffing.
23:23:07 <DKA> larry: the email vendors aren't following along - the firewall vendors aren't following along.
23:23:18 <DKA> noah: you're also punching a hole in the space of data you can deal with...
23:23:33 <noah> http://webarch.noahdemo.com/Metadata/
23:23:40 <DKA> noah: [points to example]
23:24:33 <DKA> noah: imagine this is a bug database - and they put it there to say "this is not well-formed xml" - can't serve this as text/plain
23:25:04 <DKA> larry: I'd like to cut off discussion on whether or not sniffing is good.
23:25:47 <DKA> ... the goal here is not to endorse practices but to acknowledge them, show a path forward, and show how it can evolve.
23:26:28 <DKA> ashok: I heard - in this document add a standard sniffing algorithm...
23:26:59 <DKA> larry: I want to have enough information in the registry so that they sniffing algorithm could point to it.
23:27:30 <DKA> adam: Today, I am convinced that new content types will also end up with sniffing... [so we will need it...]
23:27:39 <DKA> noah: why do the webP people want it?
23:28:04 <DKA> adam: webP want to replace jpeg - they say "jpeg gets to sniff, why not us?"
23:28:47 <DKA> noah: my ISP that if I put a jpg file they will send it as jpeg but if I put a new thing they will send it as octet stream or something...
23:28:53 <DKA> larry: we need to tell this story.
23:29:10 <DKA> noah: it would be nice if my ISP could get at the registry - thus closing the loop-hole.
23:30:09 <DKA> larry: [back to the document] one of the things we haven't touched on - practices in the community we want to ask people to stop...
23:30:24 <DKA> adam: you're proposing that the signatures be part of the MIME registry?
23:30:33 <DKA> larry: some of them are in the mime registry already...
23:30:57 <DKA> adam: if you have a separate registry - you might end up with fewer signatures and therefore less sniffing.
23:31:42 <DKA> larry: I want them all the be filled out - I want the servers to do the sniffing so that the channel to the client is more reliable. If there is unlabelled content then you should do the sniffing closer the source.
23:32:06 <DKA> adam: the folks who maintain the mime registry - do they understand the issues?
23:32:19 <DKA> larry: they are us
23:32:48 <DKA> ... we have to establish the procedures.
23:33:09 <DKA> adam: the one benefit of putting it in a standards track document is that these document go through a review process...
23:33:43 <DKA> henry: after we launched the xpointer scheme registry - the only review was a mailing list - that generated real reviews...
23:33:58 <DKA> noah: does that feel good enough for infrastructure of this criticality?
23:34:18 <DKA> henry: the media type registration list does get watched.
23:35:51 <DKA> adam: i think it's a generally reasonable direction.
23:36:06 <DKA> larry: I want to identify clearly what the problems are.
23:36:17 <DKA> adam: i am worried about the incentives of various parties.
23:39:07 <noah> http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html
23:39:44 <DKA> Topic: IRIEverywhere-27
23:40:35 <DKA> adam: at what level of detail should you describe - if you have a hyperlink in an html document how do you resolve it - the IRI spec is not accurate to what browsers do - what should we do?
23:40:48 <DKA> larry: there is a proposed spec that is more accurate. we are trying to fix it.
23:41:04 <DKA> ... martin is not completely happy with all the changes...
23:41:41 <DKA> ... roy was skeptical of if it was possible to capture all the ways applications can process strings and turn them into IRIs
23:43:11 <DKA> larry: document that is the subject of the wg - 2 documents - update to the IRI spec, has an appendix (7.2) the preprocessing steps to take a web address and turn it into an IRI...
23:44:01 <DKA> noah: adam has identified some problems, larry said we're making it better... is there a way forward?
23:45:05 <DKA> adam: there are several communities ... using URIs and IRIs ... if you have to write one document that pleases every community ... the plan is to write two documents ... we will try to reconcile these documents is there are problems. My document will be written from scratch.
23:45:46 <DKA> larry: working group chairs are interested in having you [adam] write a draft that they could incorporate as a working group work item...
23:47:12 <DKA> [discussion on working with ieft]
23:47:28 <noah> HT: The history of the LEIRI note was that someone working on an XML specification found themselves yet again preparing to copy the same transformation rules, because there was no referenceable common text to which one could refer.
23:47:58 <noah> HT: The strings start out between quotes in XML text documents, and need to wind up as RequestURIs in HTTP.
23:48:18 <noah> HT: We thought, for awhile, that it would be in 3987bis, but that stalled for other reasons.
23:48:52 <noah> HT: We then got agreement from Martin and (Michel?) to include it in IRIbis? so that we could refer to it.  I'd be very sorry to lose that.
23:49:17 <noah> AB: The section in question is an order of magnitude too small.
23:49:39 <noah> HT: I want to keep our concern "available".  We still want that common reference point.
23:49:54 <noah> AB: Not 100% familiar with constraints.  Not sure whether they're the same as HTML?
23:50:00 <noah> HT: I haven't looked at 7.1 recently.
23:50:11 <noah> LM: Let me make sure it's really 7.1 we care about.
23:50:48 <noah> AB: Consider an example of the query string.  There's some character not representable in the character set.  Some choices for how to represent it. In HTML we...
23:50:54 <noah> HT: I know the story.
23:51:02 <noah> AB: It's % escaped...
23:51:08 <noah> HT: Using the document encoding
23:51:19 <noah> HT: Pretty sure XML wants UTF-8, would have to check.
23:51:45 <noah> HT: Fairly sure it's independent of the character encoding of the XML document.
23:52:11 <noah> AB: HTML browsers are simple.
23:52:37 <masinter> masinter has joined #tagmem
23:52:49 <masinter> http://tools.ietf.org/html/draft-ietf-iri-3987bis-01#section-7.1
23:53:48 <noah> AB: Example http:///example.com (noting the intentional triple /)
23:54:15 <noah> AB: Some specifications give parses like // being the hostname and /example.com/ being the path.
23:54:44 <noah> LM: File URIs...
23:54:49 <noah> AB: Don't want to talk about them
23:55:05 <noah> LM: But we need a common parsing rule, independent of scheme.
23:55:27 <noah> AB: There are 4 sets of parsing rules, depending on scheme