Re: [Technical Errata Reported] RFC9110 (7870)

OK. I understand how you can read it that way, but it's quite contorted; I don't think the current text is unclear. Rewriting to remove the word 'exception' would imply that there are other situations where the message could be forwarded after rewriting, and that is undesirable.

Cheers,


> On 26 Mar 2024, at 10:46, Ben Kallus <benjamin.p.kallus.gr@dartmouth.edu> wrote:
> 
>> 'forward' and 'send' are defined terms in the specification, and the previous paragraph covers the 'send' -- this requirement is specific to forwarding. It's specifically there to call out the exception _only_ in the forwarding case. The existing text already specifies your option #2.
> 
> Fair enough. On to the second issue...
> 
>> How does the existing text not allow a message to be forwarded once the invalid field is replaced?
> 
> That's exactly right; the existing text *does* allow a message to be
> forwarded once the invalid field is replaced. That's the problem! Let
> me take another try at explaining this.
> 
> The first half of the sentence says that malformed CL header values
> MUST NOT be forwarded intact. In order for the second half of the
> sentence to constitute an "exception" to the first half, it would have
> to describe a situation in which a malformed CL header value *is*
> allowed to be forwarded intact (i.e., preserved in the outgoing
> message).
> 
> The thing is, the second half of the sentence does not describe such a
> situation. Instead, it describes a situation in which an invalid value
> is allowed to be normalized (i.e., the invalid value is *not* present
> in the outgoing message).
> 
> This is therefore a misuse of the word "exception," in my opinion.
> When something is described as an "exception" to a rule, I am
> expecting that thing to be a case in which the rule does not apply.
> 
> -Ben

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 26 March 2024 00:12:20 UTC