Re: [rfc-i] New version of rfc 7991bis

Hi John,

Thanks for your work on this. Notes below on draft-iab-rfc7991bis-04.

1) 2.6.7. "type" Attribute

CURRENT
The RFC Series Editor will maintain a complete list of the preferred	
values on the RFC Editor web site, and that list is expected to be	
updated over time. Thus, a consumer of v3 XML should not cause a
failure when it encounters an unexpected type or no type is
specified.

SUGGESTED
A list of the preferred values is maintained on the RFC Editor web site (https://www.rfc-editor.org/materials/sourcecode-types.txt), and that list is updated over time. Thus, a consumer of RFCXML should not cause a failure when it encounters an unexpected type or no type is specified.

Rationale: Remove mention of the RFC Series Editor. Perhaps change from "v3 XML" to "RFCXML" per "What was previously referred to as "the xml2rfc vocabulary" is now referred to as RFCXML" in [1] (and similar in 2.46.5). Compare the vocabulary reference [2].

2) 2.46.5. "type" Attribute

CURRENT
   The RFC Series Editor will maintain a complete list of the preferred
   values on the RFC Editor web site, and that list is expected to be
   updated over time.  Thus, a consumer of v3 XML should not cause a
   failure when it encounters an unexpected type or no type is
   specified.  The table will also indicate which type of art can appear
   in plain-text output (for example, type="svg" cannot).

SUGGESTED
 [cut.]

Rationale: Such a list does not exist. 

Also

CURRENT:
   The preferred values for <artwork> types are:

   *  ascii-art

   *  binary-art

   *  call-flow

   *  hex-dump

   *  svg

Perhaps:
   *  ascii-art

   *  binary-art

   *  svg

Rationale:
Past discussion and the recent revisit with the CMT confirmed that the only values that should be used are "ascii-art" and "svg". "binary-art" was kept per your suggestion. Compare the vocabulary reference [3].

3) 2.4. <area>

CURRENT
> A list of full names and abbreviations will be kept by the RFC Series Editor.

Suggested:
 [cut.]

Rationale: Such a list does not exist. 

4) A.3. The "submissionType" Attribute

CURRENT
The values for the attribute are "IETF" (the default value),	
"independent", "IAB", and "IRTF".

Suggested:
The values for the attribute are "IETF" (the default value),	
"independent", "IAB", "IRTF", and "editorial". 

Rationale: Because the new RFC Editor model docs were approved, go ahead and add the Editorial stream. Seemingly, similar updates are needed for the preceding paragraph and 2.47 <stream>.

[1] https://mailarchive.ietf.org/arch/msg/tools-discuss/-81vVY666019FWZp4kHrxNdZN_k/
[2] https://authors.ietf.org/rfcxml-vocabulary#type-2  (for sourcecode)
[3] https://authors.ietf.org/rfcxml-vocabulary#type  (for artwork)

Thanks,
Alice

On May 2, 2022, at 12:38 PM, John R Levine <johnl@taugh.com> wrote:

> I recently pushed out a new version of 7991bis.  It brings the draft mostly into agreement with what xml2rfc accepts.
> 
> The main difference I am aware of is that the XML <link> element in xml2rfc was implemented completely differently from what was in 7991, making it look more link HTML web links.  (The <link> eleements in generated HTML really are web links, this is in the XML.)  It is not clear to me whether we should make the code match the spec or the spec match the code.  The links are generated by the prep tool so mechanically regnerating them would not be very hard.
> 
> Take a look, tell me what else I missed.
> 
> Coming soon: things I think we should clean up in published XML.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest