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

[John C Klensin <[e-mail]>]

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

     john