Subject: [Ltru] Small bibliography error in RFC 4930

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 17 Jun 2007 21:26:52 +0200

RFC 4930 has several normative references to RFC 3066.

RFC 4930 has been approved by the IESG in January 2007 and published
in May 2007.

RFC 3066 have been obsoleted by RFC 4646 in September 2006, several
months before.
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 17 Jun 2007 21:59:32 +0200

On Sun, Jun 17, 2007 at 09:26:52PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> RFC 4930 has several normative references to RFC 3066.
...
> RFC 3066 have been obsoleted by RFC 4646 in September 2006, several

It is difficult even for the IETF to keep track of its own standards
:-(

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 18 Jun 2007 10:41:36 +0100

Stephane wrote:

> It is difficult even for the IETF to keep track of its own 
> standards :-(

I agree.  I have had many difficulties with this.  I think it would be a
good idea if every time an RFC is made obsolete by the publishing of a new
RFC that the new RFC reference is added to the old RFC - preferably on the
first page under "Obsoletes:". Add a new line "Obsoleted by/date:" ? How
could this best be achieved across the IETF? 

Debbie

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:[email-masked]] 
> Sent: 17 June 2007 21:00
> To: [email-masked]
> Subject: [Ltru] Re: Small bibliography error in RFC 4930
> 
> On Sun, Jun 17, 2007 at 09:26:52PM +0200,  Stephane 
> Bortzmeyer <[email-masked]> wrote  a message of 27 lines 
> which said:
> 
> It is difficult even for the IETF to keep track of its own 
> standards :-(
> 
> 
> 
>

---

From: Alice Hagens <[email-masked]>
Date: Mon, 18 Jun 2007 09:21:34 -0700

Stephane,

This was not an error. On 4/3/07, Scott Hollenbeck wrote the  
following in response to a question from the RFC Editor:

>> (3) 3730bis
>> Is RFC 3066 referenced purposely? Suggest replacing with (or
>> at least
>> adding) a reference to 4646 or 4647.
>>
>
> The reference to 3066 is deliberate.  It should stay that way.

RFC Editor/ah

---

From: Alice Hagens <[email-masked]>
Date: Mon, 18 Jun 2007 09:26:26 -0700

Sorry; replied before getting through my mail.

RFC Editor/ah

On Jun 18, 2007, at 5:39 AM, 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.  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.
>
> 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
>
> Consistency was thus thought to be a good thing.  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.
>
> -Scott-
>
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Stephane Bortzmeyer
>> Sent: Sunday, June 17, 2007 3:27 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: [ietf-provreg] Small bibliography error in RFC 4930
>>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 18 Jun 2007 08:39:44 -0400

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

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:

Consistency was thus thought to be a good thing.  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.

-Scott-

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Jun 2007 12:40:31 +0900

At 21:39 07/06/18, Hollenbeck, Scott wrote:
>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:

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.

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

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

>If this were new work

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.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 19 Jun 2007 07:50:59 -0400

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- 

> From: Martin Duerst [mailto:[email-masked]] 
> Sent: Monday, June 18, 2007 11:41 PM
> To: Hollenbeck, Scott; Stephane Bortzmeyer; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ltru] RE: [ietf-provreg] Small bibliography 
> error in RFC 4930
> 

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.

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

> 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 in doubt, it would have been easy for the WG or the IESG to

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

-Scott-