Subject: [Ltru] Re: Fix for ambiguous conformance requirements

From: "Doug Ewell" <[email-masked]>
Date: Mon, 23 May 2005 22:05:15 -0700

McDonald, Ira <imcdonald at sharplabs dot com> wrote:

> Mark summarizes the apparent concensus of the mailing list,
> to whit, conformance requirements that are verifiable for
> human or software actors simply don't matter for this spec.

I don't agree with this one bit, and don't understand why Ira chose to
express himself that way.

There isn't anything about a conformance requirement that happens to be
written in passive tense that automatically makes it unverifiable, as
long as it is apparent who the actor is.  Language tags don't create and
interpret themselves, and anyone planning to make use of the draft would
understand that.  Turning the sentences around to say "you" or "the
user" might make the sentences punchier, but no more correct.

If the RFC says, "Variant subtags SHOULD be used only with their
recommended prefix," and I am the one who is "using" them (i.e. creating
them), then I consider the sentence absolutely equivalent to "You SHOULD
use variant subtags only with their recommended prefix."  I don't know
in what way this is unclear or not verifiable.

I only wish this active/passive voice issue were the biggest hurdle I
ever had to jump when soliciting or interpreting requirements.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 23 May 2005 23:53:01 -0700

Hi -

I think there are some problems with the use of the 2119 keywords
in draft-ietf-ltru-registry-02.txt

Specifically:

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.

Likewise, the requirement "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.

In the phrase "it is reasonable to assume that there
MUST be additional very compelling evidence", the "MUST" clearly
should be "must".

There are a couple of "STRONGLY RECOMMENDED"s that should be replaced
with "strongly RECOMMENDED".

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 24 May 2005 10:21:24 +0200

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.

> "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.

> "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.

> 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.

                         Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Wed, 25 May 2005 08:43:03 +0900

>etc. still exist and even have a meaning.

It would be great if 'must', 'should' could just be used
that way. But as a draft editor who has gone through these
kinds of things, I can tell you: I'll get comments asking
why this isn't upper case, and so on. There are other words
that avoid this, such as 'have to',...

 >hilarious... and removed a.s.a.p.

For some more on the hilarious side: In the W3C I18N WG, in
particular for the Character Model, we use(d) a yellowish
color for sentences containing MUST,... (see
http://www.w3.org/TR/charmod/#C001 for an example).
We talked about adding MUSTard when we discovered that there
was something that needed a MUST :-).

Regards,   Martin.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 26 May 2005 23:05:56 -0700

Hi -

If you think this item needs further discussion, please use an appropriate
subject line.

-------------------------------------------------------------------------
Message
http://www1.ietf.org/mail-archive/web/ltru/current/msg01840.html
proposes
(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.

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

Although the exact text did not find support, this comment did
trigger a review of the use of the 2119 keywords in the draft,
in line with the spirit of the comment.  Consequently, this item is
marked "resolved."

Randy, ltru co-chair