Subject: 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

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Dec 2013 14:14:25 -0600

With many apologies to Peter and to the STOX WG for the timing of this:

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.
Should they translate a 503 into a <internal-server-error/> as for 
unknown 5xx-class responses?
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?

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".

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.
(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
undefined-condition      -> bad-request
unexpected-request       -> bad-request, unexpected-request

SIP -> XMPP -> SIP
300 -> 302
301 -> 410
302 -> 302
305 -> 302
380 -> 606, 406
400 -> 400
401 -> 401
402 -> UNDEFINED
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
504 -> 408
505 -> 606, 406
513 -> 403
600 -> 480, 600
603 -> 480, 600
604 -> 604, 404
606 -> 606, 406

RjS

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Dec 2013 11:32:01 -0700

On 12/9/13 6:53 AM, Dave Cridland wrote:
> On Wed, Nov 27, 2013 at 12:49 PM, The IESG <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     The IESG has received a request from the SIP-TO-XMPP WG (stox) to
>     consider the following document:
>     - 'Interworking between the Session Initiation Protocol (SIP) and the
>        Extensible Messaging and Presence Protocol (XMPP): Architecture,
>        Addresses, and Error Handling'
>       <draft-ietf-stox-core-07.txt> as Proposed Standard
> 
> 
> A small nit - §5.5 contains:
> 
>     Several examples follow, illustrating steps 3, 5, and 8 described
>    above (the percent-encoded string "%C3%BC" and XML Notation string
>    "&#00FC;" both represent the Unicode character LATIN SMALL LETTER U
>    WITH DIAERESIS).
> 
> I don't think this is quite true. The percent-encoded string is an
> encoding of the codepoint U+FC as UTF-8, whereas the construct &#00FC;
> is an XML notation for the character - which crucially is not part of
> the address format, but simple how one could transmit the address over
> XML (including XMPP).

You sent a similar message to the STOX WG list about another I-D
produced by that WG, but I didn't grok your point until just now. I
think this text would be clearer:

###

      +----------------------------+--------------------------+
      | SIP URI                    |  XMPP Address            |
      +----------------------------+--------------------------+
      | sip:[email-masked]    |  f&#xFC;@sip.example     |
      | sip:[email-masked]   |  o\[email-masked]  |
      | sip:[email-masked];gr=bar |  [email-masked]/bar     |
      +----------------------------+--------------------------+

   In the first example, the string "%C3%BC" is a percent-encoded
   representation of the UTF-8-encoded Unicode character LATIN SMALL
   LETTER U WITH DIAERESIS (U+00FC), whereas the string "&#xFC;" is the
   same character shown for documentation purposes using the XML
   Notation defined in [RFC3987] (in XMPP it would be sent directly as a
   UTF-8-encoded Unicode character and not percent-encoded as in a SIP
   URI to comply with the URI syntax defined in [RFC3986]).

###

> The example given is actually [email-masked] - due to there
> being no terminating ";", I'd expect that to be taken literally by an
> XML parser, and not be treated as [email-masked] as I suspect is
> desired.

That's a typo - the ';' is missing (and in fact the "00" is not needed
in accordance with the XML Notation from RFC 3987). Thus:

OLD
[email-masked]
NEW
tsch&#xFC;[email-masked]

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Dec 2013 12:25:58 -0700

> 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. :-)

> 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).

> unknown 5xx-class responses?

Yes, I think that's a reasonable mapping given the semantics of the SIP
503 response code.

> doesn't give us anything to map a 402 into. is <bad-request/> (the

I think so, but will make that explicit in the text.

> as applying to all future requests to this server, not just requests for

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.

> of them are surprising or unacceptable.

It's good that you checked these. Comments below.

> 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.

> unexpected-request       -> bad-request, unexpected-request

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.

I think that would now be 402 -> 400.

I think that would now be 503 -> 500.

Thanks again for the thorough reviews!

Peter

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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 09 Dec 2013 14:03:25 -0600

Everything below looks good to me.

RjS