Re: [Rswg] [rfc-i] New draft of grammar as implemented

Hi John,
Re: draft-irse-draft-irse-xml2rfcv3-implemented-02.txt, items 1-3 that I sent below apply to this document as well. (They are about the sourcecode type attribute, artwork type attribute, and area element.) I've noted below where the section number has changed.

Alice
--

> Begin forwarded message:
> 
> From: Alice Russo <arusso@amsl.com>
> Subject: Re: [rfc-i] New version of rfc 7991bis
> Date: May 23, 2022 at 12:47:08 PM PDT
> To: John R Levine <johnl@taugh.com>
> Cc: RFC Interest <rfc-interest@rfc-editor.org>
> 
> Hi John,
> 
> Thanks for your work on this. Notes below on draft-iab-rfc7991bis-04.
> 
> 1) 2.6.7. "type" Attribute

now: 3.46.5
> 
> 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

now: 3.6.7

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

[This doesn't apply to draft-irse-draft-irse-xml2rfcv3-implemented-02 bc it doesn't seem that xml2rfc has been updated.]

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

> On Sep 18, 2022, at 1:05 PM, John R Levine <johnl@taugh.com> wrote:
> 
> I've updated the draft to address some issues Martin Thompson brought up.
> 
> As far as I know, what the draft says matches what xml2rfc does.
> 
> https://datatracker.ietf.org/doc/draft-irse-draft-irse-xml2rfcv3-implemented/
> 
> 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
> 