Re: [Sipping] Exploders anad ad-hoc lists
Paul Kyzivat <pkyzivat@cisco.com> Wed, 26 November 2003 18:14 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20306 for <sipping-archive@odin.ietf.org>; Wed, 26 Nov 2003 13:14:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4Av-0006XY-T4 for sipping-archive@odin.ietf.org; Wed, 26 Nov 2003 13:14:06 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQIE53h025134 for sipping-archive@odin.ietf.org; Wed, 26 Nov 2003 13:14:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4Av-0006XJ-Pi for sipping-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 13:14:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20298 for <sipping-web-archive@ietf.org>; Wed, 26 Nov 2003 13:13:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4At-0002Ig-00 for sipping-web-archive@ietf.org; Wed, 26 Nov 2003 13:14:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP4At-0002Id-00 for sipping-web-archive@ietf.org; Wed, 26 Nov 2003 13:14:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4Ar-0006W5-5M; Wed, 26 Nov 2003 13:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4AK-0006V9-4v for sipping@optimus.ietf.org; Wed, 26 Nov 2003 13:13:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20264 for <sipping@ietf.org>; Wed, 26 Nov 2003 13:13:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4AI-0002Hm-00 for sipping@ietf.org; Wed, 26 Nov 2003 13:13:26 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AP4AH-0002HF-00 for sipping@ietf.org; Wed, 26 Nov 2003 13:13:25 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 Nov 2003 10:14:28 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAQICrAt028976; Wed, 26 Nov 2003 10:12:53 -0800 (PST)
Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEG93240; Wed, 26 Nov 2003 13:12:51 -0500 (EST)
Message-ID: <3FC4ED22.3040604@cisco.com>
Date: Wed, 26 Nov 2003 13:12:50 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: sipping <sipping@ietf.org>
Subject: Re: [Sipping] Exploders anad ad-hoc lists
References: <3FC209FA.6030004@ericsson.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Gonzalo, I like the concept, but I am troubled by passing the reference to the list as a sip/sips url parameter, for the following reasons: - how does it get there? In your examples, you have the parameter in the request uri, but not in the To uri. Normally a UA would determine the destination, and put it in both To and request URIs. This implies some extra special casing. - How does it stay there. If the address in the request uri is of an AoR, a proxy may replace it with a corresponding registered contact. If so, the reference to the list will be lost. - logically the request is being addressed to the service, and the list is a parameter to the service and the particular method the service is being asked to perform. Embedding the list in the address of the service seems inappropriate. I think there needs to be a better place to put the reference to the list. A new header would seem to be the logical answer. Regarding draft-camarillo-sipping-exploders-solution-00: You say the requester should subscribe to a url returned in the response to learn the outcome of the exploded requests. But that opens a time window when some status may lost. Do you have any thoughts on how to close that? (E.g. the first response to a subscription gives all the cumulative history of what has happened.) There are a couple of references to an Explode-To header, but no explanation and no examples. It seems redundant to the list, unless it is intended as a way to convey the reference to the list. Paul Gonzalo Camarillo wrote: > Folks, > > we have just submitted three drafts about exploders and ad-hoc lists. > > We have added more requirements to the following draft. The new > requirements were mainly discussed in the SIMPLE mailing list. > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-exploders-01.txt > > > The following draft describes how to carry lists of URIs in SIP > requests. It is not a finished draft. It is intended to trigger > discussions on this topic to see whether this is a step the right > direction. > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-uri-list-00.txt > > > The following draft defines a new method called EXPLODE. EXPLODE does > the same as REFER. That is, it tells a UA to send a request somewhere. > The differences are that EXPLODE accepts more than one destination > (REFER carries a single Refer-To header field) and that EXPLODE does not > establish implicit subscriptions of any type. This draft is also > intended to trigger discussions within the WG. > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-explode-method-00.txt > > > Let's try to keep discussions about this topic in the SIPPING mailing > list. I will forward this mail to the SIMPLE mailing list to let them know. > > Comments are welcome, > > Gonzalo > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Exploders anad ad-hoc lists Gonzalo Camarillo
- RE: [Sipping] Exploders anad ad-hoc lists Orit Levin
- RE: [Sipping] Exploders anad ad-hoc lists Orit Levin
- RE: [Sipping] Exploders anad ad-hoc lists Markus.Isomaki
- RE: [Sipping] Exploders anad ad-hoc lists Orit Levin
- Re: [Sipping] Exploders anad ad-hoc lists Paul Kyzivat
- Re: [Sipping] Exploders anad ad-hoc lists Gonzalo Camarillo
- Re: [Sipping] Exploders anad ad-hoc lists Gonzalo Camarillo
- Re: [Sipping] Exploders anad ad-hoc lists Paul Kyzivat
- RE: [Sipping] Exploders anad ad-hoc lists Orit Levin