[minutes] W3C/IETF Coordination call 20091008

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[minutes] W3C/IETF Coordination call 20091008

Philippe Le Hegaret
Available at

Text version:
                      W3C/IETF Coordination call

08 Oct 2009


          Masinter, Thomas, Plh, Lisa_Dusseault, mnot, Alexey, DanC,
          Jeff Hodges, jck





     * [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


   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

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

   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

   Lisa: when this was reviewed by the IESG and IAB, it was unanimously
   flagged as important, but of course that doesn't guarantee

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

   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

Strict Transport Security (STS) spec

   JeffH: spec has been sent to lists
   ... our understanding is that webapps is the place for this
   ... Doug Schepers said to put it up on www-archive and get it on the

   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

   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