Subject: [urn] A 'newbie' question on the terminology used in RFC:s

From: Bengt Neiss <[email-masked]>
Date: Tue, 24 Jan 2012 10:43:10 +0000

Since I am new to IETF standardization and after reading draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there is a question I would like to ask....

In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'. Is this intentional and are there a difference in understanding lower-case versus upper-case words (ie. upper-case is interpreted as stated in RFC 2119 and lower-case is a less strict use of the word) or should the use of lower-case words (in this case) be considered a 'typo' that should be corrected to upper-case (and as such be interpreted according to RFC 2119)?

Regards

//Bengt

---------------------------------------------------------
Bengt Neiss
Kungl. Biblioteket / National Library of Sweden
Phone: +46 (0)10 709 35 41

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Jan 2012 11:52:03 +0100

On 2012-01-24 11:43, Bengt Neiss wrote:
> Since I am new to IETF standardization and after reading
> draft-ietf-urnbis-rfc3188bis-nbn-urn-02.txt there is a question I would
> like to ask....
>
> In the text 'SHOULD' and 'should' are used as well as 'MAY' and 'may'.
> Is this intentional and are there a difference in understanding
> lower-case versus upper-case words (ie. upper-case is interpreted as
> stated in RFC 2119 and lower-case is a less strict use of the word) or
> should the use of lower-case words (in this case) be considered a 'typo'
> that should be corrected to upper-case (and as such be interpreted
> according to RFC 2119)?

The latter.

It's best to avoid these lowercase variants.

If you don't want to invoke RFC 2119, use "might", "can", "ought to", 
"advised"...

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 24 Jan 2012 15:21:27 +0100 (MEZ)

[[ speaking as author and document editor ]]

Julian and Bengt,
please see my inline comments below.

On 2012-01-24, Julian Reschke wrote
>> that should be corrected to upper-case (and as such be interpreted

No.  That is deliberate.
'should' and 'may' are perfect, plain english words.
Only the fully capitalized versions carry the RFC 2119 semantics:

--- start of quotes from RFC 2119 ----

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.

...

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

--- end of quotes from RFC 2119 ----

> It's best to avoid these lowercase variants.

I do not share this opinion, in general.
Avoiding the normal forms and semantics of everyday auxiliary verbs
seems to be some kind of silly self-enforced "political correctness".
In cases where text talks about very formal procedures however,
I try to avoid the lowercase forms, just to avoid iterated discussions
whether the capitalized form should be used, besides in one important
case of circumstances:
When the spirit of current normative text (from inside or outside the
IETF) is referred to (yet not quoted literally, e.g. for reasons of
potential copyright issues, or to allow future evolution of those
documents), but the I-D/RFC text does not aim at overriding that
'foreign' normative text, I have been advised several times to keep
the lowercase form.  For instance, when reporting on requirements
within the rfc3187bis and rfc3188bis drafts that are laid down in
external standards (ISO 2108 for ISBN, National Library standards
for NBNs) but carry on to fulfill generic URN requirements for the
URN:ISBN and URN:NBN documents, the latter use the lowercase forms
in order to avoid perceived attempts to override the applicable
normative documents.

> If you don't want to invoke RFC 2119, use "might", "can", "ought to",

There are lots of differences in the semantics that might [ no pun
intended :-) ] make these choices less appropriate than "may",
"should", or "must", in specific cases.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Jan 2012 16:03:11 +0100

> --- end of quotes from RFC 2119 ----

    In many standards track documents several words are used to signify
    the requirements in the specification.  These words are often
    capitalized.  This document defines these words as they should be
    interpreted in IETF documents.  Authors who follow these guidelines
    should incorporate this phrase near the beginning of their document:

(note the 2nd sentence)

But yes, reasonable people disagree on this. The way of least resistance 
is not to use them.

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Wed, 25 Jan 2012 14:33:22 +0200

Hello,

RFC 2119, which is the sole authority as regards this issue, uses 
(certainly intentionally) both upper-case and lower-case versions of 
these words, and these terms do have different semantics:

>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation...

I have followed the policy Alfred outlines below which is identical to 
the spirit of RFC 2119. In the I-Ds I have drafted must and MUST do not 
mean the same thing. IMHO it would be less clear to the reader what the 
relation between MUST and terms like have to, ought to, etc. would be. 
And there would be no place to check this.

My conclusion from the discussion is that there is no need to change the 
current, RFC 2119 -based policy. I fail to see how any changes could 
make semantics more clear but there are definitely many ways to create a 
muddle by using terms which are not within the scope of RFC 2119. And 
IMHO we ought to (;-)) avoid such a situation.

Alas, not all standards organizations follow an identical policy as 
IETF. For instance, if an RFC is published as an ISO standard, some 
subtle changes will be necessary. I have been asked to change a quote 
(!) from an RFC since the terminology in the quote did not match the ISO 
rules.

Juha

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 13:47:30 +0100

> these words, and these terms do have different semantics:

Again, reasonable people disagree on this, and you will questions about 
this again and again. The easiest fix is to avoid the issue by simply 
not using the lowercase variants.

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Thu, 26 Jan 2012 08:29:21 +0200

Hello,

Reasonable people such as Alfred prefer using lowercase variants, and do 
not believe that avoiding them would fix anything. Since there is no 
approach that everybody would accept (as this discussion has already 
shown) I think it is better to stick to the policy implicit in RFC 2119.

It is unfortunate that standards are often written so that people, even 
after having actually red them, do not understand them in the same way. 
Revision of RFC 2119 is (fortunately) not on the charter of URNbis. But 
it seems to me that there is a need to clarify the RFC key word policy 
so as to make an end to this kind of semantic uncertainty which makes 
writing and understanding RFCs more difficult than it should be. Other 
standards communities I have been involved with do not have this kind of 
systemic terminological issues, although now and then some individual 
concepts have been difficult to nail down. For instance in the Dublin 
Core community we had hard times trying to agree on what a document like 
object is, and finally gave up and started using the term resource 
instead.

IETF may not be able to agree on the ideal approach (even reasonable 
people can be stubborn and stick to their own views), but that will not 
be a problem of the URNbis. Within this WG the editors only need to make 
sure that all the documents produced follow the same key word policy.

Juha

-- 

  Juha Hakala