Subject: [Ltru] Re: Language Tag MIB Textual Convention

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Nov 2006 22:13:59 -0800

Hi -

(I'm CC-ing the ltru WG as a courtesy, and writing as a
technical contributor in SNMP-land with some knowledge
of the ltru WG's work)

> From: "Bill Fenner" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, November 07, 2006 8:50 AM
> Subject: Language Tag MIB Textual Convention
>
> 
> Randy,
> 
>   David McWalter and Andy Kessler are revising a IP Multicast Routing
> MIB, which for odd reasons has a Textual Convention for an RFC1766
> Language Tag:
> 
> -- Textual Conventions
> 
> LanguageTag ::= TEXTUAL-CONVENTION
> 
>    DISPLAY-HINT "100a"
>    STATUS       current
>    DESCRIPTION
>             "An RFC 1766-style language tag, with all alphabetic

This should refer to BCP 47.

>             characters converted to lowercase.  This restriction is

In RFC 4646 section 2.1 there is a differing RECOMMENDED
practice, but I don't see this as sufficient reason to change
this, particularly if there are already deployed implementations.

>             intended to make the lexical ordering imposed by SNMP useful
>             when applied to language tags.  Note that it is

This attributes more utility to SNMP "lexical" ordering than it deserves.
The only advantage (from an SNMP indexing prespective) is that
the case-mapping makes the index value unique.  To drive home
the point, here's an example, showing how some tags would be
ordered, using SNMP's rules for "lexicographical" ordering:

 de
 en
 fr
 it
 zh
 frs
 mga
 en-us
 en-gb
 fr-ca
 zh-hant
 frs-arab
 zh-hans-tw

Yes, this is a sorted list!
I think you can agree with me that few would consider
this particular ordering "useful."  So I suggest saying
something like:

   When this textual convention is used for an INDEX,
   the restriction to lower case ensures that all the possible
   representations for a particular tag will map to the same
   value, thus simplifying table lookups.

More controversial might be this additional text:

    For user interface purposes, it is RECOMMENDED
    that values be displayed using upper and lower case
    in accordance with the recommendations of BCP 47,
    even though the value 'on the wire' MUST be lower case.
 
>             theoretically possible for a valid language tag to exceed
>             the allowed length of this syntax, and thus be impossible to
>             represent with this syntax.  Sampling of language tags in
>             current use on the Internet suggests that this limit does
>             not pose a serious problem in practice."

The limit sould indeed be adequate.  See http://www.ietf.org/rfc/rfc4646.txt
section 4.3.1 for supporting analysis.

>    SYNTAX       OCTET STRING (SIZE (1..100))
> 
> We decided that this should at least be in a different MIB module,
> so that it could be imported without caring about the IP Multicast
> aspects, but then further discussion with Ted and Dan suggested
> that it might be useful for it to be in a different document
> altogether.  Ted had thought that it might be good to create a URL
> TC at the same time.

I recall some past discussion of that - I have no problem with the idea.
 
>   Do you have any thoughts on this?

See above.  :-)
 
> Thanks,
>   Bill

Randy

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Nov 2006 22:28:36 -0800

Hi -

>  en-gb

oops - these two were reversed.  The rest of the list
is indeed sorted, according to SNMP's rules.

Randy

---

From: "David McWalter" <[email-masked]>
Date: Thu, 9 Nov 2006 02:21:08 -0000

Randy,

Thanks for your help.  Below are TCs including your text.  I'd welcome any further advice.

I'll put this in an individual submission at the same time I revise IPMCAST MIB, I guess early next week.
http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast-mib-03.txt

I was surprised no-one had defined a URL TC before, so I searched and found:
http://www1.ietf.org/mail-archive/web/imss/current/msg00516.html
'There is currently a discussion going on w.r.t. URL TC on SIP 
list and some MIB doctors (like Juergen and Dan) are also involved.'

I'm really happy to not do URLs if someone else has started on this already.

Cheers,
David McWalter.
[email-masked]

LANGTAG-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI
    TEXTUAL-CONVENTION                 FROM SNMPv2-TC;

langTagMIB MODULE-IDENTITY
    LAST-UPDATED "200611080000Z" -- 8 November 2006
    ORGANIZATION "IETF Operations and Management Area"
    CONTACT-INFO "EMail: [email-masked]"
    DESCRIPTION
            "The MIB module defines textual conventions for representing
            generic tags."
    REVISION     "200611080000Z" -- 8 November 2006
    DESCRIPTION
           "Initial revision, published as RFC yyyy."
    -- RFC Ed.: replace yyyy with actual RFC number & remove this note
    ::= { mib-2 yyyy }
    -- RFC Ed.: replace yyyy with actual RFC number & remove this note

--
-- This language tag is case insensitive.  For user interface purposes,
-- it is RECOMMENDED that values be displayed using upper and lower case
-- in accordance with the recommendations of BCP 47, even though the
-- value 'on the wire' MUST be lower case.
--
LanguageTag ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "100a"
   STATUS      current
   DESCRIPTION
            "A brief tag that identifies a language.  A registry of tags
            is available at
            http://www.iana.org/assignments/language-tags.

            This value is case-insensitive.  Conventions exist for the
            capitalization of some of the subtags, but these do not
            convey any meaning.

            It is theoretically possible for a valid language tag to
            exceed the allowed length of this syntax, and thus be
            impossible to represent with this syntax.  Sampling of
            language tags in current use on the Internet suggests that
            this limit does not pose a problem in practice."
   REFERENCE "RFC 4646 BCP 47"
   SYNTAX      OCTET STRING (SIZE (1..100))

Uri ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "1024a"
   STATUS      current
   DESCRIPTION
            "A Uniform Resource Identifier (URI)."
   REFERENCE "RFC 3986 STD 66 and RFC 3305"
   SYNTAX      OCTET STRING (SIZE (1..1024))

Url ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "1024a"
   STATUS      current
   DESCRIPTION
            "A Uniform Resource Locator (URL)."
   REFERENCE "RFC 3986 STD 66 and RFC 3305"
   SYNTAX      OCTET STRING (SIZE (1..1024))

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: 07 November 2006 22:29
To: Randy Presuhn; Bill Fenner; [email-masked]; [email-masked]
Cc: LTRU Working Group; [email-masked]; David McWalter
Subject: Re: [Ltru] Re: Language Tag MIB Textual Convention

Hi -

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Nov 2006 19:10:47 -0800

Hi -

As a technical contributor...

> From: "David McWalter" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Bill Fenner" <[email-masked]>; <[email-masked]>;
<[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, November 08, 2006 6:21 PM
> Subject: RE: [Ltru] Re: Language Tag MIB Textual Convention
...
> -- value 'on the wire' MUST be lower case.

It's better to put this sort of thing in the DESCRIPTION rather
than in an comment.

>              http://www.iana.org/assignments/language-tags.

A sanity check might be in order.  The registry is of sub-tags,
which are combined using the syntax defined in BCP 47 to form
a language tag. I think it would be better to say something like:

    A language tag, constructed in accordance with BCP 47.

>             capitalization of some of the subtags, but these do not

This does precisely the wrong thing if anyone ever wants to
use one of these for an OBJECT-TYPE that will be used in
an INDEX clause.   I think there are two realistic alternatives:
    (a) limit everything to lower case, preserving compatibility
          with existing MIB objects
    (b) require it to conform to the RECOMMENDED case
         conventions of BCP 47

(a) is simpler and easier on agents.
I think the user interface gains from (b) are negligible, since
any serious user interface should supply a properly localized
language name, rather than a tag, for user consumption.
Consequently, I think (a) is a *slightly* better choice, primarily
because it's harder for agent implementors to get it wrong,
and because it would be easier for conformance testers to verify.

>             this limit does not pose a problem in practice."
...

We can make a stronger statement than that last sentence.
I suggest:
    The analysis of language tag lengths in BCP 47 confirms
     that this limit will not pose a problem in practice.

Randy

---

From: "David McWalter" <[email-masked]>
Date: Thu, 9 Nov 2006 05:52:17 -0000

Thanks, Randy.

You're especially correct about the need for uniquely-determined case values for indexes.  I've taken a guess that this is the right thing to do for URI/URLs as well.

Revised text...
DMcW.

IMPORTS
    MODULE-IDENTITY, mib-2             FROM SNMPv2-SMI
    TEXTUAL-CONVENTION                 FROM SNMPv2-TC;

LanguageTag ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "100a"
   STATUS      current
   DESCRIPTION
            "A language tag, constructed in accordance with BCP 47.

            Only lowercase characters are allowed.  The purpose of this
            restriction is to provide unique language tags for use as
            indexes.  BCP 47 recommends case conventions for user
            interfaces, but objects using this convention MUST use
            only lowercase.

            In theory, BCP 47 language tags are of unlimited length.
            This language tag is of limited length.  The analysis of
            language tag lengths in BCP 47 confirms that this limit
            will not pose a problem in practice."
   REFERENCE "RFC 4646 BCP 47"
   SYNTAX      OCTET STRING (SIZE (1..100))

Uri ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "1024a"
   STATUS      current
   DESCRIPTION
            "A Uniform Resource Identifier (URI) as defined by STD 66.

            Only lowercase characters are allowed.  The purpose of this
            restriction is to provide unique URIs for use as indexes.
            URI normalization capitalizes letters in escape sequences,
            but objects using this convention MUST use only lowercase.

            STD 66 URIs are of unlimited length.  This textual
            convention imposes a length limit on the URIs that it can
            represent."
   REFERENCE "RFC 3986 STD 66 and RFC 3305"
   SYNTAX      OCTET STRING (SIZE (1..1024))

Url ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "1024a"
   STATUS      current
   DESCRIPTION
            "A Uniform Resource Locator (URL) as defined by STD 66.

            Only lowercase characters are allowed.  The purpose of this
            restriction is to provide unique URLs for use as indexes.
            URL normalization capitalizes letters in escape sequences,
            but objects using this convention MUST use only lowercase.

            STD 66 URLs are of unlimited length.  This textual
            convention imposes a length limit on the URLs that it can
            represent."
   REFERENCE "RFC 3986 STD 66 and RFC 3305"
   SYNTAX      OCTET STRING (SIZE (1..1024))

---

From: Martin Duerst <[email-masked]>
Date: Fri, 10 Nov 2006 16:13:31 +0900

Hello David,

Randy (who, in contrast to me, is a MIB expert) has spotted
most of the language-tag related issues. Just one more issue
below.

>            "The MIB module defines textual conventions for representing

What kind of 'generic tags'? Can you please change this to

    DESCRIPTION
            generic language tags."

Maybe the 'generic' can even be left out, I wouldn't know what
it refers to (there are not 'specific' language tags).

Regards,    Martin.

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