Subject: [Dime] RFC3588 Error semantics

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 6 Mar 2006 15:32:14 -0500

I am confused about error semantics defined in RFC3588 7. Error Handling

AFAICS, in general one can have two different uses for reporting errors:
a)Conveying result for a request, if it fails
b)Reporting unexpected behavior

a) seems applicable only for requests, b) for both requests and answers.

I noticed that for some error codes the scope is limited to requests
specifically, e.g. DIAMETER_INVALID_MESSAGE_LENGTH, DIAMETER_MISSING_AVP,
whereas for some other ones the scope is mentioned as "message", e.g.
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES, DIAMETER_AVP_NOT_ALLOWED.

What is the criteria to decide whether an error is applicable only for
requests or for any message type, e.g. why is DIAMETER_MISSING_AVP only
applicable to requests, whereas DIAMETER_AVP_OCCURS_TOO_MANY_TIMES is
specified as applicable for a message?

Secondly, how the errors for answers going to be routed anyhow? Will the 'r'
bit set? If not, how can a relay agent route it, considering that it
probably will try to route based on h2hId, like it is doing for other answer
messages, -at the time such a message is received, there won't be a matching
h2hId on the relay agent-? If the 'r' bit is set, are we expecting the relay
agent to be clever enough not to store the h2hId to match for the answer
routing?

Or, are errors never supposed to be sent for received answers? If so, don't
we miss some mechanims to convey information about malformed messages by
server?

     Thanks,
     Tolga

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

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 06 Mar 2006 20:44:04 -0500

Tolga,

I'm pretty sure the intention is that the Result-Code AVP is present 
only in answer messages and that answer messages are not sent in 
response to answer messages, only in response to requests. Not having a 
mechanism for reporting errors in response messages in not unique to 
Diameter (SIP and ICMP springs to mind). I don't really see that as a 
big problem although some guidance on how to handle various types of 
errors found in messages might be useful.

Anders

---

From: <[email-masked]>
Date: Tue, 7 Mar 2006 12:50:52 +0200

I'm not to sure any extra text in 3588 would really help - RFCs
shouldn't
specify every detail ...  

>-----Original Message-----
>From: ext Anders Kristensen [mailto:[email-masked]] 
>Sent: 07 March, 2006 03:44
>To: Tolga Asveren
>Cc: [email-masked]
>Subject: Re: [Dime] RFC3588 Error semantics
>
>Tolga,
>
>I'm pretty sure the intention is that the Result-Code AVP is 
>present only in answer messages and that answer messages are 
>not sent in response to answer messages, only in response to 
>requests. Not having a mechanism for reporting errors in 
>response messages in not unique to Diameter (SIP and ICMP 
>springs to mind). I don't really see that as a big problem 
>although some guidance on how to handle various types of 
>> a)Conveying result for a request, if it fails b)Reporting unexpected 
>> behavior
>> 
>> specifically, e.g. DIAMETER_INVALID_MESSAGE_LENGTH, 
>> DIAMETER_MISSING_AVP, whereas for some other ones the scope 
>is mentioned as "message", e.g.
>> requests or for any message type, e.g. why is DIAMETER_MISSING_AVP 
>> only applicable to requests, whereas 
>> DIAMETER_AVP_OCCURS_TOO_MANY_TIMES is specified as 
>applicable for a message?
>> 
>> probably will try to route based on h2hId, like it is doing 
>for other 
>> answer messages, -at the time such a message is received, 
>there won't 
>> be a matching h2hId on the relay agent-? If the 'r' bit is 
>set, are we 
>> expecting the relay agent to be clever enough not to store the h2hId 
>> to match for the answer routing?
>> 
>> Or, are errors never supposed to be sent for received 
>answers? If so, 
>> don't we miss some mechanims to convey information about malformed 
>> messages by server?
>> 
>> 
>>      Thanks,
>>      Tolga
>> 
>> 
>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 7 Mar 2006 09:07:16 -0500

Anders,

> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Monday, March 06, 2006 8:44 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Yes, using errors only for requests is not a big issue, client can
drop connection anytime if it is unhappy with responses sent by the server
anyhow. For any possible text clarification, I would think using the word
"request" in all of the error code descriptions could be an idea -that for
certain error codes the description contains the word "message" was the
starting point for my confusion-.
> DIAMETER_MISSING_AVP,