<trackbot> Date: 08 December 2011

zakim aaaa is me

<JeniT>  /me Zakim, [IPcaller] is me

<plinss> ls

<scribe> Scribe: Dan

<scribe> ScribeNick: DKA

Noah: any regrets for next week?

Dan: regrets for next week.

Yves: I can likely scribe next week. Ask me next week.

Noah: Approval of minutes from December 1st...

[no objections heard]

Minutes of 1 December meeting approved.

Administrative items

Noah: We are mostly dependent on people fulfilling out actions for f2f.

… there is a link to a local arrangements page on our agenda for today.

… this meeting is Wednesday through Friday.

Dan: I will have to give regrets for Friday, unfortunately, unless I can switch my flight (unlikely).

<timbl> depth of ice ... if seriously cold bring skates but looking warm at the moment

Noah: TAG election - Ian announced the candidates.

… There will be an election. Robin Berjon, Henry Thompson, and Glenn Adams nominated. Election closes Jan 9th. I will invite both new candidates to participate over the phone in the f2f.

… any objections? [none heard]

… in same note from Ian, I have been reappointed.

Draft on best practices for registries

Noah: can you give us an intro, Larry?

http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt

<noah> Draft from Larry: http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt

<noah> ACTION-531?

<trackbot> ACTION-531 -- Larry Masinter to draft document on architectural good practice relating to registries -- due 2011-07-30 -- OPEN

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

Larry: We've been talking about registries and had a lot of different discussions about it. I have put together an overview of the topic and what we might want to recommend as best practices.

… this was an attempt to gather this in a document that would make intentionally strong recommendations. There was some feedback from Thomas that they might be too strong [?] but I think a finding needs to say something substantive.

… … in a framework of extensibility in general.

<noah> Why does this paragraph appear twice, follwed by different lists?

<noah> "There are a variety of ways of managing extensibility of sets of

… there is an alternative to allowing extensibility point which is to have a living standard where you update the whole document when you want to change anything.

<noah> enumerated values, and establishing a mechanism for introducing

<noah> private and/or public extensions."

Tim: The document could be more explicit on that point.

<timbl> For an RDF scheme, often addingto the exitsing spec is the best ay to go.

<timbl> (Not the RGB colours don't work for me --- mainly IANA registration is mainly for when there is a new value WITH NEW SEMANTICS. 'orage' is very easy to define , is really just a macro for exaiting semantic of an RGB value.

Larry: [summarizes some points of the document]

<timbl> By comparison, exitend 'left, center, right' to 'left, center, right, justify' is an extension to semantics.

Larry: [on Findings] a registry needs to be managed in a public, fair and transparent way… I think this is important.

… we have had, traditionally a recommendation that using URIs over registries is preferable. Perhaps we want to make that recommendation more explicit among these choices.

… do we want to recommend that you should use http URIs? This is related to our work on http-range-14...

… Using namespaces and vendor prefixes - do we want to recommend those? There have been interesting discussions about the pitfalls and transition plan from prefix names to non-prefix names…

… For Registries - if the values that are in a W3C spec are shared with other IETF-managed protocols, then W3C should use IANA as the registry.

… There is a BCP which is RFC-5226...

<noah> The draft speculates on "... recommend http: URIs? ..." Is https going to prove preferable in the long run. In any case, don't we intend to allow for that as an option?

… Section on sniffing… technical specs that want to override existing registries.

… some discussion on prefixes to convey status (e.g. x-) and how this is ineffective....

… this is rough, but contains enough material that we could massage into a workable document.

<Zakim> JeniT, you wanted to ask if doc is about registries vs URIs

JeniT: I think it's good. Some of the BPs are actually about using URIs , not registries… So is it actually about extensibility mechanisms in general and not just registries.

<timbl> Extensibility points: Examples: content-types, uri schemes, color names, host names, html attributes to the a given element, country codes, HTTP headers, css rounded corners.

Larry: Yes. it does seem to be about that.

JeniT: I'm happy with the boarder scope. It makes sense to make recommendations on when do registries make sense, when do URIs make sense...?

Noah: Proposal: let's cover the bits about registries first.

<Zakim> timbl, you wanted to say Three reasons for doing a registry I can think of: to insist on qiality, to allow lookup of semantics, to limit number because of cost of adidng new

Tim: I think we should just broaden the scope.
... I agree this is about extensibility points - how you control these. Looking through what it says but thinking of different examples… You can distinguish 4 reasons for wanting a registry:

… 1 in order to avoid conflict; 2 you want to set a bar and set review - you want to have a quality of anything introduced ; 3 it may be there to provide look-up [shame that IANA is not oriented towards lookup] ; 4 you want to limit the number because there is a cost of introducing each one.

… for example, [4] a new URI scheme could cause a lot of extra work.

… for HTML tags, when you introduce a new section, everyone needs to understand that who implements browsers. But if you add metadata, it's no skin of anyone's nose.

… so you have 2 situations - one on which you need whole community to get involved and one in which anyone besides a sub-community can ignore.

Tim: CSS rounded corners another good example...

<noah> Only tangentially related to registry-based solutions, Mark Nottingham quotes (http://lists.w3.org/Archives/Public/www-tag/2011Dec/0049.html) Roy Fielding as calling mustUnderstand-based approaches "socially reprehensible"

… we need a decision tree - questions to answer to understand what kind of extension you're doing and which of these techniques you should use.

<Zakim> Larry`, you wanted to point out I've moved to wanting URI schemes to be FCFS with only 'expert review' to weed out obviously broken entries

Larry: Tim you included URI schemes - I've been moving towards in my own opinion towards first-come-first-served maybe with a areview to prevent spam… HTML5 itself needs a mechanism for URI schemes and protocol handlers… [?] HTML ISSUE 198 - prefix coordination. Naming convention for URI schemes where you say web+schemepreferences ...

<noah> Hmm. Can you use your own new scheme in the identifier for that same new scheme :-)?

Tim: With URI schemes, you should allow people with very little cost to block out a name so that nobody else can get it…

<Zakim> noah, you wanted to talk about how this fits with other TAG priorities, and Larry's other commitments

… you could make a list that you encourage browser vendors to implement - a curated list that involves serious review.

Noah: The action under which this work has been done was hatched in February. It's never had visibility as one of our bigger projects. We're now talking about doing a finding and broadening its scope… so - does this fit under one of our existing products, should we spend time on this, and what's the scheduling / effort on this?

<noah> NM: We don't have a "product"-leve focus on this. Does it fit under existing product, if not what priority do we want to give this?

Larry: this is related to my work on mime and the Web.

<noah> LM: Well, it's motivated by and related to work on MIME on the Web.

<noah> http://www.w3.org/2001/tag/products/mimeweb.html

<noah> 30 September 2011: Draft of final report (e-mail from Larry Masinter provides outline, but says this is running a bit behind schedule)

<noah> 31 December 2011: Final TAG Report on MIME architecture, most likely in the form of a TAG finding

<noah> 31 December 2011: TAG achieves success criteria set out on the product page, and identifies further goals and next steps, if any

Noah: In the master list i see these deliverables.

… Noah: so we could do the larger report and finish it, treat registries lightly there and indicate that we will do something additional on registries in 2012; or we could punt on the larger deliverable.

Noah: Could you give us the larger issues draft in time for the f2f?

Larry: I think that they're overlapping - there is a big overlap.

Noah: let's assume the larger document gets drafted and we issue a finding - there is then a proposal to ramp up a registry document… Right?

Larry: It seems to me that the scheduling depends on what others' ideas on priorities are...

Noah: let's discuss the priority of this...

<noah> DKA: Seems to me that putting a pause on this while waiting for the bigger work might be counterproductive.

<noah> Is it an either-or? We've committed the broader document for a long time, we have a schedule, and I think we're close to meeting it.

Dan: seems like this work has some momentum behind it… Maybe reverse the order and do this one first?

Noah: I think we're far enough down the road with the larger piece...

… I'd like to finish what we committed.

… other thoughts?

<noah> ACTION-531?

<trackbot> ACTION-531 -- Larry Masinter to draft document on architectural good practice relating to registries -- due 2011-07-30 -- OPEN

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

Larry: I will note that the IAB is working on a document on extensibility and it might be [timely] but reluctant to put them in our critical path...

<noah> Larry: MIME document is now small.

<noah> Noah: Right, which is one reason I was reluctant to delay it.

Noah: I think we should stay the course. Larry you will get us a draft by the f2f for review. for now we will continue ACTION-531 and if you have new stiff that merits discussion at the f2f then let me know.

Larry: My pushback - I detect a lot more enthusiasm for this topic then for the mime topic...
... I will do what I can on the mine thing.

Noah: Is there anyone who objects to making the registries work into a product level effort.

[no objections heard]

<noah> . RESOLUTION: The TAG, with Larry in the lead, will explore mechanisms for extensibility of specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture.

<noah> . RESOLUTION: The TAG, with Larry in the lead, will prepare a document, likely a finding, discussing extensibility of specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture.

<noah> . RESOLUTION: The TAG, with Larry in the lead, will prepare a document, likely a finding, discussing architecture for extensibility points in specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture.

Tim: We've fallen in this trap of thinking of extensibility too generally. This is about a specific part of extensibility… This is very narrow and I think it's good to keep it focused on that.

+1 on the PR

<noah> . RESOLUTION: The TAG, with Larry in the lead, will prepare a document (based on http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt), likely a finding, discussing architecture for extensibility points in specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture.

that's good too.

<noah> RESOLUTION: The TAG, with Larry in the lead, will prepare a document (based on http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draft-registries.txt), likely a finding, discussing architecture for extensibility points in specifications, including but not necessarily limited to registries. This will augment the soon-to-be published (short) work on MIME architecture.

Noah: Thanks, Larry.

<noah> ACTION-531?

<trackbot> ACTION-531 -- Larry Masinter to draft document on architectural good practice relating to registries -- due 2011-07-30 -- OPEN

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

<timbl> The unyeilding medium'd not merely endured / it's that upon which Art depends / for who can perform on a tightrope secured / at only one of its ends - Piet Hein

<noah> Highly motivational, Tim.

[discussion on timelines]

<noah> ACTION-531 Due 2011-12-26

<trackbot> ACTION-531 Draft document on architectural good practice relating to registries due date now 2011-12-26

<noah> Larry needs to get back to Noah to give guidance on F2F slots for MIME and/or Registries

SPDY

<JeniT> +1

<Ashok> +1

Noah: should we invite Mark Nottingham to the TAG f2f if possible for discussion on SPDY?

<noah> General agreement that inviting Mark Nottingham to HTTP/SPDY F2F session is a good thing.

+1

<Yves> +1

<noah> ACTION: Noah to invite Mark Nottingham to SPDY/HTTP F2F session [recorded in http://www.w3.org/2011/12/08-tagmem-minutes.html#action01]

<trackbot> Created ACTION-639 - Invite Mark Nottingham to SPDY/HTTP F2F session [on Noah Mendelsohn - due 2011-12-15].

<Yves> http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html

<noah> http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html

Noah: Yves drafted an email...

<noah> Also see this thread started by Larry: http://lists.w3.org/Archives/Public/www-tag/2011Dec/0042.html

… there are some discussions on email (in www-tag).

Yves: some background - the first thing is about the use of TLS… there are many people that are for it - firesheep is a good example of dangers of putting everything in the clear. There are technical issues though - intermediaries can't work because it can't be cached… Can be important in high-latency situation. 2nd issue - if everything is encrypted then it is more difficult to discover if sensitive data is escaping from your computer...

… so do we need to encrypt everything or not. It impacts on the SPDY discussions. Although it is not mandatory to run over TLS most implementations required that.

<noah> Something feels odd about encrypting public resources like the White House home page, or the W3C home page, with the excuse that it buys speed. Authenticating the endpoint and the integrity of the channel seems to be of some value, I.e. using signatures to prevent spoofing when desired, but hiding the content seems weird. Why break caching if the content isn't secret in the first place?

… also - SPDY pipelining enhancement is a way to work around TCP limitation… HTTP over SCTP - multiplexing at the TCP level. From an architectural PoV, it's better. But there is a problem with NAT..

<Yves> another issue is the number of communication channel that needs to be provisioned in advance, roughly the same issue as pre-opening parallel connections in HTTP right now

<noah> Scribe ---> Please make sure that s/[?]/SCTP/ really takes in the formatting script

Ashok: basic question - you spoke about worries that the data might escape and you wouldn't find out. But the data that would get stolen would be encrypted. So what's the real problem with that?

Yves: If you figure out that data is escaping to someone in an encrypted form - if there are no key exchanges then it's easy to decipher….

… there's always a possibility to hid everything not not the destination for example...

Yves: [continuing] so then you have SPDY - SPDY is trying to make HTTP faster at different levels. First by a multiplexing algorithm. Also compression of almost everything. Body, headers, a special dictionary for often-used headers...

… The fact that you can upgrade from http to spdy is a cool feature but most proxies will not upgrade...

Tim: if you go through a proxy the upgrading will break?

Yves: in most proxies after you use http upgrade the proxy acts like a tcp tunnel after that.

<Zakim> noah, you wanted to ask about downsides of encrypting what's not secret anyway

Yves: smarter option would be the proxy knowing what's going on and being part of the exchange...

Noah: We're acting like this is a good thing except where it breaks proxies…

… but you shouldn't need to encrypt data if it's not secret...

… it seems tempting to me to say in general on the network that encryption should be used to keep things secret.

Yves: tokens are sent in the clear - e.g. when you use Facebook all the info is stored in a cookie...

<Yves> once auth is done

<Yves> cookie as session indication

<Zakim> timbl, you wanted to mention changes of expectations with respect to privacy or people accessing public resources, compared to the old days.

Tim: when we started [the web] it was reasonable to cache as much as possible and bandwidth was [scarce]. Now, spying software i so ubiquitous that people are more sensitive about being public aout what they read. it's a privacy issue. New expectations about privacy. The attitudes we had 10 years ago about saving cpu power by not using encryption [might need to change]. Maybe I should do everything encrypted.

<noah> Tim: There's still an issue of privacy. If you encourage public info to be sent in the clear, then you build a system where it's easy to find out what public info >you< are reading

<noah> (that's a paraphrase of what Tim said)

… the fact that caches don't work - that is an issue.

<Zakim> DKA, you wanted to make a point about what's secret / not secret...

<noah> DKA: Two points. 1) These days, even public info such as the weather channel might come with private, secure tokens that are related to your social network.

<noah> ...We're all using OAuth to authenticate around the Web. Visiting the NY Times can send a credential to Facebook. 2) Now, to contradict myself, we also cannot assume that we always have instantaneous...

<noah> ...low latency, high bandwidth, when more and more devices are on less capable networks. Not all of world has even 2G or 3G.

<noah> ...You also have latency to spacecraft (really, I kid you not...worth worrying about).

<Zakim> noah, you wanted to respond to Tim

<timbl> +1

Noah: I said we should be hesitant about encrypting things that don't need to be encrypting. What I'm hearing is that more on the Web has a need to be encrypted then I'm thinking. So the constitution of the US is public but the fact that I'm reading it is private...

… But in that case, we end up encrypting the text of the constitution possibly unnecessariliy....

<Zakim> Larry`, you wanted to summarize themes: encryption everywhere vs. deployed infrastructure. Multiplexing over TCP and HTTP-NG organizational memory.

… but it may be that in balance we are so close to the need to encrypt everything that let's just do it.

Larry: 2 themes - there are concerns about the costs of encrypting everything - the impact of intermediaries, etc…

<noah> I don't think it's just encrytion vs. deployed infrastructure. I think it's "the benefits of encryption vs. the overhead of doing it, and the loss of flexible use of the encrypted information"

… I as pointing out http-ng as a caution sign - where not to go.

… I remember there being some serious problems trying to multiplex multiple connections over a single TCP connection. At the time it was unsolvable.

… maybe this isn't an issue for the use case for which SPDY was designed - all the threads coming from a single managed server. You might have a problem where the endpoints are on the other side of a gateway or a proxy - not so managed. Also I'm having trouble imagining a long tail where http 1.1 disappears.

… http 1.1 and 1.0 seems to be in so many embedded devices and controllers….

<noah> Why are we talking about HTTP 1.1 going away. I think SPDY, if it's a good think is like HTTP 1.0 to 1.1; everyone implements both, but the use of (something similar to) SPDY grows.

… given those two constrains - might be better as an upgrade option rather than a replacement.

Tim: I'm assuming that it's an upgrade and you'd have to keep http 1.1.

Larry: Maybe it's fine that SPDY is used as an upgrade for things that currently use HTTPS.

<noah> So, there's also the whole question of "if we do need something >like< SPDY, how close to correct is SPDY in detail? Mike Belshe seemed quite willing to see those questions explored as part of a standardization discussion."

<noah> TBL: Some of us may vaguely remember head of line blocking being a practical problem. Google engineers seem to be excited that SPDY does better, and has more real time capability to adjust priorities, e.g. based on what the user is trying to see.

Yves: there is another effort - close to being published as an RFC - One potential issue with web sockets - you are replacing a well defined protocol with a set of libraries that will define the protocol...

<noah> ACTION-618?

<trackbot> ACTION-618 -- Yves Lafon to with help from Larry, Noah, and Jeni to prepare analysis on development around HTTP, like spdy, ssl use, websocket... -- due 2011-12-06 -- PENDINGREVIEW

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

<timbl> I can't remember who used to say "Cast nasturtiums" for "cast aspersions" ...

Noah: Next steps?

Yves: we need to decide what topics here are most interesting for the TAG.

Noah: Can we give you an action to prepare a session for the f2f - these seem to be the questions that face the community and let's talk about which of these if any should the TAG get involved with?

<noah> close ACTION-618

<trackbot> ACTION-618 With help from Larry, Noah, and Jeni to prepare analysis on development around HTTP, like spdy, ssl use, websocket... closed

<noah> ACTION: Yves to frame F2F discussion of SPDY/HTTP futures [recorded in http://www.w3.org/2011/12/08-tagmem-minutes.html#action02]

<trackbot> Created ACTION-640 - Frame F2F discussion of SPDY/HTTP futures [on Yves Lafon - due 2011-12-15].

<timbl> I think it was deliberately invented by someone like Peter Cook or Dudley Moore http://en.wikipedia.org/wiki/Peter_Cook

adjourned

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 0.95)

Succeeded: s/PCP/BCP/
Succeeded: s/so we/Noah: so we/
Succeeded: s/[?]/SCTP/
Found Scribe: Dan
Found ScribeNick: DKA
Default Present: +44.771.520.aaaa, DKA, noah, plinss, Ashok_Malhotra, JeniT, Yves, Masinter, TimBL
Present: +44.771.520.aaaa DKA noah plinss Ashok_Malhotra JeniT Yves Masinter TimBL
Found Date: 08 Dec 2011
Guessing minutes URL: http://www.w3.org/2011/12/08-tagmem-minutes.html
People with action items: noah yves

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.