[EAI] Confusion about backwards-compatibility of 3987bis/IRIs (was: Re: Shepherd report review of mailinglist-02)

["Martin J. Dürst" <[e-mail]>]

[cc'ed to the mailing list of the IRI WG]

[IRI WG: This came up in the EAI (email address internationalization) WG 
when discussing 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-eai-mailinglistbis-03, but 
it's highly relevant to the work of the IRI WG.]

[Everybody, please remove the EAI mailing list if you continue 
discussing IRIs, and the IRI mailing list if you discuss the 
mailinglistbis draft, thanks!]


Hello John,

On 2012/07/11 21:23, John C Klensin wrote:
> Hi Martin,

>> ...
>> As draft-ietf-iri-3987bis isn't yet done, its difficult to say
>> exactly, but while there are many changes and tweaks in the
>> details, the basic principles are exactly the same. Saying
>> that you can't cite RFC 3987 because there's a WG that is
>> working on updating it would be about the same as saying you
>> can't cite RFC 2616 (HTTP) because there's a WG working on
>
> The difference is that the group revising HTTP seems to be bound
> by strict upward compatibility.   The (tentative) decision to
> change the role of IRIs from "UI overlay" to "separate protocol
> element mostly suitable for new protocols" is a significant
> modification that calls 3987 into question.  My own guess is
> that, even if IRIs continue down that path, a profile will
> evolve that is strictly upward compatible with 3987 and that
> would be suitable for discussion in this sort of paragraph.  But
> the timing of development of the two specs is exquisitely bad.

While busy with my day job, I have been able to think about the above. I 
think that what you say above is factually mistaken, but I'm starting to 
see where in the IRI discussion you might have picked up some faint 
signals (one of your many strengths) that let to your interpretation.

But let's go back to the facts:

First (I'm probably writing this for the third time), IRIs as defined in 
RFC 3987 are not "UI overlay". They are clearly defined as protocol 
elements. Of course, they can also be used as "UI overlay", http would 
be a good example. IDNs are a parallel.

Second, of course IRIs are suitable for new protocols. But that also has 
been the case in RFC 3987.

Third, as far as I know, there is no need for a "profile" that is 
strictly upward compatible with RFC 3987. Although the 'modus operandi' 
of the IRI WG may be a bit more chaotic than the well-oiled machine of 
the httpbis WG, the goal, at least as far as I am concerned, is exactly 
the same: To update the spec so that it can be clearer and better 
aligned with actual practice.

Fourth, possibly the most serious compatibility issue between RFC 3987 
as written and 3987bis as it is currently written is the change from 
IDNA 2003 to IDNA 2008. There are varying opinions on whether the change 
from IDNA 2003 to 2008 was the right thing to do. But given that you are 
one of the main contributors to IDNA 2008, I wouldn't expect you to 
throw the first stone at 3987bis.

Fifth, while there have been some proposals in the IRI WG (and before in 
chartering it) to be more liberal with backwards compatibility and 
compatibility with URIs, I have tried hard (and I think up to now 
succeeded) to make sure that this is preserved. As an example, the 
charter of the IRI WG contains an explicit provision that a rechartering 
is needed should any updates to RFC 3986 become necessary.

So I think what's unfortunate is not the timing of development of the 
two specs, but the timing of your confusion. I hope this can be cleared 
up very soon.

If you can point out anything in the actual current 3987bis draft 
(rather than the discussion surrounding it) that let to your confusion, 
I'd appreciate it if you could tell the IRI WG, so that we can (if 
necessary after discussion) fix this as soon as possible.

Regards,    Martin.