Subject: Re: [lemonade] Comments about CATENATE-02

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Nov 2004 07:04:22 -0800

At 5:38 PM +0100 10/18/04, Alexey Melnikov wrote:

>  Pete Resnick wrote:
>
>>  On 10/14/04 at 12:06 AM +0100, Alexey Melnikov wrote:
>>
>>>   >4.  Response Codes
>>>
>>>>     When a CATENATE command fails it may return a response code that
>>>>     describes a reason for the failure.
>>>
>>>  I think this should be changed to:
>>>
>>>     When a CATENATE command fails it SHOULD return a response code that
>>>     describes a reason for the failure. Two possible response 
>>> codes are described below,
>>>     however other response codes are also possible.
>>>
>>>  i.e. we want to encourage detailed error reporting.
>>
>>  You will note that I have avoided citing RFC 2119 up to this 
>> point. RFC 2119 imperatives are *not* to be used to "encourage" 
>> anything that does not affect interoperability. I'd really prefer 
>> to leave it as-is.
>
>  More precise error reporting simplifies debugging and error 
> handling. It doesn't affect interoperability directly.

More precise error reporting can affect (and can improve) 
interoperability if it gives advice to the client on how to respond 
to an error.  Especially if the error is transitory or permanent and 
if the error can be corrected by the client and/or user.  E.g., with 
TOOBIG, does the size exceed a policy limit or the amount of disk 
currently available?  Is it the entire resulting message that is too 
big, or a chunk of it?

>
>  When I see "SHOULD" in a document I usually think "this is pretty 
> important, I better implement it". Otherwise I am more likely to 
> ignore it.
>  I guess this is just me.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is always an easy solution to every human problem -- neat,
plausible, and wrong.                            --H.L. Mencken

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Nov 2004 15:24:49 +0000

Randall Gellens wrote:

>>>  You will note that I have avoided citing RFC 2119 up to this point. 
>>> RFC 2119 imperatives are *not* to be used to "encourage" anything 
>>> that does not affect interoperability. I'd really prefer to leave it 
>>> as-is.
>>
> interoperability if it gives advice to the client on how to respond to 
> an error.

Yes.

> Especially if the error is transitory or permanent and if the error 
> can be corrected by the client and/or user.  E.g., with TOOBIG, does 
> the size exceed a policy limit or the amount of disk currently available?

Ok, so may be we need multiple separate response codes. Maybe "TOOBIG" 
SP <details>

> Is it the entire resulting message that is too big, or a chunk of it?

Does it matter?