Subject: [MIB-DOCTORS] FW: I-D ACTION:draft-mcwalter-langtag-mib-00.txt

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 14 Nov 2006 23:49:21 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 10:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-mcwalter-langtag-mib-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Language Tag MIB
	Author(s)	: D. McWalter
	Filename	: draft-mcwalter-langtag-mib-00.txt
	Pages		: 8
	Date		: 2006-11-14
	
   This MIB module defines a textual convention to represent BCP 47
   [RFC4646] language tags.  The intent is that this textual convention
   will be imported and used in MIB modules that would otherwise define
   their own representation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcwalter-langtag-mib-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-mcwalter-langtag-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mcwalter-langtag-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Nov 2006 00:16:00 +0100

> http://www.ietf.org/internet-drafts/draft-mcwalter-langtag-mib-00.txt

My comments:

a) s/Jeurgen/Juergen
b) Section 4.3.1 in RFC 4646 points to lengths of 33 characters as the
   MUST minimum and 42 characters as the SHOULD minimum. This is
   important information to capture since a language tags in an index
   should most likely be still 33 characters long. Perhaps it makes
   sense to add LanguageTag33 and LanguageTag42 TCs with an
   appropriate reference to section 4.3.1 in RFC 4646 and to drop the
   length restriction from the LanguageTag TC, adding a note that
   SIZE constraints can be added when the TC is used but such restrictions
   SHOULD be consistent with the requirements set forth in section 4.3.1
   in RFC 4646 to avoid truncation?
c) My suggestions for revising the security considerations in the URI
   document apply here as well.

/js

-- 
Juergen Schoenwaelder		 International University Bremen
				 (Jacobs University Bremen as of Spring 2007)
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 14 Nov 2006 16:46:17 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: "MIB Doctors" <[email-masked]>; "David McWalter" <[email-masked]>
> Sent: Tuesday, November 14, 2006 3:16 PM
> Subject: Re: [MIB-DOCTORS] FW: I-D ACTION:draft-mcwalter-langtag-mib-00.txt
...
>    in RFC 4646 to avoid truncation?

My own preference would be to define the TC's upper limit in one place,
though it's not a horribly strong one.

The analysis in RFC 4646 was motivated by widespread misconceptions
about the length (and structure) of language tags under RFC 3066.  It's
really a "if you don't allow at least this much space, you're asking for trouble"
analysis.  It wouldn't shock me if the numbers were to drift upward in the
future of the BCP as support for other parts of ISO 639 comes into play,
or if some of the proposals for handling transcriptions and transliterations
were adopted. Others might disagree - the discussion in ltru is still ongoing
as part of the revision of the BCP.  The 100 octet limit is clearly
overkill, but I'd be nervous about pushing it too low.  At this moment,
I'd guess that 60 would be a very conservative, reasonably future-proof
limit.

A closely related comment:
I think the lower bound for the length should be 0, to permit representation
of the case where no tagging information is present.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Nov 2006 08:09:41 +0100

> I'd guess that 60 would be a very conservative, reasonably future-proof

I am concerned about table indexing situations and the fact that
people may not read the rationale given in RFC 4646 when they pick a
number.

> of the case where no tagging information is present.

I agree.

/js