- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 20 Jan 2009 13:39:21 +0100
- To: public-ietf-w3c@w3.org
- DRAFT -W3C/IETF liaison call
06 Jan 2009
Attendees
Lisa_Dusseault, IETF Applications Area Director
Thomas Roessler, W3C Security Activity Lead
Mike Smith, W3C HTML WG Staff Contact
Mark Nottingham, IETF Liaison to W3C and IETF HTTP WG chair
Dan Connolly, W3C liaison to IETF, HTML WG Staff Contact
Doug Schepers, W3C Web Applications WG Staff Contact
Noah Mendelssohn, W3C TAG member
Sam Ruby, W3C HTML WG co-chair
Philippe Le Hegaret, W3C liaison to IETF
Tim Berners-Lee, W3C Director
John Klensin, IETF participant (former Applications Area director)
• Topics
• Convene, take roll, review agenda
• HTML5 work and review, esp. WebSockets
• W3C/IETF liaison mechanics
• next meeting?
• "Origin Header for CSRF Mitigation" to IETF or W3C
• geolocation privacy
• IDNAbis, where are IRIs actually valid? HTML,
HTTP, ...
• content coding
Convene, take roll, review agenda
Chair: DanC
Scribe: tlr
agenda was accepted with a few ammendments
danc: draft minutes to w3c-policy, then public minutes a week later
HTML5 work and review, esp. WebSockets
danc: Sam Ruby effective yesterday is co-chair of HTML WG, with Chris
Wilson
... role was formerly played by DanC and MikeSmith ...
lisa: Met IanH recently, talked to him about the protocol ...
... he said he'd be interested in moving it out of HTML5 and into I-D
format ...
... he asked questions what should be in and out of that ...
... we occasionally do API specs in the IETF, if that's most
convenient ...
... probably it isn't, though ...
... the URL stuff is more complicated ...
... Ted Hardie volunteered to help with that ...
... he has a lot of experience in that space at the IETF ...
danc: glad to hear that Lisa and IanH are having happy interactions!
... this could go through individual submission process?
lisa: likely to be contentious as an HTTP-like thing at the moment
danc: mnot, you're co-chair of the HTTPbis WG?
mnot: not co, just chair.
... websockets has been mentioned, but not reviewed ...
danc: can live with individual submission?
mnot: if informational, then, well, informational
... if standards track, potential for problems ...
danc: suspected standards track
lisa: would prefer standards track if referred from W3C document
shepazu: assume necessary
mnot: lot more review required
lisa: unless there's complete happiness during IETF Last Call, ...
... should go through WG process ...
... don't have good process for figuring out entire IETF's consensus ...
<John_C_Klensin> On the other hand, putting some of these
controversial things into a WG tends to get them and the WG stuck
too :-(
danc: did discussion about WG formation get any air time at Dec IETF?
lisa: no. March in SF. Deadline coming up soon.
danc: so, for a BOF, the time to start would be now?
mnot: no, months ago
... maybe a bar BOF ...
lisa: This is an unusual case given that there's a community of interest
... around W3C and WhatWG, and already some work on it ...
... however, it's not actually yet an I-D ...
mnot: I-D by March 2; proposals due by Jan 19
danc: theoretically doable, but risky, plausible time frame another
IETF later
<John_C_Klensin> Actually, the BOF "last possible" cutoff is 9
February. See http://www.ietf.org/meetings/74/cutoff-dates.html
lisa: could ask HTTP WG whether they're interested and would want to
recharter to accept this draft
mnot: do not want to put current work at risk, timing is important. a
number of people have pointed out that there are parts of HTML5 where
it implies that it's not following IETF specs.
mnot: places where IETF standards are intentionally ignored ...
<shepazu> definitely wrt URLs
danc: intentionally violated, not ignored
... have this list that I hope includes all those
<Zakim> DanC, you wanted to introduce a list of parts of the HTML spec http://www.w3.org/html/wg/tracker/products/2
danc: HTTP and MIME is in here, I hope ...
<DanC> ISSUE-28 http-mime-override
<DanC> ISSUE-56 urls-webarch
danc: while I'm not chairing any more, I'm hoping ...
... issues process in this WG isn't the healthiest ...
... hope the WG to make decision about these ...
... for some of these requirement things, don't expect WG to take on
req ...
... ISSUE-62 websockets-- easier to say "not taking it on, since
... it's handled elsewhere" ...
<DanC> ISSUE-62 (edit) WebSockets
shepazu: SVG dropped this on the assumption that it would be done
elsewhere
danc: tend to be conservative about taking on requirements
sam: Would like to close some more open issues
danc: URLs, and, more, media types ...
... what I understand happened is Hixie spent 7-8 years trying to get
the browsers to follow the spec ...
... bug databases are full of him trying to get them to do this ...
... came to realization that any browser that fixed this was losing
market share ...
... economic incentives for browser developers worked the wrong way ...
... he threw up his hands and started spec'ing what actually happens ...
... e-mail to URI list, people said "implementations need to change" ...
... would like to see people being open-minded on both sides ...
jck: keep running into this with e-mail, and have ran into it for 30
years ...
... the right thing to do is a combination of 3 things ...
... 1. keep specs narrow. If necessary, generate set of rules that
make clear the difference between what should be produced or stored in
files versus what might reasonably be accepted in the interest of
robustness or flexibility (or just describe what people are accepting
in spite of, or in addition to, the specs).
... 2. explain, carefully and convincingly, the reasons why the
narrower approach is really better. In particular, explain, with
examples, why "accept anything you think you can interpret" or
"interpret from content rather than labels" will inevitably lead to
some errors of classification and will impede the ability to extend
things later in directions that can't be anticipated today.
... 3. Using (2), try to convince people who generate files or send
things to take the narrower approach when possible.
When there is a marketplace practice of flexibility of interpretation
(i.e., accepting anything and guessing), the first one who gets it
right is going to get squashed in the marketplace for providing a bad
user experience. But, once file naming practice has changed, those
who do it thereafter, especially with a "strict" option that can be
turned on or off may actually gain.
We need to design and move forward on the assumption that the amount
of content on the web, the number of users, and the number of
different applications of URIs and content type identifiers will be
larger in the future, enough larger to make everything out there today
a very small. And, because of that, it is important to attempt to
push on this earlier rather than later. Put differently, assuming
that we need to ratify and encourage existing practice, no matter how
pathological long-term, is not good for anyone concerned. And we do
need to assume that most of those content developers (and those who
create tools for content developers) are not acting out of malice but
because what they are doing "works" and that no one has ever explained
to them why some of their practices may cause them and their users
harm in the long run.
noah: content sniffing or URI comparison?
mnot: this covers a number of points (including those)
sam: img tag vs a href are different here
mnot: The arguments that Ian et al make are quite valid for browsers,
but not necessarily for a lot of other software that uses
URIs/HTTP/etc. Changing the specs to accommodate these broad cases
would be harmful for other uses (e.g., enterprise content management
systems). A potential solution that others have brought up in the past
is to leave the core specifications alone, but to document/specify the
deviations from them (i.e., how they're loosened) for browsers in a
separate spec.
shepazu: John's approach is sensible, but the number of people who
would need to be aligned to conform to the URI spec is large
... browsers and authors ...
... control not just how content is consumed through browser, also
have to control how it's produced ...
... it's not just automated content creation tools that would need
to be updated, as with email clients, but also people who hand-code
content ...
... this doesn't nullify what John said; another factor to consider
jck: absolutely; differ only in that it's desirable to get "control"
out of the vocabulary convince authoring tool people that bad practice
will sooner or later get them
shepazu: even web content tools -- creators of content often not
sophisticated
<Zakim> DanC, you wanted to bring up the url case of the chinese
search service and to say something about Ian's style
danc: web marketplace is maturing, not as mature as e-mail marketplace
... so many people involved that convincing folk to do things
differently requires TV commercials ...
... speaking at web directions north; influential developer
conference ...
... Ian's style -- pretty much to collaborate with browser
developers ...
... don't expect to change his style much, expect to recruit other
people to do things differently ...
... authoring community probably underrepresented, mobile community
perhaps too ...
... anybody who thinks XML is a good idea gets scared away pretty
quickly ...
<shepazu> XML/XHTML authoring community is underrepresented as well
<Zakim> noahm, you wanted to talk about servers vs. clients
noahm: additional community -- either the ISPs or hosting providers,
or the constellation of communities ...
... "put a file there, couldn't modify .htaccess" ...
... there are practical issues in here that come up periodically ...
... one of the concerns I had when looking at HTML5 is ...
... when you document a protocol or contract, document both sides ...
... HTML5 covers consumer, much less the authoring side ...
... question is: "what do we expect people to server" -- what's
correct, what's tolerated ...
... then want to say "for consumers, what do we want them to do,
what's correct, ..."
... would like to have at least one spec that connects sender and
receiver ...
... in HTTP caes, 2616 / 2616bis ...
... in HTML, would prefer to say what correct HTML is, move
accommodations into a separate layer ...
danc: neglected to mention Mike Smith's taking a stab at an HTML spec
<shepazu> noahm++
mike: what the spec attempts to do is similar to what Noah just
described ...
... focus on producer side of HTML ...
... scope intentionally narrowed to specify HTML documents ...
... no attempt to spec how documents are to be consumed ....
<rubys> http://www.w3.org/html/wg/markup-spec/
<MikeSmith> http://www.w3.org/html/wg/markup-spec
mike: structure and content model of html ...
MikeSmith: has no official standing in WG
... working on it, is still incomplete ...
<noahm> FWIW, I've never been really happy thinking of the
specification of the narrow/correct/whatever language as being
specifically for authors. I think it should be viewed as the contract
between all parties who choose to do things "right". It specifies what
a correct HTML document >is<, and to some degree, what it >means<, for
authors and consumers alike.
<noahm> If certain consumers need to provide interpretations to other
documents that aren't quite HTML, it's good to document that as a
particular consumer (I.e. browser in this case) specification.
mnot: seems like a number of people said the same thing in different
ways ...
... how can IETF help W3C move this forward?
danc: lots of good things happening. LisaD in contact with IanH about
web sockets
<rubys> if there was such a list (as mnot is proposing), I would
participate there
mnot: get broader feedback from IETF side -- Roy is participating,
want more people
danc: could imagine brainstorming about forums
sam: sounds like W3C/IETF liaison is a big enough activity that it
needs a home
... think it would be advantageous for there to be a mailing list ...
<DanC> fyi, there is http://lists.w3.org/Archives/Public/public-ietf-w3c/
W3C/IETF liaison mechanics
lisa: w3c-policy is an IETF mailing list for this group of people.
Happy to extend that list.
danc: that one isn't publicly archived; there's another one that's
publicly archived
lisa: proliferation of those in the past
mnot: do have w3c-ietf-liaison list
... public-ietf-w3c@w3.org ...
... perhaps use that one for public discussion and general
information ...
... use w3c-policy for the more confidential things ...
lisa: apps-discuss is good for having community of well-informed people
<DanC> (pointer to apps discuss?)
<tlr> https://www.ietf.org/mailman/listinfo/apps-discuss
<DanC> (thanks)
<lisa> FYI I just joined the public-ietf-w3c@w3.org mailing list :)
mnot: have to recognize that IETF is sometimes scary to work with
... public W3C/IETF list could be the place to go to; can refer to
apps-discuss where appropriate
... liaison, part 2 ...
... worthwhile to come up with a web page about the liaison, what
resources are available etc ...
... we have lists of names, but would be useful to have a bit more ...
mnot: web page, point to people involved, mailing list, minutes --
that would be a start
... some pointers (how to get in touch with right people, how to
register media type) would be useful
<DanC> Art's msg http://lists.w3.org/Archives/Public/public-ietf-w3c/2009Jan/0001.html
mnot: don't want to go down to formal liaison memo
plh: where to put it?
<DanC> (for publishing logistics, the ESW wiki is most convenient for
me http://esw.w3.org/topic/ )
mnot: no good idea where
... ESW wiki sounds like it's ok
<scribe> ACTION: mnot to draft wiki page on IETF/W3C liaison [recorded
in http://www.w3.org/2009/01/06-ietf-minutes.html#action01]
mnot: other aspect -- are these meetings the right frequency and the
right scope?
... sometimes we seem to forget what we did last time ...
... maybe have them a little more often ...
plh: not sure -- if we had this conversation 3 months ago, it would
have looked much different
<shepazu> many people may not know what IETF (or even W3C) is or
does... perhaps the wiki could expand on that, and on the respective
scopes
<DanC> sure, doug
mnot: we need to cover materials; there's opportunity cost in that we
might want to talk more about some things
... liaison could be closer ...
timbl: examples?
lisa: geopriv!
mnot: how we develop protocols, how we deal with things -- could
scratch deeper on these
danc: feel similarly -- there are lots of things I let pass on the
IETF side
... might find more frequent meetings more convenient ...
mnot: aim would be to have more of an information transfer and
highlighting, rather than technical discussion
... as far as IETF is concerned, W3C can just participate ...
timbl: would like to see more shared knowledge
danc: swapping chairing back and forth is high cost. If somebody
wanted to take chair for 6 months (and 3 meetings), that would be great
mnot: makes sense
plh: note that we have plenty of opportunity to send agenda+ to
mailing list already; nothing that keeps us from having a call
lisa: hard to remember what you have to tell people
mnot: maybe just a matter about sending more e-mail, then have more
meetings
timbl: sometimes there is call for agenda items, and there's silence
danc: so the chair cancels the meeting
mnot: to achieve function of liaison, only people required are mnot,
plh, danc
... our job to act as conduits ...
timbl: do not think I'm critical resource for getting number of
meetings up
<Zakim> shepazu, you wanted to note that some people refuse to do
telcons
next meeting?
mnot: next IETF is March 22-27
RESOLUTION: next meetings on 13 March, 14 May, 16 July
mnot: will offer to chair these three
<scribe> ACTION: mnot to propose times for 3/13, 5/14, 7/16 liaison
calls [recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action02
]
"Origin Header for CSRF Mitigation" to IETF or W3C
<DanC> "Origin Header for CSRF Mitigation"
<DanC> http://crypto.stanford.edu/websec/specs/origin-header/
mnot: I remember some of this
... think it's HTML5 and maybe some others wanting to define new HTTP
header ...
... similar to Referer, but only host name and perhaps port ...
... notion that people strip referer due to privacy concerns ...
... so this would be a way to ensure that people could do things more
reliably ...
... use for things like ACLs for cross-site stuff ...
<John_C_Klensin> If the problem this solves is that referral info is
getting deliberately suppressed due to privacy concerns, what is to
stop this being removed for the same reason?
thomas: Adam and Collin showed up at an HTML5 call, we said "webapps,
or perhaps individual draft", heard something from Moz saying that
they want to take to IETF
lisa: there's something in the provisional registry
<lisa> http://www.iana.org/assignments/message-headers/prov-headers.html
<DanC> there's Access-Control-Allow-Origin ...
<DanC> (not preemptively, but provisionally.)
tlr: looks like it comes from the access-control / XHR2 discussion
plh: this discussion is about a separate document; seems like they are
going down the IETF route
... need to confirm with Mozilla ...
danc: there's also the question whether this is a good idea
mnot: encouraged Arun to bring it to IETF community to see discussion
... there are a number of people out there who won't give feed-back to
a document unless it's an I-D
tlr: err, how about a W3C WD?
mnot: arun sent a private draft
... I would certainly have concerns about the proposal that I'd be
happy to raise ...
danc: proponents try to go to whoever finds it most acceptable
plh: we sent advance notice to members for webapps charter
... the current version of that charter assumes that it's done at the
IETF
lisa: by whom?
plh: by Adam Barth
mnot: there's been a month or so of back-channel discussion
... concern about people implementing away ...
danc: would help for those here to agree on what side of the fence it
should be
mnot: with HTTP chair hat on, doesn't matter that much. Possibly
better review on the protocol side
... if you take it to the IETF ...
lisa: proxy and intermediary questions could get reviewed in the IETF
... also, security directorate review ...
... you want that sooner rather than later anyways ...
danc: a number of places to have this discussion
tlr: can live with this either in IETF or W3C space, think it needs
both HTTP and TAG review
... find it alarming if W3C WD path for it means more difficult to get
review ...
mnot: does review include review whether it's necessary?
<tlr> that was a thread between PLH, Arun, myself
noah: yes
danc: who's going to tell Adam?
plh: I've been in contact through Arun; new piece of information is
encouragement to submit quickly
ACTION: plh to inform Arun of March 2 deadline, encourage
quick I-D submission for Origin proposal [recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action03
]
geolocation privacy
<DanC> https://datatracker.ietf.org/liaison/486/
mnot: filed liaison statement a little while back
... got consensus within realtime applications at IETF ...
<DanC> (RIA area? I think I need a reminder)
mnot: participants and chair tried to communicate with WG, concern
about publication without ...
... privacy and security considerations ...
... perception that this spec was documenting what vendors are about
to ship quickly
... that's why we took it to a liaison statement ...
lisa: wouldn't have been a liaison statement if we hadn't all been in
that meeting
danc: what meeting is this?
mnot: bunch of people at IETF meeting in MSP
<lisa> RAI : Realtime Applications
<rubys> https://www.ietf.org/mailman/listinfo/rai
<mnot> http://www.ietf.org/html.charters/wg-dir.html#Real-time%20Applications%20and%20Infrastructure%20Area
mnot: to me, distinction is a bit fuzzy, but that's just me
lisa: geopriv was in apps before it went to RAI, discussion about
moving it back
... basically, timing conflicts question -- this had to be in the same
area as SIP for scheduling reasons ...
danc: understand some of the concerned parties were from CDT
... think they joined publication decision
... document got published with marker about open issue
<tlr> http://www.w3.org/TR/geolocation-API/
danc: gist of liaison statement was "please don't publish as FPWD"
... some of the people who were part of that request signed off on
publication decision ...
... and the thing is published ...
mnot: the people who caused this were the WG chairs, they brought it
to the area directors
... concerns were genuine and reflected entire WG ...
lisa: note that we had this discussion on the IETF side; this was
about context of this particular document
mnot: explained W3C process and what it meant; after that, they still
wanted this
shepazu: implementation is happening at many stages on the process.
Don't know that holding up FPWD would have changed implementors'
attitudes
tlr: note that Richard Barnes was at WG meeting in early December, as
were John Morris and Alissa Cooper. There's a big fat red issue in the
published FPWD that calls out the open issue.
mnot: current privacy text is being characterized as insignificant.
CDT folks were - in mid december - in process of filing formal appeal,
but were convinced to not do that
... they'll try to work directly with vendors to cool things down,
appeal later if needed ...
... crux is that vendors are pushing forward so aggressively ...
danc: any action needed?
mnot: does team have a position on this one, what you'd like to see
out of this discussion?
... can we help with that -- put pressure on group, participate, ...?
danc: always helpful if parties concerned are on the public record
tlr: hesitant to give strong advice; I'm on an update status of
roughly 4 weeks ago
plh: happy to take on getting a formal response
... I'll catch Matt D Womer ...
<scribe> ACTION: plh to contact MDW about liaison response to IETF
[recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action04]
mnot: surprised to see a formal document with such sketchy security
and privacy considerations
... might be part of what we are seeing here ...
lisa: surprised that there was no response
plh: face-to-face and related workshop were to happen when we got the
message; need to follow up with Matt
... note that in order to keep draft from moving forward, that would
take a director's decision
lisa: the chairs have our e-mail addresses; we didn't hear from them
plh: should have addressed liaison statement before publishing
lisa: hadn't realized that FPWD was published
mnot: meta point, it's important that we're being conduits here and
enable direct information exchange
IDNAbis, where are IRIs actually valid? HTML, HTTP, ...
klensin: happy to pass, or at least 0.5 pass
... we touched on key issue in earlier discussion about content
types ...
... have a choice about how we write the URI spec, where the IRI
goes ...
... there's clear right thing vs common practice by content producers
and browser vendors ...
... they are different ...
... part of the problem is that there's an assumption in part of the
IETF community where IRIs fit into the picture ...
... that might be different from opinion in W3C community ...
... and that doesn't make it any easier to move ahead ...
content coding
plh: EXI WG wants to register new content-coding
... "this is XML, but it's EXI" ...
... how do we do that?
mnot: httpbis is setting up procedures for these registries
... can they wait?
plh: not sure
mnot: separate document?
plh: would like to do it all in one package
<noahm> Looks to me like EXI >is< in last call. See: http://www.w3.org/TR/2008/WD-exi-20080919/
<DanC> so what string did they choose for the name of their content
coding?
<plh> http://www.w3.org/TR/2008/WD-exi-20080919/#mediaTypeRegistration
<noahm> http://www.w3.org/TR/2008/WD-exi-20080919/#contentCoding
<DanC> [[ In such protocols that support a mechanism to indicate the
encoding transformation of the data being exchanged, the label "exi"
is used as a content coding ]]
mnot: (reads text of HTTP content coding registration procedure)
mnot: first come first serve, recommend shot across the bow to HTTPbis
to get review whether they're using content-coding the right way ...
timbl: TAG decided that it was more complicated than it looked,
decided not to interfer
noah: TAG let it go; a bit of a stretch; but stretch not too bad
mnot: a bit of a question about format-specific content coding; do
that on list
<noahm> Mark, it's not just that it's (meta)format specific, it's that
it's not quite full fidelity. I think that there are cases where
attributes with doublequotes could be transmitted as single, or some
such.
<noahm> It's infoset based, but advertised as an encoding for XML.
danc: PLH, did you get what advice you need?
plh: yes.
Summary of Action Items
[NEW]ACTION: mnot to draft wiki page on IETF/W3C liaison
[NEW] ACTION: mnot to propose times for 3/13, 5/14, 7/16 liaison calls
[NEW] ACTION: plh to contact MDW about liaison response to IETF
[NEW] ACTION: plh to inform Arun of March 2 deadline, encourage quick
I-D submission for Origin proposal
Received on Tuesday, 20 January 2009 12:39:32 UTC