Re: [Stox] core: response code mappings
Daniel-Constantin Mierla <miconda@gmail.com> Tue, 20 August 2013 08:43 UTC
Return-Path: <miconda@gmail.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5553611E81F2 for <stox@ietfa.amsl.com>; Tue, 20 Aug 2013 01:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level:
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MLH_Stock1=0.87]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nxKAYt9qr8c for <stox@ietfa.amsl.com>; Tue, 20 Aug 2013 01:43:55 -0700 (PDT)
Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CB02611E81C5 for <stox@ietf.org>; Tue, 20 Aug 2013 01:43:54 -0700 (PDT)
Received: by mail-ea0-f173.google.com with SMTP id g10so67408eak.18 for <stox@ietf.org>; Tue, 20 Aug 2013 01:43:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ysGxsyCLYCFz8Ft4K6N2IbRRsCZLo6f9TDeOQc+wcPU=; b=hy1u02ksXJN6fESHNqWxSECLZAmM1hhgHOZ6JSU2NTKIhqZJT8JZISD7ii3AxZp+cS mgPEJ+V/sErrkrq9F3XvJIYTh8U9xaoBxKxjf37Sg1RFhYuf43YCxJYGmYxGuu1yN/hf g2wwBnW2D0cpC7i/mmlfMTADKHVp0GdWz7hc2LjG4yzFaMais9g5zO8jE/KP2DI9xbth rJm2DBOGU7qA7MJucpPc2P3y1ne0SepEqAjz2Q/Vg59rWYHzq7buvY0XCAPr2f4owTdp E9gMszzSXXQseWwBbPSQav3M+vhTYlbzktKtkvXAKG87Uv6yUPIjrPsp0zPxXWHnyv5Y 6EhA==
X-Received: by 10.14.115.133 with SMTP id e5mr689835eeh.27.1376988233920; Tue, 20 Aug 2013 01:43:53 -0700 (PDT)
Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id d8sm739280eeh.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 01:43:53 -0700 (PDT)
Message-ID: <52132C43.3040102@gmail.com>
Date: Tue, 20 Aug 2013 10:43:47 +0200
From: Daniel-Constantin Mierla <miconda@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <520EDFBB.90503@stpeter.im> <521279E3.7030309@alum.mit.edu> <52127EC5.7060907@stpeter.im> <521291A9.1030503@gmail.com> <5212970D.6070608@stpeter.im>
In-Reply-To: <5212970D.6070608@stpeter.im>
Content-Type: multipart/alternative; boundary="------------000704020408060904070307"
Cc: stox@ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [Stox] core: response code mappings
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: miconda@gmail.com
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, 20 Aug 2013 08:43:56 -0000
On 8/20/13 12:07 AM, Peter Saint-Andre wrote: > On 8/19/13 3:44 PM, Daniel-Constantin Mierla wrote: >> On 8/19/13 10:23 PM, Peter Saint-Andre wrote: >>> On 8/19/13 2:02 PM, Paul Kyzivat wrote: >>>> On 8/16/13 10:28 PM, Peter Saint-Andre wrote: >>>>> The SIP Parameters Registry has a list of SIP response codes: >>>>> >>>>> http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-7 >>>>> >>>>> >>>>> >>>>> A number of those are not specified in RFC 3261. Thus the question >>>>> arises: for which codes do we need to define mappings? We could define >>>>> mappings for all of them, but I wonder if that's advisable. Some of the >>>>> additional codes are specified in RFCs that update RFC 3261 (e.g., code >>>>> 440 from RFC 5393), whereas other codes are specified in "non-core" >>>>> RFCs >>>>> that don't update RFC 3261 (e.g., code 470 from RFC 5360). Would it >>>>> perhaps make sense to map the "core" codes and not the "non-core" >>>>> codes? >>>> I know this is almost a non-answer, but... >>>> >>>> The codes that are defined in other RFCs are there to support features >>>> that are introduced in those RFCs. If there is a mapping of that feature >>>> to XMPP, then there should be a mapping of the code. >>> That makes sense. >>> >>>> If there is no mapping of the feature, then mapping the code is less >>>> important, but still perhaps useful in some cases. E.g., it could >>>> conceivably show up in a Reason code based on signaling that was never >>>> gatewayed to xmpp. But maybe a default mapping would be sufficient in >>>> those cases. >>> I suspect that the default mapping would be fine. >>> >>> And in general, there might be more art than science here. >>> >>> I have written some proposed text for this section, but it's fairly long >>> so my inclination is to submit a revised I-D and then folks can review >>> what I've written and post to the list with feedback. >> Looking at the latest draft, it seems to bring confusion on mapping from >> xmpp-to-sip on 400 code. I read this thread and kind of understood that >> any not-obvious-mapping similar-to-a-4xx case would be handled same as >> 400 in SIP, but typically the 400 response is given for a malformed sip >> requests (like broken grammar). > So your suggestion is that we avoid mapping XMPP error conditions to SIP > 400 unless the XMPP condition is caused by a malformed request? Yes, <bad-request/> qualifies for that. Otherwise, could create confusion for implementers of sip endpoints - from sip rfc: 21.4.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field". > >> After quick read, <conflict/> would map more suggestively to 403 >> Forbidden. > As I said, it's perhaps more art than science. But mapping <conflict/> > to 403 seems reasonable if we accept your suggestion about not mapping > to 400 unless we have a good reason to do so. > >> Maybe <policy-violation> and <undefined-condition/> could get >> other mappings as well. > Well, depending on the policy being violated, <policy-violation/> might > map to 413, 414, 513, or even 406/606. I would find more appropriate 500 than 400 for mapping, also because these situations are more server related. 500 is the most generic error code in sip from my point of view -- is used even for SIP message related situations, such as CSeq value in a request within a dialog is lower than previous received one. The section in the draft seems to be a global mapping, it is no difference between types of errors in xmpp -- there can be same error tag for streams and stanzas. For example <conflict/> for streams says: 4.9.3.3. conflict The server either (1) is closing the existing stream for this entity because a new stream has been initiated that conflicts with the existing stream, or (2) is refusing a new stream for this entity because allowing the new stream would conflict with an existing stream (e.g., because the server allows only a certain number of connections from the same IP address or allows only one server-to- server stream for a given domain pair as a way of helping to ensure in-order processing as described under Section 10.1). The second example above can be associated with 'No more channels' in a SIP media server/gateway -- 500 is used in this case (at least Asterisk did it :-) ). > > Given that <undefined-condition/> is something of a catch-all, it's not > clear to me what we'd map it to in a consistent way. That would probably > depend on the application-specific element contained in the error stanza. > Indeed, could be application/case-to-case specific mapping, but otherwise I think 500 should be the catch-all case in sip side. Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
- [Stox] core: response code mappings Peter Saint-Andre
- Re: [Stox] core: response code mappings Olle E. Johansson
- Re: [Stox] core: response code mappings Peter Saint-Andre
- Re: [Stox] core: response code mappings Saúl Ibarra Corretgé
- Re: [Stox] core: response code mappings Paul Kyzivat
- Re: [Stox] core: response code mappings Peter Saint-Andre
- Re: [Stox] core: response code mappings Daniel-Constantin Mierla
- Re: [Stox] core: response code mappings Peter Saint-Andre
- Re: [Stox] core: response code mappings Daniel-Constantin Mierla
- Re: [Stox] core: response code mappings Olle E. Johansson
- Re: [Stox] core: response code mappings Daniel-Constantin Mierla
- Re: [Stox] core: response code mappings Peter Saint-Andre
- Re: [Stox] core: response code mappings Daniel-Constantin Mierla