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 <rjsparks@nostrum.com> Tue, 03 December 2013 20:14 UTC

Return-Path: <rjsparks@nostrum.com>
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 83F661AE0E0; Tue, 3 Dec 2013 12:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level:
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no
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 swrJGEEGRgNy; Tue, 3 Dec 2013 12:14:28 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE421AE0D6; Tue, 3 Dec 2013 12:14:28 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3KEPWW034676 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 3 Dec 2013 14:14:25 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <529E3BA1.1010606@nostrum.com>
Date: Tue, 03 Dec 2013 14:14:25 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: ietf@ietf.org
References: <20131127124920.17385.35362.idtracker@ietfa.amsl.com>
In-Reply-To: <20131127124920.17385.35362.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------090607010300090202060101"
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
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: Tue, 03 Dec 2013 20:14:30 -0000

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