Re: [EAI] Confusion about backwards-compatibility of 3987bis/IRIs

[I meant to cc the IRI WG, but apparently I didn't. This now goes 
separately to the IRI WG, if you want it to be cross-posted because it's 
relevant to both groups, please cc. ima@ietf.org, the mailing list of 
the EAI WG.]

On 2012/07/13 20:04, "Martin J. Dürst" wrote:
> [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.
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima
>

Received on Monday, 16 July 2012 09:57:17 UTC