Subject: RE: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)

From: "Addison Phillips" <[email-masked]>
Date: Mon, 20 Jun 2005 20:57:01 -0700

Changes in the editor's copy.

http://www.inter-locale.com/ID/draft-ietf-ltru-registry-06.html
http://www.inter-locale.com/ID/draft-ietf-ltru-registry-06.txt

~Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Addison Phillips
> Sent: 2005?6?20? 20:47
> To: Martin Duerst; Randy Presuhn; LTRU Working Group
> Subject: RE: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)
> 
> Some notes below.
> 
> Addison
> 
> Addison P. Phillips
> Globalization Architect, Quest Software
> Chair, W3C Internationalization Core Working Group
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Martin Duerst
> > Sent: 2005?6?20? 18:21
> > To: Randy Presuhn; LTRU Working Group
> > Subject: Re: [Ltru] Can we live with #944 as in draft -05? (yes, BUT)
> >
> > At 08:38 05/06/21, Randy Presuhn wrote:
> >  >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.
> >
> > 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.
> [Addison Phillips]
> 
> It isn't strictly existing protocols, since any protocol might have a
> length limitation. I don't think the extra verbiage is necessary to point
> out that these might be legacy 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).
> [Addison Phillips]
> 
> That's a no-op change, if there ever was one. It's good because it drops
> the rather convoluted "disposition" in favor of the more Anglo-Saxon
> phrasing you suggest. I'll make this change.
> >
> > -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?
> [Addison Phillips]
> 
> Divided is, to be sure, a special case of invalid. But a divided subtag
> might be valid per the ABNF--or even the registry. It makes sense to call
> out the special case of not chopping mid-tag.
> >
> > 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 "-".
> [Addison Phillips]
> 
> Okay.
> >
> > 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.
> [Addison Phillips]
> 
> This text is more-or-less inherited. Must we remove all vestiges of
> Harold's authorship? But I'll be sufficiently creative to spell out that a
> tag is an identifier... :-)
> >
> > 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.
> [Addison Phillips]
> 
> No. Section 2 has plenty of structure.
> >
> > 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".
> [Addison Phillips]
> 
> Okay, I'll fix that.
> >
> > 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].
> [Addison Phillips]
> 
> I'll look into it. I have developed a strong aversion to xml2rfc. W3C
> Specifications are much cleaner.
> >
> > -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.
> [Addison Phillips]
> 
> Agreed.
> >
> > 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."
> [Addison Phillips]
> 
> Okay.
> >
> > Also, I'd change "derivation" to something else. "derivation" sounds
> > too much like a logical, undavoidable process.
> [Addison Phillips]
> 
> "How we figured the length limit" sounds too conversational? Derivation is
> a bit stodgy, but that's life.
> >
> > 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.
> [Addison Phillips]
> 
> Okay.
> >
> > 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.
> [Addison Phillips]
> 
> This example was taken from a particular thread "early" on in this WG's
> life. Since it is a private use tag, any sort of illogical garbage might
> exist. That said, "zh-latn-CN-variant1-a-extend1-x-wadegile" would
> actually make some sense, wouldn't it?
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 20 Jun 2005 21:20:36 -0700

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>; "Martin Duerst" <[email-masked]>; "Randy Presuhn"
<[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Monday, June 20, 2005 8:57 PM
...

Ok, can we get a hum on whether these address everyone's
concerns regarding issue #944?

Randy, ltru co-chair