Subject: Re: [Dime] Invalid AVP within a Grouped AVP

From: Victor Fajardo <[email-masked]>
Date: Wed, 01 Mar 2006 08:37:40 -0500

Hi,

>Wouldn't it be better to give to the peer that makes the error as much information as possible?
>
>One way to do that would be to send the Failed-AVP with the erroneous AVP, but inside the Grouped AVP.  That is, sending a Diameter Answer with only the Grouped AVP that failed, containing a Failed AVP with the AVP that caused the error.
>
>I believe that for an application, it would be very interesting to know which is the part of the information that was erroneous or missing in the request.  And since the Grouped AVP will contain more than one information element, it would be hard to guess which is the one that caused the problem if the answer only refers to a problem in the Grouped AVP.
>
>You could argue that it may not be possible to include the Failed-AVP inside the Grouped AVP, since the ABNF of the Grouped AVP could avoid this possibility.  But since this will be a revised version of Diameter, then it could also be recommended or mandatory to allow the Failed AVP inside Grouped AVPs.  Would that be feasible?
>  
>
I think it maybe better to just extend the definition of Failed-AVP to
somehow provide inheritance information of each offending avp belonging
to a group (which maybe deep). This is probably easier for a parser
since the failed-avp occurs only at the root level as it is now (instead
of deep inside a group). It also minimizes ABNF changes. Additionally, I
also think reason code(s) (i.e, avp not allowed, duplicate avp etc) for
the each offending AVP should be provided instead of just relying on the
value of result-code avp since each offending AVPs could have different
reasons for failing.

Regards,
victor

>Thank you for bringing up this issue, I also think that it would be a good idea to include it in the next RFC.
>
>German.
>
>  
>
>>-----Original Message-----
>>From: Anders Kristensen [mailto:[email-masked]] 
>>Sent: sábado, 25 de febrero de 2006 15:45
>>To: [email-masked]
>>Cc: [email-masked]
>>Subject: Re: [Dime] Invalid AVP within a Grouped AVP
>>
>>OK, makes sense. Probably should be made explicit in the next 
>>version of the spec.
>>
>>Thanks,
>>Anders
>>
>>[email-masked] wrote:
>>
>>    
>>
>>>I agree with David on this.  The top-level AVP would be the best to 
>>>return the with the error.
>>>
>>>John
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: ext David Connelly [mailto:[email-masked]]
>>>>Sent: 25 February, 2006 08:16
>>>>To: Anders Kristensen
>>>>Cc: [email-masked]
>>>>Subject: Re: [Dime] Invalid AVP within a Grouped AVP
>>>>
>>>>I think the top level AVP is better since it is really the 
>>>>        
>>>>
>>AVP whose 
>>    
>>
>>>>value is incorrect. It is also less ambiguous in some 
>>>>        
>>>>
>>situations. For 
>>    
>>
>>>>example, if a CER message contained a 
>>>>        
>>>>
>>Vendor-Specific-Application-Id 
>>    
>>
>>>>with a bad Vendor-Id AVP, and we were to return that 
>>>>        
>>>>
>>Vendor-Id AVP as 
>>    
>>
>>>>invalid, then how would a peer know if the Failed-AVP refers to the 
>>>>embedded Vendor-Id or the top-level Vendor-Id AVP for the 
>>>>        
>>>>
>>CER itself?
>>    
>>
>>>>- David
>>>>
>>>>On Feb 24, 2006, at 1:20 PM, Anders Kristensen wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>Suppose an AVP nested within a Grouped AVP is illegal. Should the 
>>>>>server return the "most specific" illegal child AVP or the
>>>>>          
>>>>>
>>>>"top level" 
>>>>
>>>>        
>>>>
>>>>>Grouped AVP containing the offending AVP?
>>>>>
>>>>>Same question for a Grouped AVP with a missing mandatory child AVP.
>>>>>
>>>>>Thanks,
>>>>>Anders
>>>>>
>>>>>_______________________________________________
>>>>>DiME mailing list
>>>>>[email-masked]
>>>>>https://www1.ietf.org/mailman/listinfo/dime
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>DiME mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/dime
>>>>
>>>>        
>>>>
>>>      
>>>
>>_______________________________________________
>>DiME mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/dime
>>
>>    
>>
>
>_______________________________________________
>DiME mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dime
>
>
>
>  
>

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