Technical Architecture Group Teleconference -- 07 Oct 2012

<trackbot> Date: 07 October 2012

<JeniT> ScribeNick: JeniT

<scribe> Scribe: Jeni Tennison

Convene

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 there

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 covered
... 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 administration
... 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 platform
... for the election procedure, how do we optimise for these things?

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 http://www.w3.org/2012/10/07-tagmem-minutes.html#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 cool
... 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 say
... 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 group
... 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 issues
... 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 too
... 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 prioritised
... 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 resources

mnot: at Velocity, there are thousands of people thinking about this
... 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 analytically?

mnot: if someone can put the resources into that, we'd love that
... Google, Mozilla, the people who've tried it seem happy with it
... 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 that?

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 sharding
... 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 numbers

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

noah:

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 solution
... we couldn't really stop because of the deployed implementations

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 are

mnot: we have high-level goals in the charter; they're fuzzy
... IETF isn't full consensus, it's rough consensus and running code
... 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

<Yves> 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 to HTTPbis you can get authentication information
... the compression scheme in SPDY is one of the issues we've discussed
... because it's quite memory intensive

<masinter> s/to HTTPBis/with HTTP basic authentication over TLS/

mnot: 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

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

mnot: if you're doing a bunch of requests, often there's a lot of repeated information in the headers

<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 side?

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

mnot: they're on slideshare

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 constraining
... 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

<noah> http://www.slideshare.net/mnot/what-http20-will-do-for-you

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

larry: the TAG has a finding about authoritative metadata, but we have sniffing
... the reason we have sniffing is because the servers are misconfigured
... 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 sniffing
... 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 stuff

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 wire

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

mnot: 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> because a 2.0 -> 1.1 gateway can make the missing header explicit

<break>

</break>

URI Schema Proliferation

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

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

<noah> http://dev.w3.org/html5/spec/single-page.html#custom-handlers

mnot: you can't know where to dereference the geo: URI for example
... 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 them

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)

<noah> http://developers.whatwg.org/iana.html#web+-scheme-prefix

mnot: 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

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

<masinter> looking at the spec, http://developers.whatwg.org/timers.html#custom-handlers

timbl: 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 handlers
... but it changes the story about the use of the registeries
... the applicability of the guidance we give about registering values
... and the assumptions about the difficulty of deploying new schemes
... 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 about

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

noah: web+ seems to be bundling up something in the name which is about how the URIs are used

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

noah: 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 cases
... people know that if you use the web you've lost all your privacy anywe
... why should we continue to bother with these silly registeries

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 about

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 1) 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 websites
... I think that's a fairly high bar

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

<ht> It amounts to introducing a new distributed extensibility point

<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

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

<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

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 them

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 schemes
... 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

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

<jrees> Odd that the values arent communicable

ht: 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 oppised 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 platform
... 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 moment
... 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

.Larry: 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

<lunch>

<noah> You would use 800#

<ht> jrees, you there?

<ht> jar, you there?

<jrees> Hi

<ht> Skype, for a bit?

<ht> OK, not to worry

<jrees> Hmm it changes me to 'away' when i switch apps on the phone. Interesting

<ht> OK, we'll try

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

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

<noah> 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...?

<timbl_> hmmm http://itunes.apple.com/gb/album/beatles-1967-1970-blue-album/id400835735#

<timbl_> scribenick: timbl_

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.

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

Jeni:

<JeniT> Jeni is speechless

FragIds

Jeni:

<JeniT> http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23

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

<JeniT> s/hosyry/history/

[general discussion of the hosyry]

We got one set of substantive comments.

<masinter> we got a positive review from Alexey M

… We are trying to ge this through the process ASAP, no substantive comment expected

… I will this session go through our response to that comment.

… We with then just proceed though the process.

… A new editors draft is up of 23rd .

<Yves> http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html

<JeniT> 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 tho what is used in th ecurrent media type registration draft.

s/th ecurrent/the current/

… He uses the terms 'subtype', for example.

…. I did a few changes of my document to change the vocabulary.

Larry: If you go to that URL (http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14)
... They are holding it -- it is approved but on hold pending the suffix registration … on which it has a dependency.

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.

Jeni: 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 does.

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> +suffix registration definition to include 'per the RFC'

Jeni: Theo 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 unusual.

… I made no change there.

scribe: "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.

<JeniT> timbl: nice abstract

<JeniT> ... use the term 'local ids' rather than 'anchors'

<noah> 44 1793 417 679

<JeniT> timbl: if you have some generic software, it doesn't work for the media type to specify the prioritisation

<JeniT> 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.

<masinter> 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.

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 about.

<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

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 type".
... 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 draft?

Larry: I have some nots.

… Around IRIs and unicode normalization .. There are more bets 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 publish?

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.

<JeniT> s/fragids/fragids/

ht: The RDF problem is resolved at the result ion level, not the registration level.

<JeniT> s/result ion/resolution/

… 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

… Two other things we could say: Avoid things which lead to contradictory results.

scribe: 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."

<JeniT> todo: s/and may identify anything/and what it identifies is unconstrained/

… 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 anything"

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 discussed.

… We should get this document into the loop for the processes which produce media type registration documents in W3C and IETF etc.

[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 Recommenation.

<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.

________________

subtopic: *

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 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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/689

s/30/RFC30/

<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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/564

HT: I hope to get this published … it should come out soon as a ...

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

… as draft-ietf-appsawg-xml-00

LarryL 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 registrations.

[@@HT]

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.

… 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.

<Yves> https://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-06

<noah> ACTION-689?

<trackbot> 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

… 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

<trackbot> 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 http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis -- due 2012-10-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/707

<noah> close ACTION-707

<trackbot> ACTION-707 keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis closed

<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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/543

<ht> s/[@@HT]/draft-ietf-appsawg-media-type-suffix-regs/

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 do.

… The registered content handler in HTML doesn't say anything, as the registered protocol …there is nothing about fragids.

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

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

<JeniT> ACTION: Jeni to get LCWD of fragids & media types published and respond to comments [recorded in http://www.w3.org/2012/10/07-tagmem-minutes.html#action02]

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

[break]

<JeniT> ACTION: Jeni to raise a bug on registerContentHandler and registerProtocolHandler to ask for specification of how fragids are handled [recorded in http://www.w3.org/2012/10/07-tagmem-minutes.html#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].

<jrees> No point in doing awwsw

<jrees> At all

<jrees> Ok. Yes, try

<jrees> May not work

<jrees> Have wifi on bus but draining battery

<jrees> 2 things.

____________

Ashok: We published FPWG

<jrees> I have skypeout

<jrees> I have abiloty to call 800 num as noah hinted

… We got on it 3 comments, Renato Ianella about a reference to a licence -- JARand he agreed o with hime.

<jrees> Or pots

… 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:

10 If this is for non-technical people like lawyers, then there is jargon like HTTP headsets which we should explain.

<ht> s/headsets/headers/

Larry: Danny W had a comment:
... A layer at Adobe wondered what we were doing in the first place.

… 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: [@@ scibe -- passed into IRC above]

s/scibe/scribe/

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 os not law and is not policy.

Askok; 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'... Anticipatory

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 routing.

s/routing/rioting/

…. 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 late

<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 review.

… 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.

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 http://www.w3.org/2012/10/07-tagmem-minutes.html#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 http://www.w3.org/2012/10/07-tagmem-minutes.html#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: 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 unconstraint.

[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: 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]

<JeniT> 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.

<noah> You're getting No Answer? No ring?

HT: 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.

01793417417

<Yves> s/01793417417//

is the BCS number is what you get from calling outgoing calls callerid

ht: A detail question is that the way this ends doesn't say hwta happens when the attempt succeed: that we are done. Nothing else happens.

<JeniT> s/hwta/what/

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 all.

Yves: The XML community should see it..

HT: But there has been really no previous document.

<Yves> ..through the XML CG

Jenti: maybe people will expect errors to fail hard

<JeniT> s/Jenti/JeniT/

<Yves> s/Jenti/JeniT

<JeniT> timbl: XPointer's syntax includes typos

<JeniT> ... there's a narrower language that uses XPointer's schemes

<JeniT> ... and a narrower set that actually resolves to an element in the document

<JeniT> ht: noah's point was without processing you can describe three cases

<JeniT> ... the string is not a syntactially valid XPointer

<JeniT> ... per your XPointer implementation

<JeniT> s/syntactially/syntactically/

<JeniT> ... 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

<JeniT> 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]

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

jrees, can you hear us?

HT: Suppose in a new media type spec "I will use th henry X-pointer scheme".

s/th h/the h/

… What I want ois 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 togo 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..

s/togo/to go/

… This has to call out the fact that this maybe considered a change t othe implicit semantics which have been considered betore.

<jrees> Yes

… I think i should talk about semantics rather than processing.

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

______________________________________________

<jrees> No

<jrees> Muted

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

<jrees> Bye?

<noah> bye

<noah> RESOLVED: The TAG will (probably) meet in Cambridge March 19-21 2013

- DRAFT -

Technical Architecture Group Teleconference

07 Oct 2012

Attendees

Contents