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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 09 December 2013 19:26 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B61AE4E1; Mon, 9 Dec 2013 11:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level:
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZS_SOTAQQJ5; Mon, 9 Dec 2013 11:26:03 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A2F281AE4C3; Mon, 9 Dec 2013 11:26:03 -0800 (PST)
Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C5484010C; Mon, 9 Dec 2013 12:25:58 -0700 (MST)
Message-ID: <52A61946.5010908@stpeter.im>
Date: Mon, 09 Dec 2013 12:25:58 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>, ietf@ietf.org
References: <20131127124920.17385.35362.idtracker@ietfa.amsl.com> <529E3BA1.1010606@nostrum.com>
In-Reply-To: <529E3BA1.1010606@nostrum.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
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
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 19:26:06 -0000

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/