IETF Logo Mail Archive

Re: [sipcore] Artart last call review of draft-ietf-sipcore-multiple-reasons-01

Robert Sparks <rjsparks@nostrum.com> Tue, 04 October 2022 15:34 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B691C14F744; Tue, 4 Oct 2022 08:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.684
X-Spam-Level:
X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJTXAruQmj36; Tue, 4 Oct 2022 08:34:31 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63042C14F736; Tue, 4 Oct 2022 08:34:31 -0700 (PDT)
Received: from smtpclient.apple (mobile-107-107-187-94.mycingular.net [107.107.187.94]) (authenticated bits=0) by nostrum.com (8.17.1/8.17.1) with ESMTPSA id 294FYRUa019109 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Oct 2022 10:34:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1664897670; bh=MmRV7OBuMZLDYc9cRUWaCk+YPs92Js/C7yZvGyoLPWc=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=AaVH7lFGwlvj0ycA9irLNLquEquUFdg45V2CqpPpMSGjK2HP35H8u0hTEFyFGiaL4 Jidib/zct3PMjBXD9YUZw+UggLXRi13jkVeMoEBGx1oe3HO0sMBg3NF+LDqQ0b2pUX em2wVGtYS/Reg59rbnuxFiz5e5oq/5VN1Ef2iK1o=
X-Authentication-Warning: raven.nostrum.com: Host mobile-107-107-187-94.mycingular.net [107.107.187.94] claimed to be smtpclient.apple
Content-Type: multipart/alternative; boundary="Apple-Mail-D2D6DD4F-CD20-4BF8-A049-3959DECC7D8A"
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 04 Oct 2022 10:34:22 -0500
Message-Id: <A2E3F4DE-A425-4689-A376-A309876D4D5C@nostrum.com>
References: <CO3PR08MB7896B65B175AE9DE6F5ED5B8895A9@CO3PR08MB7896.namprd08.prod.outlook.com>
Cc: Todd Herr <todd.herr@valimail.com>, art@ietf.org, draft-ietf-sipcore-multiple-reasons.all@ietf.org, last-call@ietf.org, sipcore@ietf.org
In-Reply-To: <CO3PR08MB7896B65B175AE9DE6F5ED5B8895A9@CO3PR08MB7896.namprd08.prod.outlook.com>
To: "Avasarala, Ranjit (Nokia - US/Naperville)" <ranjit.avasarala@nokia.com>
X-Mailer: iPhone Mail (19G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/5aXWQ7CPkLbmUGqDdpatgx-pgFI>
Subject: Re: [sipcore] Artart last call review of draft-ietf-sipcore-multiple-reasons-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2022 15:34:35 -0000

Both sip and q.850 can already coexist in a sip message as per 3326. But only one header field value for each can be present. This document does not change that. What it does is allow new protocols that explicitly define more than one heder field value to appear to have that. It does not define such a new protocol, so there is nothing to use (except something fictional) in an example. A fictional example will introduce more confusion than clarity. The example you are looking for is in https://datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/

RjS

Sent from my iPhone

> On Oct 4, 2022, at 10:23 AM, Avasarala, Ranjit (Nokia - US/Naperville) <ranjit.avasarala@nokia.com> wrote:
> 
> Hi Robert
> 
> RFC 3326 already defines SIP / Q.850 as a possible protocol values and this draft is proposing that both can co-exist in the same response.  So some example would help better understand on how they will be added
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: Robert Sparks <rjsparks@nostrum.com> 
> Sent: Tuesday, October 4, 2022 10:19 AM
> To: Avasarala, Ranjit (Nokia - US/Naperville) <ranjit.avasarala@nokia.com>
> Cc: Todd Herr <todd.herr@valimail.com>; art@ietf.org; draft-ietf-sipcore-multiple-reasons.all@ietf.org; last-call@ietf.org; sipcore@ietf.org
> Subject: Re: [sipcore] Artart last call review of draft-ietf-sipcore-multiple-reasons-01
> 
> That will happen in a document that defines such a protocol, such as the one referenced in STIR. This document should remain minimal. 
> 
> RjS
> 
> Sent from my iPhone
> 
>> On Oct 4, 2022, at 10:02 AM, Avasarala, Ranjit (Nokia - US/Naperville) <ranjit.avasarala@nokia.com> wrote:
>> 
>> Hi Todd
>> 
>> I agree - the draft could provide few examples of where we would use SIP Reason header with multiple protocol values in the same SIP response 
>> 
>> Regards
>> Ranjit
>> 
>> -----Original Message-----
>> From: sipcore <sipcore-bounces@ietf.org> On Behalf Of Todd Herr via Datatracker
>> Sent: Tuesday, October 4, 2022 9:51 AM
>> To: art@ietf.org
>> Cc: draft-ietf-sipcore-multiple-reasons.all@ietf.org; last-call@ietf.org; sipcore@ietf.org
>> Subject: [sipcore] Artart last call review of draft-ietf-sipcore-multiple-reasons-01
>> 
>> Reviewer: Todd Herr
>> Review result: Ready with Nits
>> 
>> As someone unfamiliar with SIP Reason Header Fields, I'm of the opinion that perhaps an example of a header field with multiple values might be instructive as a contrast to the examples shown in RFC 3326, but I do not feel strongly enough about this to hold up the document.
>> 
>> 
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>

v2.23.0 | Report a Bug | By Email