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