W3C home > Mailing lists > Public > www-tag@w3.org > December 2011

Draft Minutes of 8 Dec 2011 Teleconference

From: Daniel Appelquist <dan@bluevia.com>
Date: Fri, 9 Dec 2011 11:33:15 +0000
Message-Id: <D8AE4FBB-9CA5-487B-9D44-AC3958CC4747@bluevia.com>
To: “tag” <www-tag@w3.org>
Draft minutes of the 1 December 2011 TAG teleconference are at

http://www.w3.org/2001/tag/2011/12/08-minutes.html

…and in plain text below.

Dan

---
   [1]W3C

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

                               - DRAFT -

              Technical Architecture Group Teleconference

08 Dec 2011

   See also: [2]IRC log
   [3]Agenda

      [2] http://www.w3.org/2011/12/08-tagmem-irc
      [3] http://www.w3.org/2001/tag/2011/12/08-agenda.html

Attendees

   Present
          Jeni Tennison, Ashok Malhotra, Jonathan Rees, Henry Thompson,
          Peter Linss, Noah Mendelsohn, Yves Lafon, Tim Berners-Lee

   Regrets
          Henry Thompson, Jonathan Rees

   Chair
          Noah Mendelsohn

   Scribe
          Dan Appelquist

Contents

     * [4]Topics
         1. [5]Administrative items
         2. [6]Draft on best practices for registries
         3. [7]SPDY
     * [8]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 08 December 2011

   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?

   [9]http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/draf
   t-registries.txt

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

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

     [10] 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> [11]http://www.w3.org/2001/tag/group/track/actions/531

     [11] 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, [$1\47] 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
   ([12]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.

     [12] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0049.html)

   <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> [13]http://www.w3.org/2001/tag/products/mimeweb.html

     [13] 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> [14]http://www.w3.org/2001/tag/group/track/actions/531

     [14] 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.

   Dan:+1 on the PR

   <noah> . RESOLUTION: The TAG, with Larry in the lead, will prepare a
   document (based on
   [15]http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/dra
   ft-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.

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

   that's good too.

   <noah> RESOLUTION: The TAG, with Larry in the lead, will prepare a
   document (based on
   [16]http://lists.w3.org/Archives/Public/www-tag/2011Dec/att-0037/dra
   ft-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.

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

   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> [17]http://www.w3.org/2001/tag/group/track/actions/531

     [17] 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.

   Dan:+1

   <Yves> +1

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

     [18] 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>
   [19]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html

     [19] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html

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

     [20] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html

   Noah: Yves drafted an email...

   <noah> Also see this thread started by Larry:
   [21]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0042.html
   there are some discussions on email (in www-tag).

     [21] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0042.html

   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> [22]http://www.w3.org/2001/tag/group/track/actions/618

     [22] 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
   [23]http://www.w3.org/2011/12/08-tagmem-minutes.html#action02]

     [23] 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 [24]http://en.wikipedia.org/wiki/Peter_Cook

     [24] http://en.wikipedia.org/wiki/Peter_Cook

Summary of Action Items

   [NEW] ACTION: Noah to invite Mark Nottingham to SPDY/HTTP F2F
   session [recorded in
   [25]http://www.w3.org/2011/12/08-tagmem-minutes.html#action01]
   [NEW] ACTION: Yves to frame F2F discussion of SPDY/HTTP futures
   [recorded in
   [26]http://www.w3.org/2011/12/08-tagmem-minutes.html#action02]

     [25] http://www.w3.org/2011/12/08-tagmem-minutes.html#action01
     [26] http://www.w3.org/2011/12/08-tagmem-minutes.html#action02

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [27]scribe.perl version 1.136
    ([28]CVS log)
    $Date: 2011/12/09 11:24:48 $

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



Received on Friday, 9 December 2011 11:34:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:41 GMT