Re: [Last-Call] [art] Genart last call review of draft-nottingham-rfc7320bis-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Robert, thanks for your review. Mark, thanks for your responses. I entered a Yes ballot. I have a comment below regarding the RFC 6838 reference.

> On Nov 26, 2019, at 9:32 PM, Mark Nottingham <mnot@xxxxxxxx> wrote:
> 
> 
> 
>> On 27 Nov 2019, at 1:13 pm, Carsten Bormann <cabo@xxxxxxx> wrote:
>> 
>> On Nov 27, 2019, at 02:56, Mark Nottingham <mnot@xxxxxxxx> wrote:
>>> 
>>> Do we expect most readers to be comparing the documents so closely? This is an 'obsoletes', not an 'updates'.
>> 
>> Speaking for myself as a reader only: Yes.
> 
> My concern is that every time we add text to a document, we increase the cognitive load for readers; adding the reasoning for *every* decision and change expands a page of text into 2 to 3 (or more), so we need to impose a filter of some sort.
> 
> The requirement in question is:
> 
> "Media type definitions (as per [RFC6838]) SHOULD specify the fragment identifier syntax(es) to be used with them"
> 
> It was removed because it was misleading (6838 doesn't make such a requirement a SHOULD), and the focus of this update was to reduce the number of unnecessary requirements.

I think a good solution here would be to add a sentence along the lines of the sentence above to the shepherd write-up. That way the rationale for the substitution is captured in the document’s history but not in the document itself.

Thanks,
Alissa


> 3986 isn't replacing that reference; it's providing a grounding for what fragment identifiers are.
> 
> IME this information doesn't help the reader understand the document any better unless they're closely comparing the two documents (as reviewers are now doing, and thanks to them). If folks disagree, that's fine, but I'd like to understand why they think this information is worthy of documenting in-spec.
> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________
> art mailing list
> art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/art

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux