IETF Logo Mail Archive

Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 07 July 2011 21:57 UTC

Return-Path: <christer.holmberg@ericsson.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 7D03921F8901 for <sipcore@ietfa.amsl.com>; Thu, 7 Jul 2011 14:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.435
X-Spam-Level:
X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvKlcA-cHs+h for <sipcore@ietfa.amsl.com>; Thu, 7 Jul 2011 14:57:35 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4821F8902 for <sipcore@ietf.org>; Thu, 7 Jul 2011 14:57:34 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-70-4e162bcd23f8
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.F2.20773.DCB261E4; Thu, 7 Jul 2011 23:57:33 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 7 Jul 2011 23:57:33 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "'Worley, Dale R (Dale)'" <dworley@avaya.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 07 Jul 2011 23:57:33 +0200
Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt
Thread-Index: Acw8xtXNBa4qiH7aTROq7p6uxNaD7AADja+ZAAbe7yA=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB61820CC@ESESSCMS0356.eemea.ericsson.se>
References: <20110707165628.18445.51358.idtracker@ietfa.amsl.com> <CD5674C3CD99574EBA7432465FC13C1B222B1F574B@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F574B@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Thu, 07 Jul 2011 21:57:35 -0000

Hi Dale,

Your proposed change looks good, but a couple of minor suggestions:

1. I would suggest to remove the "(that support this mechanism)" part.

2. I would suggest to say "to other SIP entities", rather than "to ALL other SIP entities", as we also need to consider the directionality.

Regards,

Christer 


-----Original Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale)
Sent: 7. heinäkuuta 2011 21:49
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt

I see in this draft:

   REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/
   capability, make any assumptions that SIP entities in the signalling
   path that receive the indicator will support, or understand the
   meaning of, the feature/capability.

I think the phrasing of this can be improved.  More importantly, it doesn't state that the proxy (that is doing the indicating) can do so even if intermediate elements don't support the proxy-feature mechanism at all.  This might be a more comprehensive way to express it:

   REQ-4: A SIP proxy MUST be able to indicate support of a
   feature/capability to all other SIP entities in the signaling path
   (that support this mechanism), even if some SIP entities in the
   signaling path (possibly including the UAC and/or UAS) do not
   support, or understand the meaning of, the feature/capability, or
   even this mechanism as a whole.

Dale
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

v2.23.0 | Report a Bug | By Email