Re: [Stox] Last Call: <draft-ietf-stox-core-07.txt> (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling) to Proposed Standard

[Robert Sparks <[e-mail]>]

Everything below looks good to me.

RjS

On 12/9/13 1:25 PM, Peter Saint-Andre wrote:
> On 12/3/13 1:14 PM, Robert Sparks wrote:
>> With many apologies to Peter and to the STOX WG for the timing of this:
> Hi Robert, no apologies are necessary (although I apologize for the slow
> reply!) -- that's what WG and IETF-wide reviews are for. :-)
>
>> I still think there's a couple of small problems with the treatment of
>> translation into and out of 503.
>>
>> The first is that we left folks without guidance if they're handling
>> translating a SIP response into an XMPP
>> response in this case - the document's rather silent about that
>> direction in the note in section 6.1.
> Good point. I think it would be helpful to make this clear in Section
> 6.2 (referring back to the note in Section 6.1).
>
>> Should they translate a 503 into a <internal-server-error/> as for
>> unknown 5xx-class responses?
> Yes, I think that's a reasonable mapping given the semantics of the SIP
> 503 response code.
>
>> There's a similar issue with 402 - the pointer to note 1 says
>> <payment-required/> no longer exists, but
>> doesn't give us anything to map a 402 into. is <bad-request/> (the
>> unknown 4xx mapping) ok?
> I think so, but will make that explicit in the text.
>
>> The second is a nit with the text in the note in section 6.1. It
>> currently says " the SIP 503 response
>> code will be interpreted as applying to the entire domain, not only the
>> specific user". That's not
>> quite right, and it's important to get this right since we're leaving it
>> mostly to the gateway designer
>> to guess at what to do. The 503 talks about the element that returned
>> it, not anything in the request,
>> so while it's right that it's not only talking about a specific user,
>> it's not right to say it's talking about
>> an entire domain (and while that entire domain would be affected _at
>> this element_, it's more than that -
>> _ANY_ domain's resource routed to this element will not be handled by
>> this element until the condition
>> that led to the 503 goes away). I suggest saying this instead: "the SIP
>> 503 response code will be interpreted
>> as applying to all future requests to this server, not just requests for
>> the specific user".
> Although the subtleties of SIP elements and response codes are not
> completely clear to me, based on what I know your text seems better to me.
>
>> I also whipped up some bad python to look at what round-tripping an
>> errror from XMPP->SIP->XMPP and
>> vice-versa looked like as a sanity check (which brought the 503 and 402
>> issues in the first item above to
>> my attention). Here's the result. Please look over them and see if any
>> of them are surprising or unacceptable.
> It's good that you checked these. Comments below.
>
>> (They are easier to read in a fixed-width font).
>>
>> I'm particularly suspicious of subscription-required ->
>> registration-required and of 301 -> 410.
>>
>>
>> XMPP -> SIP -> XMPP
>> bad-request              -> bad-request
>> conflict                 -> bad-request
>> feature-not-implemented  -> feature-not-implemented
>> forbidden                -> policy-violation, forbidden,
>> recipient-unavailable, not-allowed
>> gone                     -> gone
>> internal-server-error    -> internal-server-error
>> item-not-found           -> item-not-found, remote-server-not-found
>> jid-malformed            -> bad-request
>> not-acceptable           -> not-acceptable
>> not-allowed              -> policy-violation, forbidden, not-allowed
>> not-authorized           -> not-authorized
>> policy-violation         -> policy-violation, forbidden, not-allowed
>> recipient-unavailable    -> recipient-unavailable
>> redirect                 -> redirect
>> registration-required    -> registration-required
>> remote-server-not-found  -> remote-server-timeout, item-not-found,
>> remote-server-not-found
>> remote-server-timeout    -> remote-server-timeout, remote-server-not-found
>> resource-constraint      -> internal-server-error
>> service-unavailable      -> policy-violation, forbidden,
>> feature-not-implemented, not-allowed
>> subscription-required    -> registration-required
> Looking again at RFC 3261 and RFC 6120, I conclude that mapping XMPP
> subscription-required to SIP 407 isn't quite right, because as far I
> understand it SIP 407 has to do with authentication at a proxy, which is
> not what XMPP subscription-required is about. Thus I suggest that we map
> XMPP subscription-required to SIP 400, which would result in a
> round-trip translation of:
>
> subscription-required -> bad-request
>
> IMHO that's less problematic than the translation you've highlighted.
>
>> undefined-condition      -> bad-request
>> unexpected-request       -> bad-request, unexpected-request
>>
>> SIP -> XMPP -> SIP
>> 300 -> 302
>> 301 -> 410
> It seems that the difference between 301 and 410 in SIP response codes
> is just the lack of a forwarding address. If that is correct, we can
> handle this by mapping as follows:
>
> SIP 301 -> XMPP <gone/> with XML character data for new address
> SIP 410 -> XMPP <gone/> with no XML character data (new address unknown)
>
> Then we can map:
>
> XMPP <gone/> with XML character data -> SIP 301
> XMPP <gone/> without XML character data -> SIP 410
>
> This would result in a round-trip mapping of 301 -> 301.
>
>> 302 -> 302
>> 305 -> 302
>> 380 -> 606, 406
>> 400 -> 400
>> 401 -> 401
>> 402 -> UNDEFINED
> I think that would now be 402 -> 400.
>
>> 403 -> 603, 403
>> 404 -> 408, 604, 404
>> 405 -> 405, 501
>> 406 -> 606, 406
>> 407 -> 407
>> 408 -> 408, 404
>> 410 -> 410
>> 413 -> 403
>> 414 -> 403
>> 415 -> 606, 406
>> 416 -> 606, 406
>> 420 -> 405, 501
>> 421 -> 606, 406
>> 423 -> 500
>> 430 -> 480, 600
>> 439 -> 405, 501
>> 440 -> 403
>> 480 -> 480, 600
>> 481 -> 604, 404
>> 482 -> 606, 406
>> 483 -> 606, 406
>> 484 -> 604, 404
>> 485 -> 604, 404
>> 486 -> 480, 600
>> 487 -> 480, 600
>> 488 -> 606, 406
>> 489 -> 403
>> 491 -> 400, 491
>> 493 -> 400
>> 500 -> 500
>> 501 -> 405, 501
>> 502 -> 408, 404
>> 503 -> UNDEFINED
> I think that would now be 503 -> 500.
>
>> 504 -> 408
>> 505 -> 606, 406
>> 513 -> 403
>> 600 -> 480, 600
>> 603 -> 480, 600
>> 604 -> 604, 404
>> 606 -> 606, 406
>>
>>
>> RjS
> Thanks again for the thorough reviews!
>
> Peter
>