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


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

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

Regards,    Martin.


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