Thanks for the review Thomas. Comments inline, only on those things that you had as issues:
On 21 Apr 2024, at 13:03, Thomas Fossati via Datatracker wrote:
- (234:23): error: This parser will truncate strings at %x00
- (236:28): error: This parser will truncate strings at %x00
- (238:25): error: This parser will truncate strings at %x00
- parsing failed: 3 errors encountered
I don't understand what the error message is trying to tell me though.
Looks to me like it is complaining about long lines once unwrapped. Nothing to fix here AFAICT.
- It'd be good to state the reasons why this document updates 3864
earlier than in §6.1. [1] recommends using the intro section for that.
Given that 3864 and 4021 are purely about IANA considerations, it seemed silly to call them out in the Abstract or Section 1 since they are not of technical import to the document.
- Any reason for using the .test TLD rather than .example? RFC2606
says: ".test" is recommended for use in testing of current or new DNS
related code. ".example" is recommended for use in documentation or as
examples.[1] https://authors.ietf.org/required-content, Introduction checklist
Two reasons: First, we needed enough easily distinguishable example addresses and using only <foo>.example and example.<foo> seemed like it would be too easily confused visually. But second, we were having problems keeping the examples to 72 characters for the text versions of the document. Using .test seemed the safest way to address the problem given that 2606 reserves it. Any downside you can see in using it?
Nits/editorial comments:
In §1.2.3:
OLD:
One reason for this latter requirement is that there are
long-established sites on the Internet with mail archives that go back
decades, archives with messages containing these elements.NEW:
One reason for this latter requirement is that long-established
Internet sites have mail archives dating back decades with messages
containing these elements.
No objection. Works for me.
In §3.6.4:
OLD:
Though listed as optional in the table (Table 1) in section 3.6NEW:
Though listed as optional in Table 1 of Section 3.6
That's an annoying artifact of xml2rfc. I'll have a go at fixing it.
Thanks again,
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
