- From: Daniel Appelquist <dan@bluevia.com>
- Date: Fri, 9 Dec 2011 11:33:15 +0000
- To: “tag” <www-tag@w3.org>
- Message-Id: <D8AE4FBB-9CA5-487B-9D44-AC3958CC4747@bluevia.com>
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 UTC