On Mon, Jun 20, 2011 at 23:39, "Martin J. Dürst" <duerst <at> it.aoyama.ac.jp> wrote:

Hello Mark, others,

Overall comment:
The idea to reuse language tags to indicate transliteration/transcription source, and to add some additional tags to distinguish methods seems to be reasonable and sound.

The description of the structure of the allowed subtags and of the responsibility split between IETF (this draft) and UTC (UTS 35) looks quite messy to me, and should be cleaned up. I'd personally prefer that UTS 35 (or whatever else on the Unicode side) only define the <mechanism> part (after the m0 subtag).

That would be my preference as well (can't speak for my coauthors).

We patterned it this way following what ended up being accepted for  the -u- extension. That is, the spec is in UTS35, but there is a summary here. But of course, there are many ways to do it. And maybe this summary is too detailed, at least for the mechanism part, and we could just have it in UTS35.

We considered a number of alternatives:

• We could define everything after -t- to be the source language, and everything after -m- to be the mechanism. But that burns 2 extension letters, just one.

• We also considered having everything in the -u extension, for which we already have the structure set up. However, that would force us to have artificial source subtags like 'en0' instead of 'en', because the -u- extension wouldn't allow the 2-letter subtags (it already defines a use for them).

• We could also have -t- be just the source, and define the mechanism in -u-, also easy. But we felt it would be better to have everything under one extension.

Detailled comments:

"In addition, it may also be important to
  specify a particular specification for the transformation.": Too much 'spec' in one sentence.

ok

"For example, if one is transcribing the names of Italian or Russian
  cities on a map for Japanese users, each name will need to be
  transliterated into katakana using rules appropriate for the source
  language and target languages.": "source languages and target language"?

yes

BCP47 required information: The first three paragraphs should move to the introduction.

Other authors, what do you think?

"followed by a sequence of subtags that would form a language tag": Here and in general: Don't use 'would'.

Grammatically, it is that the sequence of subtags *would* form a language subtag if they *were* separated out. They are not actually a language tag, because they occur in the middle of another language subtag. How would you like that to be phrased?

>>>>
  The structure of 't' subtags is determined by the Unicode CLDR
  Technical Committee, in accordance with the policies and procedures
  in http://www.unicode.org/consortium/tc-procedures.html, and subject
  to the Unicode Consortium Policies on
  http://www.unicode.org/policies/policies.html.
>>>>


The following paragraph is also difficult to understand. I wouldn't know exactly what falls on what side. I think one major reason is that we are treading new ground here, it's the first time we have a singleton definition that allows reuse of language tags (with a few restrictions) as well as intends to define its own extensions.

These were both patterned after what was used for the -u- extension. We can take a look at them to try to clarify.

>>>>
  Changes that can be made by successive versions of LDML [UTS35] by
  the Unicode Consortium without requiring a new RFC include the
  allocation of new subtags for use after the 't' extension.  A new RFC
  would be required for material changes to an existing 't' subtag, or
  an incompatible change to the overall syntactic structure of the 't'
  extension; however, such a change would be contrary to the policies
  of the Unicode Consortium, and thus is not anticipated.
>>>>

2.1 Summary: There seems to be quite some overlap between the part of section 2 before the 2.1 heading.


One question I would have as a linguistic researcher is: How much effort and time is involved in getting a 'mechanism' approved? If such 'mechanisms' are e.g. rejected with arguments like "if we accept it, then everybody has to implement it" or so, then I would see that as a problem.

Good point. I'll propose some text.

07.07.2011 2:49, Pete Resnick wrote:

Most of the people on the ietf-languages list are probably on the ltru <at> ietf.org list as well, but I wanted to confirm that everyone got a chance to review this before it proceeded to the IESG. Please have a look at the ltru archive <http://www.ietf.org/mail-archive/web/ltru/current/maillist.html> and send any comments to the ltru <at> ietf.org list since that's where discussion seems to be taking place.

Thanks.

pr

07.07.2011 2:49, Pete Resnick wrote:

Most of the people on the ietf-languages list are probably on the ltru <at> ietf.org list as well, but I wanted to confirm that everyone got a chance to review this before it proceeded to the IESG. Please have a look at the ltru archive <http://www.ietf.org/mail-archive/web/ltru/current/maillist.html> and send any comments to the ltru <at> ietf.org list since that's where discussion seems to be taking place.

Thanks.

pr

Hello,

I've identified the following issue in the draft.

Section 2.2 says:

I should note that, first of all, reference to RFC 5234 is missing; moreover, and this is more important, making the ABNF definition in the form of table makes such definition an invalid one, in terms of RFC 5234.  Also, there are a number of ABNF nits here.  So, please consider changing this to:

Also, the minors comments on references.  Reference to BCP 47 should include both references to RFC 5646 and RFC 4647, like:

...and, referencing UTS 35 you shouldn't reference specific parts of the document; this should be done in the text.  Finally, I don't see where [US-ASCII] is used in the text.

Thanks,
Mykyta Yevstifeyev