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

[Simon Josefsson]

Paul Hoffman <phoffman at imc.org> writes:

> Lisa said:
>
>>Here are the TODOs on the charter from the meeting:
>>  - Consensus to be more specific which RFCs the new work would
>> obsolete, vs update or leave alone
>
> As discussed in the f2f meeting, removing Stringprep from the list of
> documents that would be updated is absolutely required.

+1

> The current work doesn't update Stringprep, it replaces it within the
> context of IDNA200x with a very different paradigm.

Right.

> 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 4018 reference nameprep.  Rather than using nameprep, perhaps it
  should have specified that its domain slots are IDN-aware and just
  reference IDNA instead, though.

* RFC 4279 reference nameprep, but only informatively.  Perhaps it
  should have referenced just IDNA; similar to RFC 4018.

* RFC 4343 reference nameprep, but only informatively.  It seems fine.

* RFC 4414 reference nameprep.  Perhaps it should have referenced just
  IDNA; similar to RFC 4018.

* RFC 5144 reference nameprep.  Perhaps it should have referenced just
  IDNA; similar to RFC 4018.

* RFC 4185, RFC 4290, RFC 4690, RFC 4713 are informational, and is
  probably not a problem.

I fear that obsoleting nameprep is going to be messy.  That was the
reason I brought this up in the first place.

It would be nice to give guidance for what protocols that rely on
Nameprep should be doing when IDNA200x is finished.

I note that using a new prefix instead of xn-- would avoid this problem.
Specifications and implementations that use IDNA2003 continue to use
xn-- and will work fine within its limitations.  New specifications and
implementations that support IDNABIS will use another prefix and also
work fine.

I'm not suggesting we adopt this approach, but I haven't
seen the disadvantages of changing the prefix clearly expressed yet.

There is a cost in maintaining both IDNA2003 and IDNABIS encodings of
strings during a transition-period.  Whether that cost is higher or
lower than the complexity in re-using the old prefix for something that
won't be fully backwards compatible is not clear to me.

I'm assuming IDNABIS won't be (fully) backwards compatible with
IDNA2003.  That is the impression I have gotten from all discussions so
far.

/Simon