- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 10 Apr 2009 10:25:47 +1000
- To: public-ietf-w3c <public-ietf-w3c@w3.org>
IETF/W3C Liaison Meeting
13 Mar 2009
Attendees
Present
DanC, Matt, lisa, Johnk, Sam, mnot, plh
Regrets
TimBL
Chair
mnot
Scribe
Matt
Contents
* [3]Topics
1. [4]Action items
2. [5]Content Transformation
3. [6]Wiki page review
4. [7]Geopriv
5. [8]IETF 74
6. [9]IETF HTML5 bar BOF
7. [10]VoiceXML use of POST
8. [11]draft-abarth-origin
9. [12]origin
10. [13]mime sniff
11. [14]Other business
* [15]Summary of Action Items
Action items
mnot: Draft of wiki, everyone okay with it?
<DanC> <[16]http://esw.w3.org/topic/IetfW3cLiaison>
[16] http://esw.w3.org/topic/IetfW3cLiaison%3E
DanC: I tweaked it a bit.
lisa: I havent' looked yet.
Content Transformation
francois: You want an introduction to the CT guidelines, I take it.
... CT Proxies were introduced by mobile carriers to allow mobile
users to access the Web at large.
... In theory it's a good idea, but in practice... there are many
legacy servers that return errors whent hey don't know the UA, so
the proxies instead replace the UA string with a well known one to
trick
... the server into thinking they know who they are.
... But in the mobile world, the UA string is essential due to
fragmentation. Mobile content creators adapt the resource based on
the capabilties of the device found in the UA string.
... These proxies ruined carefully crafted content...
<francois> x-mobile-ua, x-device-user-agent, x-original-user-agent
francois: Now CT proxies provide the original UA string in a
separate header field. There was no real consensus, so each one came
up with their own strings, using X-...
... Now with this guideline we're trying to define some practices
that will bring some order back to the world.
... This way CT proxies can still add value for legacy pages, but
allow mobile developers to be happy.
... Current draft says to send the original UA agent, but if you
receive a response that doesn't look right, then send the request
again with the fake UA.
... That doesn't satisfy everyone... they also want to use a single
HTTP header field.
... There's no immediate benefit to adding another new header... so,
can we keep the X- prefix and how can we migrate?
... The X- header field is already deployed. How do we migrate to
not having it?
mnot: rfc 3864 describes the header field registration policies.
... I don't remember specifically if we completely disallow X-, but
I think from the way you describe it you might have a rationale to
grandfather it in.
... It's in wide use?
francois: How wide?
<lisa> Have you seen [17]http://www.ietf.org/rfc/rfc4236.txt ?
[17] http://www.ietf.org/rfc/rfc4236.txt
mnot: 2 or more implementations deployed...
<DanC> (a search for "x-" in [18]http://tools.ietf.org/html/rfc3864
fails)
[18] http://tools.ietf.org/html/rfc3864
mnot: I don't see anything in the rfc that says you can't use X-...
you could make the in use argument. You could also register
something without the X- prefix.
<plh> John Klensin
JcK: Even if you register the X- there's a non-trivial risk that
someone is using the same string with different semantics.
... It's worse in X- because it's been custom for others to come
along later and reuse them with a different meaning.
plh: They did say they'd consider something other than X- right? But
if there's another UA string in the headers, how do they name it,
etc?
mnot: The UA header does allow more than one value, it's a list of
values. That should be the first place to look.
DanC: X- doesn't occur in 3864, is that by design?
mnot: I don't recall.
DanC: The X-.. once their introduced, how do we get rid of them?
x-www-form... it's everywhere. How do we get rid of them?
mnot: Don't use them unless it's a private thing.
JcK: This is a 25+ year old argument that we keep going around on.
Only use it if it's extremely private, not on the public network.
Never use one of these... names are cheap, register one if you must
and if it doesn't work it goes unused.
DanC: Why put energy into discouraging it at all? Is it just wasted
breath?
JcK: Long arguments about this...
<DanC> (fyi... [19]http://www.mnot.net/blog/2009/02/18/x- "Stop it
with the X- Already!" )
[19] http://www.mnot.net/blog/2009/02/18/x-
JcK: The private uses do have meaning, the key to registering these
things is providing a minimal description.
... If it's private, and I don't want the public to know what it is,
perhaps there's a justification there...
... RFC ???? took a different position than 2822, and 56?? took a
slightly different take on that...
mnot: While RFC [media types] says X- shouldn't be registered.
<DanC> (provisional registries are one of the best ways to mitigate
these problems, IMO)
JcK: Many of the authors of these RFCs have the wounds of it...
mnot: Does this clarify enough to make progress or add confusion?
DanC: Least cost seems to be to keep using X-.
mnot: Use a proper name, but if it hurts adoption or vendors scream,
then you could get it grandfathered in.
francois: I expect that we'll get some negative feedback from the
IETF and the w3c as well. If we have a strong use case we could
register the X- if need be.
mnot: HTTPbis can't give a formal recommendation, but we could get
someone to review the document.
francois: We did for the first draft already, and will for the
second one I imagine.
Wiki page review
[20]http://esw.w3.org/topic/IetfW3cLiaison
mnot: Any comments?
Geopriv
<plh> Matt: I've been encouraging the geo chairs to come up with a
formal reply.
<DanC> wow... this liaison statement is *still* pending?
<plh> Matt: it's taking time and I apologize for the delay
<plh> ... Richard Barnes was in attendance for the geo f2f meeting
<plh> ... came up with a consensus
<plh> ... updated the draft
<plh> ... planning to re-open this can of worms for the next draft
<plh> Mark: when will we receive a response?
<plh> Matt: was supposed to come up by last Friday
<DanC> (I got myself an android/G1 phone a week or so ago... so this
privacy stuff is now a real-world concern of mine. Maybe I'll take
another look.)
<plh> ACTION: Matt to follow up on geopriv liaison statement
[recorded in
[22]http://www.w3.org/2009/03/13-ietf-minutes.html#action01]
<plh> Plh: since the co-chair of geopriv attended the f2f meeting,
it was assumed that consensus obtained was enough to move forward
<plh> Lisa: Richard is now chair of the geopriv wg
<plh> Mark: we could cover recent changes in the IETF at the end
IETF 74
mnot: IETF 74 is next week.
lisa: There's a bof on XMPP
... There's a mail BOF.
... BOF on multi-participants online interactions, MMOX
<DanC> I'll be there, FYI.
[23]http://www.tripit.com/trip/show/id/1329957 arrive SFO Sun
mid-day, depart SFO mid-day Thu Mar 26
[23] http://www.tripit.com/trip/show/id/1329957
lisa: Second Life, virtual world companies, etc, having a debate
about interoperability and use cases and such. MMOX lots of
interest.
<Zakim> DanC, you wanted to ask date time of MMOX
mnot: Tuesday 3:20-5.
<JcK> The mail bof could have been called "find old stuff that has
been lying around for years, is widely deployed and used, clean it
up, and advance it to Internet Standard". There should be few, if
any, substantive issues -- docs that raise substantive issues will
be taken off the agenda"
lisa: OAUTH bof should be interesting to W3C I assume. Work moving
quite well on list after quiet period during holidays. Getting
consensus on charter, and have new chairs and [scribe failure]
... IPR bof, copy right issues that have come up recently.
... bar bof on HTML5.
... Bi-directional HTTP, COMET, etc.
mnot: That's during the app area meeting?
lisa: Yes.
<lisa> APPAREA :
[24]http://www.ietf.org/proceedings/09mar/agenda/apparea.txt
<JcK> DanC: OAUTH is at 1300 Monday, Apps Area at 0900
lisa: The 2nd Life folks are interested in this bidirectional stuff
and claim they've got a different use case.
mnot: Are W3C people aware of copyright problems?
lisa: There's a sun rise problem...
DanC: The IETF note-well thing didn't cover that?
mnot: Doesn't transfer copyright.
... There's an implication on standards that are published... the
idea behind the change, I could be wrong, was that other standards
organizations could re-use IETF text. Because of the sunrise
problems they can't do that.
<JcK> If I can get into the conversation, I can explain this stuff
... am very much in the middle
mnot: e.g. link draft, I have pre-November 10th contributions with
Note Well...
... Changes in IESG?
<JcK> But folks claiming to speak for/be involved in the W3C are
very active in the conversations.
<mnot> [26]http://www.ietf.org/IESGmems.html
<scribe> ACTION: plh to add mnot to Policy admins [recorded in
[27]http://www.w3.org/2009/03/13-ietf-minutes.html#action02]
mnot: Changes are not reflected on that link.
lisa: The IETF mailing list for it...
... JcK now on IAB.
... There are other changes too.
mnot: The most relavent are in apps and RAI.
IETF HTML5 bar BOF
rubys: Only 10 people signed up so far, but may be more popular than
that.
lisa: IETF people are likely to not sign up on the wiki page.
mnot: More likely to just drop in.
lisa: Sitting room for 25 or so, but probably bigger than that.
mnot: Can we get the wiki updated with location info?
rubys: Someone who has more details can send it to me or update it
themselves.
<scribe> ACTION: rubys to update the HTML5 bar BOF page with
details. [recorded in
[29]http://www.w3.org/2009/03/13-ietf-minutes.html#action03]
lisa: I don't know which room is assigned. Wednesday?
rubys: Yes.
<DanC> [30]http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009
[30] http://esw.w3.org/topic/IETF_HTML5_Meeting_March_2009
mnot: I see a lot of high level goals and a lot of concrete things
to look at.
rubys: Lots of issues we could talk about, not sure quite how to
keep things moving.
mnot: How much time?
rubys: 8pm until whenever.
mnot: Dinner before?
... We could go until 10 if we have the time.
... Is Ian coming? he's on the list.
rubys: He's told me he's coming, but then says to others he may not.
mnot: Anything we can do to prepare for this to make it successful?
DanC: Should be good. Chris Wilson not certain?
rubys: I think that's old data. I believe he's planning on being at
this and Web open (?).
<DanC> (what 7:30pm start time? "8pm Wednesday, March 25th")
lisa: The 7:30 start time is rgiht at the end of the plenary, so
some IETF people may not have had dinner.
... Room was reserved for 7:30...
mnot: Might it be worth meeting ahead of time?
VoiceXML use of POST
lisa: The IETF spec punted on interoperability questions by pointing
to the w3c spec.
... The VoiceXML stuff talks about GET and POST, but... tried to get
folks in IETF to write down stuff like this.
DanC: Not clear to me that both parties must support chunk transfer
encoding.
lisa: Re-inforcing what the HTTP spec actually requires is often
useful.
... It's worth re-iterating what's in the HTTP spec.
[31]http://lists.w3.org/Archives/Public/www-voice/2009JanMar/0014.ht
ml
[31] http://lists.w3.org/Archives/Public/www-voice/2009JanMar/
0014.html
lisa: Are redirects appropriate? etc. we're trying to set standards
for what the IETF standards must met when they use HTTP as a
transport.
... I sent mail and haven't gotten an answer yet.
mnot: You're talking about a profile of HTTP...
lisa: If we could find the right people we could get this written
down and referenced once.
mnot: Identify extensibility points, and which points we could have
variance across, etc. If there's something we could put into BIS it
might be useful.
[32]http://lists.w3.org/Archives/Public/www-voice/2009JanMar/0014.ht
ml
[32] http://lists.w3.org/Archives/Public/www-voice/2009JanMar/
0014.html
<DanC> matt, if you see mail like lisa's, please *reply* to confirm
receipt.
Matt: The chairs will be sending a response once they figure out
what it should be. Looking for clarifications on the first two
paragraphs and asking for review on the last paragraph.
<DanC> I think senders can wait a couple days when they send a
comment on a W3C WD, but more than a week is kinda off-putting
draft-abarth-origin
origin
mime sniff
<DanC> mnot: the feedback from the HTTP WG was "Use Referer" and the
question remains whether that suffices
mnot: Are we going to review this in HTTP bis was DanC's question.
<DanC> "The above algorithm is a willful violation of the HTTP
<DanC> specification."
mnot: It looked like they were specifying a mime-sniffing algorithm
for browsers on top of HTTP, but that we weren't going to
incorporate this into HTTP.
DanC: It's not on top of HTTP, it's in violation...
mnot: I think we'll have sufficient wiggle room in HTTP bis that
they could do this...
DanC: There's still some chatting to do?
mnot: That's my impression.
DanC: This is a huge hot button issue.
mnot: If they want it published as an IETF standard they're going to
need more consensus.
rubys: I am pretty confident they want to publish it as a standard.
DanC: I don't think they're breaking things, just writing down
what's broken already.
lisa: The way we deal with contentious things like this is to form
working groups. We don't have any other mechanism for reaching consensus
when there's such a substantial difference of opinion.
... We now have several such topics that could be worthy of a second
HTTP WG if we don't extend the current one.
DanC: And if no one shows up?
lisa: In a WG we have a way to make sure people play nicely. It's
where there is a lack of a WG that there's less order.
mnot: Getting to the point where there's agreement that there should
be a standard that describes what this thing describes and getting
to a charter is going to be difficult.
lisa: If there was a way forward recommended too that would be
great. A charter can have two deliverables, documenting what's there
and how to move forward...
DanC: Hixie spent 10 years trying to get browsers to follow the
spec, but the browsers would end up losing market share...
... Users will think the browser is broken and not the server.
<JcK> At the same time, some of those practices, however
well-established, can cause rather serious problems including
security ones... and there, behavior sometimes does change.
<DanC> yes, JcK, I think there's a pretty good argument on the other
side... it'll be tricky to get people to consider both sides
<lisa> yeah, sorry it was so confusing too
mnot: I fear in 10-12 years you're going to have to publish a media
type, and a 3 page algorithim on how to sniff it...
<JcK> There are pretty good arguments on both sides. The problem is,
indeed, to get people to consider both, rather than repeating the
same position over and over again.
mnot: I think it needs to be handled very carefully.
... Web socket protocol is totally different in that it's not trying
to document anything that's there, just something totally new.
Other business
mnot: Next meeting, 14th of May. No particular time.
... I'll chair the next two meetings.
... I'll be in Australia.
JcK: I'll be in Nairobi.
Summary of Action Items
[NEW] ACTION: Matt to follow up on geopriv liaison statement
[recorded in
[33]http://www.w3.org/2009/03/13-ietf-minutes.html#action01]
[NEW] ACTION: plh to add mnot to Policy admins [recorded in
[34]http://www.w3.org/2009/03/13-ietf-minutes.html#action02]
[NEW] ACTION: rubys to update the HTML5 bar BOF page with details.
[recorded in
[35]http://www.w3.org/2009/03/13-ietf-minutes.html#action03]
[End of minutes]
Received on Friday, 10 April 2009 00:26:26 UTC