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

[John C Klensin]

--On Tuesday, 18 March, 2008 22:23 +0100 Simon Josefsson
<simon at josefsson.org> wrote:

> 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.

Yes.  I continue to have the delusion that the IETF can adapt
easily to circumstances and apply good sense rather than looking
at existing rules and categories and treating them as
Procrustean beds.   But it is clear that it is a delusion.

>  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.

Yes.  I don't have the spare cycles to take this on right now,
or even the cycles needed to review a document produced by
someone else.  Others might prefer to see how this work comes
out before trying to examine the relationships of other
documents to Nameprep.  But you are certainly correct that there
is no formal bar to trying to verify and, if appropriate,
correct existing non-IDNA references to Nameprep.

>> 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?

No.  And I think that, fwiw, "Rationale" says that explicitly.
I'm reluctant to put "won't revise StringPrep or NamePrep" into
the charter because there are all sorts of things the WG won't
revise, including, e.g., RFC 3987 (which it might plausibly take
a look at) or RFC 2616 (which I would not consider plausible).
My main issue is that I would prefer that we not have to
complete a case-by-case analysis of all of the documents
concerned with internationalization so we can decide whether
this hypothetical WG should look at them... I'd rather get on
with the work.

> 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.

If that isn't obvious, I personally have no objection to its
being in the charter.

best,
   john