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> Mon, 09 December 2013 20:03 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 E0BAB1AE2AB; Mon, 9 Dec 2013 12:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 sLM64ysuivUk; Mon, 9 Dec 2013 12:03:32 -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 C9A5F1AE281; Mon, 9 Dec 2013 12:03:31 -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 rB9K3Pfb025910 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 9 Dec 2013 14:03:26 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52A6220D.8010005@nostrum.com>
Date: Mon, 09 Dec 2013 14:03: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.1
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>, ietf@ietf.org
References: <20131127124920.17385.35362.idtracker@ietfa.amsl.com> <529E3BA1.1010606@nostrum.com> <52A61946.5010908@stpeter.im>
In-Reply-To: <52A61946.5010908@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 09 Dec 2013 20:03:34 -0000

Everything below looks good to me.

RjS

On 12/9/13 1:25 PM, Peter Saint-Andre wrote:
> 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
>