RE: [Ltru] RE: [ietf-provreg] Small bibliography error in RFC 4930

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Martin,

The bottom line in my opinion is that 3730 implementers weren't writing
code with 4646 as a reference and it didn't seem wise to introduce a
reference change *that allows the possibility of required code changes*
and is *inconsistent with other normative references* when going from
proposed to draft.  More below.

-Scott- 

> -----Original Message-----
> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] 
> Sent: Monday, June 18, 2007 11:41 PM
> To: Hollenbeck, Scott; Stephane Bortzmeyer; rfc-editor@rfc-editor.org
> Cc: ietf-provreg@cafax.se; ltru@lists.ietf.org
> Subject: Re: [Ltru] RE: [ietf-provreg] Small bibliography 
> error in RFC 4930
> 
> At 21:39 07/06/18, Hollenbeck, Scott wrote:
> >After a private exchange with Randy Presuhn of the LTRU 
> working group I
> >realized it might be helpful if I provide more info to 
> explain why 4930
> >references 3066 instead of 4646.  First, let me confirm that 
> this wasn't
> >an oversight.  It was a conscious decision made with the 
> concurrence of
> >the IESG as we looked at the normative references and the standards
> >track status of those references.
> 
> Okay, but on hindsight, and looking at things in detail, I still
> think that this decision was wrong, and that it shouldn't be
> repeated.
> 
> >Rationale:
> >
> >1. 4930 is the draft standard version of 3730, updated to document
> >implementation experience with 3730.  3730 references 3066.  
> The first
> >drafts of what would become 4930 referenced 3066 before 4646 was
> >approved and published.  Implementers of 3730 and 4930 wrote code per
> >3066.
> 
> If you could explain how writing code per 3066 and writing code per
> 4646 would lead to any difference in the actual code or the observable
> protocol behavior, that would help us to accept this point.

You touched on this yourself below.  Additional language tags are
possible.  While I agree that this should be transparent to EPP, I
didn't see any compelling reason to require implementations and the user
interface code above those implementations to deal with the possibility.
I also had no assurances that existing XML Schema processors would
remain unaffected given that the 2004 XML Schema specs still cite 3066.

> >2. 3730 and 4930 include a language tag reference because 
> language tags
> >are used within XML Schema elements.  The October 2004 edition of the
> >normative XML Schema datatypes reference cites 3066:
> >
> >http://www.w3.org/TR/xmlschema-2/#language
> 
> If you look at this, you will easily see that:
> - The lexical space defined is in no conflict at all with the syntax
>   of RFC 4646.
> - RFC 4930, in its normative prose, only says that language tags must
>   be "structured as documented in [RFC3066]". While RFC 3066 didn't
>   use these terms, it essentially means that they must be "RFC 3066
>   well-formed", not "RFC 3066 valid".
>   The only point you might be able to claim here is that changing this
>   to RFC 4646 might create a requirement for implementations to check
>   for RFC 4646 well-formedness, which is admittedly a bit tighter than
>   RFC 3066. But the MUST is on the sender, where we can assume that
>   only valid stuff is used anyway, and you have no error message for
>   non-well-strucured-language-code, which makes sense because
>   the usual behavior, "language not available", is just good enough.

So you see no problem with including a normative reference to 4646 even
though the normative XML Schema spec cites 3066?  I do, and I believe
the IESG would have as well.

> >Consistency was thus thought to be a good thing.
> 
> The problem is that with this, you may have excluded a lot of 
> languages
> from potentially being used in your protocol, and you have created the
> impression that updating from RFC 3066 to RFC 4646 is a major 
> undertaking,
> which in most cases, it is not.

I've created no such impression.  I left the reference exactly as it was
when 3730 was approved by the IESG.  There haven't been any EPP
implementers screaming for support for 4646 language tags, so with 4930
NOT being new work there was no compelling reason to change the
reference.

> >If this were new work
> >I'd agree that 4646 would be the more appropriate reference, but that
> >would also depend on the XML specifications picking up 4646 as well.
> 
> XML already has (see http://www.w3.org/TR/REC-xml/#sec-lang-tag).
> For a previous version
> (http://www.w3.org/TR/2004/REC-xml-20040204/#sec-lang-tag),
> it already says "RFC 3066 or its successor".
> 
> As for XML Schema, I'm very sure they'll make the move. A previous
> version was on RFC 1766.
> http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#language
> If in doubt, it would have been easy for the WG or the IESG to
> check with W3C.

They might, but they haven't, and that creates a consistency problem.

-Scott-