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 -- Peter Saint-Andre https://stpeter.im/