- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Fri, 13 Jan 2012 23:05:22 -0500
- To: "www-tag@w3.org" <www-tag@w3.org>, public-tag-announce@w3.org
- CC: Paul Cotton <Paul.Cotton@microsoft.com>
Draft minutes of the 4-6 January 2012 TAG F2F are now linked from the
agenda at [1] and are also provided in text-only form below. Please note
that these minutes have not yet been reviewed by the TAG and will not be
considered a formal record of the meeting until approved.
Thank you very much.
Noah
[1] http://www.w3.org/2001/tag/2012/01/04-agenda
================== 4 January 2012 =====================
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG Face to Face Meeting 04 January 2012
04 Jan 2012
See also: [2]IRC log
[2] http://www.w3.org/2012/01/04-tagmem-irc
Attendees
Present
Noah Mendelsohn, Jonathan Rees, Peter Linss, Larry Masinter,
Tim Berners-Lee, Yves Lafon, Dan Appelquist, Jeni Tennison,
Glenn Adams, Henry Thompson
Regrets
none
Chair
Noah Mendelsohn
Scribe
Yves Lafon, Jeni Tennison, Dan Appelquist
Contents
* [3]Topics
1. [4]Review Agenda
2. [5]Persistent references
3. [6]MIME and the Web
4. [7]URI Definition Discovery; Metadata Architecture
5. [8]Can publication of hyperlinks constitute copyright
infringement?
* [9]Summary of Action Items
_________________________________________________________
Review Agenda
Noah: First thing is to open the floor so that we can discuss what
is on the agenda
one of the question is: do we need to continue to track issues or
should we track products (like on the product page). We need a
discussion but f2f time is already filled with technical
discussions.
Ashok: are there important things buried in issues that might
disappear if we move to products
Yves: how to track not-yet-products, create a new product? use a
generic product?
Noah: can be done using actions.
... administrative stuff
please register for scribing slots
approval of minutes
<noah> [10]http://www.w3.org/2001/tag/2011/12/22-minutes
[10] http://www.w3.org/2001/tag/2011/12/22-minutes
RESOLUTION: minutes above approved
<noah> [11]http://www.w3.org/2001/tag/products/
[11] http://www.w3.org/2001/tag/products/
fragment identifiers & mime type: not scheduled as no progress were
done
RESOLUTION: close the Web Application State (pending publication of
the final Note)
DKA: wrt API minimization, we should leave it in a better state, but
no discussion is scheduled
noah Is API minimization worth doing
DKA Absolutely
noahOK, to be considered after the election
<noah> ACTION: Ashok to draft product page on client-side storage
focusing on specific goals and success criteria Due: 2012-01-17
recorded in [12]http://www.w3.org/2012/01/04-tagmem-irc]
[12] http://www.w3.org/2012/01/04-tagmem-irc
<trackbot> Created ACTION-647 - Draft product page on client-side
storage focusing on specific goals and success criteria Due:
2012-01-17 [on Ashok Malhotra - due 2012-01-11].
<glenn> possible minor typo under "Completed" table in products
page: "Completion ... was announced on 30 December 2012"?
<Yves> indeed
Persistent references
[13]http://www.w3.org/2001/tag/products/persistence.html
[13] http://www.w3.org/2001/tag/products/persistence.html
Noah: main question is "is there anything after the workshop report
we need to do" ?
jar: workshop took place on dec 8th in Bristol
Draft report:
[14]http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html
[14] http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html
we didn't have people saying that it was an impossible goal. No pure
"cool URI" advocate stating that there was no problem to solve. No
advocate of archives being sufficient
we didn't talk about what 'persistence' was
to me persistence is like trust
Yves: trusting that it will be persistent, or that the
representation is trustable (ie: not tampered with)
jar: there is a gradation of attacks, squatting being a threat to
persistence, so it's both
people had a shared intuition of what persistence meant
registry of media types or link relation is a good example of
persistence
even in the case of ISBN, it happened that some numbers were
recycled, threatening the persistence of the identifier
There was the idea that in theory, persistent domain names were
doable. One example is the use of the .arpa system
This removes possibility to change owner, so create an immutable
name (or mutable through a review process)
Larry: .arpa currently only IPV4-related
<JeniT> [15]http://www.iana.org/domains/arpa
[15] http://www.iana.org/domains/arpa
jar: it's just the constituency that is interesting. Like .invalid
Noah: what is the update bandwidth of .arpa ?
jar: it's RFC-based; the outcome was not "move everything under
.arpa"
options can be register a subdomain, a tld that offers persistence,
etc...
noah A little confused: earlier you said there was not great
interest in a new TLD, but now you're saying .arpa is just an
existence proof. Isn't it an existence proof for a new TLD?
jar Not necessarily. What's important is that you've shown that a
regime like this can be created. Could be realized as new TLD, could
be realized as new domain under .arpa, or one could retroactively
gold plate some existing domain(s)
(discussion about persistence of names vs persistence of
representations and resolution)
<noah> Henry, do you need/want time to speak on this? We've got ~30
mins, but I want to devote the last 15 or so to TAG next steps
jar: bio names is a good example of a system where noone is
reponsible for (it works by just publishing the name) but works.
Tim: but this is not a system under lots of stress, like the dns
system is
Noah: there are different communities there, one where this
'dns-like stress' is irrelevant, and others where it is the default
Yves: we are shifting from trust in the persistence to provenance
issues of the representation, those are different
<ht>
[16]http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html
[16] http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html
<Zakim> ht, you wanted to note that I'm supposed to be reporting
too!
<ht> no audio?
<masinter> (I said): when we do protocol design to design something
to solve a problem, it's important to identify the scope of what
problem is being solved, and waht isn't. In this case, we're picking
at the edges of trust & security because of issues like SOPA
take-down notices or someone disagreeing about biological names in
some communities. The report on persistent domains hasn't been clear
about waht the scope is, and that's why we're picking on it.
<masinter> jar replied: it was interesting that at the workshop we
didn't feel a need to discuss scope at length
<jar> (I said): The scope was relative: We want domain-name-based
naming that will be perceived as as "persistent" as, say, MIME types
or ISBNs (persistence standard imported from other domain)? and are
actionable
<jar> Gavin Brown of CentralNIC
ht: the .arpa solution came from nowhere, nobody was expecting it.
the idea was that gold plated domain named ought to be governed by
community process.
<jar> gold-plating needs a community process, IETF is a good example
of such a process
the idea was also to use .arpa to create new persistent domains
(like .doi.arpa)
<jar> the governing document for .arpa already sets out the
requirements. only agreement needed would be with IAB - ICANN, IANA
not in the picture .arpa is different that any other tld, no
registrar, no contract.
<noah> Could a new TLD be created with the same characteristic?
ht: I am not at all sure that the IAB would be happy to create
something that would look like a real domain under .arpa
<jar> But expecting resistance from IAB since this would imply lots
of ordinary DNS traffic through .arpa - a new idea
the ideal approach would be to have parts of existing domains
persistents
<noah> I need to cut this off in 2 mins. We are at time, and need
10+ minutes on TAG goals.
<jar> by registering dx.doi.org.arpa, side effect would be to make
dx.doi.org 'persistent'
we could use the .arpa to record that dx.doi.org is persistent, but
not binding resolution to the .arpa domain but leave it to
dx.doi.org system (ie: normal dns behaviour)
<masinter> Doesn't ISOC run .org? Maybe just asking ISOC to offer
some persistence guarantees for organizations that meet some
persistence criteria?
<jar> PIR runs .org
Noah: Henry, do you have an email with what you just talked about?
<jar> yes, that's a promising option, larry
<ht>
[17]http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html
[17] http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html
(discussion on the product page)
<noah> [18]http://www.w3.org/2001/tag/products/persistence.html
[18] http://www.w3.org/2001/tag/products/persistence.html
Tim: we need to create a scenario document
<jar> timbl calls for a TAG document explaining the process we might
like to see in the future for gold-plating
<jar> masinter: What doesn't work now that would work better if we
succeed?
<masinter> it isn't foolish to try to obtain consensus
<ht> No, but it's foolish to give me an action to obtain it!
<masinter> criterial for me is that it be clear to a reader not
already invested in this, "what will work better, if the TAG does
this work?"
<noah> ACTION-528?
<trackbot> ACTION-528 -- Henry Thompson to create and get consensus
on a product page and tracker product page for persistence of names
-- due 2012-01-02 -- OPEN
<trackbot> [19]http://www.w3.org/2001/tag/group/track/actions/528
[19] http://www.w3.org/2001/tag/group/track/actions/528
<ht> trackbot, ACTION-528 due 2012-01-06
<trackbot> ACTION-528 Create and get consensus on a product page and
tracker product page for persistence of names due date now
2012-01-06
<masinter> somewhere, at least one of the success criteria has to be
doing something
BREAK
MIME and the Web
slides: [20]http://www.w3.org/2001/tag/2012/01/mimeweb.pdf
[20] http://www.w3.org/2001/tag/2012/01/mimeweb.pdf
<noah> FWIW: Larry's use of the term language strikes me as
sensible, if informal, but it's only vaguely related to the
carefully negotiated definition the TAG agreed a few years ago
<noah> I think there's the core of something very good here...
analogy between mime type and persistent names
<noah> My intuition is that we'll do better to challenge ourselves
to start by making this as focused and narrow as possible. If more
general principles emerge, we'll find them.
<noah> I'm very nervous about the top down view of how languages
evolve.
relation between persistent names and evolution on what names
represent
See [21]ACTION-595 Draft a report on Mime and the Web
[21] http://www.w3.org/2001/tag/group/track/actions/595
<glenn> poor connectivity here at present, will attempt to rejoin
tomorrow AM
different pace between what is defined for email, and what is
defined for the web
email needs backward compatibility, web forward compatibility
success criteria is to address 50% of the use cases listed
<noah>
[22]http://www.w3.org/2001/tag/products/mimeweb-2011-12-24.html
[22] http://www.w3.org/2001/tag/products/mimeweb-2011-12-24.html
<noah> AM: I heard versioning of languages versus versioning of
references. Those are different things
<noah> AM: I also heard versioning of languages versus XML
languages.
AM: versionning of XML vs versionning of HTML
<noah> LM: Yes, one of David Orchard's documents was about that
<noah> AM: I think there are good extracts from Dave's documents
that might be useful
AM: what about sniffing?
<Ashok> Larry, you had a document on sniffing ... what about
progressing that document?
<masinter> ashok, the document on sniffing turned into issues in the
websec tracker on the sniffing document, which i have now
volunteered to edit
Tim: mime type is key to the web architecture. There was also a
model of versioning done by Jonathan
consistent ways of identifying vesion, or relationships
<masinter> guidelines for: when to use a new MIME type vs.
registering a new one
<Zakim> noah, you wanted to talk about scoping this bottom up
<masinter> guidelines for: when to use a version indicator as a
paramter of a MIME type
but it's better to be very crisp on little pieces
Noah: maybe one thing would be to say "let's take javascript, and
figure out what people want from the mime type registration when
javascript evolves", then same thing for one or two more languages
jeni: being able to take a larger theory and narrow it to a specific
use case would be to test the theory and get the use cases to
provide feedback
<Zakim> timbl_, you wanted to go back to the 8 use cases
<noah> 1?
<Zakim> noah, you wanted to focus on mime-registration related stuff
<masinter>
[23]https://plus.google.com/106838758956333672633/posts/BbiiK6C937V
[23] https://plus.google.com/106838758956333672633/posts/BbiiK6C937V
noah: working on generic versionning for XML proved very time
consuming. this effort should focus on registering media types
rather than telling the world how to define a language
LM: in the preface, I made it clear that the goal was not to have
general definition of terms, but local ones only
<noah> NM: Larry, are you mostly buying into my suggestion that we
scope this effort mostly to the parts necessary to tell a story
about MIME registration
<noah> LM: Yes, except in so far as we need to look at other bits to
verify that they are out of scope.
Yves: 5 use cases are about language versions, one is about
discrepancy between advertized metadata and "real" content
<noah> NM: I'd be much happier if the use cases said things like:
">MIME type registration" of evolving versions of {HTML,
JavaScript}"
versioning of specifications vs versioning of implementations
Noah: HTML specs were always careful not to do big incompatible
change to the meaning of a tag. <table> will always roughly mean a
table. HTML 1.0 didn't have <img> at some point <img> was introduced
and still now it means image
this is one property of HTML that people rely on
Noah: that can be one principle that might be outlined
LM: happy to narrow down the issue, however there are always
architectural issues behind
... I have an AI on websec to work on sniffing
<noah> ACTION-531?
<trackbot> ACTION-531 -- Larry Masinter to draft document on
architectural good practice relating to registries -- due 2011-12-26
-- OPEN
<trackbot> [24]http://www.w3.org/2001/tag/group/track/actions/531
[24] http://www.w3.org/2001/tag/group/track/actions/531
<noah> ACTION-595?
<trackbot> ACTION-595 -- Larry Masinter to create a report on Mime
and the Web -- due 2011-12-29 -- OPEN
<trackbot> [25]http://www.w3.org/2001/tag/group/track/actions/595
[25] http://www.w3.org/2001/tag/group/track/actions/595
<noah> ACTION-636?
<trackbot> ACTION-636 -- Larry Masinter to update product page for
Mime and the Web -- due 2011-12-08 -- OPEN
<trackbot> [26]http://www.w3.org/2001/tag/group/track/actions/636
[26] http://www.w3.org/2001/tag/group/track/actions/636
AM: what is the ultimate goal, one large comprehensive document, or
lots of small ones?
the big document may never get done
noah: we need to change our product page to be more incremental
ashok: I would like to say 'this is the big long-range goal, and
these are the short-term steps'
<noah> Reword [27]http://www.w3.org/2001/tag/products/mimeweb.html
to:
[27] http://www.w3.org/2001/tag/products/mimeweb.html
<noah> 1) Make clear the main goal is mime registration of evolving
languages -- only bring in broader issues as necessary
<noah> LM: The registry performs an important function of review
which entries apply to which versions.
Noah: how about stating that work on that bigger product is done and
split it in smaller products?
LM: might be a distraction, better to get this product
<noah> Current goal: The goal of this activity is to help guide the
use of MIME protocol elements in Web specifications and
implementations, and to analyze, document, and propose solutions to
difficulties with current effective use of MIME in the Web.
<noah> Proposed goal: The goal of this activity is to help guide the
use of MIME protocol elements and Mime registratoins in Web
specifications and implementations, and to analyze, document, and
propose solutions to difficulties with current effective use of MIME
types and MIME registrations for languages that evolve.
Noah: Larry will write up a product page describing goals of
previous topic.
<noah> ACTION-531?
<trackbot> ACTION-531 -- Larry Masinter to draft document on
architectural good practice relating to registries -- due 2011-12-26
-- OPEN
<trackbot> [28]http://www.w3.org/2001/tag/group/track/actions/531
[28] http://www.w3.org/2001/tag/group/track/actions/531
<noah> Leave ACTION-531 for Friday
<noah> ACTION-595?
<trackbot> ACTION-595 -- Larry Masinter to create a report on Mime
and the Web -- due 2011-12-29 -- OPEN
<trackbot> [29]http://www.w3.org/2001/tag/group/track/actions/595
[29] http://www.w3.org/2001/tag/group/track/actions/595
<noah> ACTION-595 Due 2012-01-24
<trackbot> ACTION-595 Create a report on Mime and the Web due date
now 2012-01-24
<noah> ACTION-595?
<trackbot> ACTION-595 -- Larry Masinter to draft a report on Mime
and the Web -- due 2012-01-24 -- OPEN
<trackbot> [30]http://www.w3.org/2001/tag/group/track/actions/595
[30] http://www.w3.org/2001/tag/group/track/actions/595
<noah> ACTION-636?
<trackbot> ACTION-636 -- Larry Masinter to update product page for
Mime and the Web -- due 2011-12-08 -- OPEN
<trackbot> [31]http://www.w3.org/2001/tag/group/track/actions/636
[31] http://www.w3.org/2001/tag/group/track/actions/636
<noah> ACTION-636 Due 2012-01-17
<trackbot> ACTION-636 Update product page for Mime and the Web due
date now 2012-01-17
<noah> Noah to help Larry with ACTION-636, capturing new directions
from Wed 4 Jan 2012
URI Definition Discovery; Metadata Architecture
jar: [going through product page:
[32]http://www.w3.org/2001/tag/products/defininguris.html
... [reviewing schedule]
... idea is to make a call fro change proposals 15 Jan...
[32] http://www.w3.org/2001/tag/products/defininguris.html
Ashok: will you ask others beyond us?
jar: Yes - the idea is to get community consensus. We should post
call to linked-data and [other communities].
… idea is to drive this issue to something.
Noah: Do you think this will make a real difference?
jar: I think if there is no consensus and we withdraw the resolution
then that could [have an impact]. If we get w3c consensus then that
could have some effect. I think the current situation is not
tolerable.
tim: as a member of this community - I haven't reacted yet ...
… I think there is a technical issue here. What came out of range14
was the 303 recommendation - that [is not good].
… We need to work on more efficient alternatives to 303.
… I'd like to see a conclusion that we're going to underscore the
resolution but temper it with some engineering that will make
systems work in practice.
jar: that would be a great outcome.
… I think there will be an outcome. Anything that's not the current
situation is going to be positive.
JeniT: how will we assess the change proposals?
jar: we need to decide what the change proposal process would be.
JeniT: it could be quite hard to be seen as fair in assessing them.
jar: it would still go through w3c consensus process - through rec
track - [no matter what the TAG process is]
... even a statement from the TAG that "there appears to not be
consensus on this issue" would be positive.
… I proposed the idea of a "town meeting" teleconference.
<DKA> +1 to a "town meeting"
noah: the goals look good to me.
draft call for change proposals:
[33]http://www.w3.org/2001/tag/2011/12/uddp/cp-call.txt
[33] http://www.w3.org/2001/tag/2011/12/uddp/cp-call.txt
jar: I have included a plea to review the work done so far on this
issue.
Jenit: how would a change proposal show adequate understanding of
those?
jar: good question - I imagine that if it make s claim that's
refuted in one of the referenced documents then it's a problem. If
it just says "there's no way to X" and the issue-57 documents gives
a way to do X…. I should make a list of points that ought to be
addressed. E.g. "why not just use hash URIs"..
noah: in this round, there will be some non-objective evaluation.
tim: we should say this is not the time to argue terminology.
<ht> +1 to requesting terminology discussion happen elsewhere
Jenit: If I was coming to this and thinking of writing a change
proposal - I might be concerned that I go to the effort and it is
rejected based on obscure reasons...
noah: could we just say "questions are welcome on the www-tag
mailing list".
jenit: having a deadline for drafting change proposals and then a
period for discussion / revision and then a final deadline when we
will make an assessment...
noah: ideally we should put these out for community review...
jenit: could say "We encourage people to work together to create
change proposals that reflect community…"
<noah> NM: Suggest a period of community review and refinement for
all proposals to net out a good set of alternatives.
<noah> JAR: Good idea. Not currently in plan, but I'll add it.
<noah> NM: Do you want to do that in the product pages?
<noah> JAR: Yes but later.
jar: I need to add a clause welcoming proposals from anyone and
explain that we're going after consensus.
JAR: call for change proposals would be accompanied by two change
proposals: no change and withdrawal of resolution
Ashok: Do you expect something completely novel to turn up?
JAR: People might come up with something new, though I don't expect
it given we've been talking about it for 10 years
LM: I have started thinking about this in a new way: URIs as
protocol elements, with this being a way of providing a definition
of what the URI is for languages to use
... originally it sounded like discovery: "how do we discover what
this URI means?"
... but the language provides the meaning to the URI
... and the language may choose to inherit from the definition that
you get from resolving the URI
NM: When this started, people accepted that you could make URIs for
images and for people
... and it wasn't obvious that you couldn't respond with a 200 for a
URI that meant a person
LM: The HTTP protocol is defined by the HTTP RFCs, which don't say
anything about any of this, and httpRange-14 didn't change those
NM: There are certain words such as "representation" that different
people read in different ways
JAR: This is all water under the bridge
jar: we're using URIs in RDF and how do we use them?
larry: httprange14 did not effect any language that didn't cite it.
tim: no httprange14 is about URLs
larry: I didn't like httprange14 before because it tried to address
a larger scope than it should have.
tim: it ended up with the RDF community using URLs consistently with
the html community.
larry: httprange14 is in scope for RDF and not for html.
noah: my view is that this should be a comment on status codes for
the httpbis effort.
jar: I only care about RDF in this discussion. What's at stake is
the ability to refer to RDF from the Web.
... [going over baseline proposal:
[34]http://www.w3.org/2001/tag/2011/12/uddp/]
[34] http://www.w3.org/2001/tag/2011/12/uddp/
<ht> +1 to documentation over definition
tim: URIs should be universal
larry: in a SOPA case the counterfeit of chanel perfume was made to
change the DNS resolution. If I wanted to make the case that this
perfume was counterfeit then I better not use the URI because they
were forced to change the resolution.
… "uncool URIs must change"
jar: this as the persistence problem really go together. RDF also
suffers from the persistence problem.
larry: if you use a URI for meaning something in a context then you
want that meaning to be persistent. If you use DNS names which you
can't guarantee their persistence then ...
... another example- I make assertions about texaco and then chevron
and texaco merger and they change all their uris to
chevrontexaco.com...
… you have to accept the consequence.
… it may be that RDF2 will have a way of supplying a date context -
please interpret these statements as being in context...
jar: [continues through document]
... [35]http://www.w3.org/2001/tag/2011/12/uddp/#idp409552
[35] http://www.w3.org/2001/tag/2011/12/uddp/#idp409552
… I've called out places where I've generalised.
jar: this enumerates the critical parts of the TAG resolution.
jenit: I don't agree that the 4xx response is not a critical part.
jar: OK I'll put it back in.
... it seems to me that 200 http is too much of a special case - if
you're talking about web architecture then you're talking about
rfc3986 retrieval - of which http 200 responses are a class.
larry: my change proposal is to avoid the phrase "http resource."
jar: I've already done this except where I'm quoting Roy Fielding.
... I give examples of ftp and data as being retrieval-oriented
URIs.
... I will clarify further in the draft.
larry: in the web, there is an ambiguity between the touch point and
the scope of the thing referenced?
jar: this is the reason you have documentation - to explain things.
larry: you cannot eliminate ambiguity.
jar: absolutely.
larry: the resources are not what are named by the URI . I have a
problem with "the resource in question:...
jar: the ambiguity thing is a red herring.
[further wordsmithing]
jar: I'll clarify the second sentence.
... this is aimed at people using RDF.
ashok: "tis is a proposal for use with RDF."
<ht> That's a possible change proposal
<ht> but not a change to this document
larry: we could be happier when we say "this is RDF architecture.
... When you have linked data it is the function of linking data
that you use the URI both for presentation and for meaning...
noah: let's say there's a solution adopted for the RDF community. It
must be the case that the "document" community does noting to
conflict eo.
LM: We had URIs, now we have IRIs -- you don't try to impose a
non-backwards-compatible meaning
JAR: If the RDF community accepts this, that's the end of the story
NM: If there was something that was backwards-incompatible for the
document community, then that would be a problem
JAR: HTML doesn't have a stake in how this comes out
LM: Do load balancers and proxies have to start respecting this?
NM: Does Squid have to be aware of this? Is there RDF-Squid and
Other-Squid?
TimBL: There are things that screw you up: Firefox transparently
follows redirects, which is fine if it's 301s or 302s, but if it
does it with 303s then it screws you up
JAR: 303 is already documented compatibly in HTTPbis
NM: Let's talk about making a resolution for JAR to take this
forward
TimBL: I think it needs to recognise the problems with 303
JAR: the ISSUE-57 has as its purpose to do just that
... this is just a baseline
... for change proposals
... I might be able to refer to the ISSUE-57 document in here
... there is a reference to that document in the call for change
proposals
HT: it's worth saying in the call that you will find in the Issue 57
document a list of problems with the Fielding resolution
... different people have had different problems with it
JAR: I like that solution
... There's a lot in here about fragment identifiers, even though
it's not really part of httpRange-14
<ht> I'm happy for the call to go out, with the minor changes
proposed to JAR's baseliine doc't
JAR: I just need to know whether there's anything else I need to do
before sending out the call
<noah> PROPOSED RESOLUTION: The TAG will circulate a call for
proposals to (re)resolve issue httpRange-14. The call will be based
on Jonathan Rees' "d proposal for a call for change proposals",
which is based on the baseline draft at
[36]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
based on suggestions at 4 January 2012 F2F.
[36] http://www.w3.org/2001/tag/2011/12/uddp/.
<noah> PROPOSED RESOLUTION: The TAG will circulate a call for
proposals to amend issue httpRange-14. The call will be based on
Jonathan Rees' "d proposal for a call for change proposals", which
is based on the baseline draft at
[37]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
based on suggestions at 4 January 2012 F2F.
[37] http://www.w3.org/2001/tag/2011/12/uddp/.
<noah> PROPOSED RESOLUTION: The TAG will circulate a call for
proposals to amend issue httpRange-14. The call will be based on
Jonathan Rees' "proposal for a call for change proposals", which is
based on the baseline draft at
[38]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
based on suggestions at 4 January 2012 F2F.
[38] http://www.w3.org/2001/tag/2011/12/uddp/.
<timbl_> PROPOSED RESOLUTION: The TAG will circulate a call for
proposals to amend the resolution to issue httpRange-14. The call
will be based on Jonathan Rees' "proposal for a call for change
proposals", which is based on the baseline draft at
[39]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
based on suggestions at 4 January 2012 F2F.
[39] http://www.w3.org/2001/tag/2011/12/uddp/.
<noah> RESOLUTION: The TAG will circulate a call for proposals to
amend the resolution to issue httpRange-14. The call will be based
on Jonathan Rees' "proposal for a call for change proposals", which
is based on the baseline draft at
[40]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
based on suggestions at 4 January 2012 F2F.
[40] http://www.w3.org/2001/tag/2011/12/uddp/.
<noah> Passes unanimously.
<noah> ACTION-624?
<trackbot> ACTION-624 -- Jonathan Rees to draft for TAG
consideration a call for httpRange-14 change proposals -- due
2011-12-31 -- PENDINGREVIEW
<trackbot> [41]http://www.w3.org/2001/tag/group/track/actions/624
[41] http://www.w3.org/2001/tag/group/track/actions/624
<noah> close ACTION-624
<trackbot> ACTION-624 Draft for TAG consideration a call for
httpRange-14 change proposals closed
<noah> ACTION-625?
<trackbot> ACTION-625 -- Noah Mendelsohn to schedule followup
discussion of [42]http://www.w3.org/wiki/HttpRange14Options (per
agreement in Santa Clara) -- due 2011-12-21 -- CLOSED
[42] http://www.w3.org/wiki/HttpRange14Options
<trackbot> [43]http://www.w3.org/2001/tag/group/track/actions/625
[43] http://www.w3.org/2001/tag/group/track/actions/625
<noah> ACTION-589?
<trackbot> ACTION-589 -- Noah Mendelsohn to work with Jonathan to
update URI definition discovery product page Due: 2011-08-18 -- due
2011-12-23 -- CLOSED
<trackbot> [44]http://www.w3.org/2001/tag/group/track/actions/589
[44] http://www.w3.org/2001/tag/group/track/actions/589
<noah> ACTION-201?
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW
discussions -- due 2011-12-28 -- OPEN
<trackbot> [45]http://www.w3.org/2001/tag/group/track/actions/201
[45] http://www.w3.org/2001/tag/group/track/actions/201
<noah> ACTION-201 Due 2012-03-31
<trackbot> ACTION-201 Report on status of AWWSW discussions due date
now 2012-03-31
<noah> ACTION-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2012-01-31 -- OPEN
<trackbot> [46]http://www.w3.org/2001/tag/group/track/actions/282
[46] http://www.w3.org/2001/tag/group/track/actions/282
<noah> Jonathan will bump 282 date later.
<noah> ACTION: Jonathan to post call for change proposals to amend
the resolution to httpRange-14 per 4 January 2012 TAG Resolution
Due: 2012-01-17 [recorded in
[47]http://www.w3.org/2012/01/04-tagmem-irc]
[47] http://www.w3.org/2012/01/04-tagmem-irc
<trackbot> Created ACTION-648 - Post call for change proposals to
amend the resolution to httpRange-14 per 4 January 2012 TAG
Resolution Due: 2012-01-17 [on Jonathan Rees - due 2012-01-11].
Can publication of hyperlinks constitute copyright infringement?
DKA Product page:
[48]http://www.w3.org/2001/tag/products/PublishingLinking-2011-12-27
.html
[48]
http://www.w3.org/2001/tag/products/PublishingLinking-2011-12-27.html
JeniT We've been kicking this draft around - Dan I have revised it
recently.
[49]http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2012
-01-04.html
[49]
http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2012-01-04.html
JeniT following discussion with Rigo - the direction he recommended
was to have this doc focused on technical aspects of publishing and
linking and to have some other mechanism for having stronger
statements that we want to make - e.g. right to link, flagging
issues with transforming proxies, etc - questions with legal
questions associated with them.
…. we want to answer 3 main questions today. First, is that a
reasonable way forward; 2nd if so what is the best mechanism for
making those opinion statements?; 3rd given that we make those
statements, what statements should we make?
… so first question - is that a reasonable way to structure this
work?
Larry There are different kinds of opinions. There are opinions
about the technical impact are and opinions about legislation. I
wanted you to separate out the opinions about legislations from the
technical opinions.
JeniT yes - that's what we've done for the latest draft.
Noah: it strikes me as the right direction to try.
Dan: this is based on some additional feedback from Rigo.
Jenit: what should the opinion statements be?
<masinter> You can remove opinions about legal without removing
opinions about control
Dan: Bullet points on messages we want to convey. We have taken
these out of the document.
Jeni writes on board "hosting != possesion"
Larry: Can we keep this in the document rephrased as technical
point?
<masinter> ""It is impossible to control dissemination of
content-based unwanted material, merely by imposing restrictions on
service providers offering transformation services, because such
services are not able to differentiate wanted form unwanted content.
The result would be severely limited services, instead.""
<masinter>
[50]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0120.html
[50] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0120.html
Dan: Rigo would feel this would be better left out
... this is opinion
Larry: If you cannot distinguish what you can publish and what you
cannot, you cannot publish anything
... distinguish mechanically at reasonable cost
<masinter> "common carrier"
Noah discusses wording re automated algorithms to distinguish ...
scribe: what you can publish and what you cannot
... copyrighted vs. non-copyrighted material
Peter: A lawyer you not care whether it is automated or not
<masinter> in the "legal opinion" view, I'd want to make web hosting
and transformation services to be "common carriers"
Jar: I think you can consider making the point without using legal
... you can talk about requirements
<jar> System requirements come from a variety of sources. Laws and
contracts are just particular examples of requirement sources. So
talk about requirements, and avoid any hint that some legal
assessment is being made.
Jeni: We want to separate the two documents: legal and technical
Larry: Goverments do not have to make things illegal in order to
prohibit them
Jeni writes on board "filtering content can be hard".
Larry: We should point about other means of control other than
criminalization
Dan: We can work in parallel on these two things ... first publish
the technical work
Jeni writes "copying is needed for proxying /archiving"
Jeni writes "rewriring links is necessary for archiving"
Jeni writes "transforamation is needed for search engines"
Jeni writes "users don't know where they are going when they click
on a link/prefetch"
Jeni writes "deep linking is necessary -- right to link
<jar> greasemonkey is a terrific innovation… but may be incompatible
with requirements
scribe: linking is a speech act
... network effects
Dan: A speech act is something that is protected under UN Resolution
...
<noah> NM: I agree. I'm happy to see the TAG talk about the
importance of network effects & Metcalfe's law. I'm happy to see
>the W3C< make the connection to UN Resolutions. I don't see the
technical content that makes the connection to the UN part of the
TAG's remit at W3C.
Larry: Protocols should be explicit whether links imply automatic
behaviour without additional action
Jeni writes " linking vs. inclusion"
Larry: Links could be speech acts or automatic actions
Noah disagrees ... points to separation of concerns. Links can be
processsed in different ways
Larry: Protocols could annotate links to indicate whether link
should be followed
Jeni: Topics on board are examples we can pull out to talk about
legislation or contracts, etc.
Ashok: These are good starting statements
Most people in room think this is a good direction
Tim: "It would be reasonable for a Goverment to conclude that ..."
Larry: In telecom field this is the legal Common Carrier issue ...
does this translate to web hosting etc. ?
... used in Common Law Countries
Dan: Article 19 on Human Rights ... fundamental right
Jeni: Moving to vehicle ... how to disseminate these points
Noah: We need a base technical document with good, simple,
non-inflammatory examples
... We can decided how to disseminate on a case-by-case basis
... two documents technical document and a document with examples.
... perhaps combine into one document
Larry: Perhaps ask ISOC for some help
Noah: We should publish our document first
Discussion about updating the product page
Ashok: We need a new mechanism to put W3C positions front and center
Tim: Perhaps Web Foundation could pick that up
Larry: This seems the main thing that ISOC does ... we could get
them the technical background
jar: But this project is about what we think ... voice of the
technical community
Yves: Most impt thing is to publish the technical document
<jar> +1
Dan: Let's publish the technical document and then debate how to
disseminate the other stuff
Larry: Should we review your latest documemt?
jar: Technical document could have some compelling examples
<jar> The main (tech) document can contain plenty of compelling
examples, based on general system requirements (not on legal
considerations)
<jar> (which is similar to what I think Larry was saying earlier,
about administrative control)
<noah>
[51]http://www.w3.org/2001/tag/2012/01/CopyrightLinkingTopics.jpg
[51] http://www.w3.org/2001/tag/2012/01/CopyrightLinkingTopics.jpg
<noah> ACTION-627?
<trackbot> ACTION-627 -- Noah Mendelsohn to schedule very detailed
line-by-line review of Pub&Linking draft at January F2F -- due
2011-12-23 -- PENDINGREVIEW
<trackbot> [52]http://www.w3.org/2001/tag/group/track/actions/627
[52] http://www.w3.org/2001/tag/group/track/actions/627
<noah> need to reopen 627 until draft is ready
<noah> Never mind
<noah> ACTION-627 Due 2012-01-10
<trackbot> ACTION-627 Schedule very detailed line-by-line review of
Pub&Linking draft at January F2F due date now 2012-01-10
<noah> ACTION-627 Due 2012-01-17
<trackbot> ACTION-627 Schedule very detailed line-by-line review of
Pub&Linking draft at January F2F due date now 2012-01-17
<noah> ACTION-629?
<trackbot> ACTION-629 -- Daniel Appelquist to with help from Jeni to
propose changes to goals, success criteria etc. for
publishing/linking product page -- due 2011-11-11 -- OPEN
<trackbot> [53]http://www.w3.org/2001/tag/group/track/actions/629
[53] http://www.w3.org/2001/tag/group/track/actions/629
<noah> ACTION-629 Due 2012-01-17
<trackbot> ACTION-629 With help from Jeni to propose changes to
goals, success criteria etc. for publishing/linking product page due
date now 2012-01-17
<noah> ACTION-541?
<trackbot> ACTION-541 -- Jeni Tennison to helped by DKA to produce a
first draft of terminology about (deep-)linking etc. -- due
2011-12-20 -- OPEN
<trackbot> [54]http://www.w3.org/2001/tag/group/track/actions/541
[54] http://www.w3.org/2001/tag/group/track/actions/541
<noah> Changing description
<noah> ACTION-541?
<trackbot> ACTION-541 -- Jeni Tennison to helped by DKA to produce
draft on technical issues relating to copyright/linking -- due
2012-01-31 -- OPEN
<trackbot> [55]http://www.w3.org/2001/tag/group/track/actions/541
[55] http://www.w3.org/2001/tag/group/track/actions/541
<noah> ACTION: Jeni to produce a document with examples motivating
the technical points in the Copyright/Linking document Due:
2012-03-20 recorded in [56]http://www.w3.org/2012/01/04-tagmem-irc]
[56] http://www.w3.org/2012/01/04-tagmem-irc
<trackbot> Created ACTION-649 - Produce a document with examples
motivating the technical points in the Copyright/Linking document
Due: 2012-03-20 [on Jeni Tennison - due 2012-01-11].
Summary of Action Items
[NEW] ACTION: Ashok to draft product page on client-side storage
focusing on specific goals and success criteria Due: 2012-01-17
recorded in [57]http://www.w3.org/2012/01/04-tagmem-irc]
[NEW] ACTION: Jeni to produce a document with examples motivating
the technical points in the Copyright/Linking document Due:
2012-03-20 recorded in [58]http://www.w3.org/2012/01/04-tagmem-irc]
[NEW] ACTION: Jonathan to post call for change proposals to amend
the resolution to httpRange-14 per 4 January 2012 TAG Resolution
Due: 2012-01-17 [recorded in
[59]http://www.w3.org/2012/01/04-tagmem-irc]
[57] http://www.w3.org/2012/01/04-tagmem-irc
[58] http://www.w3.org/2012/01/04-tagmem-irc
[59] http://www.w3.org/2012/01/04-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [60]scribe.perl version 1.136
([61]CVS log)
$Date: 2012/01/13 21:33:37 $
[60] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[61] http://dev.w3.org/cvsweb/2002/scribe/
================== 5 January 2012 =====================
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Technical Architecture Group Face-to-Face Meeting -- 05 Jan 2012
05 Jan 2012
[2]Agenda
[2] http://www.w3.org/2001/tag/2012/01/04-agenda
See also: [3]IRC log
[3] http://www.w3.org/2012/01/05-tagmem-irc
Attendees
Present
Glenn_Adams_(by_phone), Dan_Appelquist, Tim_Berners-Lee,
Yves_Lafon, Philippe_Le_Hegaret_(part), Peter_Linss,
Ashok_Mahotra, Larry_Masinter, Noah_Mendelsohn,
Jonathan_Rees, Wendy_Seltzer_(part), Jeni_Tennison,
Henry_Thompson_(part, by_phone), Norm_Walsh_(part, by_phone)
Regrets
Chair
Noah Mendelsohn
Scribe
Jonathan Rees, Ashok Mahotra
Contents
* [4]Topics
1. [5]Administration
2. [6]Microdata + RDFa
3. [7]HTML.next
4. [8]Privacy
5. [9]TAG Priorities for 2012
6. [10]XML/HTML Convergence
* [11]Summary of Action Items
_________________________________________________________
<jar> scribenick: jar
<timbl> Larry, document RDF is at
[12]http://www.w3.org/2002/01/tr-automation/tr.rdf
[12] http://www.w3.org/2002/01/tr-automation/tr.rdf
Administration
agenda review
F2F scheduling
Next F2F is April 2-4 in the south of France.
<glenn> I have a conflict for week of Jun 11-15 should I be elected
<ht> I cannot do 25 or 29 may
<ht> should I be re-elected
<noah> We are talking about 12-14 June in Cambridge, to meet Tim's
preferences. Can you do it?
<ht> Yes
<glenn> I will be in London that week
The TAG plans to meet 12-14 June, but please don't make travel plans
yet since we need to consult with new members.
ht: It would be good for every TAG member to touch base with an IETF
meeting, IMO
LM: Let's talk to Mark N about liaison when he's here. Might be good
to interact with ISOC too
... maybe collaborate around extensibility
<masinter> suggestions for IETF general topics: (a) ask MNot on
Friday (b) IAB on extensibility, (c) ISOC members on legal impact.
<masinter> suggestions for individual TAG members of relevant IETF
working groups: RTC, IRI, URNbis, HTTPbis, websec. If you attend, be
prepared to have read relevant documents being discussed
Microdata + RDFa
<JeniT> [13]http://www.w3.org/wiki/Html-data-tf
[13] http://www.w3.org/wiki/Html-data-tf
JT: We have had wiki page set up since September. Two documents came
out of this
<JeniT>
[14]https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide
/index.html
[14]
https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide/index.html
JT: HTML data guide - advice on how to do data in HTML, when to use
which mechanism
... divided by target audiences
... Publishers: how to mix vocabularies, how to mix syntaxes - what
do you have to be aware of re possible conflicts
... Next section is for consumers - what syntax should you consume,
how to deal with mixed input
... 3rd section is for vocabulary authors. Extending existing
vocabularies to suit new requirements, designing vocabs for each
kind of syntax and that work across the syntaxes
... The plan is to publish this as a SWIG note in January
LM: What I'm missing is anything about whole-document metadata - DC,
XMP - I know this is a different problem, but some ack of this would
be nice
... The HTML meta tag seems related. The document ought to say
something about this other stuff, if only to put it out of scope.
... There should be references so that readers are directed to the
right place (if they want to know about it)
TBL: question about history of RDFa
... Dublin Core was persuaded to adopt RDF with the understanding
that RDFa would be coming along later
NM: Didn't the current [Microdata + RDFa] effort start with the
announcement of schema.org ? How have things progressed since then?
<masinter> "whole document metadata" is a separate but related topic
but likely to be confused
JT: RDFa Lite is now a WD, schema.org has adopted support for it
<masinter> and
[15]http://www.w3.org/TR/REC-rdf-syntax/#section-rdf-in-HTML
[15] http://www.w3.org/TR/REC-rdf-syntax/#section-rdf-in-HTML
JT: Google already recognized a wide variety of markups, and
schema.org was a statement of a preferred form
NM: It would be nice to be able to tell the community what the TAG's
role was in this
<masinter> also:
[16]http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecifi
cation.pdf#page=98 embedding XMP in HTML
[16]
http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf#page=98
<timbl> 2003-12-15 XFN 1.0 launched by Tantek Ãelik[$1\47], Eric
Meyer[$1\47], Matthew Mullenweg[$1\47]
<timbl> a b "XHTML and RDF W3C Note 14 February 2004". World Wide
Web Consortium. 2004-02-14. Retrieved 2007-12-27.
[17]http://www.w3.org/MarkUp/2004/02/xhtml-rdf
[17] http://www.w3.org/MarkUp/2004/02/xhtml-rdf
ashok: So there wasn't a groundswell to reduce the number of
formats? Why not?
LM: I thought the big difference had to do with namespaces and
extensibility? You can use namespaces in RDFa but not in microdata?
<masinter> i'm also concerned about relationship between embedded
metadata in linked images and metadata in links
JT: Not really. In microdata you can have multiple independent event
vocabularies
... In microdata syntax you can't say a single item is two things
from two different vocabularies... but you can always nest
<JeniT>
[18]https://dvcs.w3.org/hg/htmldata/raw-file/default/microdata-rdf/i
ndex.html
[18]
https://dvcs.w3.org/hg/htmldata/raw-file/default/microdata-rdf/index.html
TBL: What about getting triples out of HTML documents?
JT: That's the second document.
... There were problems with the HTML5 mapping of microdata to RDF
<masinter> for example,
[19]http://www.metadataworkinggroup.org/specs/ deals with
relationship. For example, img src="something.jpeg" might want to
link data about the image in the HTML, to ... override? supplant? be
resolved against ? metadata ... may need something of the scope of
[20]http://www.metadataworkinggroup.org/specs/
[19] http://www.metadataworkinggroup.org/specs/
[20] http://www.metadataworkinggroup.org/specs/
JT: The problem is it's impossible to generate idiomatic RDF without
some knowledge of the microdata vocabulary.
<masinter> would like to make sure review with
[21]http://www.w3.org/2008/WebVideo/Annotations/ happens
[21] http://www.w3.org/2008/WebVideo/Annotations/
JT: It doesn't make distinctions that RDF makes. E.g. what about
ordering of multiple values? Microdata is always ordered, but in
idiomatic RDF it would depend on vocabulary
... AFAIK everyone using microdata is using schema.org
TBL: Could you annotate the schema?
JT: Somewhere, somehow, there needs to be a registry that provides
this information
<JeniT> [22]http://dev.w3.org/html5/md/Overview.html#items
[22] http://dev.w3.org/html5/md/Overview.html#items
<JeniT> "Except if otherwise specified by that specification, the
URLs given as the item types should not be automatically
dereferenced."
<noah> We need to wrap this discussion in 2 minutes
jar: asking why there needs to be a canonical mapping for microdata
(as opposed to lots of mappings)
noah: Cost/benefit
TBL: Scaling and reuse
<Zakim> masinter, you wanted to ask that the HTML data guide address
other workflows around data management in HTML: merging HTML from
multiple sources, merging HTML data with data from
<JeniT>
[23]https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide
/index.html#consuming-multiple-formats
[23]
https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide/index.html#consuming-multiple-formats
<JeniT> I think that's expanding the scope which I don't want to do
LM: metadata about the linked object in the referring document -
this is a common workflow - possible conflicts - might be worth
calling this out
<JeniT> That might be useful, but it's outside scope
<masinter> if it is out of scope, then please note that it hasn't
been addressed and should be before the analysis is complete
NM: Thanks Jeni
JT: There's so much to say about this, we had to keep the scope
quite narrow
<timbl> I wonder why "This section is non-normative.
<timbl> This document describes a means of transforming HTML
containing microdata into RDF. "
<JeniT> [24]http://www.w3.org/html/wg/next/markup/
[24] http://www.w3.org/html/wg/next/markup/
HTML.next
nm: I'd like to know what we ought to be doing re HTML.next in the
next 3-6 months
PLH: Mike Smith did some work since we last spoke about this. New
list [of features], which is interesting
... E.g. datagrid got removed from html5, deferred
... Input mode attribute, proposal from Microsoft
NM: Looks like none of this is deep
PLH: There will be no upgrades to the HTML5 parsers
NM: That's important
<masinter> modularization of the specification?
<glenn> the proposed "element" and "template" element types appear
somewhat generic
PLH: intent element - from device API WG - for head - this is a
problem since an HTML5 parser will treat unrecognized an element in
the head as transition to body
<masinter> which of [25]http://www.w3.org/2010/11/TPAC/HTMLnext.pdf
are in scope?
[25] http://www.w3.org/2010/11/TPAC/HTMLnext.pdf
<masinter> and my own perspective:
[26]http://www.w3.org/2010/11/TPAC/HTMLnext-perspectives.pdf
[26] http://www.w3.org/2010/11/TPAC/HTMLnext-perspectives.pdf
TBL: This has always been a bug... unrecognized head elements ought
to be ignored, otherwise there's no extensibility
PLH: intent is thus an example of an extension that's NOT going to
be considered for now
... ('intent' is a misnomer)
NM: it has a pub/sub feel to it
PLH: Arrival of speech on the web is going to be a big item. Speech
incubator group is looking at it
... translate - if you don't use namespaces, that's OK, but [scribe
missed]
... translate will be part of HTML, but will be extended further
<plh> --> [27]http://www.w3.org/2011/12/mlw-lt-charter.html
Multilingual Web Working Group Charter
[27] http://www.w3.org/2011/12/mlw-lt-charter.html
NM: Before ratholing, remember the goal is what the TAG should be
doing
JAR: What about javascript related changes?
PLH: Being able to control adaptive streaming algorithm - it's a set
of APIs
... Javascript modules is not part of this discussion
LM: What I see is sets of features, which seems appropriate for the
WG
<glenn> plh? impact from media related proposals in
[28]http://www.w3.org/wiki/HTML/next#Multimedia ?
[28] http://www.w3.org/wiki/HTML/next#Multimedia
LM: at TPAC there was an interesting panel ... architectural
conflicts between SVG (etc.) and HTML, things left dangling,
references to evolving specifications
... these are not features, but they are changes to the
specification and affect evolution of the language. Maybe the WG
doesn't want to work on this, as this is painful
... might the TAG be able [to do anything] to make that kind of work
easier to do?
PLH: SVG and HTML video element conflict will be addressed by the
WGs
<glenn> plh? accessibility issues from use of canvas ? is this in
HTML.next scope ?
PLH: there is interest in making the technologies work well together
LM: color management
PLH: this is happening naturally, since implementors don't like to
implement the same thing twice with variation
LM: But that kind of pressure is not neceesarily enough
PLH: The CSS extensibility story has been falling apart. Market
successes drive out minority features...
PL: If an id contains a - then it will never become part of CSS
(this includes vendor prefixes)
... When people started using vendor prefixes for experimental
purposes that was a problem
TBL: Pain
PL: Any vendor who does [that] will get a whack from the CSS WG
LM: The question is who to blame when something goes wrong
PLH: I introduced this topic because CSS seems to have the best
extensibility story for experimental features
PL: The best approach is for the CSS WG to drive new features to rec
as fast as possible, to avoid vendor prefixes
LM: Vendor prefixes should have a year, and old features should not
be used
<masinter> What can the TAG do? Extensibility, mdularization,
references... architectural features
<glenn> what is the record for attaining REC by CSS WG? 2-3 out of
20-30 specs? some specs going on 10+ years
NM: XML namespaces often feel like vendor prefixes. There's not a
good way to say what the implementation path is for [missed]
LM: How can the TAG help? Not with the feature list. What about
architectural issues, like extensibility, maybe narrowly focussed.
PLH: Because no namespace support, we're trying to keep track of new
elements being introduced
... [in HTML]
TBL: HTML parser is a big black box, not driven by tables, no
grammar - so how to add new elements?
<masinter> timbl: table driven parser? Grammar? If you're adding new
elements, where will they be added?
PLH: Some parts of parser are going to be unchanged - error recovery
LM: What about HTML5 issues closed for lack of change proposal?
Reconsidering them for HTML6?
PLH: Correct, this can happen.
JT: Has there emerged a kind of scope for HTML.next? Or timeline?
PLH: Should be more rapid this time
<noah> ACTION-600?
<trackbot> ACTION-600 -- Daniel Appelquist to report to TAG on
goals, scope and progress to date for HTML.next work -- due
2011-10-25 -- OPEN
<trackbot> [29]http://www.w3.org/2001/tag/group/track/actions/600
[29] http://www.w3.org/2001/tag/group/track/actions/600
<noah> DKA: No progress on ACTION-600
<noah> NM: I think we'll probably reassign ACTION-600 given that Dan
is leaving the TAG, let's see how the rest of this discussion goes.
<noah> ACTION-641?
<trackbot> ACTION-641 -- Noah Mendelsohn to try and find list of
review issues relating to HTML5 from earlier discussions -- due
2012-01-17 -- OPEN
<trackbot> [30]http://www.w3.org/2001/tag/group/track/actions/641
[30] http://www.w3.org/2001/tag/group/track/actions/641
<noah> I'm sorry I didn't have time to get to ACTION-641. It's due
mid-Jan. Not sure if I'll get to it, but I'll try. Help would be
welcome.
PLH: There's the issue of modularizing the spec. To some extent this
happens because different people are working on different parts
<glenn> negative impact of modularization is cross-dependencies
between modules and time lines for completion of dependencies
NM: The TAG isn't looking for work, the question is whether we can
be of any use
<glenn> separately, there are core semantics of HTML5 spec (such as
event queue semantics) that are being normatively referenced by many
other specs in other WGs (e.g., WebApps)
<glenn> it's becoming quite a nest of dependencies with little
architectural planning for the impact
LM: We're not looking for trouble. Can we look to Philippe to bring
to our attention anything the TAG might help with?
<noah> PROPOSED RESOLUTION: The TAG decides that it will not at this
time start a significant effort on HTML.next. Therefore: 1)
HTML.next will be removed from the under consideration list on the
TAG product list 2) ACTION-600 will be closed. The TAG will look to
PLH and others to engage the ...
<noah> TAG as appropriate on HTML.next issues.
RESOLUTION: The TAG decides that it will not at this time start a
significant effort on HTML.next. Therefore: 1) HTML.next will be
removed from the under consideration list on the TAG product list 2)
ACTION-600 will be closed. The TAG will look to PLH and others to
engage the TAG as appropriate on HTML.next issues.
<noah> close ACTION-600
<trackbot> ACTION-600 Report to TAG on goals, scope and progress to
date for HTML.next work closed
LM: Request that MIME type registrations happen sooner
... You can say that there is no specification yet - register a
placeholder
... W3C has been too conservative, better to err on the side of
aggressive registration
... Enough about specs, it's time to start registering
... I want the official registry to be better than what you find in
wikipedia
JT: Talking about media type registries - I had an action re FYN
LM: If specs are allowed to fork, maybe they shouldn't contain their
own media type registration, since the reg has to talk about the
fork
<JeniT> ACTION-642?
<trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to
make plan of action for getting "follow your nose" for (at least)
microdata and RDFA from HTML5 Due: 2 January 2012 -- due 2012-01-02
-- OPEN
<trackbot> [31]http://www.w3.org/2001/tag/group/track/actions/642
[31] http://www.w3.org/2001/tag/group/track/actions/642
LM: Consider the existence of "profiles" - the pointer to the main
spec would be just one piece of information
... I want to figure out whether Philippe might need help [with any
aspect of the reg. process]
NM: Is profile still out?
PLH: Are you looking for a text/html registration that is really
vague?
LM: I was looking for a reg that talks about what someone receiving
a document [so marked] would get
NM: Document misuses of the MIME type.
LM: MIME is the wrong place to talk about conformance or
correctness.
... MIME is informational to receivers.
NM: The reg. makes promises: if doc is well formed it has such and
such a meaning (DOM, etc.)
LM: 3023 is a spec, and you can conform or not. It sets out
conformance criteria.
<JeniT> plh, what I'm worried about is the follow-your-nose from an
HTML document to understanding how the HTML document should be
processed...
TBL: The arch goes thru media type, that means you're part of a
protocol, you're committing to a particular meaning
... MIME type is a key piece of this, normative
<JeniT> plh, which can't currently happen because there's no route
from the mime type to the various extensions made to HTML
<JeniT> plh, so I guess the question is: where is the registry of
the set of HTML extensions (such as microdata, RDFa)
<plh> doesn't exist at the moment
LM: Let me try to restate. When you register, you're saying two
things, one to consumers, one to producers. Advice to consumers has
to be realistic - even for non-conforming docs
NM: When something's put on the wire, there are inferences that can
be drawn from the specs
... It's a contract
... If you send me garbage, then nothing can be inferred per the
registration
[but can be inferred some other ways?]
LM: The spec is extensible - extensions are legit according to the
spec - even though not written at the time the spec is written
NM: Is error recovery language in HTML used for ...?
[scribe couldn't distill what NM just said into something that could
be written down]
NM: Fully legal, expect it but deprecated, tolerate it
interoperably, ...
... If you see a new element name, maybe it comes from a future spec
LM: Jeni's action was to connect text/html to RDFa. No simple way to
fix that if RDFa isn't listed in the media type reg.
... A registry of HTML extensions would solve this problem
JT: Could W3C do this?
jar: W3C already does this for XHTML (XHTML namespace document)
NM: What should the TAG's involvement be in the text/html media type
registration?
PLH: No request sent yet
NM: Maybe TAG should be more actively involved
LM: There's currently a W3C policy that the media type reg is in the
language spec, because unlinking led to mismatches. This is probably
OK in many cases, but I'm not sure about text/html
<glenn> other obligations for today, will rejoin in morning
<noah> NM: I think the next step on media type registration would be
to get a balanced analysis of potentially controversial or
architecturally tricky points regarding the media type registration.
Then we can see if there's anything the TAG needs to engage.
<noah> JT: We can rescope my ACTION-642 to cover that.
<noah> NM: Great, fine with me. Thank you.
<noah> ACTION-642
<noah> ACTION-642?
<trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to
make plan of action for getting "follow your nose" for (at least)
microdata and RDFA from HTML5 Due: 2 January 2012 -- due 2012-01-02
-- OPEN
<trackbot> [32]http://www.w3.org/2001/tag/group/track/actions/642
[32] http://www.w3.org/2001/tag/group/track/actions/642
<noah> New scope: JT with help from Larry to report on potential
issues requiring TAG attention relating to HTML media type
registration.
<masinter> it says "at least"
<JeniT> "JT with help from Larry to liaise with PLH to register HTML
media type
<noah> "JT with help from Larry to propose plan to liaise with PLH
to register HTML media type
NM: what about what TAG is doing, as opposed to TAG members. [scribe
mistranscription]
<noah> ACTION-642?
<trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to
propose plan to liaise with PLH to register HTML media type -- due
2012-01-17 -- OPEN
<trackbot> [33]http://www.w3.org/2001/tag/group/track/actions/642
[33] http://www.w3.org/2001/tag/group/track/actions/642
<masinter> i liked the old action item better, because it recorded
why we're doing it
break ending
Privacy
Welcome Wendy Seltzer
introductions
WS: EFF, Berkman, now W3C team
<masinter>
[34]http://masinter.blogspot.com/2011/08/internet-privacy-telling-fr
iend-may.html
[34]
http://masinter.blogspot.com/2011/08/internet-privacy-telling-friend-may.html
<masinter> my contribution to the privacy discussion
NM: privacy, big issue, potential threat to the web. DNT
<noah>
[35]http://lists.w3.org/Archives/Public/www-tag/2012Jan/0000.html
[35] http://lists.w3.org/Archives/Public/www-tag/2012Jan/0000.html
ashok: The idea was to look at privacy from higher level. There is a
DNT WG, that's good, but it's just a corner of the "war on personal
privacy"
<masinter> want to ask about ISOC and
[36]http://www.internetsociety.org/our-work-privacy
[36] http://www.internetsociety.org/our-work-privacy
ashok: leaks from social networks
... picking up ambient information
... identifying based on clicks etc.
<masinter> [37]http://www.ietf.org/rfc/rfc3514.txt
[37] http://www.ietf.org/rfc/rfc3514.txt
ashok: Not a technological problem. Encryption may be helpful, but
not clear how far it can go
... Accountability, laws as non-technological alternative
... Mitigations? Technical, policy, education
DKA: Data minimization as technical mitigation - granularity - this
is privacy-enhancing
<masinter> What is relationship of W3C role in privacy to other
initatives
jar: Interesting:
[38]http://dataprivacylab.org/projects/irb/index.html
[38] http://dataprivacylab.org/projects/irb/index.html
DKA: I got negative feedback from the geolocation WG - they ask, who
is asking for this?
<DKA> Draft API Data Minimization finding:
[39]http://www.w3.org/2001/tag/doc/APIMinimization.html
[39] http://www.w3.org/2001/tag/doc/APIMinimization.html
NM: Here are 2 things. 1, possibility of more traffic encryption,
cf. SPDY.. performance limited devices, cost of encryption. 2.
Fingerprinting, e.g. browser configuration uniqueness . These are
technical topics
<Zakim> masinter, you wanted to ask why this is TAG work... argue
against TAG taking this as a major area, not so much because of
"lack of expertise" as "already covered". to respond to
YL:
LM: W3C is a focus of policy initiatives that aren't asked for by
developers. Constituencies come to us
... Many past difficulties around privacy have to do with venue
shopping, esp between W3C and IETF.
... Encryption is a red herring. Does nothing for privacy
<timbl> Sweeping generalizations are always wrong -- and Larry's is
no exception.
LM: Why is this TAG work? Seems like W3C work, but not TAG work -
not technical. Not interested in stopgaps
<masinter> it isn't that it is "not technical", it's that any TAG
work would be without sufficient context to be useful
<masinter> "Not interested in stopgap" => "DNT is stopgap, we
shouldn't do too many more of those"
<masinter> encryption doesn't help much with almost all of the
privacy threats i can think of
<DKA> For the record: I feel the data minimization is relevant to
the TAG since it is articulating an architectural principle - a
design best practice - that also happens to enhance privacy.
<masinter> @dka: it might be an architectural principle, but it's
not clear it really helps in most of the threat cases, and it's not
actionable
NM: Look at work plan...nothing much here re privacy, barely started
RESOLUTION: The TAG will not do a major effort on privacy at this
point. We will remove Privacy from the list of active projects.
WS: The framing is a good start. Threat categories: p2p, corporate,
individual to government - different concerns re different info
collectors
LM: [What are the] threats?
WS: Info used out of context
LM: Is there a sense that these are more than a list of anecdotes?
... What W3C could do: try to ground anecdotal tales about
hypothetical instances, in real cases
... If we had a better model of the real threats, we could do better
at responding, with technical architecture
WS: We can do better at describing
LM: We need the particular cases - not a categorization - we already
have good descriptions of categories, but they seem to be based on
hypotheticals
... need grounding in fact
TBL: [one might mine them from] risks digest
[40]http://catless.ncl.ac.uk/Risks
[40] http://catless.ncl.ac.uk/Risks
<masinter> a real threat analysis
<wseltzer> "concern" can be a harm too
<DKA>
[41]http://online.wsj.com/public/page/what-they-know-digital-privacy
.html
[41]
http://online.wsj.com/public/page/what-they-know-digital-privacy.html
<wseltzer> ...if people are deterred from using the web based on
concerns that their information may be misused
<masinter> concern can be caused by rumors too
<masinter> many people are concerned about 12/11/12 or whenver the
mayan calendar says the world will end
<masinter> would encryption help with any of the issues in
[42]http://online.wsj.com/public/page/what-they-know-digital-privacy
.html ?
[42]
http://online.wsj.com/public/page/what-they-know-digital-privacy.html
discussion of what to do, and who to do it
<wseltzer> encryption could prevent some of the snooping by
middlemen
<Yves> encryption could also lead to misplaced trust (in case of CA
attacks, for example)
<noah> WS: I'm here to work on Web Identity.
action jar to review what provenance WG is doing with an eye to
application to privacy issues
<trackbot> Created ACTION-650 - Review what provenance WG is doing
with an eye to application to privacy issues [on Jonathan Rees - due
2012-01-12].
<noah> WS: Part of that is getting the privacy story right, and
helping users to understand the implications of what they're doing
on the Web
<noah> ACTION-566?
<trackbot> ACTION-566 -- Daniel Appelquist to contact Alissa Cooper,
organize a future joint discussion on privacy with IAB. -- due
2011-10-18 -- OPEN
<trackbot> [43]http://www.w3.org/2001/tag/group/track/actions/566
[43] http://www.w3.org/2001/tag/group/track/actions/566
<masinter> [44]http://www.internetsociety.org/our-work-privacy
[44] http://www.internetsociety.org/our-work-privacy
<masinter> see
[45]http://www.ietf.org/proceedings/81/technical-plenary.html
[45] http://www.ietf.org/proceedings/81/technical-plenary.html
adjourn for lunch
<Norm> I'm hitting the road. Noah, you've got my mobile if you need
to reach me. See y'all this afternoon.
<Ashok> scribenick: Ashok
TAG Priorities for 2012
Noah: We published a finding on Web Application State.
... need to deal with Raman's document
... I suggest we move Web App State to the completed state
LM: Did we get community review?
Noah: We may want to do more to promote it and ask folks if it
helped them
LM: Any reason not to make this rec track?
Jar: Findings should make their way into architectural
recommendations
RESOLUTION: The TAG, having published a finding on Web Application
State, closes its "product" on that topic.
<noah> ACTION: Noah to announce closing of Web App State Product
Due: 2012-01-17 [recorded in
[46]http://www.w3.org/2012/01/05-tagmem-irc]
[46] http://www.w3.org/2012/01/05-tagmem-irc
<trackbot> Created ACTION-651 - Announce closing of Web App State
Product Due: 2012-01-17 [on Noah Mendelsohn - due 2012-01-12].
<noah> — <span class="needswork">product page
needed</span>)</td>
<noah> <td>Daniel Appelquist, Ashok Malhotra</td>
<noah> <td class="needswork">TBD</td>
<noah> </tr>
[47]http://www.w3.org/2001/tag/products/ is the list of stuff we are
working on
[47] http://www.w3.org/2001/tag/products/
Noah: Frag Identifiers and Mime Types is late
<noah> ACTION-594?
<trackbot> ACTION-594 -- Peter Linss to with Henry produce partial
revision of fragment id finding -- due 2011-10-18 -- OPEN
<trackbot> [48]http://www.w3.org/2001/tag/group/track/actions/594
[48] http://www.w3.org/2001/tag/group/track/actions/594
Yves: I will work on that
<noah> ACTION-594?
<trackbot> ACTION-594 -- Yves Lafon to with Peter and Henry produce
partial revision of fragment id finding -- due 2012-02-14 -- OPEN
<trackbot> [49]http://www.w3.org/2001/tag/group/track/actions/594
[49] http://www.w3.org/2001/tag/group/track/actions/594
LM: Should we integrate this with the other MIME stuff?
JT: I think it's better to keep a tight scope
Noah: The TAG agreed to invest in this effort starting by revisiting
the work plan.
(Noah updates the product page)
Noah: Publishing and Linking on the Web remains a top priority
... URI Discovery remains a top priority
... MIME architecture for the Web remains a top priority
... Other items:
... API Minimization --- leave
LM: Not clear this will make progress. Let us publish now.
Dan: Maybe a new TAG member will have new energy to put in this
... I can come back with a proposal how to publish it
Noah: We can leave open for a few weeks and then decide. Or decide
to publish now.
Dan: I will come back with a proposal for our next telcon
Noah: HTML/XML Unification
... this is either done or we keep in this mode
... Persistence of Identifiers
... should we move this up in priority
jar: Publishing a Workshop Report would be good.
... then i can do some writing based on yesterday's session
<Yves> ACTION-622?
<trackbot> ACTION-622 -- Noah Mendelsohn to schedule discussion of
html.next as possible new TAG work focus (per Edinburgh F2F)
[self-assigned] -- due 2011-12-20 -- PENDINGREVIEW
<trackbot> [50]http://www.w3.org/2001/tag/group/track/actions/622
[50] http://www.w3.org/2001/tag/group/track/actions/622
<Yves> ACTION-652?
<trackbot> ACTION-652 -- Yves Lafon to danA to come back with a
proposal on API minimization draft -- due 2012-01-17 -- OPEN
<trackbot> [51]http://www.w3.org/2001/tag/group/track/actions/652
[51] http://www.w3.org/2001/tag/group/track/actions/652
<noah> ACTION: Noah to schedule telcon discussion of Persistence
product page (which was drafted for but not reviewed at F2F0 Due:
2012-10-17 recorded in [52]http://www.w3.org/2012/01/05-tagmem-irc]
[52] http://www.w3.org/2012/01/05-tagmem-irc
<trackbot> Created ACTION-653 - Schedule telcon discussion of
Persistence product page (which was drafted for but not reviewed at
F2F0 Due: 2012-10-17 [on Noah Mendelsohn - due 2012-01-12].
Noah: Microdata and RDFa
... is this done?
JT: I think we should declare success
... I will write a final taskforce report and tell the TAG and the
HTML WG
<noah> ACTION: Jeni to write "product" page summarizing wrapup of
RDFa/Microdata work Due: 2012-01-31 [recorded in
[53]http://www.w3.org/2012/01/05-tagmem-irc]
[53] http://www.w3.org/2012/01/05-tagmem-irc
<trackbot> Created ACTION-654 - Write "product" page summarizing
wrapup of RDFa/Microdata work Due: 2012-01-31 [on Jeni Tennison -
due 2012-01-12].
Noah: Web Apps Storage
<JeniT> ScribeNick: JeniT
noah: client-side local storage is not a spec
ashok: the difficulty is there's more than one web storage
capability
(looking at draft
[54]http://www.w3.org/2001/tag/products/clientsidestorage.html )
[54] http://www.w3.org/2001/tag/products/clientsidestorage.html
ashok: the success criteria look like requirements for a Web Storage
Working Group
noah: I'm trying to spell out good practice for people developing
web apps, such as a calendaring application
... how to design a good web app
TimBL: perhaps express it as a set of patterns
... when we did a top-down analysis of versioning, it didn't really
work
... local storage is new, and it will change a lot soon
... there's a caching pattern when the URI on the web is used
everywhere to refer to the document, even when it's in local storage
noah: the TAG isn't committed to doing anything in this space at all
currently
... what we need to do here is to decide how to scope it and choose
where to invest
larry: it's difficult to come up with best practices, but we could
come up with criteria for evaluating a design
... we don't have to produce the patterns, just say how to evaluate
a design
ashok: evaluate on what basis? I thought using patterns or use cases
would help
noah: there are cases where we will have a good idea for a pattern,
such as where the same information is stored locally and on web
... but then it's hard to point to local vs web
... we need a plan that's more than just noodling on use cases
... how about we refine this draft product page?
larry: examining even one tradeoff is useful
ashok: Dan, when could we have something about the workshop? do you
have a draft?
<noah> ACTION-523?
<trackbot> ACTION-523 -- Ashok Malhotra to (with help from Noah)
build good product page for client storage finding, identifying top
questions to be answered on client side storage -- due 2011-12-20 --
OPEN
<trackbot> [55]http://www.w3.org/2001/tag/group/track/actions/523
[55] http://www.w3.org/2001/tag/group/track/actions/523
dan: there are minutes
<DKA> Minutes for off-line web apps workshop:
[56]http://www.w3.org/2011/11/05-offline-minutes.html
[56] http://www.w3.org/2011/11/05-offline-minutes.html
<noah> ACTION-523 Due 2012-01-17
<trackbot> ACTION-523 (with help from Noah) build good product page
for client storage finding, identifying top questions to be answered
on client side storage due date now 2012-01-17
<scribe> ScribeNick: Ashok
Noah: I feel moderately good about the topics we have.
JT: SPDY?
Noah: Let's talk about this after tomorrow's session.
<Norm> Norm begins by thanking Tim for the fine hospitality
<Norm> Norm begins by thanking Tim again for the fine hospitality
XML/HTML Convergence
<noah> ACTION-437?
<trackbot> ACTION-437 -- Tim Berners-Lee to create a task force on
XML / HTML convergence -- due 2011-06-01 -- CLOSED
<trackbot> [57]http://www.w3.org/2001/tag/group/track/actions/437
[57] http://www.w3.org/2001/tag/group/track/actions/437
<Norm> => [58]http://www.w3.org/2010/html-xml/snapshot/
[58] http://www.w3.org/2010/html-xml/snapshot/
<noah> [59]http://www.w3.org/2001/tag/tag-weekly#htmlxml
[59] http://www.w3.org/2001/tag/tag-weekly#htmlxml
Noah: We should review the report, determine whether further action
is required and update product pages, etc.
Norm: My goal is to publish report, which the TAG needs to do so
that we can get public review
Noah: We could publish a note
Norm: The TAG wanted a strong statement re. Polygot but there were
people that thought that that was a waste of time
... so that does not appear
... I attempted to incorporate the feedback I got
<jar> 2.1.1 in the table of contents
<noah> [60]http://www.w3.org/2010/html-xml/snapshot/
[60] http://www.w3.org/2010/html-xml/snapshot/
<timbl> In the report please change "Resolution Broadly speaking,
there are two techniques for addressing th" to "Resolution Broadly
speaking, there are two alternative techniques for addressing th"
LM: Add names of other contributers?
Dan: Are editorial comments in scope?
Norm: Yes, they are
LM: I want references to source material
Noah: Add sentence mentioning minutes of telcons
s/mentioing/mentioning/
LM: Cite [the] paper backing up the assertion that "much of HTML is
generated".
Norm: Could you identify where references would help?
Dan: Re. last para ... sets out a false dichotomy
... should say "if you want to ... . you could use polyglot"
... use positive wording
<JeniT> "Consumers that require polyglot markup will fail with
content doesn't adhere to it. Therefore, consumers that want to
access lots of random data can't use polyglot. On the other hand, in
a constrained environment (eg where the consumer is publisher),
polyglot is more viable"
<jar> People who like this sort of thing will find it's the sort of
thing they like. (re polyglot)
Norm: There was some pushback re. polyglot
Dan: If you have a corpus, you want to publish documents on the web
[but] use it also as XML, you should use XHTML
<jar> Polyglot reduces the number of versions you have to keep track
of
Noah: Multiple uses of documents
Norm: If there is an angle for giving polyglot a better angle, I'm
all for it, but the task force did not want that
JT: We want to digitally sign the pages as XML
<jar> LM: Just say there are use cases for polyglot the TF didn't
consider and didn't make progress on.
<jar> ?
Norm: I will attempt to incorporate this info in 2.1 and see if the
taskforce will [buy] off on it
<Zakim> DKA, you wanted to question the wording of the polyglot
markup paragraph.
<JeniT> scribenick: JeniT
ashok: laxer XML parsers seem interesting, and there should be more
of a reference
ndw: if you want that to happen, I think the TAG should recommend
taking that forward
noah: the conclusion of the TF was that it was unlikely to be
effective in practice, because it wouldn't be adopted by people
using XML now
ndw: the draft doesn't say that, it was just that the TF wasn't the
right body to do that
<scribe> scribenick: ashok
Norm: The taskforce did not think this was central to their concerns
<Zakim> JeniT, you wanted to ask about HTML toolchains consuming XML
Norm: We should charter a WG if we want this work to get done
JT: Why bother discussing the usecase in 2.2?
Norm: For balance ... I think it comes to the right conclusions
Tim: What was the most hardest point?
Norm: How to make XML more forgiving of errors
(Discussion of how to make XML more forgiving of errors)
Norm: The XML spec states it should be well formed
Noah: Spec does not talk about errors and perhaps how to deal with
them.
Norm: My take away was -- just put an HTML parser in front. And that
works.
<Zakim> noah, you wanted to talk about where XML forgiveness is
discussed
Noah: The conclusion section should restate earlier material. So,
...
<noah> Specifically, I noted that the sentence "However, it's
entirely unclear that the XML community would be motivated to adopt
such changes and, in any event, making such proposals is outside the
scope of this Task Force." is in the conclusions only. That thought
should also be in 2.5, I think.
<noah> Norm agreed.
jar: "HTML parser" is not defined ... perhaps use "standard HTML
parser"
Yves: It should be HTML5 Parser as it is the first spec to define
parsing model
jar: Rewrite for the naive user ... define terms
Norm: Define HTML parser as something that conforms to HTML5 spec
jar: In 2.2 can you make a stronger statement if input is XHTML
Norm: It's likely to get XHTML right
jar: It is worth saying that
... Does not discuss XSLT
Norm: XSLT is a XML tool, not an HTML tool
JT: Use XSLT to covert XML to HTML?
... the document says that
jar: Says in 2.5 "the HTML parser", earlier it says "an HTML
parser".
<Zakim> JeniT, you wanted to ask about embedding XML islands in
polyglot/XHTML
Norm: Should always say "an HTML5 parser"
Tim: Cannot substitue XML parser for HTML parser ... they produce
different DOMs
Norm: Eventually, there will be a single DOM
<JeniT> JeniT: section 2.4 should mention (a) that you can embed any
old XML in XHTML without <script> and (b) that you cannot use the
<script> method in Polyglot markup
Noah: There is a missing shim between XML and HTML DOMs
Norm: There are several shims around
(Discussion about differences in DOMs)
<Zakim> masinter, you wanted to review comments
LM: Editorial stuff re. comment should go to Task Force
Norm: SOTD needs updating
LM: There is ladder of comparisons, XML/HTML infosets etc.
... Asks about digital signatures ... cannot do it in HTML
... need to convert HTML to XML
<jar> LM: what if you want to apply EXI to HTML?... want to know how
to slot this (and other random use cases) into the document
Norm: Document is clear about where it says XHTML and HTML
... no confusion there
<jar> LM: no orientation to layered architecture - surface syntax,
parse tree, element semantics
LM: Should say why someone should care about this document
Noah: Who is the audience for this?
Norm: The intro says that.
... Technical folks on one side or the other interested in the issue
<jar> LM: maybe the average AC member as audience
Noah: Does this document do it for that audience?
LM: Other audiences: Typical AC member, someone in the trade press
<DKA> I think the document is fine for the Intended audience (modulo
my earlier comments regarding polyglot).
<jar> "Readers are encouraged to report additional use cases" -
really? I thought you were trying to wrap this up
Noah: The question is "Is it a useful piece of work for the audience
it is intended for"
(Discussion about different audiences)
Noah: There is a wiki, right? Would that answer the question?
Dan: This is useful for folks struggling with these problems
Noah: Can we discuss next steps?
Norm: It's going to be hard to get all the references ... this
represents the judgements of a lot of smart people
Tim: I support taking the document forward
Ashok: Norm should react to the comments he has received and then we
should vote whether to publish the document
Noah: How shall we publish the document?
Tim: Let's publish as a Finding and then a Note
JT: Do you want public review?
Norm: I would like to publish the draft as is as a Finding then fix
it up and publish as a Note
<jar> LM volunteers to write status section
Noah: Does anybody object to publishing the document as a Draft
Finding as soon as Norm makes the changes we recommended?
Norm: I would like to have it published in some form
DKA: Editorial changes should be incorporated
Yves suggests a W3C Note
scribe: Notes can be updated
Yves: It was a product of a task force
Tim: Gets it into the mainstream
Feeling that Note is better
Noah: Norm, pl. work with Yves to prepare a document to be published
as a Note
... we can then review and then we can vote and publish
RESOLUTION: The TAG thanks Norm Walsh and the task force, and
expects that Norm will shortly provide the TAG for review a draft on
XML/HTML Unification to be published as a W3C note for comunity
review and comment. TAG chair will check with TAG before giving
final clearance for publication.
<DKA> +1
LM: Change the name of the document?
<noah> ACTION-587?
<trackbot> ACTION-587 -- Jonathan Rees to prepare issue-57 and
issue-63 documents for TAG members to discuss at Sept F2F -- due
2011-10-11 -- CLOSED
<trackbot> [61]http://www.w3.org/2001/tag/group/track/actions/587
[61] http://www.w3.org/2001/tag/group/track/actions/587
<noah> ACTION-591?
<trackbot> ACTION-591 -- Noah Mendelsohn to ping Norm end of Sept.
on revised HTML/XML report per discussion on 1 Sept 2011 -- due
2011-12-27 -- PENDINGREVIEW
<trackbot> [62]http://www.w3.org/2001/tag/group/track/actions/591
[62] http://www.w3.org/2001/tag/group/track/actions/591
Tim: The Taskforce stems from Raman's request for XML/HTML
unification
Noah: I will prepare a covering note, which I will share with you,
which will have some of the history
Norm: I prefer in the cover letter
LM: Could be in the introduction
Tim: I prefer the history in the cover letter
<noah> ACTION: Noah to check Norm Walsh draft of W3C Note with the
TAG, draft cover letter to include with Note, and review that with
the TAG Due: 2012-01-17 [recorded in
[63]http://www.w3.org/2012/01/05-tagmem-irc]
[63] http://www.w3.org/2012/01/05-tagmem-irc
<trackbot> Created ACTION-655 - Check Norm Walsh draft of W3C Note
with the TAG, draft cover letter to include with Note, and review
that with the TAG Due: 2012-01-17 [on Noah Mendelsohn - due
2012-01-12].
JT: Asks about taking the XML5 work forward
<noah> JT: Two additional things we might do 1) possible
encouragement of W3C to do something like XML5 on liberal XML
processing 2) possibly do a new version of note that would better
target needs of AC members, etc.
<noah> ACTION: Noah to schedule discussion of possibly getting W3C
to invest in technologies for liberal XML processing (e.g. XML5)
recorded in [64]http://www.w3.org/2012/01/05-tagmem-irc]
[64] http://www.w3.org/2012/01/05-tagmem-irc
<trackbot> Created ACTION-656 - Schedule discussion of possibly
getting W3C to invest in technologies for liberal XML processing
(e.g. XML5) [on Noah Mendelsohn - due 2012-01-12].
<noah> NW: XML Prague is weekend of 11th and 12th of February (Jeni
is keynoting on Microdata and RDFa)
<noah> NW: Anne will present XML5. Robin Berjon had some ideas for
the task force, and he will present those. Norm is chairing a panel
on XML/HTML.
<Norm> => [65]http://www.xmlprague.cz/2011/sessions.html
[65] http://www.xmlprague.cz/2011/sessions.html
<noah> ACTION: Noah to schedule telcon discussion of possible
XML/HTML Unification next steps Due: 2012-01-27 [recorded in
[66]http://www.w3.org/2012/01/05-tagmem-irc]
[66] http://www.w3.org/2012/01/05-tagmem-irc
<trackbot> Created ACTION-657 - Schedule telcon discussion of
possible XML/HTML Unification next steps Due: 2012-01-27 [on Noah
Mendelsohn - due 2012-01-12].
<JeniT> [67]http://www.xmlprague.cz/2012/sessions.html
[67] http://www.xmlprague.cz/2012/sessions.html
<Norm> => [68]http://www.xmlprague.cz/2012/sessions.html
[68] http://www.xmlprague.cz/2012/sessions.html
<noah> ACTION-657 Due 2012-01-17
<trackbot> ACTION-657 Schedule telcon discussion of possible
XML/HTML Unification next steps Due: 2012-01-27 due date now
2012-01-17
<jar> scribe: Jonathan Rees, Ashok Mahotra
Summary of Action Items
[NEW] ACTION: Jeni to write "product" page summarizing wrapup of
RDFa/Microdata work Due: 2012-01-31 [recorded in
[69]http://www.w3.org/2012/01/05-tagmem-irc]
[NEW] ACTION: Noah to announce closing of Web App State Product Due:
2012-01-17 recorded in [70]http://www.w3.org/2012/01/05-tagmem-irc]
[NEW] ACTION: Noah to check Norm Walsh draft of W3C Note with the
TAG, draft cover letter to include with Note, and review that with
the TAG Due: 2012-01-17 [recorded in
[71]http://www.w3.org/2012/01/05-tagmem-irc]
[NEW] ACTION: Noah to schedule discussion of possibly getting W3C to
invest in technologies for liberal XML processing (e.g. XML5)
recorded in [72]http://www.w3.org/2012/01/05-tagmem-irc]
[NEW] ACTION: Noah to schedule telcon discussion of Persistence
product page (which was drafted for but not reviewed at F2F0 Due:
2012-10-17 recorded in [73]http://www.w3.org/2012/01/05-tagmem-irc]
[NEW] ACTION: Noah to schedule telcon discussion of possible
XML/HTML Unification next steps Due: 2012-01-27 [recorded in
[74]http://www.w3.org/2012/01/05-tagmem-irc]
[69] http://www.w3.org/2012/01/05-tagmem-irc
[70] http://www.w3.org/2012/01/05-tagmem-irc
[71] http://www.w3.org/2012/01/05-tagmem-irc
[72] http://www.w3.org/2012/01/05-tagmem-irc
[73] http://www.w3.org/2012/01/05-tagmem-irc
[74] http://www.w3.org/2012/01/05-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [75]scribe.perl version 1.135
([76]CVS log)
$Date: 2012/01/14 00:50:29 $
[75] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[76] http://dev.w3.org/cvsweb/2002/scribe/
================== 6 January 2012 =====================
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Technical Architecture Group Teleconference
06 Jan 2012
See also: [2]IRC log
[2] http://www.w3.org/2012/01/06-tagmem-irc
Attendees
Present
Dan Appelquist, Jonathan Rees, Ashok Malhotra, Noah
Mendelsohn, Larry Masinter, Tim Berners-Lee, Yves Lafon,
Peter Linss, Mark Nottingham (invited guest for morning
session)
Regrets
Henry Thompson
Chair
Noah Mendelsohn
Scribe
Jeni, Dan
Contents
* [3]Topics
1. [4]Mime and the Web (with Mark Nottingham)
2. [5]Web protocols: HTTP Futures & SPDY (with Mark
Nottingham)
3. [6]Redirection semantics
4. [7]Redirection of POST and User Intervention
5. [8]Identifier Overloading
6. [9]Issues for Jeff
7. [10]Action Item Review
8. [11]CA Issue
* [12]Summary of Action Items
_________________________________________________________
Mime and the Web (with Mark Nottingham)
(introductions)
mnot: chairing HTTPbis, liaison from IETF to W3C
... "Web Linking" spec is an attempt to respecify Link: header
... lots of requirements for link-based protocols
... and typed links
... for example in HTML rel="stylesheet"
... Atom used link relations as well
... and there's a registry and an XML syntax for links and link
relations
... eg copyright statements, next/previous links
... wanted to revive Link: HTTP header
... to convey links in headers rather than body of the message
... HTML had linking, Atom had linking, and they weren't matched
... RFC provides a model that you can serialise in various ways
... needs a context, a type, and a target
... (which you could map to RDF if you wanted to)
jar: is that called out anywhere?
mnot: not particularly
... and so to registration
... link types being a particular example
... we felt there should be one registry
... the HTML groups wanted to use a wiki
... we felt that was too freeform, and noisy
... and could lead to changing semantics in a backwards-incompatible
way
... so we tried to address their concerns in the registry
... but they (the HTML group) didn't feel it was an appropriate
thing to use
... time passes
... the link relation registry is a lot of work to maintain
... every interaction requires discussion with the author
noah: the overhead is high but the rate isn't high
<timbl>
[13]http://www.iana.org/assignments/link-relations/link-relations.xm
l
[13] http://www.iana.org/assignments/link-relations/link-relations.xml
mnot: we would like to see a higher rate, but can't support it at
that overhead
jar: this is the same issue in journal publication
mnot: the question is whether value is being added
... we have a common system of expert review in IETF
... the underlying question is what is registry for?
... some people see it as a gating function: if it's not registered,
then it won't be used
... to prevent stuff that is bad from being used
... but the gating function makes people less likely to use the
registry
noah: so people go ahead and do it anyway, without using the
registry
mnot: we discovered this was common to registries for media types,
link relations, HTTP headers and URI schemes
... talked to Ned Freed
... who runs the media type registry
... saw that people were misinterpreting the function of registries
... actually the registry should reflect what is in use
noah: is there a middle ground?
mnot: for a lot of people, registry is just a barrier to get past
... especially because the work is all up-front
noah: no one says they would deploy more quickly if it was
registered
mnot: there's no benefit in the registration
masinter: it just exposes you to criticism
timbl: text/n3 is an example for me
... the best practice was to use Turtle, but people would use
application/rdf+xml because it was registered
mnot: people who pay attention to standards might care
timbl: getting media types into Apache does have a big effect
mnot: Apache put lots of stuff in, it's driven by the market
timbl: So Apache mime .types works and iana doesn't -- why doens't
IANA use the same process as Apache?
mnot: we want to create a virtuous cycle, for example with
machine-readable registry data
... for example for link relations that lets you add attributes to
registry entries
... so that a browser can see whether it's a link that could be
followed
... or archived and so on
... so if I come up with a new link relation, and it's treated in a
generic way
... the browsers can have a more automated process for adding
semantics
noah: we have to give Jeff Jaffe early warning about potential
larger issues
... it seems that there's a bigger story here about market forces
driving standards
mnot: what we want to do is make IANA a suitable place for these
registries
... which is complex, but worth trying
<Zakim> JeniT, you wanted to ask whether browsers will really pick
up on this metadata automatically
<JT:/cite>> You spoke of browsers automatically going to registries
and doing something useful with what they find. Do you have actual
experience with people being willing to do that? I haven't seen it
in my work on RDF.
<mnot:> My understanding is that Ian Hickson and Anne van Kesteren
felt this would be very helpful in the registries
<mnot:> I think one aspect of the value is during the browser
development and QA process, where those building a browser can pull
from the central registry, do some work to integrate with their
browser or tests, and then deploy.
<larry:> It's almost as if you want to have so much in the IANA
registry that you would never want to use it real time.
<mnot:> Hmm. Probably if you do things real time there will be
attack vectors.
<HTJT:cite>> And the process for staying in sync is to do a pull
every time they release the browser.
<mnot:> Yes, but they are on very quick update cycles now
<mnot:> Seems unlikely we'll see people automatically supporting new
media type handlers.
<Larry:> I think I've seen things where apps on phones can register
for URI prefixes
noah: has anyone looked at associating some a Javascript handler
with eg a link relation
... which the browser could then use to handle likes of those types
mnot: that's a bit speculative
... we want to focus on a virtuous cycle where code can use the
information in the registry
timbl: ontologies are like this
mnot: the registry needs to reflect what's in use, not how things
should be
... you need to make the barrier to entry low
... and iteration rapid
... to incrementally improve the entry
noah: it sounds like you're going very far over to there being no
barriers
... towards something completely open like a wiki
... I think it's more a shift towards that rather than going
completely to the extreme
mnot: the problem is that expert reviewers have a tendancy to try to
maintain quality and prevent new entries going in
mastinter: registries have rows and columns
... there's a column with 'review status' which people making the
entry can't change
... which can be 'unreviewed' or 'unacceptable'
<noah> Philippe le Hegaret joins us in the meeting room
mnot: yes, we've talked about having a range of statuses
... it comes down to having a process to manage the registry
... if you have a wiki, that's going to happen because there are
going to be conflicts within the community
... and there will be cases where you can't tell what to do, where
there are two implementations using the same name with different
semantics
<mnot> [14]http://www.w3.org/wiki/FriendlyRegistries
[14] http://www.w3.org/wiki/FriendlyRegistries
mnot: so we started having meetings within IETF, and have set up a
mailing list
... FriendlyRegistryProcess
... for example, turning the expert reviewer into more of a
community moderator than a gatekeeper
... for example, Apple is using a bunch of URI schemes which aren't
currently in the registry
noah: should one size fit all?
... it might be different for URI schemes than for link relations
... it might be that it has different technical consequences to
introduce new URI schemes
timbl: there should be very few URI schemes added, but a larger
number of media types
... because that's how the system is designed
... about switching to a model where you register what exists
... that does avoid conflict
... I would support a very open bug tracking system on the registry
... suppose someone registers something, and that automatically
opens up a bug tracker for them, so people could make comments on it
mnot: yes, we talked about this
timbl: not for the process of the registration, but to register
technical issues
mnot: we talked about having a wiki page for each entry
... there's a hidden bug tracker for IANA
timbl: tracker for issues about the entry
mnot: we do want to support third parties to register protocol
elements
... so if a company hasn't registered something, others can do it
instead
timbl: ideally you want that to go through very fast, so that there
can be feedback on the entry
mnot: and that comes back to the different statuses on the entries
... to label that something has technical or legal issues
... we want to order the entries to make the good ones more
prominent
(moving on to next steps)
mnot: we've had some discussions on this within IETF for the last
year or so
... Ned is doing a revision of [some RFC]
... and revisions of link relations RFCs
... and the message header registries RFCs
... and another document to distil this discussion into "how to set
up a registry"
masinter: I have done some work on that
mnot: there are things that IANA can do without updating RFCs
jar: are they cooperative?
<masinter> in
[15]http://www.w3.org/2001/tag/2011/12/evolution/Registries.html
[15] http://www.w3.org/2001/tag/2011/12/evolution/Registries.html
mnot: yes, they need the IETF to take the initiative and they are
resource constrained
... and we've talked about having Wiki pages for each entry
... this is a long term project
... the mailing list is the main contact place
... I am the main contact
masinter: a little W3C resource would make things go a lot faster
<Yves>
[16]https://www.ietf.org/mail-archive/web/happiana/current/maillist.
html
[16] https://www.ietf.org/mail-archive/web/happiana/current/maillist.html
<noah> [17]https://www.ietf.org/mailman/listinfo/happiana
[17] https://www.ietf.org/mailman/listinfo/happiana
timbl: is anyone within the TAG following it?
yves: I am on the mailing list
masinter: I am as well
noah: I'm assuming Larry is our point person on this
masinter: I need help
... I haven't been able to write this up in a way that was
understood
... we need some resources to make some things happen
... and I don't know how to actually make this happen
noah: what aspects of this should be done within the TAG?
... perhaps we could just free up some of Larry's time to work on
it?
mnot: we would appreciate your review of what we have written up on
the wiki
noah: so we should have one or two TAG members review it and frame a
way forward
timbl: we can register our enthusiasm and encouragement
<masinter> the main problem i see is that current and previous TAG
findings might be in conflict with the new directions being pursued,
and that the TAG is more of a bottleneck than a group that can help.
timbl: on TAG ground, each registry is a piece of the architecture
of the web
... the TAG could dive into how much damage there is when someone
makes a new URI scheme
<masinter> i prepared some material on this subject in the slides i
put together for this meeting and was unable to get agenda time to
present it
noah: arguably it's not a registry discussion
timbl: for a given registry, the TAG might want to point out the
damage done by a badly designed scheme
mnot: so long as that doesn't prevent entries going into the
registry
... even if the bad ones are highlighted with blinking 'Evil' icons
noah: should we actually do this (about URI schemes)
... is there any new work that we should kick off now?
... also, does it help to have a formal TAG resolution to support
this work?
mnot: probably not now, I just wanted to socialise this with you
noah: we're very interested in this, and we have been looking at
this in an ongoing way, and we will keep on doing so
Web protocols: HTTP Futures & SPDY (with Mark Nottingham)
noah: a few months ago, it started to look as though SPDY was
expanding beyond Google
... we had a technical discussion at TPAC 2011
... it looks like there could be major changes to the web due to
innovations such as SPDY
... doing everything through SSL
mnot: the SPDY guys have strong dislike for transparent protocols
(?)
noah: and there's a privacy angle here
... we haven't for a while looked at this level of web architecture
... we want to decide if this is an area where the TAG needs to do
serious work, what the goals are, who is going to do it
... and top priority is to have discussion with Mark
... we could look at Yves email
[18]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html
... to which there were some responses
[18] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html
mnot: I would like to talk for 10 minutes and then have discussion
mnot: we started HTTPbis about 4 years ago
... the idea was to revise HTTP because we now had 10 years of
implementation experience of RFC2616
... there was a lot of knowledge locked up in people's heads that we
wanted to get written down
... with quite a tight charter
... not a new version of HTTP, no extensions, just fixing the specs
... we're almost done
... we have about 11 design tickets open, many of those will be
closed really soon
... the editors are Yves, Roy Fielding and Julian Reschke
... we wanted to make something solid for 10-20 years
... meanwhile implementers have come up with SPDY, mostly for
performance
... addressing a number of issues with HTTP and its serialisation
over TCP (?)
... the Google guys have an implementation, both server and client
... Patrick McManus has done implementation in Firefox, also HTTP
pipelining
... he's found it easier to do SPDY than HTTP pipelining
... it should be in Firefox 11
timbl: so it hasn't actually gone to market
yves: Opera also provided feedback on pipelining
mnot: the main problem with pipelining is that you have to use a lot
of heuristics about when you can use pipelining
... within pipelining, requests can block
noah: but in SPDY, you can interleave?
mnot: yes
... Mike probably also covered Jim Getty's concerns about buffer
bloat
... I did an implementation of HTTP pipelining and SPDY in Python,
and SPDY was much simpler
... Amazon is using SPDY in the Kindle now, or are in process of
doing so
... Daniel Stenburg, behind curl, is implementing a C library for
SPDY
noah: in Amazon Fire, there's the split browser, do they also use
SPDY in requests out to the wider web?
mnot: I'm not sure
... Google is practically the only server implementation
... GenX has just announced implementation too
... I noticed this momentum a couple of months ago
... it's not just Google any more
... I've had a lot of private discussions with various people, and
everyone is very very interested in tracking/implementing this stuff
... the market is choosing with its feet
... the question is whether this gets done within a standards
organisation, with interactions with other implementers than Google
... it seems like it's necessary to take this work on
noah: we asked Mike how he felt about that, and he seemed to be keen
on standardisation
mnot: we've had an ongoing discussion about standardisation
... the team understands it will involve
... there's a tension between getting to market and for everyone
else to have their concerns met
... I've been talking to people about this and putting together a
proposed charter for this work
... HTTPbis is just finishing up, and I don't want to distract from
that
... but time is important for the SPDY guys too
... I've been talking about rechartering the HTTPbis group to work
on HTTP evolution
... perhaps not saying that we should start from SPDY
... Roy has been working on WAKA (?)
... but it's not been made public
... looking at that and SPDY, I think they are conceptually very
close
... continuing the HTTP 1.1 revision
... we have split up HTTPbis into components
... SPDY only requires changes in one of those components
... Part 1 of HTTPbis
timbl: what's SPDY's relationship to HTTP headers
mnot: it compresses them, but it uses the HTTP headers
... there are some headers that aren't needed in SPDY
... I used the same API as for HTTP when I did SPDY implementation
... there might be other tweaks, but SPDY would be a superset
noah: SPDY would multiplex on one connection rather than having
multiple connections
timbl: people have assumed HTTP would be replaced in the future
... and therefore HTTP URIs would be replaced by other things
... but the HTTP namespace can be persistent even if the protocol
works
... calling it HTTP 2 might be useful to avoid that confusion
mnot: questions about spdy: URIs have always been resisted
noah: there's an interaction with HTTPS and TLS and certificates
... there are differences between http: and https: URIs, https: uses
certificates and http: don't
mnot: there's a set of issues around TLS, about whether the CAs are
a good source of truth
noah: how far has the discussion gone?
mnot: core people in SPDY feel that using TLS by default would
improve the web
... other people don't agree
noah: there are a bunch of issues with TLS, one of which is to do
with name resolution
... it means I have to get a certificate for my server
mnot: right now SPDY says you will deploy over TLS
timbl: what about certificates from DNS Sec?
mnot: there's a bunch of work on that, yes
... which sometimes gets governments involved
... the question is whether we can leverage it in time for SPDY
... in the IETF people are uncomfortable with the 'S' in 'HTTPS'
... that there shouldn't be a flag in the URI that indicates
security
... but the browser people like it
... the concept of the origin server means having 'S' is really
useful
timbl: but you may want to add more constraints, not just the 'S'
bit
mnot: the question is about whether you should have it in the
identifier
timbl: in RDF it's a real pain
... moving to HTTPS wreaks havoc with links
... I've wondered about using POWDER to put a label on the home page
... to say that anything that starts 'https' should have the same
identity as if you had 'http'
... like a canonical link
mnot: I have a format for describing canonical URIs for a domain
... but this is a real tangent
plinss: my understanding is that TLS and SPDY are orthogonal
mnot: the way it's currently defined, TLS and SPDY are bundled
... I think there are cases where you don't want to use it
masinter: if you start with a HTTP URL, does it use SPDY?
mnot: it will upgrade the connection
... for an HTTPS URI, there's another negotiation
noah: Google is using SPDY by default for HTTPS URIs
mnot: using TLS NPN is an uncontroversial use
... OpenSSL isn't going to support it until the next version
noah: how does this affect CDNs such as Akamai?
mnot: they will need to support it
... it used to be hard because you need an IP per certificate
... now there's TLS SNI extension (?) but it's not perfectly
deployed
... which is the Host header for TLS
... so that you can have 100 hostnames on one IP address
noah: how does the HTTPS work through something like Akamai?
mnot: they will need to know your private key or generate one for
you
... one of the metrics of a tracker is rapid changing of
certificates
... back to the charter
... the new bit is working on HTTP 2.0 with the goal of improving
performance
... more efficient use of network resources
... deployment on today's internet, using IPv4 and IPv6
... maintaining ease of deployment
... and balancing that with reflecting modern security requirements
... there's a new requirement in IETF, any protocol has to have
"mandatory to implement security"
... it has to have an adequate security mechanism that
implementations must support
... the idea is to recharter the working group
... starting work around end of March
... which means HTTPbis needs to have been substantially done by
then
... I'm hoping the HTTPbis review will be fairly straightforward
... because it's already gone through so much review
... particularly because we're not introducing new things
... we would put out a call for proposals for a starting point, one
of which will be SPDY
... there's a lot of running code out there for SPDY
... the obvious question is why recharter the HTTP WG to do this,
rather than creating a new one?
... I think it's worthwhile because we have a good working pattern
and an established community
... we've talked about Mike Belshe and Julian Reschke being editors
on the spec
timbl: the WG might have to be warned about being open to new people
mnot: we have almost complete coverage of HTTP implementers
... this needs to be a worthy replacement for HTTP 1.1
... we've got firewall, client, library, intermediary, embedded guys
... if I can't get it through, we'll charter a separate WG
... this is obviously of interest and importance to the TAG
DKA: in naming it HTTP 2.0, isn't there a danger that the scope gets
expanded?
mnot: yes, we've dealt with that in HTTPbis
... and the charter is written in a focused way
... to prevent that
<masinter>
[19]http://masinter.blogspot.com/2011/12/http-status-cat-418-i-teapo
t.html
[19]
http://masinter.blogspot.com/2011/12/http-status-cat-418-i-teapot.html
timbl: looks good....
… I think it's good to bring it out under a http 2.0 banner -
<Zakim> timbl, you wanted to ask about the extensibility point of
HTTP headers in SPDY
… I think the fine line between directly taking on board existing
work and allowing people to make arbitrary changes to existing work
that runs is one I understand...
jar: Jim Gettys gave us a presentation on buffer bloat, and I
wondered how this related
... is this radical enough?
... he was talking about self-authenticating content and things
mnot: this enables a solution to buffer bloat
... it will use TCP better
... particularly when people pull content back onto single domains
rather than sharding
... right now the interest is in maintaining the client/server model
noah: I think Jim spoke sympathetically about SPDY
timbl: back to the HTTP level, I've been trying to push rather than
a content-addressable system, you might be able to go back to the
referer of a link to get information
<masinter> there's a possibility that the two go together: SPDY for
interactive, dynamic, personal, private traffic, and content
addressible networking for public, cachable, distributed content.
timbl: for example, to bootstrap into a peer-to-peer system
mnot: have you seen Metalink?
... a new link relation called 'duplicate'
mnot: an exact byte-for-byte duplicate for a given representation
<masinter> [20]http://tools.ietf.org/html/rfc5854
[20] http://tools.ietf.org/html/rfc5854
timbl: the idea is to cache everything you link to to two levels
mnot: there's a lot of interesting things to do in caching
... the quality of cache implementations is something that bothers
me
<masinter> pursuing both simultaneously would mean you wouldn't have
to rely on caching
mnot: I'm concerned around the parallel tracks of caching, for
example with AppCache
timbl: caches tend to be temporary; this idea is a mutual-aid system
<masinter> wonder if some of hte weaker parts of HTTP could be left
behind
timbl: you'd build it into Apache and the client, and you'd be able
to get data from parts of the network that were cut off
masinter: there's lots of HTTP that isn't very good, that you could
leave behind if you're not encapsulating all of HTTP
... and others that you could promote
... for example caching based on time stamps vs on ETags
... also HTTP uses the same transport for dynamic, private,
interactive content as for large, public, static content
... right now we use Vary headers to distinguish between them
... maybe there's some other way that would be more reliable
mnot: I'm nervous about that, because how far do you go? we don't
want two separate protocols really
masinter: you only split things off when they really don't fit
mnot: I'm not convinced they don't fit
noah: you can use a new URI scheme, that requires an early
commitment
DKA: do you know of any mobile implementations of SPDY?
mnot: I don't know of any, but it looks like a tempting target for
mobile, because the connection is used more efficiently
... it looks like a real win, and you can use SPDY in the proxy
noah: what about battery drain on doing encryption?
<masinter> look at SPDY android
mnot: people claim TLS is not that hard; it depends on cipher
strength
... I consider TLS and wire protocols to be separate
DKA: the major battery drain aside from the display is usually the
radio
noah: I propose that this is put on the alert list for Jeff
... it sounds as if the right people are working on this in the
IETF, but I can't see that we need to parachute in
... I think we should have a contact point in the TAG, and monitor
progress
mnot: I would add that this is likely to be discussed at Paris in
late March
noah: Yves, you've traditionally had actions on this
yves: I will follow this for W3C anyway
<noah> close ACTION-640?
<noah> close ACTION-640
<trackbot> ACTION-640 Frame F2F discussion of SPDY/HTTP futures
closed
yves: my email also touched on WebSocket
... most of the communication on that won't use URIs
<noah> ACTION: Yves to prepare telcon discussion of protocol-related
issues, e.g. Websockets/hybi (but not SPDY)Due: 2012-02-21 [recorded
in [21]http://www.w3.org/2012/01/06-tagmem-minutes.html#action01]
[21] http://www.w3.org/2012/01/06-tagmem-minutes.html#action01
<trackbot> Created ACTION-658 - Prepare telcon discussion of
protocol-related issues, e.g. Websockets/hybi (but not SPDY)Due:
2012-02-21 [on Yves Lafon - due 2012-01-13].
<noah> ACTION: Yves to track IETF efforts on HTTP 2.0 & SPDY Due:
2012-03-20 [recorded in
[22]http://www.w3.org/2012/01/06-tagmem-minutes.html#action02]
[22] http://www.w3.org/2012/01/06-tagmem-minutes.html#action02
<trackbot> Created ACTION-659 - Track IETF efforts on HTTP 2.0 &
SPDY Due: 2012-03-20 [on Yves Lafon - due 2012-01-13].
noah: we need to talk about things for Jeff
<mnot> [23]https://datatracker.ietf.org/wg/dane/charter/
[23] https://datatracker.ietf.org/wg/dane/charter/
noah: CA system
... perhaps other security aspects
... perhaps how to deal with the TAG issues
... action item review
<masinter> you might want to also look at the long list of dead TAG
findings
Redirection semantics
<masinter> [24]http://www.w3.org/2001/tag/findings
[24] http://www.w3.org/2001/tag/findings
mnot: issue with fragment identifiers and redirections
<masinter> and also "Approved findings" we no longer believe in
mnot: HTTP doesn't say which one gets precedence
... we talked with you and at the time we said, 'there's not good
interop here'
... so didn't say what to do
... we didn't cover when the request has a fragid and the redirect
location doesn't
... since then, we've tested implementations
... and there is good interop
... from a webarch standpoint would the TAG be concerned if the
combination of fragid and redirect were determined by HTTP rather
than media type dependent?
noah: ht might have input on this
mnot: we need an answer soon because we want it in HTTPbis
... my opinion is that from an implementation standpoint it is bad
to make it media type dependent
<noah> noah: would it be convenient for you to send an e-mail asking
the TAG to consider this question? If so, i'll use that to trigger
telcon discussion.
<noah> mnot: Fine, no problem, I'll send the note.
mnot: making it the same for everything is significantly less
complex
<noah> Recent TAG finding on fragment identifiers in Web
Applications
[25]http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
[25] http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
timbl: this is deeply connected with how the Semantic Web / Linked
Data worked
... to me it was a shock that you could redirect to something with a
fragid in it
... how common is it to have that kind of redirection?
jar: Dublin Core
<mnot> HTTPbis bug:
[26]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295
[26] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295
plinss: I think this is going to become more common as you have
fragments on video/audio
jar: URL shorteners
timbl: do you have RDF test cases?
mnot: no
... there's strong interop amongst the implementations we've checked
timbl: adding the fragid to the redirected URI isn't a problem
jar: +1
... I think it's implied by RFC3986
masinter: one way or the other it has to be made explicit
mnot: I'll send noah an email and we'll take it forward
jar: I weighed in on this before and didn't get any reaction
<noah>
[27]http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
[27] http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
noah: the TAG did quite a bit of work in the last year on web
application state and fragid semantics
... that might be of interest
<mnot> [28]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238
[28] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238
Redirection of POST and User Intervention
mnot: most of the browsers redirect automatically
... because the users don't know whether it's safe to redirect
across domains
... so perhaps we should remove that requirement from HTTP
... but it's a fairly big change
... but it doesn't reflect reality
timbl: has anyone suggested any improvement?
... currently this is a fairly huge hole
mnot: there are so many ways to generate requests to multiple hosts
in browsers
... they are moving away from making security visible
... because it doesn't meaningfully improve security
timbl: so it's a cross-domain issue?
mnot: we could phrase the requirement be about cross-domain
redirects
<jar> n.b. the discussion is of 301 redirects specifically (with
unsafe methods such as POST)
mnot: we can't make incompatible changes in HTTPbis unless it's a
serious security issue
... and this isn't serious
... right now this applies same-domain
timbl: relaxing it for same-origin makes sense
mnot: one browser prompts in a couple of specific situations
... but most already ignore the requirement
Identifier Overloading
mnot: Sec- prefix on HTTP headers
... adding semantics to an identifier brings problems
... how do you add more prefixes?
... X- for experimental, then it gets adopted
... (that is close to deprecated)
noah: how you support decentralised extensibility + smooth evolution
from experimental to common is something the TAG could look at
... I'm not sure we can do that well in the TAG
mnot: we're covering it a bit in happiana
jar: registries, decentralised extensibility and persistent naming
are all closely related
noah: it's more about whether the community can see progress
(wrapup)
Minutes integration: Wednesday : Yves ; Thursday: JAR ; Friday : Dan
<JeniT> "we need to talk about things for Jeff
<JeniT> CA system
<JeniT> perhaps other security aspects
<JeniT> perhaps how to deal with the TAG issues
Issues for Jeff
Noah: Jeff has asked the TAG to alert him to big controversies and
threats to the Web that he might not know about.
… I have ACTION-568.
<noah> ACTION-568?
<trackbot> ACTION-568 -- Noah Mendelsohn to draft note for Jeff
Jaffe listing 5 top TAG priorities as trackable items. -- due
2012-01-03 -- OPEN
<trackbot> [29]http://www.w3.org/2001/tag/group/track/actions/568
[29] http://www.w3.org/2001/tag/group/track/actions/568
… We are overdue on this action.
… We need a plan that will close in a few days for an initial note
to Jeff.
… This says "5" but I don't think 5 is a magic number.
Yves: 20 items is too many.
Noah: Let's see what we have.
<Yves>
[30]https://lists.w3.org/Archives/Member/tag/2012Jan/0001.html
[30] https://lists.w3.org/Archives/Member/tag/2012Jan/0001.html
Noah: [outlines above list]
[discussion on death of protocols]
Yves: this is the list discussed during f2f in Edinburgh.
Noah: two more - one is a think Dan asked for: should app cache vs
app packaging be on the heads-up list for Jeff?
… Noah: I think the only reason to highlight this is if it's not
adequately highlighted in the workshop report.
Dan: risk is more generally apps vs web.
Jenit: which we already have.
Ashok: [asks for clarification]
Noah: We need descriptions of threats or potential threads to send
to Jeff - between a paragraph and a short page.
... if people like the list, let's look at each one.
JeniT: should the registries and IANA stuff get moved into the
bigger section?
… especially rdfa vs html link relations.
Yves: this is not new.
… if there will be more issues based on this - e.g. registries being
misused - then yes.
Noah: If we think e.g. Happiana will rise into a key issue then we
might raise it to Jeff.
… we could make it an addendum to the main list.
Yves: "there have been issues - there will probably be more issues -
there is this work happening (IANA)"
JAR: … and a small effort by w3c staff could help.
Noah: Jeff asked me for [major issues] that might hit him.
JeniT: Along those lines, the section on SPDY and http - this feels
less like something that we need to be mega-concerned about.
Noah: I think http is a major part of the Web - we should [outline
the key topics] and then say "we have been working with e.g. mnot
about it and this is what's happening..."
... let's go through the things Yves has drafted on each of these.
... first - "Specifications with the Same Scope…"
... Question I would ask - you talk about RDFa
Yves: With the evolution of different stacks, they step on other
technology stacks' feet. It's difficult to predict that.
Noah: If we know of anything similar to microdata/rdfa then we
should alert Jeff.
Yves: another one might be xpath and css selectors.
Noah: is that resolving?
Yves: I think it's more or less under control.
JeniT: We can say - following discussion with plh over html.next
there seem to be areas e.g. speech but our advice from him was that
this wasn't going to cause problems.
<noah> I think we need to tell Jeff where the ones we know about
stand, and where there are others that are likely to be problems. I
hear Yves saying: microdata/RDFa and CSS/XPath are probably headed
for resolution, but these things will keep happening.
… the two things that could be hot topics look like they are being
handled in the right way.
Noah: I think this should come out under my signature on behalf of
the TAG.
… I feel sufficiently informed on this one to take a cut.
<noah> Current draft: The TAG, as part of its review activity will
continue to monitor such
<noah> issues.
<noah> Suggested: The TAG, as part of its review activity will
continue to monitor such
<noah> issues.
Yves: last para where I said TAG is reviewing what is going on -
even if we don't know an issue that will happen in the next 6
months, in 2 months we might discover an issue.
<noah> issues and we will alert you to any that we think are of
particular concern.
Noah: Next one - "phone apps vs web apps"
yves: there are a range of issues here, and I'm not sure what the
crux is
<noah> YL: On the mobile, I'm not sure where the issues are.
DKA: there's things like URI schemes as well
<noah> DKA: It touches on things like vendor-specific URIs
DKA: and the "death of the web"
noah: can you send me an email?
<noah> ACTION: Dan to put together a bulleted list of items to go
into this category [recorded in
[31]http://www.w3.org/2012/01/06-tagmem-minutes.html#action03]
[31] http://www.w3.org/2012/01/06-tagmem-minutes.html#action03
<trackbot> Sorry, couldn't find user - Dan
DKA: give me an action to include APIs, packaging, offline use,
tools, monetisation
noah: if you could just draft a section?
DKA: ok
JeniT: do Facebook apps have similar characteristics?
DKA: the risk on mobile is apps running outside the browser, that
could be done in the browser
... due to artificial constraints
noah: widgets could run outside the browser, are they bad too?
DKA: this is where it's a grey area, because some people don't think
Widgets are the Web
... because they don't have addressability, for example
noah: outside the browser, forward/back navigation doesn't work
Ashok: are you thinking of Apps like iPad Apps?
DKA: it's definitely not just on the mobile phone, but this whole
class of device
... which uses the AppStore model
... which diminishes the importance of the web
... there are plenty of Apps that use web technologies
... but you can't use the web to download them, rate them, talk
about them etc
noah: I don't care about how I got the App but how you navigate out
of the App
yves: so what about the Chrome Apps?
... they are using web technologies
noah: if they're not linking to things on the web, then that's not
so good
yves: the threat is the creation of a walled garden
Ashok: +1
DKA: so Chrome apps run in the browser, but you can only download
them and use them in Chrome
noah: should we start each section with 'Threat:'
DKA: I think that's good: the threat is the browser is no longer the
way that people find and download information
noah: I'm want to focus on the risk/threat for Jeff
DKA: the death of the browser as the mechanism for accessing
information is the threat here
Ashok: in the browser, you can go to a different web page, and from
an App you can't
noah: many Apps do it, but they break
Ashok: this is a way to try to earn money
... to package something that you can then charge for
yves: not only for paying, but for editorial control: you can censor
things
DKA: why should you care? because you won't be able to see
information that isn't approved
... on the web I can find other points of view
noah: most of this is stuff Jeff will be aware of
... perhaps we want to say that he should be more worried about
losing this war
DKA: there are other things about debunking claims such as not being
able to charge for things
... or accessing location
... or accessing the camera
noah: in my experience geolocation doesn't work as well in the
browser as in an App
DKA: the macro-issue is the other functions that the web can't do
that Apps can
noah: vendors that support Apps may limit the ability of the
browsers to perform as well as the Apps do
... Apps have more complete access to the platform
... they lose flexible linking to other web pages
... the threat is that this remains attractive: the web hasn't blown
these things away
Ashok: if APIs on the phone are really that much better than the
APIs from the browser, that's a cause for concern
DKA: this is a complex area; highlighting some stuff on the
technical level would be a good idea
... let me draft something for Jeff
... to give him some ammunition
Noah: CAs
Yves: we should note that there is work going on in IETF and other
places to help...
JAR: Jeff ought to be mobilising w3c to work on this issue. This is
really important.
Tim: do you mean the first response or designing a better system?
JAR: I mean that it's not obvious where to go. We have some ideas...
... Issue is the trust structure...
Larry: In some case, if we don't figure it out then things won't
advance. But in this case if we don't figure it out then bad things
will happen.
Noah: I think we all agree.
... [wordsmithing the description]
… I'd like to see a paragraph "the practical effect of this is that
right now in certain countries users are being redirected to
fraudulent or improper copies of web sites - and that there is no
way to fix this in the immediate future."
Yves: not only redirecting - but people having the feeling that they
have a secure channel - and are not being spied on.
Noah: We should start with some brief war stories - Another example:
we have seen man-in-the-middle attacks to spy on politically
sensitive traffic...
Yves: as in Tunisia.
Noah: I think it's important to say: right now it's not obvious how
the technology will be deployed to stop this from happening.
Larry: There's a concern that this is an architectural flaw rather
than a set of isolated events. I share this concern.
Yves: I can redraft this.
... we might expand on what we mean by trust issues...
Noah: As long as the key points are up front.
JeniT: can we move that up to the top of the list?
Yves: I agree.
… add "red flag here."
Noah: Now - "SPDY and HTTP"
... The highlight here is - this is not a threat, this is something
you should be aware of …
Yves: there should be info at the bottom about the new efforts in
this space - the IETF httpbis rechartering.
Noah: I can redraft this based on what we heard from Mark
Nottingham.
... now "Death of Protocols"
... Can someone offer an example of this?
Yves: not many things are using web sockets in a way you could call
a "protocol." You just wait for data to come in without having the
framing of http...
… I'm not aware of any widely deployed app using web sockets though.
So it's a potential threat.
JAR: What's written here sounds right.
Noah: Can you give me an example?
Yves: e.g. the way communication was done in the past before TCP…
Noah: Why is that death of protocols rather than "death of
standardised interoperable protocols."
JAR: It's not the death of existing protocol. It's the death of the
process by which people publish their protocols.
Tim: It could be the birth of many protocols… Some of these may get
standardised, some won't...
JAR: The outcomes could be good. There were objections from within
IETF - for where the locus of documentation is. The traditional IEFT
way of doing things is to write a RFC, associated that with a port,
etc… Locus of communication is in IEFT and with the community around
that (e.g. those building firewalls, routers, etc…).
… what people are bothered by is - even though innovation is
supported - that it's disruptive.
Tim: if you run over TCP then you can tai end-to-end without talking
to people...
Noah: We were in a world where code was hard to deploy - now when
you go to a site and you want the weather, there's a chance the site
will send you the javascript code at that moment to speak that
protocol in order to get the weather. The code is mobile and hence
the value of standard protocols is greatly diminished.
Tim: issue Jonathan was raising - you used to take new protocols to
the IETF. But as long as you use an existing underlying protocol
then maybe you're safe now [for using these new protocols].
JAR: I think this is complicated.
… having to do with what layers in the stack have information about
the traffic. It used to be that routers were pretty simple. Modern
routers at wire speed are looking at things like the URI of an http
request and making decisions as the packet goes by...
… so it's a question of the locus of intelligent.
Larry: 20 years ago some guy at CERN wrote some code and I
downloaded it. The Web was deployed before there were any standards.
Noah: But tim didn't download a new copy of the browser every time
[he visited a web page.]
Larry: IETF and w3c have policy initiatives around security,
privacy, monitoring, ports, firewalls, etc… if there's never any
need to do protocol review or standardisation, how do we retain
those "community goods."
<noah> Possible message to Jeff: "As dynamically downloaded
JavaScript libraries are increasingly used to implement ad-hoc,
problem-specific protocols to access data, the usage and value of
Web technologies such as URIs and HTTP may be reduced."
Tim: e.g. quality review.
Yves: there's also the possible reuse of that protocol.
<jar> goes to the network as a commons
… if you're building something that gets widely used, and you're
using a protocol that's not published then people will have a hard
time reusing, etc...
Tim: I think it's better to come to Jeff with possible failure
scenarios.
… one failure mode : when you buy some home automation hardware, it
comes with its own Web server and runs its own protocol between the
client and the server and as a result you have vendor lock-in.
<noah> Possible message to Jeff: "As dynamically downloaded
JavaScript libraries are increasingly used to implement ad-hoc,
problem-specific protocols to access data, the usage and value of
Web technologies such as URIs and HTTP may be reduced, and we run
the risks that result from proprietary protocols. For example
{insert Tim's example of home toaster controller here}."
<JeniT> DKA: why is that any different now from in the past?
<JeniT> Yves: the difference is it's done in the browser
Tim: 2nd scenario : the toaster protocol might run on UDP so it
brings my home network down…
<Yves> it's not vendor lock-in, it's difficult upgrade path, no
review on what can go wrong (security etc...)
Tim: these are hidden protocols.
... What's breaking is the ability to construct things in a modular
way.
Noah: No this might be well structured but it's all very immediate.
Tim: What am I missing?
Noah: I'm saying the right model is - I'd like to use this on things
that don't support javascript, I'd like to be able to implement it
in multiple environments, etc...
Tim: What you're trying to do is to combine multiple components...
Noah: damage would be no freedom of choice in toasters.
<noah> TBL: Issues include vendor lockin, badly designed (no IETF
review)
Peter: This happens now...
JAR: difference is it goes through firewalls...
Peter: I think the main difference is that it's going to happen
within the web browser [with Websockets].
Tim: example of using libraries - standardisation will happen
between people making the libraries.
Peter: my fear is that people will use proprietary protocols so that
makes it more difficult for others to re-use data across the Web.
Larry: people have already been layering for decades proprietary
protocols over http. Maybe this is actually not a problem.
Noah: I'd like to take a look at where we stand. We're mostly there
except on this one.
…worth another 10-15 minutes?
JAR: What larry said.
<Yves> +1
JeniT: Yes I agree we shouldn't raise it to Jeff if we can't
articulate a problem.
+1
Noah: anyone who could offer something to discuss on a telecon.
... Ok - for the moment this will not be included in the note to
jeff unless someone comes forward with a proposal on the text.
... ok - Yves to draft something on "overlapping specs"; Dan to do
apps and web apps; Noah to do Certs (to be moved to top with red
flag); Yves to do SPDY; Protocols is out unless someone comes out
with text to discuss; all - please send me paragraphs and I will
integrate them.
<scribe> ACTION: Dan to draft text on apps and webapps [recorded in
[32]http://www.w3.org/2012/01/06-tagmem-minutes.html#action04]
[32] http://www.w3.org/2012/01/06-tagmem-minutes.html#action04
<trackbot> Sorry, couldn't find user - Dan
<noah> ACTION: Noah to integrate input from DKA and Yves for note to
Jeff, and draft section on CA Due: 2012-10-17 [recorded in
[33]http://www.w3.org/2012/01/06-tagmem-minutes.html#action05]
[33] http://www.w3.org/2012/01/06-tagmem-minutes.html#action05
<trackbot> Created ACTION-660 - Integrate input from DKA and Yves
for note to Jeff, and draft section on CA Due: 2012-10-17 [on Noah
Mendelsohn - due 2012-01-13].
<noah> ACTION-660 Due 2012-01-17
<trackbot> ACTION-660 Integrate input from DKA and Yves for note to
Jeff, and draft section on CA Due: 2012-10-17 due date now
2012-01-17
[end of discussion on Jeff note]
<noah> [34]http://www.w3.org/2001/tag/group/track/actions/overdue
[34] http://www.w3.org/2001/tag/group/track/actions/overdue
ACTION-344?
<trackbot> ACTION-344 -- Jonathan Rees to alert TAG chair when CORS
and/or UMP goes to LC to trigger security review -- due 2012-01-01
-- OPEN
<trackbot> [35]http://www.w3.org/2001/tag/group/track/actions/344
[35] http://www.w3.org/2001/tag/group/track/actions/344
JAR: Answer has been "Ok - explain to users of the spec how to be
careful."
Action Item Review
<noah> ACTION-480?
<trackbot> ACTION-480 -- Daniel Appelquist to draft overview
document framing Web applications as opposed to traditional Web of
documents -- due 2011-07-05 -- OPEN
<trackbot> [36]http://www.w3.org/2001/tag/group/track/actions/480
[36] http://www.w3.org/2001/tag/group/track/actions/480
<noah> close ACTION-480
<trackbot> ACTION-480 Draft overview document framing Web
applications as opposed to traditional Web of documents closed
ACTION-601?
<trackbot> ACTION-601 -- Noah Mendelsohn to document in product
pages wrapup of HTML5 last call work, leading to HTML next review --
due 2011-12-27 -- OPEN
<trackbot> [37]http://www.w3.org/2001/tag/group/track/actions/601
[37] http://www.w3.org/2001/tag/group/track/actions/601
<noah> action-601?
<trackbot> ACTION-601 -- Noah Mendelsohn to document in product
pages wrapup of HTML5 last call work, leading to HTML next review --
due 2011-12-27 -- OPEN
<trackbot> [38]http://www.w3.org/2001/tag/group/track/actions/601
[38] http://www.w3.org/2001/tag/group/track/actions/601
Noah: I believe I did this - can I close this action?
<noah> close ACTION-601
<trackbot> ACTION-601 Document in product pages wrapup of HTML5 last
call work, leading to HTML next review closed
<noah> ACTION-645?
<trackbot> ACTION-645 -- Noah Mendelsohn to take off draft
indication and put dates on URI Definition and Discovery Product
page -- due 2011-12-29 -- OPEN
<trackbot> [39]http://www.w3.org/2001/tag/group/track/actions/645
[39] http://www.w3.org/2001/tag/group/track/actions/645
<noah> close ACTION-645
<trackbot> ACTION-645 Take off draft indication and put dates on URI
Definition and Discovery Product page closed
CA Issue
Noah: You could make a case this is a security problem that the TAG
should be involved in in an ongoing way. Seems like a really
important development to me. We should be involved.
Ashok: It doesn't look like our's to tackle.
JAR: Everyone should have awareness of, especially us.
Noah: If we thought the Web was going to crumble then we should go
to w3c membership and say that.
JAR: at least 3 different solutions have been put forward and it's
not clear [which is best].
<jar> [40]https://www.youtube.com/watch?v=Z7Wl2FW2TcA I think
[40] https://www.youtube.com/watch?v=Z7Wl2FW2TcA
JAR: e.g. "SSL and the future of authenticity"
... …and a third one.
JeniT: is there anything useful we can say to people developing web
applications with SSL about what they should or should not be
doing...
<jar>
[41]https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-
against-google
[41]
https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google
Yves: i think it's more for users - that they should rely on more
than just the ssl padlock...
Noah: How urgent is this?
Yves: If it's easy enough to divert DNS and create fake
certificates...
JAR: whole part of the video [above] is that it's very easy to do
this.
Yves: The first issue is that users should know that even if they
think it's safe it might not be safe… E.g. in some countries even if
they are using SSL then it might not be safe. In that case, they
should be using secure VPNs…
Dan: Isn't someone like EFF already providing that advice to end
users?
Yves: yes - EFF worked on https everywhere - working against fire
sheep - but this can give the sense of false security. You need a
bit of judgement.
… do you want to access sensitive data on a network with https if
you think you might be snooped on.
JAR: The point of the 3 proposed improvements is that thinks don't
have to be as bad as they are.
… question of how do you bootstrap trust...
… my intuition is tat it's important. Can we weigh in, review the
solutions, etc…
JeniT: Larry suggests we get someone to brief us on these solutions.
JAR: What can w3c do?
<masinter> Mark also pointed at
[42]https://datatracker.ietf.org/wg/dane/charter/ effort in this
area
[42] https://datatracker.ietf.org/wg/dane/charter/
Tim: One intriguing thing - they use the same keys for webid, ssl
and ssh. If you use a key from one world in another world then you
won't have to have on trust system for each domain (web sites,
email, etc…).
… with some interoperability you could use a mixture of different
sources of trust.
… if you join a group (e.g. an employer), you can get some
certificates and a level of trust within that group.
… e.g. Csail - they sign their own certs, and you have to make
browser exceptions in order to use their [secure web sites].
<jar> timbl: trust interoperability
… there should be a better way to do that - when you join a group
you get trust associated with that groups including email certs, web
browsing certs, etc...
Dan: I think getting experts in would be good.
JAR: I think Harry Halpin could do that.
Ashok: I'll ask Harry to join us on a telco and talk to us.
[Next step: Ashok to ask Harry to join us and brief us on the
security proposals...]
JAR: I recommend watching the video.
<jar> Looking at Harry's email
[43]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0083.html
[43] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0083.html
Noah: One think I'd note is that web app sec as a narrower charter
than web security ...
Yves: yes - mostly to work on cors.
Noah: Security domain lead - should we talk to Thomas and ask him
"read harry's note - tell me what you're already doing about this?"
Dan: could we get Harry and Thomas on the next call to discuss?
<scribe> ACTION: Ashok to ask harry and thomas to join us on a
future TAG call. [recorded in
[44]http://www.w3.org/2012/01/06-tagmem-minutes.html#action06]
[44] http://www.w3.org/2012/01/06-tagmem-minutes.html#action06
<trackbot> Created ACTION-661 - Ask harry and thomas to join us on a
future TAG call. [on Ashok Malhotra - due 2012-01-13].
Summary of Action Items
[NEW] ACTION: Ashok to ask harry and thomas to join us on a future
TAG call. [recorded in
[45]http://www.w3.org/2012/01/06-tagmem-minutes.html#action06]
[NEW] ACTION: Dan to draft text on apps and webapps [recorded in
[46]http://www.w3.org/2012/01/06-tagmem-minutes.html#action04]
[NEW] ACTION: Dan to put together a bulleted list of items to go
into this category [recorded in
[47]http://www.w3.org/2012/01/06-tagmem-minutes.html#action03]
[NEW] ACTION: Noah to integrate input from DKA and Yves for note to
Jeff, and draft section on CA Due: 2012-10-17 [recorded in
[48]http://www.w3.org/2012/01/06-tagmem-minutes.html#action05]
[NEW] ACTION: Yves to prepare telcon discussion of protocol-related
issues, e.g. Websockets/hybi (but not SPDY)Due: 2012-02-21 [recorded
in [49]http://www.w3.org/2012/01/06-tagmem-minutes.html#action01]
[NEW] ACTION: Yves to track IETF efforts on HTTP 2.0 & SPDY Due:
2012-03-20 [recorded in
[50]http://www.w3.org/2012/01/06-tagmem-minutes.html#action02]
[45] http://www.w3.org/2012/01/06-tagmem-minutes.html#action06
[46] http://www.w3.org/2012/01/06-tagmem-minutes.html#action04
[47] http://www.w3.org/2012/01/06-tagmem-minutes.html#action03
[48] http://www.w3.org/2012/01/06-tagmem-minutes.html#action05
[49] http://www.w3.org/2012/01/06-tagmem-minutes.html#action01
[50] http://www.w3.org/2012/01/06-tagmem-minutes.html#action02
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [51]scribe.perl version 1.136
([52]CVS log)
$Date: 2012/01/13 17:54:01 $
[51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[52] http://dev.w3.org/cvsweb/2002/scribe/
Received on Saturday, 14 January 2012 04:06:45 UTC