Re: [Rswg] Policy on application of <bcp14> tags?

[Bob Briscoe <[e-mail]>]

John,

On 17/12/2022 15:06, John C Klensin wrote:
>
> --On Thursday, December 15, 2022 08:47 +1300 Brian E Carpenter
> <[e-mail]> wrote:
>
>> On 15-Dec-22 04:57, Robert Sparks wrote:
>>> On 12/14/22 8:08 AM, Eliot Lear wrote:
>>>>
>>>> On 14.12.22 14:59, Bob Briscoe wrote:
>>>>> Mark,
>>>>>
>>>>> On 12/12/2022 02:36, Mark Nottingham wrote:
>>>>>> FWIW - we dealt with this in RFC8941; there's an example
>>>>>> of spec text that isn't actual spec text, and we had the
>>>>>> RPC remove the bcp14 tags.
>>>>> [BB] Thank you for this. This is exactly what I would
>>>>> expect.
>>>>>
>>>>>   From the conversation so far, I think there are some
>>>>>   subtle cases where keywords in capitals are not normative,
>>>>> and it all depends on context. So, my take-away message
>>>>> from all this is that any update to RFC7991 ought to say
>>>>> that "A <bcp14> tag does not alter the requirement level of
>>>>> the text, which is determined solely by the text itself and
>>>>> its context".
>>>> For the dopy among us, the <bcp14> tag <bcp14>*MUST
>>>> NOT*</bcp14> be used when normative language is not intended.
>>>>
>>> While not as funny, I have to point here to the similar irony
>>> in the discussion that developed the language in rfc8174
>>> which landed at
>>>
>>> ```
>>>
>>>          The key words "MUST", "MUST NOT", "REQUIRED",
>>>          "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>>>          "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>>          "OPTIONAL" in this document are to be interpreted as
>>>          described in BCP 14 [RFC2119] [RFC8174] when, and
>>>          only when, they appear in all capitals, as shown here.
>>> ```
>> 'as shown here but without quotation marks' would have been
>> better. Or to
>> cover Bob's issue:
>>
>> 'as shown here but without quotation marks, and not as part of
>> a quotation
>> from another document.'
>>
>> So in answer to my earlier question, I think this is an IETF
>> process issue,
>> with the applicability of the <bcp14> tag being an operational
>> detail.
> Brian,
>
> In addition to, or instead, of things you and others had to say
> about this particular issue (including whether there is an IETF
> process issue involved, I suggest this is part of the
> higher-level I've been trying to raise from time to time, one
> that definitely falls in the RSWG remit.   That involves several
> intertwined issues that I've tried to raise before but, because
> there have been no substantive responses, let me try again and
> state them in yet another slightly different way:
>
> * Is RFCXML markup intended as generic markup for use by
> document authors or as more format-like markup that is intended
> to be the output of other tools?  "Both" may be a reasonable
> answer.  However for cases where we expect document authors to
> use it directly, we should be careful to minimize the number and
> kind of document elements we expect to be identified by markup.
> If it is really only an intermediate language -- produced by
> other tools but expected to be used directly only by the RPC --
> then it is not clear whether discussions about applicability of
> particular elements are reasonable in this WG or whether those
> are operational issues for the RPC only.
>
> * An almost-different question is whether the main purpose for
> which document markup is designed and defined is document
> production (as more or less assumed in the bullet above) or
> whether it is to create metadata for indexing or searching
> documents or compiling statistics about them. However, if we
> intend RFCXML to be a tool to be used directly by authors, we
> should be careful about the number of such elements and their
> properties because the additional markup is burdensome for
> authors and may discourage people from writing or editing RFCs
> (or drive them toward higher-level tools rather than direct use
> of RFCXML -- as I said, almost different).  However, if we
> intend that those additional elements be added by heuristics
> (e.g., in markdown) or by the RPC and its tools, then it is not
> clear why we are discussing them here.  And, to the extent to
> which the concern is indexing or search independent of the
> document itself, why not just incorporate the heuristics into
> the indexing or search machinery rather than making the RFCXML
> source documents more complex (and having this sort of
> conversation when the heuristics get it wrong).
>
> That bring me back to <bcp14> but with the understanding that it
> is really just an example.  Now, RFC 7991 Section 2.9 says its
> use is optional (so does draft-iab-rfc7991bis-04.html).  If it
> is, then this discussion thread should probably be about whether
> it is needed at all or whether it should either be removed from
> the vocabulary or marked as "for RPC or other tool use only".
> Then it says "might be highlighted", which is a format markup
> statement if I have ever seen one and hence should be a matter
> for the RPC and not document authors.  If the RPC is expected to
> go through documents one sentence or word at a time to determine
> what should be highlighted (BCP 47-related or otherwise), why
> expect authors to do that too.  If we don't expect them to do
> that, then an optional <bcp47>" element is a recipe for keywords
> being highlighted in some documents and not others depending on
> whether the authors did the extra work (or markdown tools got
> the work right) and that is an inconsistency that we, and our
> readers, don't need.
>
> Conclusion: As we think about what new and different elements
> can be added to the vocabulary or redefined, can we look at the
> existing ones, especially the explicitly optional ones, and ask
> whether they are really needed and, if so, who or what should be
> supplying them?  If we are trying to encourage more people to
> participate in the IETF and write documents, complexity is not
> our friend.
>
> Finally, to repeat something said in passing above, <bcp47> is
> just an example and not the only one.  To illustrate, consider
> the distinction between <td> and <th>.

[BB] I agree with John. Of the options I gave in my original post, 
having read the posts so far, my preference is:
"2) Remove the <bcp14> tag from the vocabulary"

The status of requirements keywords is dependent on them being in 
capitals, which is more than adequate visually.
Quite aside from the risk of incorrect application of <bcp14> tags, I 
hadn't even noticed that the keywords were rendered in bold as well. And 
if I had, it wouldn't have helped my interpretation one jot.
So this tag is just complexity for no gain.

I also agree with John that any other instances of optional tags should 
be critically reviewed.
Keep it simple.

Cheers


Bob



>
>       john
>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/