Martin J. Dürst
2012-07-16 09:56:39 UTC
[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. ***@ietf.org, the mailing list of
the EAI WG.]
separately to the IRI WG, if you want it to be cross-posted because it's
relevant to both groups, please cc. ***@ietf.org, the mailing list of
the EAI WG.]
[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,
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.
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
https://www.ietf.org/mailman/listinfo/ima
[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,
Hi Martin,
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...
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 boundAs 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
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.
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.
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
https://www.ietf.org/mailman/listinfo/ima