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