Re: [Stox] core: response code mappings

[Peter Saint-Andre <[e-mail]>]

On 8/19/13 3:44 PM, Daniel-Constantin Mierla wrote:
> 
> 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).

So your suggestion is that we avoid mapping XMPP error conditions to SIP
400 unless the XMPP condition is caused by a malformed request?

> After quick read, <conflict/> would map more suggestively to 403
> Forbidden. 

As I said, it's perhaps more art than science. But mapping <conflict/>
to 403 seems reasonable if we accept your suggestion about not mapping
to 400 unless we have a good reason to do so.

> Maybe <policy-violation> and <undefined-condition/> could get
> other mappings as well.

Well, depending on the policy being violated, <policy-violation/> might
map to 413, 414, 513, or even 406/606.

Given that <undefined-condition/> is something of a catch-all, it's not
clear to me what we'd map it to in a consistent way. That would probably
depend on the application-specific element contained in the error stanza.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/