Megan Ferguson <[email protected]> wrote: > Michael, Bernie, and Tim
> Combining a few author responses here to close these topics out:
> 1) Regarding the text Michael pointed out:
> We have updated to use Bernie’s suggestion (with a few editorial tweaks
Thank you.
Moving curious comments to the end.
>> I'm also curious about the how/why IA_PD-options got hyphen wrapped
>> (section 21.22), but in our text it was just moved to a new line.
>>
> [rfced] The submitted XML file contained a non-breaking hyphen in that
> instance. We did not keep the non-breaking hyphen, as typically words
> that "naturally" contain hyphens can contain line breaks in RFCs. If
> you want that particular term to be kept together, please let us know
> and we will insert the entity (&nbhy;)
Ah. I had looked at your XML, but not ours...
I suspect that RFC8415 had the non-breaking space, my guess... inserted by the
RPC.
I see it not hyphen-wrapped in 8415.
I don't have the XML for it handy, so I can't tell for sure :-)
{The XML in our git didn't have a non-breaking hyphen there}
**I'd rather it (&nbhy;) was put back so that someone doing a search ^S
IA_PD-options will find it**
>> I’m not seeing any difference from headers on 8415 that indicate this
>> would be an IETF Full Standard document?
>>
>> RFC8200 has “STD: 86”.
> [rfced] Thank you for bringing this to our attention. This document has
> been assigned a new STD number (102).
COOL.
> Please let us know if this is not correct (i.e., it should be part of
> an existing STD). See the complete list of Internet Standards here:
> https://www.rfc-editor.org/standards
I think that it's correct that it's a new STD.
Glad we caught that. Should it have been more clearly noted in some way/
> We will await approvals from each of the parties listed on the AUTH48
> status page prior to moving forward to publication.
...!
===
> 2) To address the “non-issues” in Michael’s mail:
>> ---- non-issues:
>>
>> A question about the many minor changes where a list item has a :
>> added. The colon appears in the <dt> as text, it's not produced by
>> xml2rfc. Someone did s,</dt>,:</dt>,g right?
> [rfced] Right.
>> So that seems like a stylistic thing that (authors) should just be
>> more aware of. It seems like it aught to be something xml2rfc
>> "enforces"
It was curiosity; generally as an author I prefer to stay as close to
whatever the RPC will produce as go. Not only does it make my review at the
end easier, (fewer meaningless changes), but presumably the RPC has good
readability reasons, and it makes life easier for others :-)
> [rfced] There is not a requirement that the term in a definition list
> be followed by a colon. Sometimes a term is followed by other
> punctuation or a line break (if newline="true"). From our perspective,
> this is a style choice that should not be enforced by the tool.
I wouldn't mind if the tool could optionally do this for us :-)
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
