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

[Simon Josefsson]

John C Klensin <klensin at jck.com> writes:

> I think that what this means is that 
>
> 	(i) The new charter should explicitly indicate that this
> 	(IDNAbis) work does not obsolete nameprep.

I agree.

> 	It might indicate that it would leave it a partial orphan.

There is no IETF status to express that, I think.  This status will be
implied if we specify a new IDNA approach and make new protocols use it.
Eventually Nameprep can be re-classified as HISTORIC once we finish
(ii):

> 	(ii) Once the work is finished, we need to go back and
> 	review each of the documents that Simon has identified
> 	(even the informative-reference ones) and prepare one or
> 	more new documents that update _them_ with better
> 	references and/or references to IDNAbis and/or clarify
> 	the relationship of Nameprep to other things.  If that
> 	document were to succeed in effectively eliminating all
> 	pointers to Nameprep, it could then obsolete it. 

We could start to do this now, if we cared to.  If the documents indeed
should reference IDNA and use IDN-aware domain name slots instead of
referncing Nameprep, that is a mistake regardless of IDNABIS.

> But I don't see any of that as being in the critical path for
> the proposed WG.

Right.  Still, this suggests the WG needs to clearly specify which
documents are to be updated/obsoleted.

I think we have established that StringPrep and NamePrep should not be
updated, right?

I don't see any need to revise Punycode?

Thus, the scope of the IDNABIS WG should be to create a replacement for
RFC 3490 (IDNA).  That should be in the WG charter in my opinion.

>> It would be nice to give guidance for what protocols that rely
>> on Nameprep should be doing when IDNA200x is finished.
>
> As indirectly suggested above, I think we are going to have to
> go through them on a case by case basis and see if they should
> really be referencing Nameprep, IDN-aware slots and IDNA (and
> eventually IDNAbis), or Stringprep directly.   I think we may
> discover all three cases.

Agreed.

/Simon