Subject: RE: [Ltru] Re: #944 in draft -04

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 10 Jun 2005 09:53:09 -0700

Hi,

The charset name limit of 40 is _only_ for the "cs..." Alias
required for the MIBenum (numeric) value for the IANA Charset
MIB.  

Here's the relevant quote from page 4 of RFC 2978:

   "All charsets MUST be assigned a name that provides a display string
   for the associated "MIBenum" value defined below.  These "MIBenum"
   values are defined by and used in the Printer MIB [RFC-1759].  Such
   names MUST begin with the letters "cs" and MUST contain no more than
   40 characters (including the "cs" prefix) chosen from from the
   printable subset of US-ASCII."

The limit in the registry itself of all charset names to 40 characters
has been there for years as a comment, so I suppose that's the rule that 
IANA _thinks_ they're enforcing (despite Frank's examples).

Cheers,
- Ira

> > 
> > > The longest charset permitted is 40
> > 
> > Really ?  I only looked into the IANA registry, not in the RfC:
> 
> Me too: there is a note right at the top of the registry that 
> says the maximum size is 40, which I (foolishly) relied on :-).
> > 
> > Extended_UNIX_Code_Fixed_Width_for_Japanese
> > ....5...10....5...20....5...30....5...40....5
> > Extended_UNIX_Code_Packed_Format_for_Japanese
> > 
> > Okay, the latter has a decent EUC-JP preferred MIME alias, and
> > the former is a DBCS.
> 
> In any case, the text we chose on this thread works fine: the 
> limit may be more than 50 characters and it may be far less 
> than that too (there might be *NO* room with a sufficiently 
> perverse set of choices).
> 
> Addison
> 

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 20 Jun 2005 16:38:44 -0700

Hi -

I'd like to see whether we can close issue #944 regarding whether
a conformant implementation can impose length constraints and what
those constraints might be.  So I'd like to get a "hum" from the group:

Can you live with the resolution of this issue are reflected in
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-05.txt ?

As you may recall from the discussion, points of concern included
whether the MUSTs and SHOULDs made sense,  whether the
lengths given were meaningful, and whether the underlying rationale
was sufficiently clear.

Randy, ltru co-chair

---

From: Martin Duerst <[email-masked]>
Date: Tue, 21 Jun 2005 10:20:44 +0900

>lengths given were meaningful, and whether the underlying rationale

Overall, I'm quite satisfied.

But here are a few, mostly editorial, nits:
(for Randy: I think all these can be lumped together unless
somebody wants to have one of them addressed specifically).

-05.txt says:
    Some applications and protocols are forced to allocate fixed buffer
    sizes or otherwise limit the length of a language tag in a particular
    application.
It might be a good idea to reword this slightly to mention backwards
compatibility and/or to stress the fact that these would mainly be
existing protocols.

-05.txt says:
    and such
    documentation SHOULD include the disposition of any longer tags (for
    example, whether an error value is generated or the language tag is
    truncated).
I don't like the use of a noun that then gets expanded into a 'whether'
sentence. Maybe:
    and such
    documentation SHOULD include what happens to longer tags (for
    example, whether an error value is generated or the language tag is
    truncated).

-05.txt says:
    If truncation is permitted it MUST NOT permit a subtag to be divided
    or the formation of invalid tags (for example, one ending with the
    "-" character).
please at least reword to:
    If truncation is permitted it MUST NOT permit a subtag to be divided
    or an invalid tag to be formed (for example, a tag ending with the
    "-" character).
Also, I'm not sure why we need two things (divided, formed) here. Wouldn't
the later just be enough?

Somewhat more serious, it looks like the current draft talks a lot about
subtags, but never exactly says what they are. A reader has to look at
section 2.2, to somehow get the concept of subtag by enumeration, before
being able to reasonably well understand the start of 2.1.
So please, somewhere very early in 2.1, say that subtags are separated
by "-".

An even more serious problem is that section 1 speaks about language
identifiers, and the word 'tag' doesn't appear a single time in that
section. Please add something at the end of section 1 saying that
this document defines a language tag that is designed to serve as
a language identifier. Or even better, use the stem 'identif...'
just for the purpose, and the word 'tag' for the thing, as done in
the title.

Also, please give Section 2.1 more structure. If there are subsections,
good style requires that almost everything (except a relatively short
intro piece) is a subsection, and that there are at least two of them.
The easiest thing to do is to make the ABNF 2.1.1, and the length
stuff 2.1.2.

Please add a short intro paragraph to Chapter 2.

-05.txt says:
    Some specifications are space constrained but do not have a fixed
    length limitation.  For example, see [RFC 2231] [23].  This protocol
    has no explicit length limitation: the length of the language tag in
    this document is limited by the length of other header components
    (such as the charset's name) coupled with the 76 character limit in
    [RFC 2047] [10].
The referrent of 'This' is unclear. There is no protocol mentioned
before, just an RFC. The reader shouldn't have to go to the bibliography
to figure out that this might be a protocol. The referent of 'this'
is confusing, too. Is 'this document' our draft? or RFC 2231? or
a mail document being sent around? Probably best remove "in this
document".

References such as [RFC 2231] [23] look extremely ugly. Please make this
either [RFC 2231] or [RFC2231] only (my strong preference) or something
like RFC 2331 [23].

-05.txt says:
    (each subsequent subtag includes '-')
This is very dangerous. Please change to something like 'the length of
this and all subsequent subtags includes the preceeding "-"', to avoid
the impression that the "-" is in any way part of the subtag.

Also, 'showing how the 42 character recommendation was derived' and
then populating that with "unlikely" is confusing. It would be easier
to understand if these two things were separated, i.e. first giving
just the simple example, and then afterwards saying something like
"Having more than one extlang or variant is considered to be highly
unlikely, but this was included in the 42 limit to make sure that
even highly unlikely tags can be processed by applications respecting
this limit."

Also, I'd change "derivation" to something else. "derivation" sounds
too much like a logical, undavoidable process.

The text about truncation is in two different places:
First where it says:
    If truncation is permitted it MUST NOT permit a subtag to be divided
    or the formation of invalid tags (for example, one ending with the
    "-" character).
and later where it says:
    Applications or protocols which have to truncate a tag MUST do so by
    progressively removing subtags along with their preceding "-" from
    the right side of the language tag until the tag is short enough for
    the given buffer.  If the resulting tag ends with a single-character
    subtag, that subtag and its preceding "-" MUST also be removed.
The first MUST in the second paragraph seems to be very similar to
the MUST NOT above. The second MUST in the second paragraph comes as
a (somewhat unexpected) additional restriction.
Please put everything about truncation together, maybe even in its own
subsection.

I'm not sure zh-Hant-CN-variant1-a-extend1-x-wadegile makes a good example.
Wade-Giles is a romanization, one would therefore expect zh-Latn rather than
zh-Hant.

Regards,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Jun 2005 04:01:25 +0200

Randy Presuhn wrote:

> So I'd like to get a "hum" from the group:

Chapter 2.1 in -05 is fine, although I'd delete one statement:

| At up to 11 characters, this combination is longer than the
| longest possible language subtag (8 characters):

No idea what it's supposed to mean, but it's not 3 + 3*4 = 15.

                           Bye, Frank