Subject: [Ltru] problematic SHOULDs in matching draft

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Mar 2006 15:02:22 -0800

Hi -

As a technical contributor...

Background, RFC 2119 section 3:
   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Generally, the context of such a recommendation is the behaviour of a
conformant implementation of the specification.  If the specification
gives operational guidelines, it may apply to users, but for protocols
and algorithms the usage is normally limited to implementations of or
other specifications using the specification in question.

Consequently, several passages seem a bit problematic, in that they use
such normative language to characterize behaviour of the user of an
application.  I don't want to be in the business of deciding whether
users conform to the specification!  :-)

The following passages have problems with "SHOULD":

Old:
   matching schemes.  Use of one or more wildcards SHOULD NOT be taken
   to imply that a certain number of subtags will appear in the matching
   set of language tags.
New:
   matching schemes.  Use of one or more wildcards does not imply that
   a corresponding number of subtags will appear in the matching
   set of language tags.

Old:
   Protocols and specifications SHOULD clearly indicate the particular
   mechanism used in selecting or matching language tags.

New:
   Protocols and specifications requiring conformance to this specification
   MUST clearly indicate the particular mechanism used in selecting or
   matching language tags.

Old:
   string processing.  Users SHOULD select language ranges that are
   well-formed, valid language tags according to [RFC3066bis]
   (substituting wildcards as appropriate in extended language ranges).

I'm not sure what to do about this.  We shouldn't be talking about what
happens at a user interface other than as an example.  What are the bad
things that happen if the language range isn't a well-formed, valid
language tag?  If nothing horrible happens, (an empty result does not
qualify as horrible) then SHOULD is too strong anyway.  Perhaps
we should just delete everything in the paragraph after "processing."

Old:
   Users SHOULD replace tags or subtags which have been deprecated with
   the Preferred-Value from the IANA Language Subtag Registry.  If the

This just seems wrong.  In some ways, this is a kind of canonicalization,
and as such should be part of the matching algorithm's specification
(perhaps as a option) rather than a constraint on user behaviour.  Alternatively,
in the spirit of the rest of the paragraph, I could live with:
New:
   Applications SHOULD use the Preferred-Value from the IANA Language
   Subtag Registry for tags or subtags which have been deprecated.  If the

Old:
   Users SHOULD avoid subtags that add no distinguishing value to a
   language range.  When filtering, the fewer the number of subtags that
This is not a question of interoperability.  While sound advice, following
this advice won't make an implementation any more or less conformant to the
specification.  I'm tempted to suggest moving all of this kind of material
to a separate, non-normative section on "Practical guidelines for users of
language matching algorithms"

This one does deal with interoperability, but needs a little nudge to be
in alignment with 3066bis:
Old:
   Private-use subtags require private agreement between the parties
   that intend to use or exchange language tags that use them and great
   caution SHOULD be used in employing them in content or protocols
   intended for general use.  Private-use subtags are simply useless for
   information exchange without prior arrangement.

New:
   Private-use subtags require private agreement between the parties
   that intend to use or exchange language tags that use them.  They
   SHOULD NOT be used in content or protocols intended for general use.
   Private-use subtags are simply useless for information exchange
   without prior arrangement.

Randy

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

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 30 Mar 2006 15:29:26 -0800

Comments follow.

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: 2006年3月30日 15:02
> To: LTRU Working Group
> Subject: [Ltru] problematic SHOULDs in matching draft
> 
> Hi -
> 
> 

This was already modified per another comment.
>    MUST clearly indicate the particular mechanism used in selecting or

Done.
> we should just delete everything in the paragraph after "processing."

We can remove the normative text. It could just as well read "Users really ought to select..."
>    Subtag Registry for tags or subtags which have been deprecated.  If the

Done.
> language matching algorithms"

It IS in a separate section, which is called "Choosing Language Ranges", which is in a separate ghettoized section containing only advice for users.
>    without prior arrangement.
Done.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Mar 2006 18:59:21 -0800

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; "'LTRU Working Group'" <[email-masked]>
> Sent: Thursday, March 30, 2006 3:29 PM
> Subject: RE: [Ltru] problematic SHOULDs in matching draft
...
> It IS in a separate section, which is called "Choosing Language Ranges",
> which is in a separate ghettoized section containing only advice for users.
...

That intent wasn't clear to me.  That section (4.1) also has two paragraphs (the last
two) that are clearly in terms of applications and protocols, and have normative
material in them that would impact interoperability.

Randy