Re: [urn] A 'newbie' question on the terminology used in RFCs

Julian Reschke <julian.reschke@gmx.de> Tue, 24 January 2012 15:03 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC59421F84D1 for <urn@ietfa.amsl.com>; Tue, 24 Jan 2012 07:03:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.241
X-Spam-Level:
X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY5rt5BrkNcq for <urn@ietfa.amsl.com>; Tue, 24 Jan 2012 07:03:23 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9D88721F84D4 for <urn@ietf.org>; Tue, 24 Jan 2012 07:03:15 -0800 (PST)
Received: (qmail invoked by alias); 24 Jan 2012 15:03:13 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 24 Jan 2012 16:03:13 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+4rgMAhK64cufalSuoLQJ0s3GveNJfuJZ9Z07Oga W4YWf30xNVRN2r
Message-ID: <4F1EC82F.1050406@gmx.de>
Date: Tue, 24 Jan 2012 16:03:11 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>
References: <201201241421.PAA01865@TR-Sys.de>
In-Reply-To: <201201241421.PAA01865@TR-Sys.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org
Subject: Re: [urn] A 'newbie' question on the terminology used in RFCs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2012 15:03:24 -0000

On 2012-01-24 15:21, Alfred � wrote:
> [[ speaking as author and document editor ]]
>
> Julian and Bengt,
> please see my inline comments below.
>
> On 2012-01-24, Julian Reschke wrote
>> 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.
>
> 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 ----
> ...

    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