Subject: IETF/W3C Agenda and Call Information

From: Philippe Le Hegaret <[email-masked]>
Date: Tue, 06 Oct 2009 09:45:08 -0400

Apologizes for the late notice for the call information.

Call Information:
  Tuesday, 6 October 15:00-16:00 UTC (11:00am-12:00pm Boston local)
  Zakim Bridge +1.617.761.6200, conference 4383 ("IETF")

Agenda items: (Updated and in no particular order)
 - Geolocation
 - IDN and IRIs
    - http://tools.ietf.org/id/draft-iab-idn-encoding-00.txt 
    - https://datatracker.ietf.org/idtracker/draft-ietf-idnabis-protocol/
    - ICANN work on an IDN ccTLD fast-track
    - some work on variant problems around ICANN, too
    - URI/IRI/Href/Web address
     http://lists.w3.org/Archives/Public/public-html/2009Sep/0939.html
 - vCard 4.0 and HTML5 microformats
   http://lists.w3.org/Archives/Public/public-html/2009Oct/0082.html
 - Upcoming IETF BOFs of W3C relevance
 - Strict Transport Security Specification (STS)
   http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html
 - HTML 5 and text/html media type

Philippe

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Oct 2009 15:38:15 +0100

>   http://lists.w3.org/Archives/Public/public-html/2009Oct/0082.html
I should add to this that iCalendar got published as RFC 5545. So HTML5 
WG should be notified about that.

On an unrelated note: IETF LTRU WG has published update to Language 
Tags, this is RFC 5646 now.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 06 Oct 2009 16:38:52 +0200

Sorry about that, but I'm already triple-booked in that slot..... good 
luck, there's lots of fun here!

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Oct 2009 16:43:31 +0200

> Tags, this is RFC 5646 now.

s/microformats/microdata/

That being said, the "predefined vocabularies" are gone from HTML5, see 
also <http://lists.w3.org/Archives/Public/public-html/2009Oct/0107.html>.

BR, Julian

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 6 Oct 2009 16:45:23 +0200

IRC channel or jabber room?
--
Thomas Roessler, W3C  <[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Oct 2009 15:47:28 +0100

Julian Reschke wrote:

>> I should add to this that iCalendar got published as RFC 5545. So 
>> HTML5 WG should be notified about that.
>>
> That being said, the "predefined vocabularies" are gone from HTML5, 
> see also 
> <http://lists.w3.org/Archives/Public/public-html/2009Oct/0107.html>.

While they are gone from HTML5, I am still concerned that W3C tries to 
redefine IETF specs in a possibly incompatible way.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Oct 2009 16:49:57 +0200

Alexey Melnikov wrote:
> ...
> ...

And rightly so. As far as I understand, the author is planning to 
publish them as separate specs, but still through the HTML WG.

Personally, I'd like to see this aligned with 
<http://www.w3.org/TR/vcard-rdf> and 
<http://tools.ietf.org/id/draft-perreault-vcarddav-vcardxml-02.txt>.

BR, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Oct 2009 17:50:55 +0100

[...]

> - Upcoming IETF BOFs of W3C relevance
The BOFs of relevance in Hiroshima are:

1) IRI (we talked about this at length during the call)
2) 6lowapp - Lisa has talked about that.

The only other thing I would add is:
3). DECADE - this group is talking about standardizing/designing a 
protocol for accessing network caches, for use by P2P and client/server 
applications.

BTW, you can find more information about all BOFs at 
<http://trac.tools.ietf.org/bof/trac/wiki>.

---

From: Philippe Le Hegaret <[email-masked]>
Date: Thu, 08 Oct 2009 15:35:29 -0400

Please, send me updates to those meeting within a week,

Thank you,

Philippe
                      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
     _________________________________________________________

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

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

   mnot: agree with Larry

   <DanC> (has it seen airtime on the httpbis WG mailing list?)

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

   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

   <JcK> reviews for tech quality/ standardization, but they are
   reviews for relevance, editorial quality, etc.

   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