Re: [Stox] core: response code mappings

[Daniel-Constantin Mierla <[e-mail]>]

On 8/19/13 10:23 PM, Peter Saint-Andre wrote:
> On 8/19/13 2:02 PM, Paul Kyzivat wrote:
>> On 8/16/13 10:28 PM, Peter Saint-Andre wrote:
>>> The SIP Parameters Registry has a list of SIP response codes:
>>>
>>> http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-7
>>>
>>>
>>> A number of those are not specified in RFC 3261. Thus the question
>>> arises: for which codes do we need to define mappings? We could define
>>> mappings for all of them, but I wonder if that's advisable. Some of the
>>> additional codes are specified in RFCs that update RFC 3261 (e.g., code
>>> 440 from RFC 5393), whereas other codes are specified in "non-core" RFCs
>>> that don't update RFC 3261 (e.g., code 470 from RFC 5360). Would it
>>> perhaps make sense to map the "core" codes and not the "non-core" codes?
>> I know this is almost a non-answer, but...
>>
>> The codes that are defined in other RFCs are there to support features
>> that are introduced in those RFCs. If there is a mapping of that feature
>> to XMPP, then there should be a mapping of the code.
> That makes sense.
>
>> If there is no mapping of the feature, then mapping the code is less
>> important, but still perhaps useful in some cases. E.g., it could
>> conceivably show up in a Reason code based on signaling that was never
>> gatewayed to xmpp. But maybe a default mapping would be sufficient in
>> those cases.
> I suspect that the default mapping would be fine.
>
> And in general, there might be more art than science here.
>
> I have written some proposed text for this section, but it's fairly long
> so my inclination is to submit a revised I-D and then folks can review
> what I've written and post to the list with feedback.
Looking at the latest draft, it seems to bring confusion on mapping from 
xmpp-to-sip on 400 code. I read this thread and kind of understood that 
any not-obvious-mapping similar-to-a-4xx case would be handled same as 
400 in SIP, but typically the 400 response is given for a malformed sip 
requests (like broken grammar).

After quick read, <conflict/> would map more suggestively to 403 
Forbidden. Maybe <policy-violation> and <undefined-condition/> could get 
other mappings as well.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda