Re: rfc3987bis and RFC 6365

Sorry, I sent this email before completing the message. Addendum below.

On 6/7/12 12:42 PM, Peter Saint-Andre wrote:
> <hat type='individual'/>
> 
> At IETF 84, we discussed the desirability of aligning the terminology in
> 3987bis with RFC 6365 ("Terminology Used in Internationalization in the
> IETF"). This is ticket #85 in the tracker:
> 
> http://trac.tools.ietf.org/wg/iri/trac/ticket/85
> 
> I've completed a review of both documents and have a few suggestions...
> 
> 1. In Section 1.3, cite RFC 6365 and specify that terms are to be
> understood as defined in that document unless otherwise specified (in
> fact, now that we have RFC 6365 it's not clear why we're citing RFC
> 2130, RFC 2277, or ISO 10646). I suggest:
> 
> OLD
>    The following definitions are used in this document; they follow the
>    terms in [RFC2130], [RFC2277], and [ISO10646].
> 
> NEW
>    Various terms used in this document are defined in [RFC6365] and
>    [RFC3986].  In addition, we define the following terms for use in
>    this document.
> 
> 2. Don't define anew in rfc3987bis terms that are defined in RFC 6365.
> That would mean removing the following definitions from Section 1.3:
> 
> - character
> - character repertoire
> - character encoding (use "character encoding scheme" or "character
> encodiring form" instead)
> - charset
> 
> 3. Do we really need to define "octet", "sequence of characters", and
> "sequence of octets"?
> 
> 4. Strangely, RFC 6365 does not define "UCS", so I suppose it's OK to
> define that here.
> 
> 5.
> 
> Peter
> 

5. Various sections use the term "character encoding" when, per RFC
6365, "character encoding scheme" seems to be meant (examples include
Sections 4, 4.1, 5.2, 5.3, 5.4, 7.1, 7.3, 7.4, and 7.7).

The other uses of i18n terminology throughout the document appear to be
consistent with RFC 6365, but it would be helpful if other folks check
as well.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Received on Thursday, 7 June 2012 19:48:02 UTC