Final Sigma (was: RE: Esszett, Final Sigma, ZWJ and ZWNJ)

[Mark Andrews]

In message <5E65B2325D4E8E523D764B92 at PST.JCK.COM>, John C Klensin writes:
> 
> 
> --On Saturday, February 28, 2009 10:44 +1100 Mark Andrews
> <Mark_Andrews at isc.org> wrote:
> 
> > 	You could get partial support the moment the type code was
> > 	allocated.  Clients would query for the record.  Authoritative
> > 	servers could use unknown type support to add the record.
> > 	It would work for all names except those with CNAMEs.
> 
> Excuse me?  How can one expect clients to "query for the record"
> before they, and the protocols they support, are updated?

	Say that IANA assigns 56 for this record (HIP + 1).  The
	existing infrustructure supports loading, caching and
	querying for TYPE56 as a opaque blob.   Applications just
	query for TYPE56.  As the servers and caches upgrade they
	go from treating it as a opaque blob to something with a
	structure they are aware about.

	They also learn in the process the new rules associated
	with TYPE56 and stop following CNAME's when doing lookups
	etc.

> Remember that, as one moves out toward the stub resolvers, there
> are a lot of systems that haven't heard of RRSIG or even EDNS0
> and that will probably be updated only when their hardware rusts
> out.  You also said some things about the additional section --
> I assume that any required changes there would require software
> development and deployment.  Is that not correct?
>
> > 	Support for CNAMEs requires servers and caches to be updated.
> 
> And, of course, a decision that adding this type of information
> to CNAMEs is wise given that it is metadata and much closer to
> an ordinary RR than RRSIG is.
> 
> Incidentally, no directionality indicator is needed: Bidi is
> complicated, but largely takes care of itself unless you have
> visions of right-to-left Latin strings.
> 
>      john
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org