Subject: Draft minutes W3C/IETF coordination call 2009-01-06

From: Thomas Roessler <[email-masked]>
Date: Wed, 7 Jan 2009 13:33:43 +0100

Draft minutes below the .signature.

John, I mis-scribed your argument about e-mail and would welcome a  
correction.

I'll publish these around Jan 20 unless there are any objections.
--
Thomas Roessler, W3C  <[email-masked]>

- DRAFT -W3C/IETF liaison call
06 Jan 2009
Agenda

See also: IRC log

Attendees
Present Lisa_Dusseault, Thomas Roessler, Mike Smith, Mark Nottingham,  
Dan Connolly, Doug Schepers, Noah Mendelssohn, Sam Ruby, Philippe Le  
Hegaret, Tim Berners-Lee, John Klensin Chair DanC Scribe tlr
Contents
	• Topics
		• Convene, take roll, review agenda http://www.w3.org/mid/[email-masked]
		• 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
	• Summary of Action Items
Convene, take roll, review agenda http://www.w3.org/mid/[email-masked]
danc: lisa, please pronounce your last name.

Lisa: Dusseault

danc: (round of introductions)

HTML5 work and review, esp. WebSockets
<lisa> congratulations or consolations, Sam

<shepazu> congrats, sam, and thank you

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 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, note timing constraints
... a number of people have pointed out that there are parts of HTML5  
where it implies that it's ...
... not following IETF specs ...

<Zakim> DanC, you wanted to introduce a list of parts of the HTML spec http://www.w3.org/html/wg/tracker/products/2

<shepazu> definitely wrt URLs

mnot: places where IETF standards are intentionally ignored ...

danc: intentionally violated, not ignored
... have this list that I hope includes all those

<DanC> zooming out to http://www.w3.org/html/wg/tracker/issues

<DanC> ISSUE-28 (edit)

<DanC> http-mime-override

danc: HTTP and MIME is in here, I hope ...

<DanC> ISSUE-56 (edit)

<DanC> 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" ...

<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 ...
... convince people who generate files to do foo ...
... first one who gets it right is going to get squashed in the market  
place
... but first person who does it after file naming practice has  
changed is not going to ...
... attempt to fix earlier rather than later ...

noah: content sniffing or URI comparison?

mnot: a number of points

sam: img tag vs a href are different here

mnot: valid argument for browsers, but lot of software out there that  
changing the spec would be harmful for
... maybe what's right for a browser isn't right for an enterprise  
content mgmt system ...
... spec that says "browsers will deviate in this way" is probably  
less harmful than change to core URI spec ...

shepazu: John's approach is sensible. # of people to whom to align URI  
is large
... browsers and authors ...
... control not just how content is consumed through browser, also  
have to control how it's produced ...

shepazu: doesn't nullify what John said; another factor to consider

jck: absolutely; differ 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/

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.

<MikeSmith> http://www.w3.org/html/wg/markup-spec

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

<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.

<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
... [email-masked] ...
... perhaps use that one for public discussion and general  
information ...
... use w3c-policy for the more confidential things ...

<DanC> (pointer to apps discuss?)

lisa: apps-discuss is good for having community of well-informed people

<tlr> https://www.ietf.org/mailman/listinfo/apps-discuss

<DanC> (thanks)

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 ...

<lisa> FYI I just joined the [email-masked] mailing list :)

<DanC> Art's msg http://lists.w3.org/Archives/Public/public-ietf-w3c/2009Jan/0001.html

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> (for publishing logistics, the ESW wiki is most convenient for  
me http://esw.w3.org/topic/ )

mnot: don't want to go down to formal liaison memo

plh: where to put it?

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

<DanC> sure, doug

<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

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
... would 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

danc: call ca March 10?

noah: TAG has meeting before 6th?

danc: thinking about that, not a conflict

mnot: more likely for me to be in the US on 12 March

Candidate date: Friday 13 March

Also, 14 May?

<timbl> are all these same time of day?

<DanC> good question

mnot: July 16

timbl: can't do 16 July

<timbl> I am not free Jul 16

lisa: 16 July is conveniently 2 weeks before stockholm

mnot: will offer to chair these three

RESOLUTION: next meetings on 13 March, 14 May, 16 July

<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: think I was quoting from a mail message

<DanC> From: Dan Connolly <[email-masked]>

<DanC> To: W3C/IETF <[email-masked]>

<DanC> Cc: Michael(tm) Smith <[email-masked]>, Doug Schepers <[email-masked] 

<DanC> Subject: "Origin Header for CSRF Mitigation" to IETF or W3C?

<DanC> Date: Tue, 25 Nov 2008 09:48:16 -0600

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 ...

<DanC> "Origin Header for CSRF Mitigation"

<DanC> http://crypto.stanford.edu/websec/specs/origin-header/

<DanC> "webapps" = W3C Web Applications WG

<lisa> http://www.iana.org/assignments/message-headers/prov-headers.html

<DanC> there's Access-Control-Allow-Origin ...

<DanC> (not preemptively, but provisionally.)

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

<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?

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

<scribe> 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 ...
... adn 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

IDNAbis, where are IRIs actually valid? HTML, HTTP, ...
mnot: meta point, it's important that we're being conduits here and  
enable direct information exchange

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?

mnot: (reads text)

<plh> http://www.w3.org/TR/2008/WD-exi-20080919/#mediaTypeRegistration

mnot: first come first serve, recommend shot across the bow to HTTPbis  
to get review whether they're using content-coding the right way ...

<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 ]]

<noahm> http://www.w3.org/TR/2008/WD-exi-20080919/#contentCoding

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.

danc: draft minutes to w3c-policy, then public minutes a week later

<noahm> It's infoset based, but advertised as an encoding for XML.

Summary of Action Items

[NEW]ACTION: mnot to draft wiki page on IETF/W3C liaison [recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action01 
]
[NEW] 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]
[NEW] ACTION: plh to contact MDW about liaison response to IETF  
[recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action04]
[NEW] 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 
]

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/07 12:29:33 $

---

From: Dan Connolly <[email-masked]>
Date: Wed, 07 Jan 2009 09:02:27 -0600

> Draft minutes below the .signature.

Thanks...

> I'll publish these around Jan 20 unless there are any objections.

I cleaned up the attendance/intro stuff a bit
and changed the order of some of the IRC comments
to flow better; attached find the result and diffs.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
--- Draft_minutes_W3C_IETF_coordination_call_2009-01-06	2009-01-07 08:59:49.000000000 -0600
+++ ietf-minutes-edited.txt	2009-01-07 08:59:05.000000000 -0600
@@ -1,35 +1,43 @@
 - DRAFT -W3C/IETF liaison call
 06 Jan 2009
-Agenda
-
-See also: IRC log
 
 Attendees
-Present Lisa_Dusseault, Thomas Roessler, Mike Smith, Mark Nottingham,  
-Dan Connolly, Doug Schepers, Noah Mendelssohn, Sam Ruby, Philippe Le  
-Hegaret, Tim Berners-Lee, John Klensin Chair DanC Scribe tlr
-Contents
-	� Topics
-		� Convene, take roll, review agenda http://www.w3.org/mid/[email-masked]
-		� 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
-	� Summary of Action Items
-Convene, take roll, review agenda http://www.w3.org/mid/[email-masked]
-danc: lisa, please pronounce your last name.
 
-Lisa: Dusseault
+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
 
-danc: (round of introductions)
+Convene, take roll, review agenda
 
-HTML5 work and review, esp. WebSockets
-<lisa> congratulations or consolations, Sam
+Chair: DanC
+
+Scribe: tlr
+
+agenda was accepted with a few ammendments
 
-<shepazu> congrats, sam, and thank you
+danc: draft minutes to w3c-policy, then public minutes a week later
+
+
+HTML5 work and review, esp. WebSockets
 
@@ -106,33 +114,28 @@
 
-<Zakim> DanC, you wanted to introduce a list of parts of the HTML spec http://www.w3.org/html/wg/tracker/products/2
+mnot: places where IETF standards are intentionally ignored ...

-mnot: places where IETF standards are intentionally ignored ...
-
 danc: intentionally violated, not ignored
 ... have this list that I hope includes all those
 
-<DanC> zooming out to http://www.w3.org/html/wg/tracker/issues
-
-<DanC> ISSUE-28 (edit)
-
-<DanC> http-mime-override
+<Zakim> DanC, you wanted to introduce a list of parts of the HTML spec http://www.w3.org/html/wg/tracker/products/2

-<DanC> ISSUE-56 (edit)
+<DanC> ISSUE-28 http-mime-override
 
-<DanC> urls-webarch
+<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" ...
+... ISSUE-62 websockets-- easier to say "not taking it on, since
+... it's handled elsewhere" ...

@@ -244,6 +247,7 @@
 
 <rubys> http://www.w3.org/html/wg/markup-spec/
+<MikeSmith> http://www.w3.org/html/wg/markup-spec

@@ -257,7 +261,9 @@
 
-<MikeSmith> http://www.w3.org/html/wg/markup-spec
+<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.
 
@@ -266,10 +272,6 @@
 
-<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.
-
 <rubys> if there was such a list (as mnot is proposing), I would  
 participate there
 
@@ -284,7 +286,9 @@

+
+
 
@@ -299,14 +303,14 @@
 information ...
 
-<DanC> (pointer to apps discuss?)
-
 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 [email-masked] mailing list :)
+
@@ -315,22 +319,20 @@
 
-<lisa> FYI I just joined the [email-masked] mailing list :)
-
-<DanC> Art's msg http://lists.w3.org/Archives/Public/public-ietf-w3c/2009Jan/0001.html
-
 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> (for publishing logistics, the ESW wiki is most convenient for  
-me http://esw.w3.org/topic/ )
+<DanC> Art's msg http://lists.w3.org/Archives/Public/public-ietf-w3c/2009Jan/0001.html

 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
 
@@ -345,12 +347,12 @@
 
-<DanC> sure, doug
-
 
+<DanC> sure, doug
+
@@ -364,7 +366,7 @@
 
 danc: feel similarly -- there are lots of things I let pass on the  
 IETF side
-... would find more frequent meetings more convenient ...
+... might find more frequent meetings more convenient ...
 
@@ -399,54 +401,24 @@
 
-next meeting?
-mnot: next IETF is March 22-27
-
-danc: call ca March 10?
-
-noah: TAG has meeting before 6th?
-
-danc: thinking about that, not a conflict
-
-mnot: more likely for me to be in the US on 12 March
-
-Candidate date: Friday 13 March
 
-Also, 14 May?
-
-<timbl> are all these same time of day?
-
-<DanC> good question
-
-mnot: July 16
-
-timbl: can't do 16 July
+next meeting?
 
-<timbl> I am not free Jul 16
+mnot: next IETF is March 22-27
 
-lisa: 16 July is conveniently 2 weeks before stockholm
+RESOLUTION: next meetings on 13 March, 14 May, 16 July

-RESOLUTION: next meetings on 13 March, 14 May, 16 July
-
 <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: think I was quoting from a mail message
-
-<DanC> From: Dan Connolly <[email-masked]>
 
-<DanC> To: W3C/IETF <[email-masked]>
-
-<DanC> Cc: Michael(tm) Smith <[email-masked]>, Doug Schepers <[email-masked] 
- >
-
-<DanC> Subject: "Origin Header for CSRF Mitigation" to IETF or W3C?
+"Origin Header for CSRF Mitigation" to IETF or W3C
 
-<DanC> Date: Tue, 25 Nov 2008 09:48:16 -0600
+<DanC> "Origin Header for CSRF Mitigation"
+<DanC> http://crypto.stanford.edu/websec/specs/origin-header/
 
@@ -457,11 +429,15 @@
 
-<DanC> "Origin Header for CSRF Mitigation"
+<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?
 
-<DanC> http://crypto.stanford.edu/websec/specs/origin-header/
+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
 
-<DanC> "webapps" = W3C Web Applications WG
+lisa: there's something in the provisional registry

@@ -469,16 +445,6 @@

-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
-
-<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?
-
 tlr: looks like it comes from the access-control / XHR2 discussion
 
@@ -500,8 +466,7 @@
 
 plh: we sent advance notice to members for webapps charter
-... the current version of that charter assumes that it's done at the  
-IETF
+... the current version of that charter assumes that it's done at the IETF
 
 lisa: by whom?
 
@@ -539,10 +504,11 @@
 
-<scribe> ACTION: plh to inform Arun of March 2 deadline, encourage  
+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
 
@@ -566,9 +532,7 @@
 
-
-
 
 mnot: to me, distinction is a bit fuzzy, but that's just me
@@ -587,7 +551,7 @@
 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 ...
-... adn the thing is published ...
+... and the thing is published ...
 
@@ -648,10 +612,12 @@

-IDNAbis, where are IRIs actually valid? HTML, HTTP, ...
 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 ...
@@ -680,22 +646,18 @@
 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?
-
-mnot: (reads text)
-
 <plh> http://www.w3.org/TR/2008/WD-exi-20080919/#mediaTypeRegistration
-
-mnot: first come first serve, recommend shot across the bow to HTTPbis  
-to get review whether they're using content-coding the right way ...
-
+<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 ]]
 
-<noahm> http://www.w3.org/TR/2008/WD-exi-20080919/#contentCoding
+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 ...
 
@@ -710,24 +672,21 @@
 
-danc: draft minutes to w3c-policy, then public minutes a week later
-
 <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 [recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action01 
-]
+[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  
-[recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action02]
-[NEW] ACTION: plh to contact MDW about liaison response to IETF  
-[recorded in http://www.w3.org/2009/01/06-ietf-minutes.html#action04]
-[NEW] 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 
-]
 
-[End of minutes]
-Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
-$Date: 2009/01/07 12:29:33 $
+[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

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Jan 2009 13:02:16 -0500

--On Wednesday, January 07, 2009 13:33 +0100 Thomas Roessler
<[email-masked]> wrote:

> John, I mis-scribed your argument about e-mail and would
> welcome a correction.

Have rewritten that material, more or less into a summary of
what I would have said if I had not been watching the clock.
The changed material is below, edited from Dan's version (in
case the two are different).  Feel free to revise back to your
more abbreviated chat-based style.

The minutes should also mention that we raised the IRI-validity
problem and decided to defer it because of time.   It might or
might not be worth mentioning that I/we believe there is a
difference of opinion between the IETF and W3C (or at least
groups within both) about this and its connection to the URI
interpretation question/ content sniffing issue that we
discussed at more length.  (I did mention both in my very quick
summary.)

FWIW, as the amount of energy I need to devote to IDNs and email
i18n winds down over the next several months (I hope), I'd be
happy to do some serious work on the "why one should be very
conservative about what one puts in a URI slot" topic if we
could find an appropriate place for that work and its review.

    john

  ____________

[...]

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.  

[...]

shepazu: John's approach is sensible. # of people to whom to
align URI  
is large
... browsers and authors ...
... control not just how content is consumed through browser,
also  
have to control how it's produced ...

shepazu: 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

[...]

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 11 Jan 2009 13:52:37 +0100

Updated version (with changes from John K and Mark N) attached.  Will  
publish Jan 20-ish.
--
Thomas Roessler, W3C  <[email-masked]>

On 7 Jan 2009, at 16:02, Dan Connolly wrote:

> <ietf-minutes-edited.txt><,minutes-diff.txt>