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

[John C Klensin]

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

> 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 think that what this means is that 

	(i) The new charter should explicitly indicate that this
	(IDNAbis) work does not obsolete nameprep.  It might
	indicate that it would leave it a partial orphan.
	
	(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. 

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

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

See above.   And I share your belief that the Nameprep
references in some of those documents may actually be wrong and
that they should be referencing IDNA and/or IDN-aware slots and
thereby picking up the operations and constraints in RFC 3490 as
well as those of RFC 3491.  I've now taken a quick look at  RFC
4018 and am fairly sure of it in that case.   I have not looked
carefully at the others yet.

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

     john

p.s.  While I think it has been largely covered on this list,
watch for more specific notes (suitable for insertion into
"Rationale") on the "changing the prefix" issue in the next few
days.