Re: [sipcore] Question on Require in responses

"Christer Holmberg" <christer.holmberg@ericsson.com> Sun, 03 May 2009 18:24 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119403A70E6 for <sipcore@core3.amsl.com>; Sun, 3 May 2009 11:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.827
X-Spam-Level:
X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEMmVz-MxWyF for <sipcore@core3.amsl.com>; Sun, 3 May 2009 11:24:37 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6C8A728C25C for <sipcore@ietf.org>; Sun, 3 May 2009 11:24:32 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b7aae000004a86-a3-49fde1b4c7d2
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CC.84.19078.4B1EDF94; Sun, 3 May 2009 20:25:56 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 May 2009 20:25:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 03 May 2009 20:25:05 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0B168210@esealmw113.eemea.ericsson.se>
In-Reply-To: <FBC06204-9091-4DF2-80C0-66D4CB35344E@softarmor.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] Question on Require in responses
Thread-Index: AcnJum/b2hRk+CDkRk2wxEFtMy23fQCYSVLw
References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF0CA32319@esealmw113.eemea.ericsson.se> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <CA9998CD4A020D418654FCDEF4E707DF0CA9565E@esealmw113.eemea.ericsson.se> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> <FBC06204-9091-4DF2-80C0-66D4CB35344E@softarmor.com>
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Dean Willis <dean.willis@softarmor.com>, Hans Erik van Elburg <ietf.hanserik@gmail.com>
X-OriginalArrivalTime: 03 May 2009 18:25:06.0666 (UTC) FILETIME=[7BE70CA0:01C9CC1C]
X-Brightmail-Tracker: AAAAAA==
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Question on Require in responses
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Sun, 03 May 2009 18:24:38 -0000

Hi, 

>>The option tag is a means of 1) discovering whether or not the far- 
>>end supports a specific extension and of 2) declaring the criticality 
>>of understanding that extension relative to satisfying a request and 
>>3) informing the UAC of what extensions were applied to the request 
>>in order to generate the response. This is purely a function of 
>>capability negotiation, not one of invocation.
>>
>>The extension itself (typically, an extension header field, although 
>>there are other types of extensions) is what causes the extension to 
>>be invoked.
>Depends a bit how you define extension, but I would argue that if I 
>require an extension to be supported on a transaction/dialog by the 
>UAS and the UAS accepts the request that this means that for this call 
>the UAS behaves as it should according to the extensions 
>specification.
>
>Saying that an extensions invokes itself is meaningless to me.
>
>A UAS may choose to only invoke the extension behaviour if it finds 
>that the extension is required. That comes close to saying that the 
>require:extension invokes the behaviour in the UAS, but it is not at 
>all the same.
>
>
>The Require doesn't control whether the UAS invokes the extension. The
UAS may invoke the extension on its own recognizance.  Most likely, it
chooses to do so based on 1) the presence of a Supported 
>indicator for the extension in a request as evidence that the UAC
supports the extension or the presence of an extension header in the
request that also indicates support in the UAC and 2) support for 
>that extension in the UAS. Other extensions may not require support in
the UAC, so may be enacted by this UAS purely on local policy.

100rel does not carry any extension headers in the request, nor does
RFC3262 say that the UAC must insert Supported in addition to Require.

But, RFC3262 DOES say:

"The UAS MUST send any non-100 provisional response reliably if the
initial request contained a Require header field with the option tag
100rel."

So, in my opinion Require:100rel means:

1. The UAC supports 100rel (no Suppored needed)
2. The UAS MUST use the extension (if sending non-100 provisional
responses).

I have nothing against saying that the definition of each option-tag
should specify how it is used, and what Require really means as far as
the UAS is concerned, but I don't think the generic definition of
Supported and Require that you are proposing fits all cases.

Regards,

Christer