Hi -
I've assigned this #4
Randy
----- Original Message -----
> From: "Phillips, Addison" <addison at amazon.com>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; <ltru at ietf.org>
> Sent: Sunday, February 08, 2009 9:27 AM
> Subject: "different from" issue
>
> [now follow individual emails with the editor's proposed disposition for each issue raised]
>
> (editor hat ON)
>
> Issue: use of phrase "different rules to the ones"
>
> Resolution: no change. The sentence is clear and sufficiently grammatical.
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> > -----Original Message-----
> > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> > Behalf Of Randy Presuhn
> > Sent: Friday, February 06, 2009 4:11 PM
> > To: ltru at ietf.org
> > Subject: [Ltru] Edith Whitehead's proposed editorial changes to
> > 4646bis i-d
> >
> > Hi -
> >
> > Subject line changed for tracking sanity....
> >
> > As a technical contributor...
> >
> > > From: "Edith Whitehead" <quaiouestenglish at yahoo.com>
> > > To: <ltru at ietf.org>
> > > Cc: <cewcathar at hotmail.com>; <mark at macchiato.com>;
> > <addison at amazon.com>; <randy_presuhn at mindspring.com>
> > > Sent: Friday, February 06, 2009 9:31 AM
> > > Subject: Re: [Ltru] Editor's copy of draft-4646bis updated...
> > ...
> > > ! 4.1 par 3
> > >
> > > { ORIGINAL TEXT }
> > >
> > > " Standards, protocols, and applications that reference this
> > document
> > > normatively but apply different rules to the ones given in
> > this
> > > section MUST specify how language tag selection varies from
> > the
> > > guidelines given here."
> > >
> > > { ! CORRECTION: CHANGE: "different rules to the . . . " >
> > "rules different than those . . . "
> > > you can say : "rules different than," "rules different from,"
> > or "different rules than,"
> > > but where do you get "different rules to"? It's not English.
> >
> > Nor is "different rules than". If folks feel a need for a change,
> > "rules different from" would be more acceptible.
> >
> > ...
> > > ?? 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 . . ."
> >
> > Disagree. I see no need for this change.
> >
> > ...
> > > ? 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.