- From: Philippe Le Hegaret <plh@w3.org>
- Date: Mon, 19 Oct 2009 17:37:50 -0400
- To: public-ietf-w3c@w3.org
Available at
http://www.w3.org/2009/10/06-ietf-minutes.html
Text version:
W3C/IETF Coordination call
08 Oct 2009
Attendees
Present
Masinter, Thomas, Plh, Lisa_Dusseault, mnot, Alexey, DanC,
Jeff Hodges, jck
Regrets
Chair
Plh
Scribe
mnot
Contents
* [2]Topics
1. [3]Geolocation
2. [4]IDN and IRIs
3. [5]vcard 4.0 and HTML5 microformats
4. [6]Strict Transport Security (STS) spec
* [7]Summary of Action Items
_________________________________________________________
Geolocation
TLR: comment from IETF Chair recieved
... WG has not yet been able to reply
... no prediction on timeline
<masinter> also comment from other members?
TLR: Discussed at TAG meeting two weeks ago; I believe that the TAG
isn't planning anything further
Larry: My recollection is that there are procedural issues
... Concern about venue shopping
<DanC> (but the TAG has no plans to follow up on the procedural
issues)
Larry: This is not an issue that the TAG will be a primary voice on,
will defer
... to groups like this for procedural oversight
<masinter> and that it would apply to other issues like Device APIs
TLR: Will come up in API and Policy WG
PLH: Overall timeline for Geolocation?
TLR: "real soon now"
IDN and IRIs
TLR: Icann is putting out a cctld fast-track process
... launch is in november
... issues around how to deal with different variants of a string
... worst case: two cases that look the same, read the same leading
to
... different A labels
Larry: This wouldn't be an issue if the HTML5 spec didn't contain
yet another URL definition
... (wouldn't be an IETF/W3C coordination issue, might be a
IRI/ICANN/IDNA coordination issue)
<masinter> it would be an IETF issue to deal with in revising the
IRI spec
<JcK> Larry, it would still be a coordination issue although the
HTML5 spec certainly aggravates things. So does the IAB issue, the
ICANN issue, some basic DNS issues which interact with root variant
notions, etc., etc., ad nauseum
TLR: purpose of this agenda item is to assure we have roughly the
same view of the problem, etc.
JCK: at a high level, this whole area requires throwing things away
and leaving things away, not patching, we're finding
... e.g., idna was a mistake
... i.e., we have some fairly fundamental problems, including how
long we can keep patching things and introducing more complexity
... underlying discussion should be about a general model, and then
how do we get there, rather than "what's the next intermediate
patch"
Larry: procedurally, I'm hoping to spend time with Martin next week
on the IRI document
... especially on organisation
... my hope is to try to move rationale to a separate BCP document
... that document could be updated separately
... part of that is the HTML5-specific pre-processing for
whitespace, etc.
... in this manner, we cna adapt to there being at least five
different specs with different syntactic rules
... I admit there's lots of confusion, and it does sometimes seem
hopeless, but I'm not willing to say we need to cut it off yet
PLH: So you're organising a BoF at the next IETF?
Larry: Lots of specs that aren't in alignment
... HTTP specifies some, browsers and servers have some support for
utf-8 in the path
... HTML5 has its own requirements for browsers
... IDNA requirements and methods John mentioned; e.g., what strings
are valid for hostnames
... mailto URI scheme, where e-mail i18n has some effect
... unfortunately, there's little communication
... starting a WG seems like the only way to get some authority;
IETF seems like the right place
PLH: is there feedback / indication of how many people will show?
Larry: hoping we'll have better than the bar bof in Stockholm
... we had about 10 people there
... I can't think of any other way to achieve the coordination
necessary
Lisa: when this was reviewed by the IESG and IAB, it was unanimously
flagged as important, but of course that doesn't guarantee
participation
Larry: Hiroshima is difficult for some, so the mix will be different
<tlr> it's also no guarantee for the existence of a solution.
*fingers crossed*
Larry: Hopefully this won't be seen as indicative
<tlr> strike "browser"
Larry: it would be nice if browser vendors would show up
Lisa: IDNAbis won't be meeting in Hiroshima, but the usual suspects
should still be there
Larry: We have to get people to agree that it's not good for us to
have multiple sets of slightly different rules
PLH: This impacts HTML5, but also XML Core
... What about RDFa?
Larry: I think that a lot of these specs need to be much more clear
about the robustness rule; i.e. what a processor should be willing
to be able to accept, and what conservative producers should produce
<JcK> It also impacts anything that needs to compare two identifier
strings for equality... especially if those strings have
special-purpose comparison rules (e.g., IDNA2003) or rules that
mapping to the same target
<JcK> doesn't constitute equality (HTML) or that are not expected to
be looked up at all. That combination affects the entire URN space
as well as other things. _Very_ large scope.
Larry: so there needs to be some asymmetry between producers and
consumers
... IRI document already had a 'ladder' of equality; even with ASCII
there are opportunities for spoofing
JCK: You can't magically make spoofing disappear; ladders may not
help us a lot when we get to interop issue, e.g., when rules are
interpreted differently
Larry: determining whether two identifiers with different
serialisation are the same; this is a problem that goes back a long
time, we're not going to solve it
JCK: This is a powerful argument for 1) reducing the number of
representations a given identifer can have. Unfortunately, the trend
is to increase this number
<tlr> "we don't know whose problem it is"
PLH: Larry's effort seems to be to keep the centre of this work in
the IETF; I'm happy about that
Larry: any offers of help would be greatly appreciated
vcard 4.0 and HTML5 microformats
PLH: vcard has been separated out of HTML5 recently; a separate
draft
... status of that draft is not clear at this time
Larry: My understanding is that the browser vendors want to document
what they implement, which is different than the RFC
DanC: I heardt this was about additional functionality; e.g.,
copy/paste
... We avoid duplication by getting early review; splitting it out
is the first step that enables that
PLH: My understanding is that this wasn't universally supported by
browser vendors anyway
PLH: as Dan said, if this one gets some steam, we can re-address it
Alexey: concerned about the general problem of re-specification
Larry: My concern with the URI issue is not regarding coordination;
it's whether it's OK for browsers to work in a different way than
e-mail clients, for example
... Most e-mail clients work differently than browsers; is that OK?
... Same question for IM clients
... We're seeing a divergence in technical direction because e-mail
client vendors are engaged in the IETF, while browser vendors are in
the W3C
Lisa: The IETF is the only game in town for e-mail interop
<JcK> Larry, your question really amounts to whether it is ok to
have web-based email work differently for MUA-based email. And the
answer to that question had better be "no" unless we want really
confused users.
TLR: We need to be careful about layers here; there are several
layers that these problems manifest at. E.g., when an e-mail client
renders HTML, they may use browser components
<DanC> re how HTML works in email, it's frightening. see workshop
report [8]http://www.w3.org/2007/05/html-mail/
[8] http://www.w3.org/2007/05/html-mail/
<jeffh> divergence just because it "seems" like it doesn't matter
(perhaps due to poor form on part of some player(s)) is not ok.
(imho)
TLR: This cuts both ways. I don't think we're doing ourselves a
favour about e-mail vendors; it depends on the topic, just as with
browser vendors
<masinter> for text/plain
<tlr> in other words, it's a rathole
DanC: MSFT used the Word component for their latest e-mail rendering
engine, rather than IE7; it's a nightmare. We had a workshop about
this recently.
Larry: WRT charset sniffing - rule about windows vs iso8859 is
followed by browsers, but not e-mail clients
<DanC> (hmm... the windows-1252 issue is so small that it pales in
comparison to most of the other stuff we're talking about. win-1252
is a compatible extension of iso-8859-1)
<JcK> But it is even worse, because some rather good MUAs render
HTML as link-less as a malware-propagation preventative.
Larry: there still remains some concern
PLH: We're starting to tackle this issue-by-issue; starting with
IRIs
Strict Transport Security (STS) spec
JeffH: spec has been sent to lists
... our understanding is that webapps is the place for this
currently
... Doug Schepers said to put it up on www-archive and get it on the
list
PLH: Speaking from a W3C perspective, we have some process issues
with it, potentially
... It's not in the scope of webapps charter
PLH: To put it on REC track, we'd have to recharter, which may bring
other issues
JeffH: There are also other drafts that are in the same space
mnot: why not make this some sort of attribute of SSL, the
certifiate etc? This work would certainly be useful in other
contexts
JeffH: That would be interesting in the long term, yes
... but we want something that can be deployed soon
PLH: putting issues of the scope of the charter aside, we'd like to
hear whether there's concern from the IETF side about this happening
in the W3C
Larry: I'd urge consideration of publication as Informational RFCs
... this would give some level of review, get a published document
... and would appropriately indicate that this is a vendor solution
... but could still be referenced normatively
JeffH: Does the W3C see any issue with this?
PLH: I don't think so; if the IETF is interested, I don't think we'd
have an issue
<JcK> Larry, there is always some "doing the work" component of Info
Publication. Either an AD needs to decide to sponsor the thing,
which involves some process, or the doc needs to be submitted as an
Independent Submission, in which case there is both RFC Editor (ISE)
and IESG review. Those may not be reviews for tech quality/
standardization, but they are reviews for relevance, editorial
quality, etc.
mnot: agree with Larry
<DanC> (has it seen airtime on the httpbis WG mailing list?)
TLR: regarding similar specs - I wonder how many of the people on
this call have an interest in this area, and will be at the TPAC
TLR: might be good to get a bar bof during TPAC
JeffH: sounds good
<masinter> +1 for trying to schedule coordination over protocol work
at TPAC
JeffH: CORS is already in webapps; this is one of the reasons we
thought it might be appropriate
PLH: next meeting before thanksgiving
meeting adjourned
Received on Monday, 19 October 2009 21:37:53 UTC