Subject: [Technical Errata Reported] RFC4282 (1850)

From: RFC Errata System <[email-masked]>
Date: Tue, 8 Sep 2009 08:38:52 -0700 (PDT)

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1850

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]>

Section: 2.4

Original Text
-------------
   o  Unassigned code points are specified in Section 2.5 of [RFC4013].
      The use of unassigned code points is prohibited.

Corrected Text
--------------
  o Unassigned code points MUST be ignored

Notes
-----
Unassigned code points sometimes go through a process called "assignment".  This means that they suddenly become valid.

Implementations that forbid unassigned code points will not be updated when the standards change to assign them.  Therefore, they should ignore unassigned code points.

Happily, this is what all implementations do.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 Sep 2009 19:44:07 +0200

I thought about writing a long response to this, referencing RFCs 3454 &
4013 and the Unicode 3.2 standard but in the end decided that the use of
logic and analysis would be a total waste of time.  So I'll just say that
this Errata makes no sense at all & let it go at that.  To understand why
it's nonsense, you'll have to do your own research.

> Unassigned code points sometimes go through a process called
> "assignment".  This means that they suddenly become valid.
> 
> Implementations that forbid unassigned code points will not be updated
> when the standards change to assign them.  Therefore, they should
> ignore unassigned code points.
>

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 10 Sep 2009 11:07:18 +0200

Jari Arkko [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> Humor me

If you insist...

> Apparently I don't understand i18n as well as the rest of you do :-)

I absolutely not an expert on internationalization (though I confess to
having conversed occasionally with Paul Hoffman & Harald Alvestrand, who are
veritable founts of knowledge on the subject -- hopefully if I get any of
this wrong one of them can save us from my ignorance): the last work I did
on it was for L2TPv3 more than 4 years ago.  Fortunately, however, no such
expertise is really needed, aside from the abilities to read and reason.
The reference in the original text to which the erratum refers is to section
2.5 of RFC 4013, but that just points to Appendix A.1 of RFC 3454.  Appendix
A.1 is just a list of the unassigned code points in Unicode 3.2.  There is
no mechanism specified in 3454 for assigning code points (via IANA, for
example); that's because code points are assigned in the Unicode standard.
That should be enough: the list of unassigned code points is in an RFC
which, by definition, will never change.  If, however, one possessed a
little bit of knowledge about Unicode (say, from spending 20-30 minutes
looking around http://www.unicode.org) one could discover that the assigned
and unassigned code points are part of the Unicode repertoire for a given
major or minor version of the standard.  This means that section A.1 of RFC
3454 defines forever the set of unassigned code points: unassigned code
points may be assigned but not in v3.2.  I hope it's clear from this
discussion that talking about "unassigned code points" w/o reference to a
stringprep profile or Unicode version is meaningless.  The "old text" was
correct and precise, including a stable reference to a well-defined set of
code points; the proposed replacement text is, quite literally, nonsense.

> Jari