Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

Christer Holmberg <> Mon, 25 October 2010 06:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACBAD3A6936 for <>; Sun, 24 Oct 2010 23:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.059
X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DX-5zCp5uIzz for <>; Sun, 24 Oct 2010 23:30:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 198EB3A694A for <>; Sun, 24 Oct 2010 23:30:39 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b28ae00000135b-bb-4cc5247753b3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1E.E3.04955.77425CC4; Mon, 25 Oct 2010 08:32:23 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Mon, 25 Oct 2010 08:32:23 +0200
From: Christer Holmberg <>
To: Dean Willis <>, Paul Kyzivat <>
Date: Mon, 25 Oct 2010 08:32:22 +0200
Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
Thread-Index: ActyKz9XBsvaszlvTdywAaHTG0Wc2gB4Zw+7
Message-ID: <>
References: <> <> <>, <> <>, <> <>, <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Oct 2010 06:30:55 -0000


>> [as chair]
>> To all sipcore participants:
>> Christer has been looking for a way to accomplish a particular
>> function that 3gpp wants. This proposal seems a plausible way to do
>> that. But it is of necessity defining a more general mechanism.
>> I'd really appreciate comments from others (including people in no
>> way involved with 3gpp) regarding this mechanism. For instance, do
>> you consider the semantics to be well defined? Do you see need for
>> more about security implications?
>I think it's important to note that we're talking about a way of
>advertising "option tags" -- the same option tags that theoretically
>get added to the "Supported" headers in lots of messages, and that the
>"Options" request was particularly designed to collect.
>Specifically, Christer has identified a use case where it is important
>for other nodes to understand the options supported by a proxy in the
>registration path, when that proxy is reasonably expected to be on the
>request path for future requests using that registration.
>If, OTOH, we're really talking "feature tags" that refer to vendor-
>tree specific feature identification -- well, then we're back to the
>old service-identifier problem.

Actually, the draft DOES talk about feature tags.

And, yes, we could start to talk about service-ids again, but that is a much wider topic, and is related to the usage of feature tags in general.

UAs are already allowed to indicate capabilities using feature tags, and the draft allows intermediaries to do the same.

But, of course, if one *requires* someone else to support something, option-tags should be used, but insertion of option-tags by intermediaries is outside the scope of the draft.