Issue:
>
> ...
> > ?? Also, CHANGE: "apply" to "adhere to" or simply "follow" (I
> like "adhere to" better;
> > "apply" might be a word you use with applications and rules but I
> do not use it with anything but formatting,
> > "formatting is applied . . ."
>
Randy commented:
> Disagree. I see no need for this change.
Resolution: no change. The editors don't see a reason to modify this.
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
>
> ...
> > ? Also, CHANGE: "the ones" to "those" (I think the the text is
> more cohesive with 'those'
> > because it refers back to 'the rules'--this is an idea that
> Halliday has about cohesion too) }
>
> Disagree. I see no need for this change.
>
> > "Standards, protocols, and applications that reference this
> document
> > normatively but adhere to rules different than those given in
> this section . . . "
>
> This proposed usage of "than" is simply wrong, and I cannot support
> it.
>
> ...
> > ! 4.1 par 6 item 1 second bullet
> >
> > {ORIGINAL TEXT }
> > " Note that some subtag sequences might not represent the
> > language a casual user might expect, especially if when
> > relying on the subtag's description in the registry. "
> >
> > {! CORRECTION: delete either "if" or "when" as "if when" seems a
> bit redundant, right? }
>
> Yup. However, the entire phrase "especially...registry" is not
> helpful
> to the sense of the paragraph in question. Consequently, I think
> that if a change is to be made, it would be better to delete
> everything from the comma to the word "registry".
>
> ...
> > ! 4.3 Par 1 Bullet 1 last sentence
> >
> > {ORIGINAL TEXT}
> > "o A language priority list [RFC4647] describing a user's
> language
> > preferences. This is a (possibly weighted) list of
> potentially-
> > unrelated varieties, expressing a preference, rather than
> as a
> > declaration about actual content."
> ...
> > "This is a (possibly weighted) list of potentially unrelated
> varieties,
> > expressing a preference, rather than a declaration of actual
> content."
>
> Yup. However, this sentence is entirely redundant, so if there is
> going
> to be a change, I'd rather just delete it.
>
> > ! 5.1, par 4, sentence 2
> >
> > { ORIGINAL TEXT }
> >
> > " Inserted records can be placed anywhere in the appropriate
> section; there is
> > no guarantee of the order of the records beyond grouping them
> together by 'Type'."
> ...
> > "Inserted records can be placed anywhere in the appropriate
> section; there
> > is no guarantee of their order beyond their being grouped
> together by 'Type'."
>
> Ok. This "can" probably should be a MAY, but it's not a big deal
> and it's not
> worth changing.
>
> ...
> > ! 4.4.2 Par 1, last sentence
> >
> > { ORIGINAL TEXT }
> >
> > " Such truncation MUST NOT
> > permit a subtag to be chopped off in the middle or the
> formation of
> > invalid tags (for example, one ending with the "-"
> character)."
> ...
> > "Such truncation MUST NOT permit the formation of invalid tags--
> > either by chopping a subtag off in the middle, or by leaving a
> singleton without any subtag."
>
> Disagree. The original text is gramamtically and technically
> correct.
> The proposed text changes the meaning in a subtly incompatible way.
> Consider the case where chopping a subtag in the middle does *not*
> result in an invalid tag, but instead produces a tag containing a
> subtag
> not present in the original.
>
> ....
> > ? 3.5 "Registration Procedure for Subtags" Par 4, 2nd sentence
> >
> > { ORIGINAL TEXT }
> >
> > " Note that each response is not limited in
> > size so that the request can adequately describe the
> registration."
> >
> > {COMMENTS: the word "response" is not clear here, and this
> sentence
> > is awkward and unclear as a whole.
>
> I think the sentence is abundantly clear in context, and see no
> need for change.
> ...
>
> > ? 3.7 par 4 & 5
> ...
> > {COMMENT: the two maintaining authorities, IANA, and the
> individual
> > authority, might be confused by readers here??
> ...
>
> Given the topic of the section, I find it difficult to imagine such
> confusion
> taking place.
>
> > "Failure on the part of the maintaining authority to maintain
> this record . . . "
>
> It's difficult to keep a straight face when reading the proposed
> replacement.
>
> ...
> > ? 4.1 Par 5
> >
> > { ORIGINAL TEXT }
> >
> > " A subtag SHOULD only be used when it adds useful distinguishing
> > information to the tag. Extraneous subtags interfere with the
> > meaning, understanding, and processing of language tags. In
> > particular, users and implementations SHOULD follow the
> 'Prefix' and
> > 'Suppress-Script' fields in the registry (defined in Section
> 3.1):
> > these fields provide guidance on when specific additional
> subtags
> > SHOULD be used or avoided in a language tag."
> >
> > {COMMENT/CORRECTION for Sentence 1:
> > the way it's written, someone might interpret it as meaning that
> all subtags,
> > including a primary language subtag, are optional, but a primary
> language
> > subtag is really a good idea, a real SHOULD}
> >
> > INSERT AT BEGINNING--replace sentence 1 with 2 sentences
> >
> > "All language tags--except those that are exclusively private
> use--
> > SHOULD include one (primary) language subtag. Any additional
> > subtag SHOULD only be included when it adds useful distinguishing
> > information to the tag. "
>
> Strongly disagree. This changes the sense of the text.
> [As co-chair: it took extensive discussion to reach agreement on
> this text, and I'm extremely relectuant to even consider changes to
> it unless something is demonstrably broken.]
>
> > ?? {A SECOND COMMENT/CORRECTION for Sentence 3: word
> > choice; change "follow" to "consult" I would never say "follow"
> > for either unless I said "follow the guidelines . . ."; "consult"
> > is the best word with "users" probably; not sure at all about
> > implementations but I would not say "follow"}
>
> Disagree. While I appreciate the preference for "consult", it
> does not mean the same thing as "follow".
>
> ...
> > ? 4.1 par 6 item 2 example second bullet last sentence
> >
> > { ORIGINAL TEXT }
> >
> > "(The tag "uz-Zxxx"
> > could also be used where content is not written, as the
> subtag
> > 'Zxxx' represents the "Code for unwritten documents".)"
> >
> > { COMMENT/CORRECTION I do not see what clarity or information
> > the word 'code' adds to this sentence so I CORRECTED it }
>
> I believe it's a quote from the subtag's registry enty.
>
> > "The tag "uz-Zxxx"
> > could also be used where content is not written as the
> script subtag 'Zxxx' is used to indicate unwritten documents"
>
> I think this would be a step backwards, since it de-emphasizes the
> generative nature
> of subtags.
>
> ...
> > ? 4.1.1 par 5, last sentence
> >
> > ORIGINAL TEXT }
> >
> > "For example, Romanian ('ro') and
> > Moldavian ('mo') do not share a macrolanguage, but are far
> more
> > closely related to each other than Cantonese ('yue') and Wu
> ('wuu') ,
> > which do share a macrolanguage."
> > {! COMMENT: the [ro] [mo] example is a bit of a problem as one
> of the
> > subtags has now been deprecated; [ca] and [oc], 'Catalan' and
> > 'Occitan'/'Provencal,' would be better examples;
> > alternately you might choose [gsw] 'Alsatian' or 'Schwyzerdütsch'
> > and [swg] 'Swabian'--but I know less about Alsatian;
> > There may be other possibilities; on a quick perusal of RFC 4645
> > I did not find khmer, for example, though I discovered there are
> some
> > maybe mutually intelligible varieties any & know little about
> Asian
> > languages anyway}
>
> Strongly disagree. The example serves its purpose as it is,
> and none of the cases cited is as dramatic and clear-cut
> as that of Romanian and Moldavian. (Which explains nicely
> *why* the subtag met the fate that it did.)
>
> [As co-chair: there already seems to be a rough consensus
> to not change this section.]
>
> > 4.2 par 5
> > { ORIGINAL TEXT }
> > " This relationship is not guaranteed in all cases:
> specifically,
> > languages that begin with the same sequence of subtags are NOT
> > guaranteed to be mutually intelligible, although they might be.
> For
> > example, the tag "az" shares a prefix with both "az-Latn"
> > (Azerbaijani written using the Latin script) and "az-Cyrl"
> > (Azerbaijani written using the Cyrillic script). A person
> fluent in
> > one script might not be able to read the other, even though
> the
> > linguistic content (e.g., what would be heard if both texts
> were read
> > aloud) might be identical. Content tagged as "az" most
> probably is
> > written in just one script and thus might not be intelligible
> to a
> > reader familiar with the other script."
> > {COMMENT/CORRECTION I found the language, 'this relationship
> > is not guaranteed,' kind of vague. Also I did not like the phrase,
> 'written
> > in just one script'--an example specifying one of the two scripts
> might help
> > make this sentence clearer to someone skimming this. I tried to
> rewrite
> > this paragraph: I simplified the first sentence and used more
> specific
> > language (the word 'always' here, does refer the reader back to
> what's
> > been said in the paragraph above about the general relationship
> between
> > language tags sharing a prefix--one that we now see does not
> always
> > guarantee mutual intelligibility); I also rewrote slightly the
> second sentence,
> > and inserted "however" (to tie back to the previous statement)
> > "only" into the fourth sentence.}
> >
> > ?? "Tags that share the same prefix are not always mutually
> intelligible.
> > For example, the prefix 'az' is shared by both "az-Latn"
> (Azerbaijani
> > written using the Latin script) and "az-Cyrl" (Azerbaijani
> written using
> > the Cyrillic script). A person fluent in one script might not be
> able to
> > read the other, even though the
> > linguistic content (e.g., what would be heard if both texts were
> read
> > aloud) might be identical. However, content tagged as "az" most
> > probably is written in just one of these scripts and thus might
> not
> > be intelligible to a reader familiar with only the other script."
>
> Disagree. The change to the first sentence makes it sound like
> mutual intelligibility is normally presumed when there is a shared
> prefix, and that cases like this are rare exceptions. The existing
> text
> is clearer and more to the point.
>
> > ? 4.5 par 2 item 4 & par 4 "Example . . . "
> ...
> > { COMMENT/CORRECTION: the first example actually goes with item
> > 5 & the second with item 4 so it's confusing; I prefer to have
> the examples
> > with the items they illustrate; thus I'd move the second of the
> examples
> > so that it followed item 4-- }
>
> I'm neutral on this proposal. I see the benefits to interspersing
> the
> examples with the list of rules, but I also see advantages to the
> current organization with the examples following the rules.
> I'm not persuaded at all that this is a change that in any way
> *needs* to be made.
>
> ...
> > ?? 3.5 par 21
> ...
> > {! COMMENT/CLARIFICATION ? Please explain "SHALL NOT" versus
> "MUST NOT"--
>
> This is spelled out in RFC 2119.
>
> Randy
>
>
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.