Subject: [Ltru] Re: Fw: errata for RFC 4646 Appendix B

From: "Doug Ewell" <[email-masked]>
Date: Wed, 14 Mar 2007 08:08:16 -0700

Nicolas Krebs <nicolas1 dot krebs3 at netcourrier dot com> wrote:

>> Appendix B says:
>>
>>   sl-rozaj (Resian dialect of Slovenian
>>
>> It should say:
>>
>>   sl-rozaj (Resian dialect of Slovenian)
>
> urn:ietf:rfc:4646 Appendix B ( 
> http://tools.ietf.org/html/rfc4646#page-56 ) has indeed a missing 
> bracket, and urn:ietf:id:draft-ietf-ltru-4646bis-02 too ( 
> http://tools.ietf.org/html/draft-ietf-ltru-4646bis-02#page-61 ).
>
> I suggest to fix this in official errata of rfc 4646, and in rfc 
> 4646bis.

Is this appropriate for a missing parenthesis in a text description of a 
non-normative example?

I agree that it's an error, and my experience with RFC errata is 
severely limited, but I tend to think of them as being more suited to 
errors that might affect implementations or otherwise lead to genuine 
misunderstanding.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 14 Mar 2007 19:21:04 +0100

Doug Ewell wrote:

> Is this appropriate for a missing parenthesis in a text description
> of a non-normative example?

Yes, errata are also used for typos.  The ABNF erratum (when it's
submitted) is of course somewhat more interesting... :-)

Frank

---

From: Martin Duerst <[email-masked]>
Date: Thu, 22 Mar 2007 18:12:43 +0900

>> I suggest to fix this in official errata of rfc 4646, and in rfc 4646bis.
>
>Is this appropriate for a missing parenthesis in a text description of a non-normative example?

I very much agree with your sentiment, re. the errata page (of course
not re. our new draft, that definitely should be used to fix typos).

>I agree that it's an error, and my experience with RFC errata is severely limited, but I tend to think of them as being more suited to errors that might affect implementations or otherwise lead to genuine misunderstanding.

The current state is that it's already in the ERRATA, but marked as
UNVERIFIED. We may as well tell the RFC Editor that the can make that
official. Telling them that this is indeed correct, but not worth to
put on the page doesn't seem to make much sense to me.

If I don't receive any objections in the next couple days, I'll
write to tell the RFC editor that this ERRATUM is official
(or whatever they call the respective state).

Regards,    Martin.

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

---

From: Martin Duerst <[email-masked]>
Date: Thu, 22 Mar 2007 18:12:43 +0900

Regards,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Mar 2007 20:47:30 +0100

Martin Duerst wrote:

> I'll write to tell the RFC editor that this ERRATUM is official

I thought that only RFC authors can "verify" errata (?)  In the
case of this obvious typo I've no idea why the RFC editor added
an "UNVERIFIED" note - maybe they fear that "somebody" could try
to start another avalanche of appeals.

If you try to verify the typo anyway please submit also the real
ABNF erratum, the RFC says:

|   ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
|   UNICHAR    = "&#x" 2*6HEXDIG ";"

But actually this should be:

|   ASCCHAR    = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
|   UNICHAR    = %x26.23.78 2*6HEXDIG ";"    ; Lower case "x" in "&#x"

Frank