Wwhich RFCs the new work would obsolete, vs update or leave alone

[Simon Josefsson]

Marcos Sanz/Denic <sanz at denic.de> writes:

>> > Similarly, we should remove Nameprep from the list of documents that
>> > are obsoleted unless we are sure that there are no other RFCs that
>> > rely on Nameprep. If we are sure nothing else relies on Nameprep
>> > (unless it is also relying on IDNA2003 in general), we can keep
>> > Nameprep on the list of things to be obsoleted.
>> 
>> I did a quick scan:
>
> [...]
>
>> * RFC 5144 reference nameprep.  Perhaps it should have referenced just
>>   IDNA; similar to RFC 4018.
>
> RFC 3982 is missing from your list. And I don't think that 3982 or 5144 
> are exactly similar to the 4018 case, since they are IRIS profiles with a 
> domain name slot to carry the "normalized" form of the IDN (that is, after 
> Nameprep). They could maybe have got away with 
> ToUnicode(ToASCII(domainname)) instead of Nameprep(domainname), modulo the 
> few subtle well-known differences.

I looked more closely at RFC 3982, and I believe it should use
ToUnicode(domainname) as described in section 4 of RFC 3490.  Am I
correct that the <idn> children should contain the UTF-8 version of the
IDN?  If so, it is a IDN-aware domain name slot.  It should also discuss
whether the string is to be treated a stored or query string.

If this is not done, the protocol won't translate, for example, the
string U+3002 into '.', which is done by ToUnicode but not by Nameprep.

I see you are named as co-author of RFC 3982.  Do you think it would be
useful to revise the document to fix this?

/Simon