W3C home > Mailing lists > Public > www-tag@w3.org > October 2012

Draft minutes of TAG F2F 7th October 2012

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sat, 13 Oct 2012 22:27:04 +0100
Message-Id: <C1DE80D8-A8B5-439D-8EA1-64A41295B6D8@jenitennison.com>
To: "www-tag@w3.org List" <www-tag@w3.org>

Draft minutes for the most recent TAG F2F day one, 7th October 2012 are available at:


and reproduced below.




      [1] http://www.w3.org/

                               - DRAFT -

   This is version has not been approved as a true record of the
   TAG's meeting and there is some risk that individual TAG
   members have been misquoted. This transcript should typically
   not be quoted, except as necessary to arrange for correction
   and approval.

              Technical Architecture Group Teleconference

07 Oct 2012


      [2] http://www.w3.org/2001/tag/2012/10/07-agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2012/10/07-tagmem-irc


          Noah, Peter, Ashok, TimBL, Jeni, Larry,
          Jonathan_(by_phone), Henry, Mark_Nottingham


          Noah Mendelsohn

          Jeni Tennison, TimBL


     * [4]Topics
         1. [5]Convene
         2. [6]TAG Election Procedures
         3. [7]HTTP 2.0
         4. [8]URI Schema Proliferation
         5. [9]FragIds
         6. [10]3023bis
         7. [11]Publishing & Linking on the Web
         8. [12]3032bis revision
         9. [13]Administration
     * [14]Summary of Action Items

   <trackbot> Date: 07 October 2012

   <JeniT> ScribeNick: JeniT

   <scribe> Scribe: Jeni Tennison



     [15] http://www.w3.org/2001/tag/2012/10/07-agenda#Convene

   noah: main goals:
   ... last call on fragid draft
   ... review comments on FPWD

   ashok: there aren't many comments

   noah: ... ok, to move that forward
   ... ht, jar & JeniT have asked for time on httpRange-14
   ... I haven't put as much time on the agenda as they say they
   need, so we might have to juggle
   ... with mnot, we have HTTP 2.0 and URI schema proliferation
   ... and finally, I don't think we're doing enough, and some of
   what we're doing is near the end game
   ... so we need to find new things to do
   ... which is complicated a little by the fact we have a lot of
   seats up for new members this February

   larry: we should discuss who's going to TPAC, and what to say

   noah: yes, we should talk about that under administration

   larry: we might want more time than that

   noah: ok

   larry: I did send some other topics; I think most of them are
   ... maybe informally we can talk about precision vs flexibility
   of specifications & error handling
   ... which came up again recently

   noah: we do have several TBD sessions, so we can see how we
   want to use that time

   ht: we need 10 minutes for TAG election procedures & 10 for
   ... we should concentrate on what we can't do on the phone

   noah: let's get to 3:30 and see

   ht: is jar calling at 3pm?

   noah: I think so

   larry: let's push election procedure & TPAC on Tuesday
   ... and cover topics of interest to jar this afternoon

   noah: ok

   timbl: tomorrow evening we'll head over to ODI to see the
   building & have dinner

   noah: we have Stuart joining us tomorrow afternoon, and Dan
   Appelquist is coming for dinner
   ... and on Tuesday mid morning

TAG Election Procedures

   noah: what's worrying me is that we have a large turnover

   larry: what about the AB?

   noah: I won't be at TPAC, but you could meet with the AB there
   ... the other piece is about tactical voting

   larry: in the election I was elected, there wasn't competition

   ht: the last one, there were more candidates than seats, and
   there was tactical voting
   ... people didn't get to express their second choice

   timbl: it's hard to characterise how it affects the makeup of
   the TAG

   noah: so what should we do?

   ht: ask the AB to review the voting procedures to change them
   to a form of proportional representation

   noah: who's in favour?

   (all say yes)

   larry: I'm concerned about a bigger question
   ... which is whether the TAG has the right expertise that the
   W3C needs
   ... that's the question: whether we have the security and
   protocol expertise
   ... the liaison with other organisations
   ... where we're going in the long term for the good of the web
   ... for the election procedure, how do we optimise for these

   timbl: I think that's interesting, and important
   ... but I think short term we should send a message to the AB

   noah: what should I do?

   timbl: just send a message to the AB

   <scribe> ACTION: noah to send a message to the AB to ask them
   to review the election procedures for the TAG [recorded in

     [16] http://www.w3.org/2001/tag/2012/08/23-minutes#action01

   <trackbot> Created ACTION-744 - Send a message to the AB to ask
   them to review the election procedures for the TAG [on Noah
   Mendelsohn - due 2012-10-14].

   timbl: the bigger question is whether the TAG should cover all
   the W3C work
   ... or target specific areas where the TAG can give value

   noah: I totally agree on not having the mix of people we need

   timbl: I'm asking how we know what's ideal for the TAG makeup

   noah: the AC might not nominate a slate of people who cover
   what we need to do
   ... appointed members have generally targetted the needs we
   have, in contrast to elected members
   ... the other thing is that we need more than one expert in an
   area such as security
   ... otherwise we can't review each others' work effectively

   larry: I disagree: the main impediment to the election is
   finding people who are willing to put up the time & expense
   ... even if it's self-nomination, you want to encourage people
   with the right skill set to volunteer
   ... the AC thinking doesn't matter, it's targetting the people
   who will put themselves forward

   timbl: the model that works is if someone thinks that it sucks
   that the TAG doesn't have representation in an area, and they
   find them and campaign for them
   ... where someone notices a gap and tries to get it filled
   ... the big problem is where no one in the area is aware of the
   TAG and vice versa

   larry: the major concern about getting people to volunteer is
   the effectiveness of the TAG and its authority
   ... if we're not producing things that are relevant, then it's
   hard to persuade people to dedicate time to the TAG
   ... finally, I noticed the HTML-WG is doing more elevating
   appeals on formal objections
   ... I'm wondering if the TAG were involved in dealing with
   appeals and formal objections
   ... more reactive to disputes in the organisation, it would
   call for more breadth and less depth
   ... do we have a broad range of skills that can deal with
   issues as they arise
   ... as opposed to diving into things in depth
   ... how else does the Director decide on formal objections?

   timbl: that's an interesting point, and it would perhaps be
   ... but it does require a deep dive
   ... by the time you have a formal objection, the argument tree
   is very deep

   ht: I think we should come back to this
   ... the narrative of the TAG includes helping the Director when
   everything gets too much
   ... we produced a document that said what the Director would
   ... but helping Director is part of our remit
   ... I think we should come back to this

HTTP 2.0

   noah: mnot, could you give us a quick overview of how things
   stand within IETF?

   mnot: we were rechartered officially on Tuesday
   ... the new charter is on the IETF website
   ... there aren't any huge surprises in it

   <noah> We == IETF HTTP Working Group

   mnot: we're going to start with the SPDY specification
   ... the editors will be Julian Reschke (in a technical capacity
   to support the production of the documents)
   ... he puts a huge amount of effort into these specs, and he
   has to support himself

   timbl: maybe W3C should have a Kickstarter system

   larry: there are some things not in the charter, that perhaps
   W3C can do, or play a role in

   mnot: yes, we would welcome that
   ... Alexy Melnikov is also an editor
   ... and Martin Thomson
   ... the idea is to publish a draft based on SPDY very soon

   ashok: quick question: the only real technical stuff in the
   charter was the SPDY parallel connections business
   ... is there anything else technical other than that?

   mnot: we're chartered to start with SPDY, which means it's a
   default which we'll refine
   ... we're not doing a requirements-first process
   ... so we'll have to respond to what people ask for in the
   ... I'm hoping for a good broad representation

   noah: what about the alternative technologies? what's happened
   with them?

   mnot: SPDY came from a 20% project from Google
   ... and it's been picked up by a number of other parties
   ... we're going to draft based on that, then get a bunch of
   ... which will come from the alternative techs, including the
   next version of SPDY
   ... we'll hold some meetings, dig into the issues, and try to
   get consensus on that
   ... plus gathering metrics, test suites and so on

   noah: have people been doing technical due diligence on SPDY?
   ... to work out whether it's about speed or something else
   that's targetted

   mnot: it's about optimising for speed, making better use of the
   underlying transport

   larry: HTTP/NG floundered because of doing flow control at
   multiple layers simultaneously
   ... you get delays that don't align

   mnot: yes, you've expressed that and Henrick has expressed that
   ... we either ship with flow control or without it

   larry: you might not see this if you run controlled servers
   ... the SPDY results required scheduling, so that the client
   knows what to request when

   mnot: it's called 'prioritisation' now

   larry: the Google benchmarks were done using the Google
   frontend server, and resources that had been optimised and
   ... we're going down a road that has intermittent failure
   modes, but none of the measurements of performance are set up
   to encounter those as you would in actual deployment

   mnot: yes, we need more test cases and to characterise the
   protocol better
   ... so Akamai is trying this out for precisely this reason

   larry: people who are concerned about web performance, you
   should look at the whole picture, how you arrange your

   mnot: at Velocity, there are thousands of people thinking about
   ... they asked whether we would provide guidance about how to
   get the best out of the protocol, and I think we should

   timbl: what's the status of SPDY and Apache

   mnot: there's a module but it's not in the core

   timbl: I'm surprised it can plug in

   mnot: Apache 2 is very modular and you can put new protocols in
   pretty easily

   noah: so all the head of line blocking stuff can't be tackled

   mnot: if someone can put the resources into that, we'd love
   ... Google, Mozilla, the people who've tried it seem happy with
   ... we haven't seen any counter examples yet

   noah: the obvious role for the TAG is to just keep in touch
   ... do the TAG members feel we need to be more focused than

   larry: the only thing to do is to put it in our report of
   things that W3C should put resources into it
   ... into the analytical work for example
   ... to bring people together to collaborate to collect the
   tests and curate them

   mnot: all the big test corpuses are from the late 90s, on
   servers that don't exist and browsers that don't exist, and web
   usage has changed
   ... we've started a github repository
   ... so we can curate the tests and replicate them

   larry: the issue for SPDY is not when you have a mashup from 15
   different sites, some of which that are spread out because of
   ... data split out because you're pulling from multiple servers
   ... this is in contrast to the Google case where the requests
   are all to the same server

   mnot: the operational characteristics are going to change, for
   example you won't want to shard, or have sprite images,
   uncombine your Javascript
   ... because that will give you less overhead

   larry: there's a difference between not getting full effect,
   and things getting worse

   mnot: the argument is that it will give more benefit for the
   sites that haven't done massive optimisation already
   ... we have to look at real code and real sites and get the

   larry: there are papers that say things get worse in some cases

   ht: we had the same thing with EXI: tell us your performance
   metrics, show us the tests, prove it

   timbl: in the future, to get interoperability you either need
   all clients & servers to fall back to HTTP, or you need
   everything to support the new protocol

   mnot: SPDY is only designed for TLS, and we need more than that
   ... we need a robust upgrade mechanism from 1.1 to 2.0

   noah: is there a goal that all servers will interoperate with
   existing clients and so on?

   mnot: yes
   ... there might be a point in the future where 1.X doesn't
   exist any more
   ... like people don't have to support 0.9 any more
   ... but we don't have to force it

   noah: it all feels good, except that it feels early to choose
   the technology
   ... like with SOAP, having it out there squewed the technical
   ... we couldn't really stop because of the deployed

   timbl: SOAP is a bad analogy
   ... replacing HTTP is a well-defined box, you can apply a lot
   of focus
   ... SPDY has been out for years

   noah: it's only in terms of not knowing what the requirements

   mnot: we have high-level goals in the charter; they're fuzzy
   ... IETF isn't full consensus, it's rough consensus and running
   ... I think we have enough strong voices

   larry: I have a question: I've heard there's been an exploit?

   mnot: 'crime' -- when you're able to look into the compressed
   stream to see what it contains
   ... I can use cookies to manipulate the compression space to
   figure out what it contains


     [17] http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/

   mnot: because SPDY uses compression, if you can have the client
   to make multiple requests
   ... it's quite esoteric
   ... it doesn't just apply to SPDY, but with HTTP basic
   authentication over TLS you can get authentication information
   ... the compression scheme in SPDY is one of the issues we've
   ... because it's quite memory intensive
   ... so we'll be looking at that to both make it friendlier and
   to avoid the 'crime' attack
   ... if you have walls between parts of the payload then you
   avoid the attack
   ... I'd like to be able to pull out a particular header without
   decompressing the stream
   ... if you're doing a bunch of requests, often there's a lot of
   repeated information in the headers

   <masinter> put HTTP headers in XML and then use XSI

   <masinter> (that was a joke)

   noah: that would require storing some state, wouldn't it?

   mnot: yes, the question is how much

   noah: is there anything else we should get organised on our

   Ashok: mnot, do you have the slides for your talk?

   mnot: they're on slideshare


     [18] http://www.slideshare.net/mnot/what-http20-will-do-for-you

   timbl: around extensibility: is it possible to use this
   opportunity to do extensibility better than in HTTP?

   mnot: in HTTPbis one of our goals is to improve the description
   of extensibility
   ... so we've done that for each extensibility point
   ... and established new registeries
   ... and improving the IANA registry processes
   ... which should make it easier to register new headers and
   link relations
   ... in terms of extensibility of the protocol, we're just
   changing the syntax on the wire
   ... not changing the headers and so on
   ... we need to gateway HTTP/1.X to 2.X for example, which is
   ... I'm going to work with Julian on this, to standardise a
   little around header syntax
   ... I do have a concern that there's going to be another
   channel for metadata in 2.0 separate from headers
   ... right now we have control headers mixed in to
   representation headers
   ... which isn't great

   timbl: and no syntactic way to distinguish them

   mnot: in SPDY there's framing with messages about how to use
   TCP and so on
   ... you could have some metadata available for intermediaries
   rather than encrypted, which might be good

   Ashok: you could put policies in there, signing and so on

   mnot: we'll see

   <Zakim> masinter, you wanted to talk about sniffing in HTTP 2.0
   and to talk about content-addressable networking for static

   larry: the TAG has a finding about authoritative metadata, but
   we have sniffing
   ... the reason we have sniffing is because the servers are
   ... my proposal was for browsers to turn off sniffing if it's
   HTTP 2.0
   ... to drive servers to fix their media types
   ... could you put into the update something that removes some
   of this variability

   mnot: HTTP is a hop-by-hop protocol
   ... Akamai could front with HTTP/2.0 a 1.X server, and can't
   get them to fix their media types

   larry: if you have intermediaries then they have to do the
   ... the other way around you don't care

   mnot: that seems convaluted

   timbl: so you make Apache SPDY implementation parse throw an
   error if it's not clean code going through

   larry: if you add SPDY support to a 1.1 server, all the content
   will come blank because it's a server configuration error in
   not providing the correct media type

   noah: if you're an intermediary, how do you know what to
   convert to?

   <Yves> asking intermediaries to do the sniffing can be done
   only for intermediaries that want to transform the content,
   otherwise latency will go up

   mnot: my inbox is full of people asking for HTTP/2.0 to fix
   problems with 1.X
   ... the last time we tried to do this was with pipelining, and
   it didn't work out
   ... I'm not convinced that people will implement it
   ... you can bring it up in the group
   ... none of the implementers are going to like that suggestion

   <Zakim> ht, you wanted to ask about HTTPbis relations

   ht: what's the relationship between HTTPbis and 2.0?

   yves: HTTPbis is finishing, almost done
   ... 2.0 is new stuff

   timbl: 2.0 is a transformation of 1.1: you can point to the 1.1

   mnot: the 1.1 series of specifications define the semantics,
   which we are not going to touch in 2.0

   ht: what's in scope for 2.0 vs what was in scope for bis?

   mnot: it's just how we serialise the semantics of HTTP onto the
   ... we're bumping the major version because it's not compatible
   on the wire, not because we're reinventing the semantics
   ... the APIs in the implementations won't change

   <masinter> it's possible to change the default for missing

   <masinter> because a 2.0 -> 1.1 gateway can make the missing
   header explicit

URI Schema Proliferation


     [19] http://dev.w3.org/html5/spec/single-page.html#custom-handlers

   larry: the issue was raised about sites defining themselves as
   handlers for URI schemes and media types
   ... the issue was whether this could be done securely
   ... whether there's a blacklist or a whitelist

   ht: doesn't mean the lists are fixed

   mnot: there could be a registry

   larry: a list is a list
   ... the spec said that content handlers were a blacklist, that
   there were some that couldn't be overwritten
   ... but protocol handlers, they said they couldn't predict
   which protocol handlers were out there
   ... so they gave a whitelist
   ... but that wasn't extensible enough, so they introduced a
   special syntax for the scheme: web+

   timbl: where web+ means...

   larry: this is a scheme where you can override the handling of
   the protocol


     [20] http://developers.whatwg.org/iana.html#web+-scheme-prefix

   mnot: I try to think about the use cases; there's little
   discussion of the use cases
   ... one is URIs that are pure identifiers eg geo: scheme

   larry: or tel:

   mnot: right, they're not locators, pure identifiers
   ... you can't know where to dereference the geo: URI for
   ... there's nowhere to go to dereference that
   ... but with registerProtocolHandler you could say, send those
   URIs to Yahoo maps or Google maps or Apple maps
   ... that's an interesting use case
   ... with my IETF hat on, there are a lot of people in IETF who
   are interested in late-binding of URIs to doing something with

   timbl: I'd like to be able to pick what I do with mailto:
   ... and mail ids
   ... I'd like to do something intelligent with those

   mnot: right, you could write a handler to maybe look locally
   and then go off to other servers
   ... so that's one cluster of use cases
   ... the other one is people building protocols on top of HTTP
   such as OpenID and OAuth and WebCal
   ... something which is HTTP but I'm giving it special semantics
   ... I'm a little more concerned about this, because you're
   locking your identifier to a single protocol (assuming HTTP)
   ... for example, OpenStack are using HTTP, maybe they'll choose
   to use their own URI scheme, and I'm not sure whether that's a
   good use of URIs

   <masinter> looking at the spec,

     [21] http://developers.whatwg.org/timers.html#custom-handlers

   timbl: take daap: you can get open source music servers
   ... I'd like to run a server that serves up my music and
   metadata and playlists, but I have playqueues
   ... with HTTP I'd have conneg on format of music and playlists
   and so on
   ... there's a lot of extensibility which is being blocked, to
   block competition

   mnot: I'm pretty convinced that it's not the right way to build
   HTTP-based protocols
   ... but we don't have the guidance about how to do that well
   ... the feedback I'm planning to give personally is that I'd
   like them to expose a registerLinkRelationHandler
   ... I'd like to see the markup of the link -- the link relation
   -- to determine how to handle the link

   larry: my concerns are different
   ... the use cases are compelling, and there are lots of them
   ... it's a great feature, great motivation for doing it
   ... both registering content type handlers and protocol
   ... but it changes the story about the use of the registeries
   ... the applicability of the guidance we give about registering
   ... and the assumptions about the difficulty of deploying new
   ... my concerns are about security
   ... and for all that we've made registeries easier to get into,
   it removes the motivation to register things
   ... the community that we most want to reach to register things
   and follow our recommendations
   ... if you can dynamically allocate a handler, then why bother
   to register
   ... it decreases the value of registration
   ... there's a marginal value that the registry would tell you
   what something means, and let you find a handler for it
   ... but now you can just provide your own, the marginal value
   of declaring yourself owner of something in the registry has
   been reduced
   ... there's nothing in the spec about using registered values
   for example

   noah: if there isn't web+ what are we asking people to do?

   mnot: there are two issues: one is the existence of the
   register*Handler, and the other is the web+ convention

   larry: I got involved in the debate over web+ but I think
   that's a distraction, the first is the thing we have to worry

   noah: there's something very local about register*Handler
   ... registering something in an IANA registry is very global

   mnot: but it's not either/or

   noah: I understand that, but Larry was saying that
   register*Handler would reduce the value of the other path

   <masinter> registerProtocolHandler has an immediate effect,
   while registering something in IANA still leaves you with
   "running code" as a question

   mnot: if there are problems in the IANA registration we have to
   fix them, but that's separate

   noah: what about the web+ issues?

   mnot: I think there are a lot of questions to be answered, like
   what's the relationship between foo and web+foo?

   <masinter> I'm not concerned about the methods once the
   security and privacy concerns are addressed. I'm just wondering
   why we continue to work on the registries, since they aren't
   nearly as useless as the IANA registries.

   timbl: was web+ designed by people who felt they didn't control
   the whitelist?

   larry: the rationale for it was given as that they didn't want
   to do a blacklist because they were uncertain about existing
   deployed protocols

   <masinter> perhaps vendors have lots of schemes that they don't
   want anyone to overwrite, but they don't want to bother

   noah: web+ seems to be bundling up something in the name which
   is about how the URIs are used
   ... that feels very wrong to me: we should be figuring out how
   to make whitelists

   mnot: the browsers say they don't want to be updating the
   whitelists all the time
   ... but actually they get all sorts of whitelists all the time
   ... which they update all the time

   larry: I had a use case that I was worried about
   ... when we did mailto: there was concern about privacy
   ... that when you clicked on mailto: it didn't send the message
   right away
   ... we didn't want them to interact with the server until you
   had looked at the message and confirmed it
   ... if I register GMail to handle it, GMail gets notified when
   I compose the message

   mnot: the default action for any URI is that it's safe

   larry: the problem is that the handler makes a permanent change
   to the system

   mnot: I think the presumption is that the browser guys will
   have a user experience around managing the mappings

   larry: this is all going to happen: there are compelling use
   ... people know that if you use the web you've lost all your
   privacy anywe
   ... why should we continue to bother with these silly

   mnot: my concern is mostly around that by allowing this
   capability in browsers, it tilts the creation of web
   applications toward a certain architecture
   ... that's why I want a registerLinkRelationHandler
   ... and the other concern is about the web+ convention
   ... it's almost aesthetic, but it's like X-

   noah: you're bundling something into the name, and the thing
   you're naming has other uses
   ... the name has other uses which have nothing about the
   protocol handler
   ... this feels like something that the TAG should do something

   mnot: there's emerging consensus in the IETF from discussions
   around X-
   ... which is putting structured information inside identifiers,
   anything that is ephemeral or temporal or context-specific
   ... we've had a few experiences of this in protocol designs,
   where it's not worked out

   noah: how can we work with the IETF towards a good solution?

   mnot: what kind of timelines are we on?

   ht: I think the longer term question is longer term
   ... we've lived in a world in which there have been a handful
   of schemes for a long time
   ... it looks as if we're headed for a world in which that is
   going to change
   ... what are the consequences of that?

   mnot: that was my first reaction, and I'm not sure any more
   ... I don't think we'll see 50,000 bloom overnight

   ht: even if we go from less than 10 to more than 50 over the
   next five years, what's going to happen?

   timbl: it's not just a large number, it's a shift from being
   defined openly in the IETF but to locking people in to a
   particular system

   mnot: you have to convince people to use the URIs on their
   ... I think that's a fairly high bar

   <noah> [22]http://www.w3.org/TR/webarch/#pr-reuse-uri-schemes

     [22] http://www.w3.org/TR/webarch/#pr-reuse-uri-schemes

   <ht> It amounts to introducing a new distributed extensibility

   <noah> Good practice: Reuse URI schemes

   <noah> A specification SHOULD reuse an existing URI scheme
   (rather than create a new one) when it provides the desired
   properties of identifiers and their relation to resources.

   <ht> And per analysis which JAR has recently done, distributed
   extensibility introduces the potential for interop loss

   <ht> At the very least, introducing distributed extensibility
   into the URI name system at the scheme level is a novelty which
   we really need to examine

   timbl: I'm thinking about itunes: which people use to point to
   an iTunes App

   mnot: it's interesting because Apple have moved to using a
   content type

   noah: we wrote about that

   mnot: if we have good handlers for content types and link
   relations, then I don't think there's a strong need for
   extensibility around URI schemes

   noah: what could we do about this that would be effective?

   larry: my take is that this is the future, and the TAG should
   stop trying to limit the number of URI schemes
   ... now doi: can be deployed, now info: can be deployed
   ... the arguments we've given in the past no longer applies

   ht: because you no longer have to change the browser to support

   mnot: there's the question about the web+ schemes, whether they
   should be linking to the registry

   noah: I believe we've previously had strong review of new URI
   ... this seems to suggest that review is superfluous

   larry: Dave Thaler took all the URI schemes in Wikipedia and
   registered them as provisional schemes, in the last month or so
   ... there were about 70 of them

   mnot: we can't stop people from deploying schemes
   ... we can try educating them, and document the best practices

   larry: there's skype: and notes:

   ht: it becomes a market economy

   mnot: perhaps it's self-limiting

   ht: wrt message handlers, about registry management and
   IANA/IETF expert review

   mnot: there are only a handful of people who care about this
   stuff, and there's consensus amongst them

   <jrees> Odd that the values arent communicable

   ht: it's moving towards saying that it's about documenting the
   state of deployment etc
   ... with the side effect that it serves as a collision
   avoidance mechanism
   ... if you have distributed extensibility without a collision
   avoidance mechanism, then there's potential for a train wreck
   ... so long as the registration is lightweight, you're ok

   mnot: it would be nice if all the URI schemes, link relations
   and so on were well-specified and architecturally sound
   ... but that's not the world
   ... for me the really interesting part is whether registries
   are the correct approach for HTTP methods as opposed to URI
   schemes and link relations

   ht: the other thing to cover is the motivation of the
   application focus of the major focus of the major vendors is at
   the moment
   ... why they're interested in the web as the application
   ... the browser as the app delivery platform
   ... and the relevance of the mobile web
   ... the major concern of a number of vendors is to break the
   platform-specific advantage
   ... platform-specific apps have a performance advantage at the
   ... a lot of why vendors are pushing the browser is about
   fixing that to avoid being locked out of these platforms
   ... that's not my insight, btw, it's mnot's

   larry: there are some principles that we would like to have,
   such as links
   ... the protocol handler shouldn't have to go to the web, it
   could go to the local app
   ... the question is whether creating native apps is in scope
   for W3C, and I think it is

   Ashok: I am also concerned about security
   ... about people hijacking your handler

   noah: it feels like only half the technical things being
   proposed are needed to achieve the goal
   ... a sense that we can't afford to wait to get things right

   <timbl> hmmm

     [23] http://itunes.apple.com/gb/album/beatles-1967-1970-blue-album/id400835735

   <masinter> note that registerContentHandler doesn't say
   anything about fragment identifiers

   <timbl> ScribeNick: timbl

   <scribe> Scribe: TimBL


   <noah> Vocabulary: A set class/property/element/attribute names
   for use in a markup language or other media-typed content


     [24] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html#dfn-vocabulary


     [25] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html

   <noah> +suffix registration

   <noah> a registration for a +suffix

   <noah> Should that be a >media-type< registration for...?

   Noah: We are now in our schedule up to fragid semantics
   ... We traditionally do some admin and planning after the
   break, but we can do whatever we like.


     [26] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23


   Jeni: The history is we got a proper FPWD out Juneish.

   [general discussion of the history]

   Jeni: We got one set of substantive comments.

   <masinter> we got a positive review from Alexey M

   Jeni: We are trying to ge this through the process ASAP, no
   substantive comment expected
   ... I will this session go through our response to that
   ... We will then just proceed though the process.
   ... A new editors draft is up of 23rd .


     [27] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html


     [28] http://lists.w3.org/Archives/Public/www-tag/2012Sep/0042.html

   Jeni: Looking at my response to Sebastian
   ... He seemed to be using RFC2046 terminology, different to
   what is used in the current media type registration draft.
   ... He uses the terms 'subtype', for example.
   ... I did a few changes of my document to change the

   Larry: If you go to that URL
   ... They are holding it -- it is approved but on hold pending
   the suffix registration ... on which it has a dependency.

     [29] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14)

   Jeni: The comment #2 he had was about long noun phrases.
   ... The majority of the changes I made were to try to fix that.
   ... This is to make it easier to read. Also introduced new
   terms like metaformat and vocabulary to make the text easier to
   read... maybe I went to far. Let's discuss that.
   ... Noah, please now do your anti-'vocabulary' rant.

   Larry: It looked better to me with 'vocabulary'.

   Jeni: We use the term 'metaformat' but I am not sure everyone

   Noah: I am fine with what you are trying to do.

   Jeni: I used 'fragid' and '+suffix' as a shorthand.
   ... for media type suffix registrations.

   <JeniT> todo: +suffix registration definition to include 'per
   the RFC'

   Jeni: The other definitions were there already [just before
   section 3]
   ... Now the email comment point #3
   ... He suggested the term 'pragmatics' for the rules which we
   use to process something, but I pushed back as I felt that was
   ... I made no change there.
   ... "Media Subtype Registration" he said you should use but out
   isn't defined so I said no.
   ... "Structured Syntax Suffix Registrations" I tried to adopted
   what was good about his suggestion and otherwise pushed back.
   ... There were no logical issues, only linguistic ones.

   timbl: nice abstract
   ... use the term 'local ids' rather than 'anchors'
   ... if you have some generic software, it doesn't work for the
   media type to specify the prioritisation

   JeniT: yes, in the body of the document it says that

   timbl: The bit " Where fragid syntaxes do overlap, media type
   registrations should specify which take priority in resolving a
   given fragid." but in the case of an unknown media type using a
   known suffix, there is no known media type spec to specify
   which can override.


     [30] http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2Ffragid-best-practices%2F&doc2=http%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2Fdoc%2FmimeTypesAndFragids

   ht: Let's just chop out masses of the abstract

   timbl: no, nice length, nice summary -- many people will only
   read that.

   JeniT: In general, the media type registration has to specify
   how fragids are interpreted
   ... This is attempting to summarize Best Practice 2.


     [31] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html#specify-resolution-of-overlaps

   timbl: This is about multiple conflicting structures

   ht: At the end of section 5,
   ... there is this very delicate wording issue, which is the way
   we dealt with the RDF case.
   ... If a point in a [lexincal] space defined by the generic
   processing is not in is domain, then you look for a more
   specific scheme to give you an answer.
   ... This means in the RDF case, this work so long as foo#baz is
   something the generic +xml spec does not have anything to say

   <JeniT> todo: make sure to include fact that +xml generic
   processing must be preserved in media type

   Jeni, maybe put tth eBP numbers in the TOC


     [32] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html#enable-additional-fragids

   [discussion of that, HT getting in sync w spec]

   Noah: I don't have a problem with what you mean by "top level
   ... You could say "such as image or text".

   <JeniT> todo: add a 'such as' for top-level type and +suffix
   use in abstract

   Noah: Are people leaning toward approaching this as a top-level

   Larry: I have some notes.
   ... Around IRIs and unicode normalization .. There are more
   best practices than are listed here.

   <JeniT> todo: say we're not addressing unicode normalisation,
   internationalisation, use of fragids in registerProtocolHandler

   Noah: You are swelling the punch line... should we hold off or

   Larry: No, publish

   jeni: In the SOTD you can mention things like where other work
   would be possible and relevant.

   Larry: Or in the introduction.

   Noah: A separate Future Work Section?

   JeniT: no need for that.

   ht: The RDF problem is resolved at the resolution level, not
   the registration level.
   ... The trick is that in fact the XML system will in practice
   for RDF documents not return a resolved thing for a RDF fragid.
   ... You have to just avoid using about="#foo" and id="foo" in
   the same document or things break.

   <JeniT> or it means that you are making statements about the
   element in the XML document

   ht: Two other things we could say: Avoid things which lead to
   contradictory results.
   ... Or we can also re-issue the RDF+xml spec to allow the XML
   one to take priority.
   ... Or maybe we should point out what could go wrong if you
   don't avoid it.

   <JeniT> todo: possibly add sentence that says that if you don't
   follow the rules aroudn honouring generic processing of fragid
   structures, you can get points where the same fragid points to
   different things based on different processing

   <noah> maybe s/different/generic vs. specific/ ?

   Ashok: Re BP7, the end of it says "anything" .. "should say
   that such fragids are resolved according to rules in the
   registration of the vocabulary and may identify anything."
   ... I would prefer "not constrained" in some way.

   <JeniT> todo: s/and may identify anything././

   timbl: may identify anything becomes "identify whatever is
   defined in the M T R".

   <noah> Best practice 7: leave out the words "and may identify

   timbl: If you have many generic patterns defined, then the
   later ones cannot override the earlier ones, as they have to be
   consistent with systems which were defined wit knowledge of
   only the early spec. Therefore is reasonable to apply the
   algorithms in chronological order by date of spec.

   larry: We shouldn't define Bps for a spec which is being
   ... We should get this document into the loop for the processes
   which produce media type registration documents in W3C and IETF

   [meta re agenda]

   Larry: We should made sure that this document is referenced
   where it should be.
   ... There is Public Relations about going to Proposed

   <masinter> registerContentHandler needs to say something about
   fragment identifiers

   Jeni: I will do another draft, take it to a telecom for
   conformation then publish it.

   Larry: I am happy to Last Call this now.

   [Straw poll suggests making the basic Last Call decision now]

   PROPOSED: We will vote to go to last call under the following
   -- JeniT will indicate when draft is final, then four working
   days for objects, failing which implicitly permission for JeniT
   to publish.

   RESOLUTION: We will vote to go to last call under the following
   -- JeniT will indicate when draft is final, then four working
   days for objects, failing which implicitly permission for JeniT
   to publish.


   HT: ... I now have the write lock on 3023bis

   <noah> ACTION-689?

   <trackbot> ACTION-689 -- Henry Thompson to work with Noah to
   draft a further request to the RFC3023bis editor from the TAG
   to include advice regarding what a particular +xml media type
   registration should do wrt fragid semantics along the lines in
   the discussion on media types and fragment identifiers at the
   f2f on 2012-04-04 -- due 2012-10-01 -- OPEN


     [33] http://www.w3.org/2001/tag/group/track/actions/689

   <ht> draft-ietf-appsawg-xml-00

   <noah> ACTION-564?

   <trackbot> ACTION-564 -- Henry Thompson to track fragid issues
   in 3023bis, report to TAG and/or communicate with 3023bis
   editors as appropriate -- due 2012-09-30 -- OPEN


     [34] http://www.w3.org/2001/tag/group/track/actions/564

   HT: I hope to get this published ... it should come out soon as
   a ...
   ... as draft-ietf-appsawg-xml-00

   Larry: There is a deadline October 15th for -00 versions of
   Internet drafts =before the next IETF meeting

   <noah> hmm ... I see no actions to Jeni on fragids...

   HT: There is a October 19 deadline for last call for +suffix


   HT: There is a document with a bunch of +suffix registrations
   which have never been registered and includes language from
   JeniT's document.

   <masinter> 2012-10-15 (Monday): Internet Draft Cut-off for
   initial document (-00) submission by UTC 24:00, upload using
   IETF ID Submission Tool.

   HT: It references 3023 of course, I hope it could reference my
   version instead of course.
   ... So text/xml and text/xml[…]entity are being undeprocated
   due to deployment
   ... The resolution is that text/xml can override text/ in
   defining default charset.


     [35] https://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-06

   <noah> ACTION-689?

   <trackbot> ACTION-689 -- Henry Thompson to work with Noah to
   draft a further request to the 3023bis editor from the TAG to
   include advice regarding what a particular +xml media type
   registration should do wrt fragid semantics along the lines in
   the discussion on media types and fragment identifiers at the
   f2f on 2012-04-04 -- due 2012-10-01 -- OPEN


     [36] http://www.w3.org/2001/tag/group/track/actions/689

   <noah> close ACTION-689

   <trackbot> ACTION-689 work with Noah to draft a further request
   to the 3023bis editor from the TAG to include advice regarding
   what a particular +xml media type registration should do wrt
   fragid semantics along the lines in the discussion on media
   types and fragment identifiers at the f2f on 2012-04-04 closed

   HT: and our representations about fragids are bing implemented.

   <noah> ACTION-564?

   <trackbot> ACTION-564 -- Henry Thompson to track fragid issues
   in 3023bis, report to TAG and/or communicate with 3023bis
   editors as appropriate -- due 2012-09-30 -- OPEN


     [37] http://www.w3.org/2001/tag/group/track/actions/564

   <noah> ACTION-564 Due 2012-10-23

   <trackbot> ACTION-564 Track fragid issues in 3023bis, report to
   TAG and/or communicate with 3023bis editors as appropriate due
   date now 2012-10-23

   [discussion of how to explain this all to trackbot]

   <noah> ACTION-707?

   <trackbot> ACTION-707 -- Henry Thompson to keep an eye on
   -regs-00.txt and relation to RFC 3023bis -- due 2012-10-05 --

     [38] http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt


     [39] http://www.w3.org/2001/tag/group/track/actions/707

   <noah> close ACTION-707

   <trackbot> ACTION-707 keep an eye on
   -regs-00.txt and relation to RFC 3023bis closed

     [40] http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt

   <noah> ACTION-543?

   <trackbot> ACTION-543 -- Peter Linss to propose addition to
   Fragid draft to discuss sem-web use of fragids not grounded in
   media type -- due 2012-09-26 -- OPEN


     [41] http://www.w3.org/2001/tag/group/track/actions/543

   Jenit: 543 was for me to write stuff around complex identifiers
   in RDF etc, which lead to this work, and got repurposed at some
   point to something for Peter? Not sure how.

   Larry: I have something I don't want to do but I think I should
   ... The registered content handler in HTML doesn't say
   anything, as the registered protocol …there is nothing about

   Jeni: We should be taking on work around that whole area.

   Noah: There is session at the end on TAG priorities. Remind me

   <JeniT> ACTION: Jeni to get LCWD of fragids & media types
   published and respond to comments [recorded in

     [42] http://www.w3.org/2001/tag/2012/08/23-minutes#action02

   <trackbot> Created ACTION-745 - Get LCWD of fragids & media
   types published and respond to comments [on Jeni Tennison - due

   <JeniT> ACTION: Jeni to raise a bug on registerContentHandler
   and registerProtocolHandler to ask for specification of how
   fragids are handled [recorded in

     [43] http://www.w3.org/2001/tag/2012/08/23-minutes#action03

   <trackbot> Created ACTION-746 - Raise a bug on
   registerContentHandler and registerProtocolHandler to ask for
   specification of how fragids are handled [on Jeni Tennison -
   due 2012-10-14].

Publishing & Linking on the Web

   Ashok: We published FPWG
   ... We got on it 3 comments, Renato Ianella about a reference
   to a licence -- JAR and he agreed with him.
   ... One from D Booth who wants a section -- "Who are we writing
   this document for"?
   ... The Third comment is from a lawyer from CDT the center for
   democracy and technology:
   ... 1) If this is for non-technical people like lawyers, then
   there is jargon like HTTP headers which we should explain.

   Larry: Danny W had a comment:
   ... A layer at Adobe wondered what we were doing in the first
   ... We should explain the history. Some anecdotes.

   Timbl: Maybe some example of people actually confused out there
   on the web.

   Noah: SOPA and PIPA came later.

   Jenit: It was people being arrested for embedding when the were
   reported as linking.

   <masinter> I'm not sure what initiated our discussion of
   "publishing and linking" motivating the work, but now that we
   have the document, I see news articles daily which remind me
   that governance of the Internet is difficult enough... Should
   YouTube have taken down the offensive video ostensibly causing
   riots? How can facebook prevent being used for "cyberbullying"
   ? Are there any underlying principles we can discover?

   <masinter> So the question is "without rewriting this document
   completely from the ground up, is there anything we (the W3C
   Technical Architecture Group) can do to make this level of
   analysis more useful. To someone.

   <masinter> If we can find a (substantial) community that finds
   it (reasonably) useful, then that will be sufficient. There may
   be some other document we could write that would be even more
   useful, but the TAG has a limited attention span.

   Ashok: One suggestion was to start with the legal issues and
   then derive the technical bits .. but we are not qualified to
   write that document.
   ... JAR has provided two very useful documents, one pointing to
   early RFCs, and a book, soI will add those in.

   Larry: I replied to Danny: [@@ scribe -- passed into IRC above]

   Ashok: We have had comments saying it is very useful to spell
   out these differences.

   <jrees> It was about dissonance between consesus among tech
   fiolks and rest of society

   <noah> TBL: Make clear that this is not a policy document

   timbl: We need to make it clear that the document is not law
   and is not policy.

   Ashok: Maybe we can get Thinh N'guyen to look at it,
   ... Then too look at technical terms we need to explain.

   <jrees> Purpose was to record consensus of tech community, re
   expectations on purpose and use of tech

   [Two or three TAG members have read this version]

   <jrees> State the obvious. Not immediately 'useful'...

   Larry: What I would like to see happen.
   ... I see a lot of activity. We have seen with concern the
   moves to use Internet policy to the ITU,
   ... we have seen various countries wanting to control
   communication, and the debate offer the YouTube video and the
   ... I think we have reached the edge of the TAG's remit, I
   think we have hit a good point, and happy if we have been a bit
   controversial. No one else in the W3C is sodding this. I think
   it important for W3C too do this.

   <jrees> If we wait for the doc to be 'useful' it will be too

   <Ashok> +1

   Noah: I hope we can say that this is very well done. Fragids we
   can sort out later, but this has to be consistent, as its
   intent is to clarify.

   <jrees> Point is to not be reactive, to put tech neck out re
   purpose of tech

   Askok: You want the governance and risks documents to be
   separate documents?

   Larry: "Publishing and linking" has been through a lot of
   ... It is clear -- or it will be when we explain -- why we got
   started in this.

   <noah> I just want to be sure that, as far as it goes, it's
   clear and of high quality. I haven't (unfortunately) read it
   lately, so am not well informed. Larry says: yes, quality is
   very good, so I'm happy.

   Ashok: Let's fix known bugs then ask the TAG about last call.

   Larry: Would be nice to have it in Last Call at TPAC.

   Yves: There is no moratorium BEFORE TPAC, only DURING

   Ashok: The Intro needs some use cases to be found....
   ... The Intro needs some use cases to be found….Jenit: Some
   pointers already in the document.

   Larry: Just some background about why we did this

   Ashok: Ok.
   ... We will try to get feedback from commentators rapidly.
   ... David Booth we can.

   Noah: On the call on the 18th, let us know where we are.

   Ashok: OK.

   Noah: See the product page for this.


     [44] http://www.w3.org/2001/tag/products/PublishingLinking.html

   <noah> ACTION: Ashok to update product page on publishing and
   linking: dates and link to public draft [recorded in

     [45] http://www.w3.org/2001/tag/2012/08/23-minutes#action04

   <trackbot> Created ACTION-747 - Update product page on
   publishing and linking: dates and link to public draft [on
   Ashok Malhotra - due 2012-10-14].

   <noah> ACTION: Ashok to prepare draft of Publishing and Linking
   by Oct 15 - Due 2012-10-15 [recorded in

     [46] http://www.w3.org/2001/tag/2012/08/23-minutes#action05

   <trackbot> Created ACTION-748 - prepare draft of Publishing and
   Linking by Oct 15 [on Ashok Malhotra - due 2012-10-15].


3032bis revision

   [HT projects]

   <ht> From our minutes of April f2f:

     [47] http://www.w3.org/2001/tag/2012/04/04-minutes#item02

   <ht> RESOLUTION: The TAG requests the 3023bis editors to adopt
   the following wrt fragids: The semantics of barename fragment
   identifiers is as follows: for those barenames in a +xml
   document which are "identifiers of an element" as defined in
   [XPointer Framework], a barename fragid identifies the element
   [XPointer Framework] says is does. The semantics of all other
   barename fragids are unconstrained

   <ht> by this specification. Likewise wrt other fragids using
   registered XPointer schemes, i.e. that XPointer "failure to
   find" errors are not errors, rather a statement of

   [HT edits on screen]

   Ht: This is my proposed resolution of that change.

   <noah> hmm. Let me check.

   <ht> Please note that the other editors have not seen this, and
   may not agree to it:

     [48] http://www.w3.org/2001/tag/2012/10/private_draft_draft_3023bis_draft.htm

   [scribe asks for URI to it -- shared with the TAG but not
   generally accessible]


     [49] https://www.w3.org/2001/tag/2012/10/private_draft_draft_3023bis_draft.htm#frag

   HT: The first question is whether the change requested (to say
   that for the +foo you do not claim control of syntaxes you do
   not control) is described here.
   ... Maybe by getting out of the way here we can allow some one
   to generate say a new spec for text/* -- this is broader than
   what was originally asked for.
   ... A detail question is that the way this ends doesn't say
   what happens when the attempt succeed: that we are done.
   Nothing else happens.

   Noah: Works for me as is.
   ... Who would object to this broadening? Let's put it out there
   and see whether anyone objects -- this is the Internet after

   Yves: The XML community should see it..
   ... through the XML CG

   HT: But there has been really no previous document.

   JeniT: maybe people will expect errors to fail hard

   timbl: XPointer's syntax includes typos
   ... there's a narrower language that uses XPointer's schemes
   ... and a narrower set that actually resolves to an element in
   the document

   ht: noah's point was without processing you can describe three
   ... the string is not a syntactically valid XPointer
   ... per your XPointer implementation
   ... it's helpful to pull out three possibilities (1) you
   resolve the XPointer (you win), (2) you lose because it's not
   syntactically correct, (3) you lose because the pointer doesn't
   identify an element in the document

   timbl: I think there's another case in XPointer that they
   haven't talked about, which is about what schemes are supported

   [discussion of possible combinations or error]

   NM: My concern is that a fragid like element(A) should refer to
   element(A), regardless of whether my particular processor
   supports it

   HT: Suppose in a new media type spec "I will use the henry
   X-pointer scheme".
   ... What I want is for this spec to leave it alone, so I can
   grab it.
   ... Whether -- the scheme is registerers by there is no
   resolution for this particular case -- or ...

   Noah: Suppose [missed]

   HT: I need to go away and think about this.
   ... When we need to push this past the XML community, the best
   way is to push this past the CG..
   ... This has to call out the fact that this maybe considered a
   change t othe implicit semantics which have been considered

   <jrees> Yes

   HT: I think i should talk about semantics rather than

   [ Discusssion involved also
   [50]http://www.w3.org/TR/xptr-framework/#syntax ]

     [50] http://www.w3.org/TR/xptr-framework/#syntax


   RESOLUTION: TAG will meet 15-17 January, tentatively at Adobe
   West Coast, but may switch to Cambridge depending on Noah, Tim
   Jeni availability.

   [more discussion]

   RESOLUTION: The TAG will (probably) meet in Cambridge March
   19-21 2013

Summary of Action Items

   [NEW] ACTION: Ashok to prepare draft of Publishing and Linking
   by Oct 15 - Due 2012-10-15 [recorded in
   [NEW] ACTION: Ashok to update product page on publishing and
   linking: dates and link to public draft [recorded in
   [NEW] ACTION: Jeni to get LCWD of fragids & media types
   published and respond to comments [recorded in
   [NEW] ACTION: Jeni to raise a bug on registerContentHandler and
   registerProtocolHandler to ask for specification of how fragids
   are handled [recorded in
   [NEW] ACTION: noah to send a message to the AB to ask them to
   review the election procedures for the TAG [recorded in

     [51] http://www.w3.org/2001/tag/2012/08/23-minutes#action05
     [52] http://www.w3.org/2001/tag/2012/08/23-minutes#action04
     [53] http://www.w3.org/2001/tag/2012/08/23-minutes#action02
     [54] http://www.w3.org/2001/tag/2012/08/23-minutes#action03
     [55] http://www.w3.org/2001/tag/2012/08/23-minutes#action01

   [End of minutes]

    Minutes formatted by David Booth's [56]scribe.perl version
    1.136 ([57]CVS log)
    $Date: 2012/10/13 21:25:16 $

     [56] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [57] http://dev.w3.org/cvsweb/2002/scribe/

Jeni Tennison
Received on Saturday, 13 October 2012 21:27:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:48 UTC