Re: NEW ISSUE: repeating non-list-type-headers

Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>>>>    Multiple message-header fields with the same field-name MUST NOT be
>>>>    present in a message unless the entire field-value for that
>>>>    header field is defined as a comma-separated list [i.e., #(values)].
>>> No, unlike the old text, that does not say when you may use them.
>> Ahem? "...unless the entire field-value..."?
> 
> You are turning "Messages may X iff Y" into "Messages must not X unless
> Y"; if Y is true, with the old version you know "Messages may X", with
> your version you just know you are not violating "Messages must not X".
> It might well be that Messages SHOULD NOT include duplicates even then.

Sorry?

Unless there's another place in the spec making statements about 
repeating headers (is there?), both

   MAY do X, iff Y

and

   MUST NOT do X, unless Y

are equivalent.

>> Of course both forms should be treated the same. The question I was 
>> asking: what is a recipient -- in particular a client -- supposed to do 
>> with a message where header values are known to be invalid?
> 
> Where the specification does not say that, the client is supposed to do
> something that's appropriate for the particular client and the circum-
> stances it is acting in. Some clients may close the connection on sight
> of the bad header, others might ignore it, others might process only
> some part of it, and yet others might not notice the error at all. It's
> unlikely there is a one size fits all recommendation we could make.

I'm concerned about clients that ignore the problem and randomly pick 
one of the values.

Best regards, Julian

Received on Tuesday, 20 November 2007 11:09:24 UTC