Subject: [Ltru] Fix for ambiguous conformance requirements

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 22 May 2005 11:10:26 -0700

Hi folks,                                           Sunday (22 May 2005)

Addison - Below is an update for section 1 of ltru-registry that
resolves my concerns about implied performers of uppercase imperatives.

------------------------------------------------------------------------

(add title to last paragraph of section 1 and add one new paragraph)

1.1  Conformance Terminology

    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [10].

    Consistent with previous versions of this document, RFC 1766 [21]
    and RFC 3066 [23], most conformance requirements in this document
    are written in passive voice using uppercase conformance keywords.
    Content authors, authoring tools, content distributors, distribution
    tools, and content repositories (e.g., content servers and content
    archives) that create or copy language tags MUST comply with all of
    these conformance requirements.  Content users and user tools (e.g.,
    web browsers) that create or copy language tags in content queries
    SHOULD also comply with all of these conformance requirements.

------------------------------------------------------------------------

Comments?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

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

---

From: "Addison Phillips" <[email-masked]>
Date: Sun, 22 May 2005 14:20:42 -0700

Hmm... I'm not happy with this text. It is too vague for my tastes.

First, many of the requirements in this document have nothing to do with the listed implementation types or uses of language tags. They apply strictly to the registry and its population and maintenance.

Second, why do you think this is necessary? The MUST-ification and SHOULD-ification of various items should apply to the audience interested in that particular item without additional trappings. If one or another requirement should be strengthened or relaxed, then let's discuss that. If you think that different levels of MUST-ifying should apply to different applications, then we should spell that out in place and not vaguely mention it in the introduction.

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of McDonald, Ira
> Sent: 2005?5?22? 11:10
> To: [email-masked]
> Subject: [Ltru] Fix for ambiguous conformance requirements
>

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 23 May 2005 08:17:37 -0700

Hi Addison,

Sigh...I tried.

Conformance requirements written in the passive imperative are
essentially useless.  A given actor (person or software) can be
said to comply with a conformance requirement only if they are 
explicitly named as the subject of an active voice sentence.

The whole section 2 is full of passive sentences about the MUST
or SHOULD length/content/position of specific classes of language
subtags.  Why bother to have them?  Conformance requirements
never apply to _readers_.  They only apply to _actors_.

There is clearly no support on this mailing list for rewriting 
every conformance requirement to active voice with explicit actors.

I'll stop wasting your time.

Cheers,
- Ira

> From: Addison Phillips [mailto:[email-masked]]
> Sent: Sunday, May 22, 2005 5:21 PM
> To: McDonald, Ira; [email-masked]
> Subject: RE: [Ltru] Fix for ambiguous conformance requirements
> 
> 
> First, many of the requirements in this document have nothing 
> to do with the listed implementation types or uses of 
> language tags. They apply strictly to the registry and its 
> population and maintenance.
> 
> Second, why do you think this is necessary? The 
> MUST-ification and SHOULD-ification of various items should 
> apply to the audience interested in that particular item 
> without additional trappings. If one or another requirement 
> should be strengthened or relaxed, then let's discuss that. 
> If you think that different levels of MUST-ifying should 
> apply to different applications, then we should spell that 
> out in place and not vaguely mention it in the introduction.
> 
> Addison
> 
> Addison P. Phillips

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 24 May 2005 09:02:34 -0700

We could just say that:

"any such limitation SHOULD be clearly documented. A protocol that allows tags to be truncated at an arbitrary
limit, without giving any indication of what that limit is, has the potential for causing substantial harm by changing the
meaning of tags in substantial ways."

Addison

Addison P. Phillips

> Behalf Of Doug Ewell
> Sent: 2005年5月24日 6:48
> To: LTRU Working Group
> Subject: [Ltru] Re: Fix for ambiguous conformance requirements
> 
> Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:
> 
> > The phrase "[a]ny such limitation MUST be clearly documented" doesn't
> > quite work when one considers the RFC 2119 guidelines which state "In
> > particular, they MUST only be used where it is actually required for
> > interoperation or to limit behavior which has potential for causing
> > harm".  I suggest replacing this MUST with SHOULD.
> 
> I think a protocol that allows tags to be truncated at an arbitrary
> limit, without giving any indication of what that limit is, is right on
> the edge of "having potential for causing harm."  It could change the
> meaning of tags in substantial ways.  SHOULD doesn't seem strong enough.
> Is there some way we can convey that it's a really, really awful idea
> without running afoul of RFC 2119?
> 
> --
> Doug Ewell
> Fullerton, California
> http://users.adelphia.net/~dewell/
> 
> 
> 
>

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 24 May 2005 10:58:29 -0700

Changes being made as noted below.

Addison

Addison P. Phillips

> Behalf Of Frank Ellermann
> Sent: 2005?5?24? 1:21
> To: [email-masked]
> Randy Presuhn wrote:
> > "[a]ny such limitation MUST be clearly documented"
> 
> It was "MUST be documented" + "ShOULD NOT be divided", and we
> agreed to swap MUST / SHOULD.  Didn't quite make it in -02, I
> forgot to check it,  Still needs to be fixed in -03pre
[Addison Phillips] 

Done, will post later.
.
> 
> > "If the processor generates tags, it MUST do so in canonical
> > form..." doesn't fit within 2119's framework, but a SHOULD
> > would be appropriate.
> 
> Apparently that has been removed in -03pre.
[Addison Phillips] 

References to canonical form are mostly removed or SHOULD-ified.
> 
> > "it is reasonable to assume that there MUST be additional
> > very compelling evidence", the "MUST" clearly should be
> > "must".
> 
> <g>  Indeed.  This MUST be a disease of all draft editors,
> sooner or later they forget that lower case "must", "should",
> etc. still exist and even have a meaning.
[Addison Phillips] 

De-MUSTardized.
> 
> > a couple of "STRONGLY RECOMMENDED"s
> 
> Two.  Still in -03pre.  In theory it's allowed to define it,
> but it would look silly.  The first I ever saw an IETF WG it
> was in the process of an "OUGHT-ification" with an upper case OUGHT as
> something that's not quite a SHOULD.  The effect was
> hilarious... and removed a.s.a.p.
[Addison Phillips] 

Fixed.
>                          Bye, Frank