Subject: [Ltru] RE: Gen-art review: draft-ietf-ltru-registry-12.txt

From: "Addison Phillips" <[email-masked]>
Date: Wed, 31 Aug 2005 12:36:00 -0700

I fully agree with the need to clarify as appropriate.

I'm going to do the following:

1. Forward my responses to Elwyn to the LTRU list unexpurgated.
2. Break down the results into separate items (I need this for my modification list too), with Elwyn's original issue, my response, and the associated change(s) in the editor's copy that I propose to make. Randy, if you can "rt" each one from that and we'll be in sync.

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: Randy Presuhn [mailto:[email-masked]]
> Sent: 2005?8?31? 11:50
> To: Addison Phillips; Elwyn Davies
> Cc: Martin Duerst; [email-masked]; Scott Hollenbeck; gen-
> [email-masked]
> Subject: Re: Gen-art review: draft-ietf-ltru-registry-12.txt
> 
> Hi -
> 
> I'd like to hold the rest of the follow-up discussion on the ltru WG
> mailing list,
> in order to ensure that there are no surprises and to keep a record there.
> Addison, could you include excerpts from your discussion with Elwyn in
> your
> postings to ltru? That way we should be able to quickly come to consensus
> on any changes or clarifications to the text.  I imagine that gen-
> [email-masked] is
> not terribly interested in our discussion, just the final results.
> 
> I view any case where we need to explain something to a reviewer as
> a demonstration that the material in question is not sufficiently clear,
> so
> I think that even in the cases where no change is technically needed, we
> should consider making the text even clearer or more explicit.
> 
> Randy, ltru co-chair
> ----- Original Message -----
> From: "Elwyn Davies" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" <[email-masked]>;
> "Scott Hollenbeck" <[email-masked]>;
> <[email-masked]>
> Sent: Wednesday, August 31, 2005 10:41 AM
> Subject: Re: Gen-art review: draft-ietf-ltru-registry-12.txt
> 
> 
> > Thanks for the swift responses - I am fine with most of your responses
> > and I hope they get into a revision.
> >
> > A couple of responses/clarifications below...
> >
> > Regards,
> > Elwyn
> >
> >
> >
> > Addison Phillips wrote:
> >
> > >Thanks for this note. I'm not sure of what the procedural handling of
> these comments should be. Many of these comments would make
> useful additions to the document.
> > >
> > >My main question (Randy) is: what is the process impact of
> incorporating changes based on these comments?
> > >
> > >Response comments below are personal, of course. I expect I'll be
> sending these to the list also after Randy forwards the
> message.
> > >
> > >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: Elwyn Davies [mailto:[email-masked]]
> > >>Sent: 2005?8?31? 7:19
> > >>To: [email-masked]
> > >>Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck;
> [email-masked];
> > >>Addison Phillips
> > >>Subject: Gen-art review: draft-ietf-ltru-registry-12.txt
> > >>
> > >>Background for those on the CC list, who may be unaware of GenART:
> > >>GenART is the Area Review Team for the General Area of the IETF.  We
> > >>advise the General Area Director (i.e. the IETF/IESG chair) by
> providing
> > >>more in depth reviews than he could do himself of documents that come
> up
> > >>for final decision in IESG telechat.  I was selected as the GenART
> > >>member to review this document.  Below is my review, which was written
> > >>specifically with an eye to the GenART process, but since I believe
> that
> > >>it will be useful to have these comments more widely distributed,
> others
> > >>outside the GenART group are being copied.
> > >>
> > >>
> > >>
> > <<snip>>
> >
> > >>Transition issue:
> > >>I think the transition from RFC3066 to the subtag registry needs a
> > >>little more attention.  There are a few words in s3.7, but I think the
> > >>process might need a little fleshing out.  In particular suggestions
> > >>about ensuring there is not an interregnum with no reviewer in place
> > >>(they are appointed by different authorities) and giving notice of the
> > >>changeover (e.g., a number of weeks after the publication of the
> > >>RFC(s)).  In principle the changeover should be seamless but it would
> > >>probably be good to have the initial registry in place (i.e.,
> translated
> > >>from the initial state RFC) and reviewed before it becomes
> authoritative.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >It may appear a bit vague. In practice, however, there has only ever
> been one Language (Sub)tag Reviewer, Michael Everson. The
> change in appointing authorities was suggested by the IESG itself, so
> there should be no interregnum. There are rules in place to
> deal with any in-process registrations, which would mark the main problem
> source.
> > >
> > >
> > Assuming Michael is willing to continue you shouldn't have any problems
> > with personnel, but it still might be worth asking your AD and IANA
> > about phase-in process, and seeing if there is anything worth
> documenting.
> >
> > <<snip>>
> >
> > >>Irritant:
> > >>Early in the document it is specifically set out that language tags
> are
> > >>case insensitive and should be normally represented in lower case.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >This is NOT correct. It actually says:
> > >
> > >--
> > ><<snip>>
> > >
> > You are of course right!  This was mostly provoked by thinking how messy
> > these strings looked with the assortment of case.  Your suggestion later
> > on covers most of the irritation.
> >
> > <<snip>>
> >
> > > <<snip>>
> > >
> > >>s2.2.2: This states that an extended language subtag '...MUST include
> > >>exactly one prefix field....' .  The implication of this seems to be
> > >>that the same extended language subtag cannot be used for multiple
> > >>primary languages.  I think it would be worth spelling out the
> reasoning
> > >>behind this as it might be seen as an undesirable restriction.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >That's not just the implication, but entirely the idea. Extended
> language subtags are meant to be closely associated with the
> primary language subtag. Since they occur directly after the primary
> language subtag, there are no intervening values or additional
> variants that can creep into their prefix (requiring more than one prefix).
> In addition, extlangs are expected to be used with the
> ISO 639-3 concept of "macro languages" (languages that contain other
> languages). An example of this is the spoken variation Mandarin
> Chinese. The tag for this would be zh-cmn and "cmn" would be an extlang
> with a prefix of "zh". It doesn't make sense to use "cmn"
> with a different language prefix, such as "de" or "ja".
> > >
> > >
> > >
> > What I was perhaps not saying as well as I could was: does this
> > therefore mean that you can't use the same extlang tag for different
> > primary languages?  the example you give could be a case in point -
> > 'cmn' is a reasonable abbreviation for 'common' and the space is not
> > that big - or are you allowed to register the same extlang with a
> > different prefix in a separate record?  I wasn't sure if this would be
> > allowed.
> >
> > <<snip>>
> >
> > >>pointer to this discussion in the 'Prefix' discussion in s3.1 would
> then
> > >>help.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >Good idea.
> > >
> > >
> > >>s3.1: para 1, last sentence:  Given that *all* the initial records are
> > >>in the initial registry load RFC, maintaining registration forms for
> > >>just the RFC3066 subset seems a little odd.  Why not all or none,
> since
> > >>presumably they can be created by an automated script?
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >The RFC 3066 registry is maintained in perpetuity and its format is
> different than that of the draft. That registry is maintained
> as an obsolete reference (it just seemed prudent to do so). Generating
> many registration forms for the initial set, however, doesn't
> seem that useful.
> > >
> > >
> > If the RFC3066 registry is being maintained then it seems like not
> > generating any registration forms at all would be the right answer.
> >
> > <<snip>>
> >
> > >>s3.1: definition of 'Prefix': I think a more formal (ABNF) description
> > >>of the possible values might help. Presumably an 'extlang' can have a
> > >>primary language tag and up to 2 other extlangs and a 'variant' can
> have
> > >>a complete language (including up to 3 extlangs)and possibly a script
> > >>and/or a region.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >Would that really add anything to the document? It would be easy to do,
> yes, but I'm not sure that it is unclear as written.
> > >
> > >
> > I think the words are currently a little woolly and you are reliant to
> > an extent on the examples.  If a formal definition is easy I would add
> it.
> >
> > >>s3.1: discussion of 'Preferred-Value':  '...SHOULD be preferred when
> > >>selected language tags.'  appears to be garbled... I am not sure
> exactly
> > >>what is intended.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >The value in the record that contains a 'Preferred-Value' field should
> be replaced with the value in the Preferred-Value. That
> is, Preferred-Value is how a subtag is deprecated in favor of a different
> subtag. The cases where this applies are then enumerated.
> Some textual tweaking to make this clearer is probably called for.
> > >
> > >
> > I know what the overall intent is... I just cannot parse this sentence
> > at all!  Something about generating or constructing language tags was
> > intended I suspect.
> >
> > >>s3.2: last para:  the requirement to get the case pattern of a certain
> > >>subset of tags right seems an unecessary hurdle - the registry can
> > >>enforce this if it seems really desirable.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >That requirement could be relaxed to SHOULD.
> > >
> > >
> > I think that would relieve most of my irritation.
> >
> > <<snip>
> >
> > >>s3.4: para 2 and para next but one after Figure 5: At first sight
> these
> > >>paras appear to conflict?  the second one appears to indicate that
> type
> > >>'extlang' subtags can be registered but they are not mentioned in the
> > >>first one. Presumably this is because extlang is currently reserved
> for
> > >>future use, but it would be good to mention this in para 2.  Text
> saying
> > >>something like 'extlang records will also be able to be registered by
> > >>this process when they are introduced'.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >The key word in para 2 is "independently". There are also registrations
> that can occur due to standards body activity (assignment
> of a new ISO 3166 code, for example).
> > >
> > >Extlangs cannot currently be registered, as noted they are reserved.
> However, the rules for extlangs are spelled out so that
> implementations can take them into account. Therefore it is important to
> point out that they must have a Prefix again here. The
> conditional nature of their existence might be better mirrored by the
> wording, though.
> > >
> > >
> > When I first read through the document I was very confused by the talk
> > about what needed to be done with extlangs after Figure 5 but nothing
> > about them earlier.  I think you probably need a few extra words to
> > distinguish the two cases.. independently didn't trigger the right chain
> > of thought for me.
> >
> > >>s3.4: para next but one after Figure 5: I cannot find the requirement
> > >>that Variant subtags have at least one Prefix field: extlang fields
> are
> > >>explicitly specified to have exactly one but Variants appear to be
> > >>allowed 0 or more.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >You are looking at the requirement. Perhaps the matching requirement in
> Section 2.2.4 should be strengthened from MAY to MUST?
> > >
> > >
> > [I think you mean s2.2.5]: To make it consistent, yes, the s2.2.5
> > statement should be "MUST include one or more 'Prefix' fields".
> >
> > <<snip>>
> >
> > >>s2.2.8: In reading the document for the first time, I found the use of
> > >>'redundant' as a type slightly confusing.  It would help to clarify
> > >>things if text was added (probably in this section) to the effect that
> > >>subtags that don't come from RFC3066 but eventually become 'redundant'
> > >>are NOT handled by the use of the 'redundant' type but by marking them
> > >>as deprecated and (maybe) adding a Preferred-Value as described in
> s3.1.
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >That isn't correct. Redundant tags are values registered under RFC 3066
> that are now defined by (separate) subtags in the
> registry. For example, the tag "zh-Hant" is now defined by the subtags
> 'zh' and 'Hant' and thus is redundant. It is NOT deprecated
> and never may be deprecated by rule. This is in contrast to grandfathered
> values, which may sometimes become redundant (the only
> time a zebra in this zoo may change its stripes) or may be deprecated, but
> which always maintain their validity.
> > >
> > >What's important to note is that redundant tags are valid.
> > >
> > >
> > This is maybe a US/UK usage problem! I was reading 'redundant' in the
> > 'no longer wanted' sense rather than purely the 'alternative among more
> > or less equals'.  A few words to make it clear what is going on would
> > help others  to avoid the same trap.
> > <<snip>>
> >
> > >>s3.1: para next but one after definition of 'Added': s/registered
> > >>written or transcribed/registered that has been written or transcribed
> > >>into/ (repeated in s3.4 in para about 'description' field.)
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >Yes. Actually a comma is missing there, but your version works too.
> > >
> > >
> > I thought there was a comma missing initially but
> > s/registered/registered,/ completely alters the sense.
> > <<snip>>
> >
> > >>s3.5: last but one para:  This paragraph talks about matching... there
> > >>is a draft (draft-ietf-ltru-matching) specifically about this matter
> > >>which does not appear to be referenced.  Should this matter be
> discussed?
> > >>
> > >>
> > >[Addison Phillips]
> > >
> > >Do you mean Section 3.6? Matching is actually mentioned sporadically
> here and there in the document in a general manner. The
> first occurrence is in S2.1, para2. Matching here can be assumed to mean
> RFC 3066-style prefix matching. The matching draft
> enumerates other schemes too.
> > >
> > >Originally the matching draft was part of this document, please note.
> > >
> > >
> > [yes I meant s3.6].  I haven't read the matching draft in detail, but I
> > guess it would be useful to refer to it somewhere around s2.1.
> >
> > <<snip>>
> > Regards,
> > Elwyn
> 
> 

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

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 31 Aug 2005 12:37:13 -0700

Here was my original response to Elwyn for reference only.

Addison

Addison P. Phillips

> From: Addison Phillips
> Sent: 2005?8?31? 9:03
> To: 'Elwyn Davies'; [email-masked]
> Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck; [email-masked]
> Subject: RE: Gen-art review: draft-ietf-ltru-registry-12.txt
> 
> these comments should be. Many of these comments would make useful
> additions to the document.
> 
> My main question (Randy) is: what is the process impact of incorporating
> changes based on these comments?
> 
> Response comments below are personal, of course. I expect I'll be sending
> these to the list also after Randy forwards the message.
> 
> Addison
> 
> Addison P. Phillips
> > Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck; [email-masked];
> > Addison Phillips
> > advise the General Area Director (i.e. the IETF/IESG chair) by providing
> > more in depth reviews than he could do himself of documents that come up
> > specifically with an eye to the GenART process, but since I believe that
> > it will be useful to have these comments more widely distributed, others
> > Document: draft-ietf-ltru-registry-12.txt
> > Intended Status: BCP
> > Shepherding AD: Scott Hollenbeck
> > PROTO Shepherd: Randy Presuhn
> > Review Trigger: IETF Last Call, ends 6 September 2005
> >
> > Summary:
> > This document is generally in good shape and well written but is not yet
> > ready for publication.  It has in my view a couple of minor process
> > issues that need to be sorted out, one issue which seems to be an
> > unnecessary irritant, some minor restructuring to improve readability
> > and some editorial nits.  I would also suggest that areas which may be
> > affected by the introduction of 'extended language subtags' are all
> > revisited to ensure that they properly and clearly cover both the
> > initial case (with no extlang subtags) and the future development
> > including one or more extlang subtags. [My initial impression was that
> > the new idea was not as well integrated as it might have been but on
> > re-reading most of the 'issues' have become clear... hence the
> > suggestion that some additional clarity might be gained by a few extra
> > words in relevant areas.]
> >
> > Transition issue:
> > probably be good to have the initial registry in place (i.e., translated
> > from the initial state RFC) and reviewed before it becomes authoritative.
> [Addison Phillips]
> 
> It may appear a bit vague. In practice, however, there has only ever been
> one Language (Sub)tag Reviewer, Michael Everson. The change in appointing
> authorities was suggested by the IESG itself, so there should be no
> interregnum. There are rules in place to deal with any in-process
> registrations, which would mark the main problem source.
> >
> > Recall of Language Subtag Reviewer:
> > Given recent IETF discussions, should the document set out ways for the
> > community to request the unfrocking (recall) of the Language Subtag
> > Reviewer in the event of non-performance or repeated inappropriate
> > decisions?   Also would it be appropriate to suggest that the IESG
> > document the name of the reviewer on their web page and periodically
> > reconfirm the appointment?  I don't think a fixed term appointment would
> > be desirable, and I agree this is not something for nomcom to be
> > involved in.
> [Addison Phillips]
> 
> Those are good questions. I'm not sure if there are any similar practices
> anywhere else in the IETF. Presumably the appointing authority is the
> unappointing authority too and the body to whom to appeal?
> >
> > Irritant:
> > Early in the document it is specifically set out that language tags are
> However, in the tags defined by this document, the uppercase US-ASCII
> letters in the range 'A' through 'Z' are considered equivalent and mapped
> directly to their US-ASCII lowercase equivalents in the range 'a' through
> 'z'. Thus the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or "mN-
> cYrL-Mn" (or any other combination) and each of these variations conveys
> the same meaning: Mongolian written in the Cyrillic script as used in
> Mongolia.
> --
> 
> The document goes to great lengths to say that case distinctions must not
> be considered when processing language tags. However, the canonical form
> follows the ISO standards: this practice has long standing in the
> community at large and is enshrined in Section 4.4 ("Canonicalization of
> Language Tags") thusly:
> 
> --
> When performing canonicalization of language tags, processors MAY
> regularize the case of the subtags (that is, this process is OPTIONAL),
> following the case used in the registry. Note that this corresponds to the
> following casing rules: uppercase all non-initial two-letter subtags;
> titlecase all non-initial four-letter subtags; lowercase everything else.
> --
> 
> > However, because the corresponding ISO documents use title case for
> > script codes and upper case for region codes, this representation has
> > been used in the normative text (ss 2.2.3 and 2.2.4) and registrations
> > of these codes MUST use this representation (s3.2).  This struck me as
> > unecessary bureaucracy for registrants.  It would seem to me enough to
> > RECOMMEND that the registry conform to the case patterns and otherwise
> > allow users and registrants whatever case they choose.
> [Addison Phillips]
> 
> This bureaucracy only applies to independently registered values
> (variants), in practice, and isn't binding on those. The underlying ISO
> standards, when mirrored, won't be an issue, since their assignments will
> already come in the canonical format.
> >
> > Restructuring:
> > The Language Tag Reviewer of RFC3066 has metamorphosed into a Language
> > Subtag Reviewer.  The subtag reviewer is first mentioned in s3.1 in a
> > rather sudden way.  The role of the reviewer is scattered across several
> > sub-sections of s3 and how the person is appointed is buried in depths
> > of s3.4 (Registration Procedure for Subtags).  I think it would be
> > valuable to summarize the role of the Language Subtag Reviewer and set
> > out how this person is appointed (and maybe also recalled) right at the
> > start of s3.
> [Addison Phillips]
> 
> That seems like a sensible thing to do.
> >
> > Update Load
> > There has been considerable debate about the expected load of updating
> > the registry especially over the next couple of years.  It might be
> > worth adding some notes about the expected load and emphasising that
> > such changes will have minimal impact on applications due to the
> > backwards compatibility rules.
> [Addison Phillips]
> 
> Aside from revisions to document in question, the day-to-day activity of
> the ietf-languages list has been fairly steady over its lifetime. That
> isn't expected to change. The number of ISO 639-1/-2 and ISO 3166
> registrations in a given year has tended to be small (on the order of a
> dozen relevant changes per year). The addition of ISO 639-3 or ISO 639-6
> has been considered as a possibility, but that would be a special case and
> be coincident with a revision of the document.
> >
> >
> > Review:
> > =======
> >
> > Substantive:
> > ============
> >
> > primary languages.  I think it would be worth spelling out the reasoning
> That's not just the implication, but entirely the idea. Extended language
> subtags are meant to be closely associated with the primary language
> subtag. Since they occur directly after the primary language subtag, there
> are no intervening values or additional variants that can creep into their
> prefix (requiring more than one prefix). In addition, extlangs are
> expected to be used with the ISO 639-3 concept of "macro languages"
> (languages that contain other languages). An example of this is the spoken
> variation Mandarin Chinese. The tag for this would be zh-cmn and "cmn"
> would be an extlang with a prefix of "zh". It doesn't make sense to use
> "cmn" with a different language prefix, such as "de" or "ja".
> 
> A
> > pointer to this discussion in the 'Prefix' discussion in s3.1 would then
> > help.
> [Addison Phillips]
> 
> Good idea.
> >
> > s2.2.3: item 3: Is it desirable to have normative text using other than
> > lower case for tag identifiers? See also s3.2 comment below.
> [Addison Phillips]
> 
> Yes. See above.
> 
> > s2.2.4: Item 6 and (maybe) examples: as per s2.2.3, Item 3.
> [Addison Phillips]
> 
> Same.
> >
> > s2.2.4: Item 3A: [Out of interest...] Why not economic groupings?  Their
> > bureaucrats have languages all their own ;-) .
> [Addison Phillips]
> 
> The economic groupings are things like "10 poorest countries" and "10
> richest countries" and the like. The economic groupings don't describe
> stable regional entities and might be controversial, especially in
> language tags ("French as spoken in poor countries")
> 
> >
> > s3.1: the 'Language Subtag Reviewer' makes a rather sudden entry here.
> > 'Who is this person?' the naive reader may ask.  It would be a good idea
> > to add a sub-section before 3.1 introducing the Language Subtag
> > Reviewer, summarizing the role and setting out how the person is
> > appointed (and recalled) - move text from s3.4.  Since the the Language
> > Tag Reviewer (a wholly different person ;-) ) from RFC3066 is also
> > mentioned, it is important that it is clear which one is referred to -
> > the full title should be used throughout (e.g. several incomplete
> > instances in s3.4) - a handy abbreviation (although LSR is already
> > taken in MPLS land) might shorten the document a bit!
> [Addison Phillips]
> 
> A very little bit :-).
> 
> A small subsection could be created to deal with this issue.
> >
> > just the RFC3066 subset seems a little odd.  Why not all or none, since
> different than that of the draft. That registry is maintained as an
> obsolete reference (it just seemed prudent to do so). Generating many
> registration forms for the initial set, however, doesn't seem that useful.
> >
> > s3.1: para after ABNF: Numeric ranges?  This section talks about
> > alphabetic ranges such as c..k.  Is this supposed to cover numeric
> > ranges as well?
> [Addison Phillips]
> 
> Yes. It is an oversight (since there are no numeric ranges initially).
> >
> > s3.1: definition of 'Tag' field: Presumably the syntax of a tag of type
> > 'grandfathered' is restricted to the 'grandfathered' format from s2.1?
> > (Looking at the initial state it may well be) Given that grandfathered
> > items are all in the initial registry load this is perhaps academic.
> [Addison Phillips]
> 
> Tag applies to both grandfathered and redundant types, although the ANBF
> for 'grandfathered' turns out to describe both accurately.
> >
> > s3.1: para after definition of 'Added': the 'MUST' requirement to follow
> > the capitalization conventions of the underlying standards in the
> > registry seems a little strange given earlier views on interpretation of
> > case.
> [Addison Phillips]
> 
> This has the effect of making the registry follow the optional
> canonicalization rules quoted earlier and making the registry mirror the
> ISO standards more closely. The case in the registry has no impact on
> interpretation of tags: these are defined to be case insensitive as you
> note, but the common practice has been to use the ISO case forms.
> >
> > primary language tag and up to 2 other extlangs and a 'variant' can have
> > selected language tags.'  appears to be garbled... I am not sure exactly
> > what is intended.
> [Addison Phillips]
> 
> The value in the record that contains a 'Preferred-Value' field should be
> replaced with the value in the Preferred-Value. That is, Preferred-Value
> is how a subtag is deprecated in favor of a different subtag. The cases
> where this applies are then enumerated. Some textual tweaking to make this
> clearer is probably called for.
> >
> > s3.3: Item 12: Is there any chance that the meaning of the grandfathered
> > tag and the (later) combination of valid subtags might be different?  If
> > so what should happen?  The reviewer should take a view on this I
> > think!  Should there be some words on how to process such overlaps in
> > the validating processor section?
> [Addison Phillips]
> 
> There is a very small chance of this happening, so it should be dealt with
> as noted.
> >
> > s3.4: para 2 and para next but one after Figure 5: At first sight these
> > paras appear to conflict?  the second one appears to indicate that type
> > first one. Presumably this is because extlang is currently reserved for
> > future use, but it would be good to mention this in para 2.  Text saying
> that can occur due to standards body activity (assignment of a new ISO
> 3166 code, for example).
> 
> However, the rules for extlangs are spelled out so that implementations
> can take them into account. Therefore it is important to point out that
> they must have a Prefix again here. The conditional nature of their
> existence might be better mirrored by the wording, though.
> >
> > that Variant subtags have at least one Prefix field: extlang fields are
> > s4.1: Item 2: example: I am not clear how one would represent the
> > combination of latin and braille since only one script subtag seems to
> > be allowed.  Maybe there is a special subtag for the combination? or is
> > it intended that both complete tags are used?
> [Addison Phillips]
> 
> If runs of text may be marked up individually, then they should be.
> Otherwise the language tag indicates the intended audience of the content
> (which will be one or the other). You could equally say the same of a
> document that mixes English and French or en-US and en-GB.
> 
> Yes, multilingual documents (and not just multi-script documents) exist
> which do not have any particular primary language that is "above" the
> others, but that is a limitation of the headers or other meta-data
> structures that use language tags, not the tags themselves. Tags identify
> one language unambiguously, not multiple languages or language forms mixed
> together. The higher level protocol must deal with that.
> 
> See for example the section "Two types of language declaration" in:
> 
> http://www.w3.org/International/tutorials/language-decl/
> 
> >
> > Editorial:
> > ==========
> >
> > Global: Some pieces of ABNF are described as 'Figures' but others
> > aren't, and not all figures have titles (e.g., Figure 4, and Figure 5).
> > [Figure 2 and Figure 3 don't appear as such]
> [Addison Phillips]
> 
> This is the result of xml2rfc. I'll check it.
> >
> > s2.2.6: Item 2:  'below' should point to s2.2.7.
> [Addison Phillips]
> 
> Yes.
> >
> > as deprecated and (maybe) adding a Preferred-Value as described in s3.1.
> [Addison Phillips]
> 
> that are now defined by (separate) subtags in the registry. For example,
> the tag "zh-Hant" is now defined by the subtags 'zh' and 'Hant' and thus
> is redundant. It is NOT deprecated and never may be deprecated by rule.
> This is in contrast to grandfathered values, which may sometimes become
> redundant (the only time a zebra in this zoo may change its stripes) or
> may be deprecated, but which always maintain their validity.
> 
> > s3.1: Seems rather long... maybe could be broken up into subsections.
> [Addison Phillips]
> 
> That might be possible.
> >
> > s3.1: discussion of Comment field: s/frowned on/strongly NOT
> RECOMMENDED/
> [Addison Phillips]
> 
> It's okay to make this normative, but the idea was to give a sense of the
> likely behavior of the community. It is possible that a long screed might
> be justified from time to time.
> >
> > s3.2: s/an change/a change/
> [Addison Phillips]
> 
> Yes.
> >
> > s3.2: para before figure 4: is the intent of this that each email
> > contains insertion or modification data for exactly one record?  if so
> > it should say this explicitly... at present it is sort of implied in
> > that it appears to forbid mixing of INSERT and MODIFY but doesn't say
> > just one record per email.
> [Addison Phillips]
> 
> It should say one per email.
> 
> > s5.1 is slightly more precise - it says 'enclosed record' (singular).
> [Addison Phillips]
> 
> Yep.
> >
> > which does not appear to be referenced.  Should this matter be discussed?
> [Addison Phillips]
> 
> Do you mean Section 3.6? Matching is actually mentioned sporadically here
> and there in the document in a general manner. The first occurrence is in
> S2.1, para2. Matching here can be assumed to mean RFC 3066-style prefix
> matching. The matching draft enumerates other schemes too.
> 
> > s3.7: Presumably the language tag reviewer here the RFC3066 person
> > rather than the language subtag reviewer defined in this draft?  this
> > should be made crystal clear!  it might well be the same person but
> > handover (or retitling) and authority are missing from this document!
> >
> [Addison Phillips] Yes, I agree. Although I believe we expect it to be the
> same person at the moment.

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 31 Aug 2005 12:49:51 -0700

And my follow up.

Next comes the individual threads.

Addison

Addison P. Phillips

> Sent: 2005?8?31? 12:49
> To: 'Elwyn Davies'
> Cc: [email-masked]; Randy Presuhn; Scott Hollenbeck;
> [email-masked]
> Responses follow.
> been
> I agree.
> language
> Yes. The meaning of any subtag is defined and can't change in different
> contexts. That is, '1996' is subtag describing a particular orthography of
> German. It can't just be used as an arbitrary year number. The subtag
> 'cmn' will mean "Mandarin Chinese" and won't have any meaning with a
> different macro language.
> >
> >
> > <<snip>>
> >
> It's easy to do and therefore probably worthwhile. I'll work up a version.
> >
> be
> Yes. I'll propose suitable text modifications.
> >
> Actually, I think this point was raised before. I'll propose suitable text
> for the "independent" part and the extlang material.
> >
> I do mean 2.2.5.
> No, the usage is meant to be similar. The redundant tags are "no longer
> wanted" in that all of their subtags are now separately defined. A
> grandfathered tag must be handled in an implementation by an exceptional
> process--there is a list of grandfathered values used to validate these
> tags--while redundant tags are described entirely by various subtags in
> the registry and the registry entries can be entirely ignored by an
> implementation. The entry merely exists so that people know where the RFC
> 3066 registered value went.
> >
> Yes, and appropriately too!
> 
> Here is the corrected sentence:
> --
> At least one of the 'Description' fields MUST contain a description of the
> tag being registered, written or transcribed into the Latin script;
> --
> 
> The point is at least one description must be in the Latin script, not
> that the tag must be in the Latin script (of course it is---> it is
> required to be in our particular subset of ASCII).
> >
> here
> We could as easily (actually, since it's an RFC and draft-matching is a
> draft, more easily) refer to matching as described in RFC 3066, RFC 3282
> and, of course, RFC 2616 Section 14.4.