From simple-admin@ietf.org Fri Jan 2 17:26:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27060 for ; Fri, 2 Jan 2004 17:26:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcXkM-0000lC-00 for simple-archive@ietf.org; Fri, 02 Jan 2004 17:26:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcXic-0000ZN-00 for simple-archive@ietf.org; Fri, 02 Jan 2004 17:24:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcXfa-0000JU-00; Fri, 02 Jan 2004 17:21:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcXfB-0000mw-Uc; Fri, 02 Jan 2004 17:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcXeL-0000mF-4W for simple@optimus.ietf.org; Fri, 02 Jan 2004 17:20:09 -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 RAA26735 for ; Fri, 2 Jan 2004 17:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcXe8-0000Gh-00 for simple@ietf.org; Fri, 02 Jan 2004 17:19:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcXa4-000084-00 for simple@ietf.org; Fri, 02 Jan 2004 17:15:44 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AcXV4-0007fJ-00 for simple@ietf.org; Fri, 02 Jan 2004 17:10:34 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i02M9ZOf023660; Fri, 2 Jan 2004 16:09:35 -0600 (CST) Message-ID: <3FF5EC1F.33E38A71@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727C@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Jan 2004 16:09:35 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Mikko, I guess re-usability would be a good-enough motivation to split the dopcument. Thanks, Alex. mikko.lonnfors@nokia.com wrote: > Hi, > > Main motivation to slip the current document is to improve reusability > of the MIME type ('application/pidf-partial+xml'). There are other > places than presence event package where this content format may be > used. If there wouldn't be any other usages for this then keeping > document in its current form would make sense. But if somebody writes a > new draft which utilized 'application/pidf-partial+xml' MIME type then > it is much more convenient if there is a standalone definition for that. > > - Mikko > > -----Original Message----- > From: ext Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Wednesday, December 24, 2003 12:00 AM > To: Lonnfors Mikko (NRC/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] splitting of partial notify draft > > Hi, > I think I like the document in its current form. Is there a technical or > ligistic reason for > splitting it? The current form is compact and keeping everything in one > place aids > readability. > Cheers, > Alex. > > mikko.lonnfors@nokia.com wrote: > Hi folks, > Current partial notify draft (draft-ietf-simple-partial-notify) contains > new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence > event package is used with that particular MIME type. One think which > could be done is to slip the current draft into two. One part would > contain MIME type definition and other would cover how that particular > MIME type is used with presence event package. This way it would > probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > So, I would like to know how people feel about this. Please vote for: > 1) > Split the document > 2) > Keep it as it is > - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 2 17:26:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27095 for ; Fri, 2 Jan 2004 17:26:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcXkQ-00012G-7u for simple-archive@odin.ietf.org; Fri, 02 Jan 2004 17:26:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02MQQRS003980 for simple-archive@odin.ietf.org; Fri, 2 Jan 2004 17:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcXkQ-000127-0l for simple-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 17:26:26 -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 RAA27074 for ; Fri, 2 Jan 2004 17:26:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcXkN-0000lH-00 for simple-web-archive@ietf.org; Fri, 02 Jan 2004 17:26:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcXid-0000ZU-00 for simple-web-archive@ietf.org; Fri, 02 Jan 2004 17:24:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AcXfa-0000JU-00; Fri, 02 Jan 2004 17:21:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcXfB-0000mw-Uc; Fri, 02 Jan 2004 17:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcXeL-0000mF-4W for simple@optimus.ietf.org; Fri, 02 Jan 2004 17:20:09 -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 RAA26735 for ; Fri, 2 Jan 2004 17:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcXe8-0000Gh-00 for simple@ietf.org; Fri, 02 Jan 2004 17:19:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcXa4-000084-00 for simple@ietf.org; Fri, 02 Jan 2004 17:15:44 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AcXV4-0007fJ-00 for simple@ietf.org; Fri, 02 Jan 2004 17:10:34 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i02M9ZOf023660; Fri, 2 Jan 2004 16:09:35 -0600 (CST) Message-ID: <3FF5EC1F.33E38A71@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727C@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 02 Jan 2004 16:09:35 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mikko, I guess re-usability would be a good-enough motivation to split the dopcument. Thanks, Alex. mikko.lonnfors@nokia.com wrote: > Hi, > > Main motivation to slip the current document is to improve reusability > of the MIME type ('application/pidf-partial+xml'). There are other > places than presence event package where this content format may be > used. If there wouldn't be any other usages for this then keeping > document in its current form would make sense. But if somebody writes a > new draft which utilized 'application/pidf-partial+xml' MIME type then > it is much more convenient if there is a standalone definition for that. > > - Mikko > > -----Original Message----- > From: ext Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Wednesday, December 24, 2003 12:00 AM > To: Lonnfors Mikko (NRC/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] splitting of partial notify draft > > Hi, > I think I like the document in its current form. Is there a technical or > ligistic reason for > splitting it? The current form is compact and keeping everything in one > place aids > readability. > Cheers, > Alex. > > mikko.lonnfors@nokia.com wrote: > Hi folks, > Current partial notify draft (draft-ietf-simple-partial-notify) contains > new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence > event package is used with that particular MIME type. One think which > could be done is to slip the current draft into two. One part would > contain MIME type definition and other would cover how that particular > MIME type is used with presence event package. This way it would > probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > So, I would like to know how people feel about this. Please vote for: > 1) > Split the document > 2) > Keep it as it is > - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Jan 3 20:10:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19358 for ; Sat, 3 Jan 2004 20:10:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcwmM-0003YO-00 for simple-archive@ietf.org; Sat, 03 Jan 2004 20:10:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acwiw-0003Tt-00 for simple-archive@ietf.org; Sat, 03 Jan 2004 20:06:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Acwgv-0003PB-00; Sat, 03 Jan 2004 20:04:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcwgU-00066b-8j; Sat, 03 Jan 2004 20:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acwfa-00065J-Bd for simple@optimus.ietf.org; Sat, 03 Jan 2004 20:03:10 -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 UAA19294 for ; Sat, 3 Jan 2004 20:03:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcwfP-0003ON-00 for simple@ietf.org; Sat, 03 Jan 2004 20:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcwbG-0003KM-00 for simple@ietf.org; Sat, 03 Jan 2004 19:58:39 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Acwas-0003Hb-00 for simple@ietf.org; Sat, 03 Jan 2004 19:58:14 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i040vdL01596 for ; Sat, 3 Jan 2004 18:57:40 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 4 Jan 2004 00:57:38 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA7817E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg , "Drage, Keith (Keith)" Cc: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Simple] RE: Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Jan 2004 00:57:35 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I would maybe suggest a small amount of additional informative text to presence-10 in auth48 just to add clarity. I accept there is no problem with the normative material, but as you say, it is subtle. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 31 December 2003 18:48 > To: Drage, Keith (Keith) > Cc: 'simple@ietf.org' > Subject: Re: Question on draft-ietf-simple-presence-10 > > > > > > There is overlap in the callee capabilities mechanism with the > > Allow, Accept, Accept-Language, and Allow-Events [9] header fields, > > which can also be used in target refresh requests. Specifically, > > the Allow header field and "sip.methods" feature tag indicate the > > same information. The Accept header field and the "type" feature > > tag indicate the same information. The Accept-Language header field > > and the "language" feature tag indicate the same information. The > > Allow-Events header field and the "sip.events" feature tag indicate > > the same information. It is possible that other header fields and > > feature tags defined in the future may also overlap. When there > > exists a feature tag that describes a capability that can also be > > represented with a SIP header field, a UA MUST use the header field > > to describe the capability. A UA receiving a message that contains > > both the header field and the feature tag MUST use the header > > field, and not the feature tag. > > > > I am not convinced this is consistent with clause 6.11.2 of the > > presence-10 specification which states: > > > > A PA MAY choose to migrate subscriptions at any time, through > > configuration, or through dynamic means. The REGISTER request > > provides one dynamic means for a presence server to discover that > > the function can migrate to a PUA. Specifically, if a PUA wishes to > > indicate support for the PA function, it SHOULD use the caller > > preferences specification [9] to indicate that it supports the > > SUBSCRIBE request method and the presence event package. The > > combination of these two define a PA. > > > > as in some cases it is provisions of RFC 3261 and RFC 3265 through > > the use of the Allow and Allow events header that will define a PA. > > Maybe the text should be revised to reflect the precedence of those > > headers. > > Actually, I dont think there is a conflict, but the reason is subtle. > If you look at the first sentence in the text from callee caps above, > you will note that it is explicitly talking about *target refresh > requests*. The presence spec is talking about registrations. The > difference is that registrations can contain information about > multiple UAs, and therefore the capability information needs to be > contact-specific; thus, it is appropriate to use the callee caps > parameters. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Jan 3 20:11:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19420 for ; Sat, 3 Jan 2004 20:11:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acwmo-0006pA-BR for simple-archive@odin.ietf.org; Sat, 03 Jan 2004 20:10:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i041AYS2026228 for simple-archive@odin.ietf.org; Sat, 3 Jan 2004 20:10:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acwmo-0006ox-7e for simple-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 20:10:34 -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 UAA19379 for ; Sat, 3 Jan 2004 20:10:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Acwmh-0003YT-00 for simple-web-archive@ietf.org; Sat, 03 Jan 2004 20:10:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Acwix-0003U2-00 for simple-web-archive@ietf.org; Sat, 03 Jan 2004 20:06:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Acwgv-0003PB-00; Sat, 03 Jan 2004 20:04:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcwgU-00066b-8j; Sat, 03 Jan 2004 20:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Acwfa-00065J-Bd for simple@optimus.ietf.org; Sat, 03 Jan 2004 20:03:10 -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 UAA19294 for ; Sat, 3 Jan 2004 20:03:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcwfP-0003ON-00 for simple@ietf.org; Sat, 03 Jan 2004 20:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcwbG-0003KM-00 for simple@ietf.org; Sat, 03 Jan 2004 19:58:39 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Acwas-0003Hb-00 for simple@ietf.org; Sat, 03 Jan 2004 19:58:14 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i040vdL01596 for ; Sat, 3 Jan 2004 18:57:40 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 4 Jan 2004 00:57:38 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00AA7817E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg , "Drage, Keith (Keith)" Cc: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Simple] RE: Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Jan 2004 00:57:35 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I would maybe suggest a small amount of additional informative text to presence-10 in auth48 just to add clarity. I accept there is no problem with the normative material, but as you say, it is subtle. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 31 December 2003 18:48 > To: Drage, Keith (Keith) > Cc: 'simple@ietf.org' > Subject: Re: Question on draft-ietf-simple-presence-10 > > > > > > There is overlap in the callee capabilities mechanism with the > > Allow, Accept, Accept-Language, and Allow-Events [9] header fields, > > which can also be used in target refresh requests. Specifically, > > the Allow header field and "sip.methods" feature tag indicate the > > same information. The Accept header field and the "type" feature > > tag indicate the same information. The Accept-Language header field > > and the "language" feature tag indicate the same information. The > > Allow-Events header field and the "sip.events" feature tag indicate > > the same information. It is possible that other header fields and > > feature tags defined in the future may also overlap. When there > > exists a feature tag that describes a capability that can also be > > represented with a SIP header field, a UA MUST use the header field > > to describe the capability. A UA receiving a message that contains > > both the header field and the feature tag MUST use the header > > field, and not the feature tag. > > > > I am not convinced this is consistent with clause 6.11.2 of the > > presence-10 specification which states: > > > > A PA MAY choose to migrate subscriptions at any time, through > > configuration, or through dynamic means. The REGISTER request > > provides one dynamic means for a presence server to discover that > > the function can migrate to a PUA. Specifically, if a PUA wishes to > > indicate support for the PA function, it SHOULD use the caller > > preferences specification [9] to indicate that it supports the > > SUBSCRIBE request method and the presence event package. The > > combination of these two define a PA. > > > > as in some cases it is provisions of RFC 3261 and RFC 3265 through > > the use of the Allow and Allow events header that will define a PA. > > Maybe the text should be revised to reflect the precedence of those > > headers. > > Actually, I dont think there is a conflict, but the reason is subtle. > If you look at the first sentence in the text from callee caps above, > you will note that it is explicitly talking about *target refresh > requests*. The presence spec is talking about registrations. The > difference is that registrations can contain information about > multiple UAs, and therefore the capability information needs to be > contact-specific; thus, it is appropriate to use the callee caps > parameters. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 5 06:51:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14138 for ; Mon, 5 Jan 2004 06:51:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdTGK-00058D-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 06:51:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdTER-00053n-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 06:49:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdTDV-00050N-00; Mon, 05 Jan 2004 06:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTDG-0007zB-8g; Mon, 05 Jan 2004 06:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTCV-0007xf-DN for simple@optimus.ietf.org; Mon, 05 Jan 2004 06:47:15 -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 GAA14041 for ; Mon, 5 Jan 2004 06:47:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdTCR-0004xt-00 for simple@ietf.org; Mon, 05 Jan 2004 06:47:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdTAc-0004tJ-00 for simple@ietf.org; Mon, 05 Jan 2004 06:45:18 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly02a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AdT94-0004n6-00 for simple@ietf.org; Mon, 05 Jan 2004 06:43:42 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly02a.srv.mailcontrol.com (MailControl) with SMTP id i05Bh8Yr017323; Mon, 5 Jan 2004 11:43:08 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Mon, 5 Jan 2004 11:43:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] splitting of partial notify draft Message-ID: <45730E094814E44488F789C1CDED27AE01E22F57@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] splitting of partial notify draft Thread-Index: AcPRfsAMZpuejyyVQL6uTVjqKP2XugCAkZmQ From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Jan 2004 11:43:08 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This sounds like a sensible suggestion to me. Chris. >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com] >Sent: 02 January 2004 22:10 >To: mikko.lonnfors@nokia.com >Cc: simple@ietf.org >Subject: Re: [Simple] splitting of partial notify draft > >Hi Mikko, > >I guess re-usability would be a good-enough motivation to split the >dopcument. > >Thanks, >Alex. > > >mikko.lonnfors@nokia.com wrote: > >> Hi, >> >> Main motivation to slip the current document is to improve reusability >> of the MIME type ('application/pidf-partial+xml'). There are other >> places than presence event package where this content format may be >> used. If there wouldn't be any other usages for this then keeping >> document in its current form would make sense. But if somebody writes a >> new draft which utilized 'application/pidf-partial+xml' MIME type then >> it is much more convenient if there is a standalone definition for that. >> >> - Mikko >> >> -----Original Message----- >> From: ext Alex Audu [mailto:alex.audu@alcatel.com] >> Sent: Wednesday, December 24, 2003 12:00 AM >> To: Lonnfors Mikko (NRC/Helsinki) >> Cc: simple@ietf.org >> Subject: Re: [Simple] splitting of partial notify draft >> >> Hi, >> I think I like the document in its current form. Is there a technical or >> ligistic reason for >> splitting it? The current form is compact and keeping everything in one >> place aids >> readability. >> Cheers, >> Alex. >> >> mikko.lonnfors@nokia.com wrote: >> Hi folks, >> Current partial notify draft (draft-ietf-simple-partial-notify) contains >> new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence >> event package is used with that particular MIME type. One think which >> could be done is to slip the current draft into two. One part would >> contain MIME type definition and other would cover how that particular >> MIME type is used with presence event package. This way it would >> probably be much easier to reuse partial PIDF MIME type. Similar >> approach has been taken in winfo. >> So, I would like to know how people feel about this. Please vote for: >> 1) >> Split the document >> 2) >> Keep it as it is >> - Mikko > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 5 06:51:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14170 for ; Mon, 5 Jan 2004 06:51:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTGP-0008KV-Io for simple-archive@odin.ietf.org; Mon, 05 Jan 2004 06:51:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05BpHVf032015 for simple-archive@odin.ietf.org; Mon, 5 Jan 2004 06:51:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTGP-0008KI-Fd for simple-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 06:51:17 -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 GAA14144 for ; Mon, 5 Jan 2004 06:51:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdTGL-00058L-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 06:51:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdTES-00053u-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 06:49:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdTDV-00050N-00; Mon, 05 Jan 2004 06:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTDG-0007zB-8g; Mon, 05 Jan 2004 06:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdTCV-0007xf-DN for simple@optimus.ietf.org; Mon, 05 Jan 2004 06:47:15 -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 GAA14041 for ; Mon, 5 Jan 2004 06:47:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdTCR-0004xt-00 for simple@ietf.org; Mon, 05 Jan 2004 06:47:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdTAc-0004tJ-00 for simple@ietf.org; Mon, 05 Jan 2004 06:45:18 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly02a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AdT94-0004n6-00 for simple@ietf.org; Mon, 05 Jan 2004 06:43:42 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly02a.srv.mailcontrol.com (MailControl) with SMTP id i05Bh8Yr017323; Mon, 5 Jan 2004 11:43:08 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Mon, 5 Jan 2004 11:43:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] splitting of partial notify draft Message-ID: <45730E094814E44488F789C1CDED27AE01E22F57@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] splitting of partial notify draft Thread-Index: AcPRfsAMZpuejyyVQL6uTVjqKP2XugCAkZmQ From: "Chris Boulton" To: , Cc: X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Jan 2004 11:43:08 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This sounds like a sensible suggestion to me. Chris. >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com] >Sent: 02 January 2004 22:10 >To: mikko.lonnfors@nokia.com >Cc: simple@ietf.org >Subject: Re: [Simple] splitting of partial notify draft > >Hi Mikko, > >I guess re-usability would be a good-enough motivation to split the >dopcument. > >Thanks, >Alex. > > >mikko.lonnfors@nokia.com wrote: > >> Hi, >> >> Main motivation to slip the current document is to improve reusability >> of the MIME type ('application/pidf-partial+xml'). There are other >> places than presence event package where this content format may be >> used. If there wouldn't be any other usages for this then keeping >> document in its current form would make sense. But if somebody writes a >> new draft which utilized 'application/pidf-partial+xml' MIME type then >> it is much more convenient if there is a standalone definition for that. >> >> - Mikko >> >> -----Original Message----- >> From: ext Alex Audu [mailto:alex.audu@alcatel.com] >> Sent: Wednesday, December 24, 2003 12:00 AM >> To: Lonnfors Mikko (NRC/Helsinki) >> Cc: simple@ietf.org >> Subject: Re: [Simple] splitting of partial notify draft >> >> Hi, >> I think I like the document in its current form. Is there a technical or >> ligistic reason for >> splitting it? The current form is compact and keeping everything in one >> place aids >> readability. >> Cheers, >> Alex. >> >> mikko.lonnfors@nokia.com wrote: >> Hi folks, >> Current partial notify draft (draft-ietf-simple-partial-notify) contains >> new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence >> event package is used with that particular MIME type. One think which >> could be done is to slip the current draft into two. One part would >> contain MIME type definition and other would cover how that particular >> MIME type is used with presence event package. This way it would >> probably be much easier to reuse partial PIDF MIME type. Similar >> approach has been taken in winfo. >> So, I would like to know how people feel about this. Please vote for: >> 1) >> Split the document >> 2) >> Keep it as it is >> - Mikko > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 5 12:41:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26087 for ; Mon, 5 Jan 2004 12:41:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdYjE-00056y-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 12:41:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdYhN-00052h-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 12:39:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdYgD-0004yV-00; Mon, 05 Jan 2004 12:38:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYfx-0005IK-IW; Mon, 05 Jan 2004 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYfM-00057H-LX for simple@optimus.ietf.org; Mon, 05 Jan 2004 12:37:24 -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 MAA25953 for ; Mon, 5 Jan 2004 12:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdYfK-0004wo-00 for simple@ietf.org; Mon, 05 Jan 2004 12:37:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdYdT-0004th-00 for simple@ietf.org; Mon, 05 Jan 2004 12:35:28 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AdYcR-0004px-00 for simple@ietf.org; Mon, 05 Jan 2004 12:34:23 -0500 Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i05HXumR009455; Mon, 5 Jan 2004 12:33:57 -0500 (EST) Message-ID: <3FF99FFF.4090903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'simple@ietf.org'" References: <475FF955A05DD411980D00508B6D5FB00AA7817E@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00AA7817E@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 12:33:51 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit OK, will do. -Jonathan R. Drage, Keith (Keith) wrote: > I would maybe suggest a small amount of additional informative text to presence-10 in auth48 just to add clarity. I accept there is no problem with the normative material, but as you say, it is subtle. > > regards > > Keith > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 31 December 2003 18:48 >>To: Drage, Keith (Keith) >>Cc: 'simple@ietf.org' >>Subject: Re: Question on draft-ietf-simple-presence-10 >> >> > > > >>>There is overlap in the callee capabilities mechanism with the >>>Allow, Accept, Accept-Language, and Allow-Events [9] header fields, >>>which can also be used in target refresh requests. Specifically, >>>the Allow header field and "sip.methods" feature tag indicate the >>>same information. The Accept header field and the "type" feature >>>tag indicate the same information. The Accept-Language header field >>>and the "language" feature tag indicate the same information. The >>>Allow-Events header field and the "sip.events" feature tag indicate >>> the same information. It is possible that other header fields and >>>feature tags defined in the future may also overlap. When there >>>exists a feature tag that describes a capability that can also be >>>represented with a SIP header field, a UA MUST use the header field >>> to describe the capability. A UA receiving a message that contains >>> both the header field and the feature tag MUST use the header >>>field, and not the feature tag. >>> >>>I am not convinced this is consistent with clause 6.11.2 of the >>>presence-10 specification which states: >>> >>>A PA MAY choose to migrate subscriptions at any time, through >>>configuration, or through dynamic means. The REGISTER request >>>provides one dynamic means for a presence server to discover that >>>the function can migrate to a PUA. Specifically, if a PUA wishes to >>> indicate support for the PA function, it SHOULD use the caller >>>preferences specification [9] to indicate that it supports the >>>SUBSCRIBE request method and the presence event package. The >>>combination of these two define a PA. >>> >>>as in some cases it is provisions of RFC 3261 and RFC 3265 through >>>the use of the Allow and Allow events header that will define a PA. >>>Maybe the text should be revised to reflect the precedence of those >>>headers. >> >>Actually, I dont think there is a conflict, but the reason is subtle. >>If you look at the first sentence in the text from callee caps above, >>you will note that it is explicitly talking about *target refresh >>requests*. The presence spec is talking about registrations. The >>difference is that registrations can contain information about >>multiple UAs, and therefore the capability information needs to be >>contact-specific; thus, it is appropriate to use the callee caps >>parameters. >> >>-Jonathan R. >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 5 12:41:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26135 for ; Mon, 5 Jan 2004 12:41:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYjH-0005TV-OQ for simple-archive@odin.ietf.org; Mon, 05 Jan 2004 12:41:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05HfRHT021041 for simple-archive@odin.ietf.org; Mon, 5 Jan 2004 12:41:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYjH-0005TI-IX for simple-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 12:41:27 -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 MAA26101 for ; Mon, 5 Jan 2004 12:41:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdYjF-000573-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 12:41:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdYhO-00052o-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 12:39:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdYgD-0004yV-00; Mon, 05 Jan 2004 12:38:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYfx-0005IK-IW; Mon, 05 Jan 2004 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdYfM-00057H-LX for simple@optimus.ietf.org; Mon, 05 Jan 2004 12:37:24 -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 MAA25953 for ; Mon, 5 Jan 2004 12:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdYfK-0004wo-00 for simple@ietf.org; Mon, 05 Jan 2004 12:37:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdYdT-0004th-00 for simple@ietf.org; Mon, 05 Jan 2004 12:35:28 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AdYcR-0004px-00 for simple@ietf.org; Mon, 05 Jan 2004 12:34:23 -0500 Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i05HXumR009455; Mon, 5 Jan 2004 12:33:57 -0500 (EST) Message-ID: <3FF99FFF.4090903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'simple@ietf.org'" References: <475FF955A05DD411980D00508B6D5FB00AA7817E@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00AA7817E@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 12:33:51 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK, will do. -Jonathan R. Drage, Keith (Keith) wrote: > I would maybe suggest a small amount of additional informative text to presence-10 in auth48 just to add clarity. I accept there is no problem with the normative material, but as you say, it is subtle. > > regards > > Keith > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 31 December 2003 18:48 >>To: Drage, Keith (Keith) >>Cc: 'simple@ietf.org' >>Subject: Re: Question on draft-ietf-simple-presence-10 >> >> > > > >>>There is overlap in the callee capabilities mechanism with the >>>Allow, Accept, Accept-Language, and Allow-Events [9] header fields, >>>which can also be used in target refresh requests. Specifically, >>>the Allow header field and "sip.methods" feature tag indicate the >>>same information. The Accept header field and the "type" feature >>>tag indicate the same information. The Accept-Language header field >>>and the "language" feature tag indicate the same information. The >>>Allow-Events header field and the "sip.events" feature tag indicate >>> the same information. It is possible that other header fields and >>>feature tags defined in the future may also overlap. When there >>>exists a feature tag that describes a capability that can also be >>>represented with a SIP header field, a UA MUST use the header field >>> to describe the capability. A UA receiving a message that contains >>> both the header field and the feature tag MUST use the header >>>field, and not the feature tag. >>> >>>I am not convinced this is consistent with clause 6.11.2 of the >>>presence-10 specification which states: >>> >>>A PA MAY choose to migrate subscriptions at any time, through >>>configuration, or through dynamic means. The REGISTER request >>>provides one dynamic means for a presence server to discover that >>>the function can migrate to a PUA. Specifically, if a PUA wishes to >>> indicate support for the PA function, it SHOULD use the caller >>>preferences specification [9] to indicate that it supports the >>>SUBSCRIBE request method and the presence event package. The >>>combination of these two define a PA. >>> >>>as in some cases it is provisions of RFC 3261 and RFC 3265 through >>>the use of the Allow and Allow events header that will define a PA. >>>Maybe the text should be revised to reflect the precedence of those >>>headers. >> >>Actually, I dont think there is a conflict, but the reason is subtle. >>If you look at the first sentence in the text from callee caps above, >>you will note that it is explicitly talking about *target refresh >>requests*. The presence spec is talking about registrations. The >>difference is that registrations can contain information about >>multiple UAs, and therefore the capability information needs to be >>contact-specific; thus, it is appropriate to use the callee caps >>parameters. >> >>-Jonathan R. >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 5 14:20:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28548 for ; Mon, 5 Jan 2004 14:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdaGo-0000sg-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 14:20:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdaAY-0000iI-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 14:13:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ada88-0000Zl-00; Mon, 05 Jan 2004 14:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ada71-0008Rb-GO; Mon, 05 Jan 2004 14:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ada6f-0008QA-Qi for simple@optimus.ietf.org; Mon, 05 Jan 2004 14:09:41 -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 OAA28358 for ; Mon, 5 Jan 2004 14:09:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ada6Y-0000Xl-00 for simple@ietf.org; Mon, 05 Jan 2004 14:09:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ada1Y-0000P6-00 for simple@ietf.org; Mon, 05 Jan 2004 14:04:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AdZyh-0000ID-00 for simple@ietf.org; Mon, 05 Jan 2004 14:01:27 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i05J0OK6016638; Mon, 5 Jan 2004 14:00:25 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFA12145; Mon, 5 Jan 2004 14:00:23 -0500 (EST) Message-ID: <3FF9B447.7070306@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 14:00:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Paul Kyzivat wrote: > >> >> >> hisham.khartabil@nokia.com wrote: >> >>> >>> What are the use cases where an end point would end an old IM session >>> only to start a new one, where the new one is not *replacing* the old >>> one? >> >> >> >> I don't offhand have one for the simplest case, though give me some >> time and I may be able to come up with one. >> >> But I do have a slightly more complex one: >> >> - start out with call havine one MSRP session. >> >> - add a 2nd MSRP session for a file transfer. >> >> - lose connectivity on both. >> >> - decide to attempt restoration of only one. >> (perhaps because don't want to retry the file xfer automatically) >> >> - with your approach, the two original m-lines would each get a zero >> port number, and a 3rd m-line would would be used for the >> recovered session. >> >> How does the answerer know which session the new m-line replaces? >> >> As soon as there are multiple MSRP sessions the number of scenarios >> like this multiply. I think there must be some clear way for the >> endpoints to associate the new session with the old one. Note this is >> true whether lost messages are to be retransmitted or not. This >> affects the UI - does the old window, with its history of the >> conversation, get attached to the new session, or is a new window >> created? > > So, how would you deal with that if these were RTP session? I agree that this is a general problem, not just a problem for MSRP. But we have to start somewhere to deal with it. Using the same media lines for the replacement session solves the association problem for any media type - MSRP, RTP, whatever. But it also does leave the problem of distinguishing a "reconnect" offer from a "don't change anything" offer. > Back to the original question of how do we tell a "reconnect" offer from > a "don't change anything" offer: I just had an offline discussion with > Robert, where he points out that, if there is any change, the o line > version will change. So it seems like we could say that, if the active > sides sends a new offer with the same version number, it means no > change. If it has a new version number, it means reconnect. That doesn't work at all well when there are multiple media sessions in the call. Suppose I have voice and msrp sessions, and I want to put the voice call on hold. That requires a change to the SDP and its o-line. But it doesn't mean that the msrp session should reconnect. > (I note with great embarrassment that the examples in the MSRP draft are > missing o lines...) > > This does not seem to solve Paul's issue of replacing one stream, but > not another. It is not clear to me that this is an MSRP issue, > though--how would you handle it for RTP? I think we must recognize that this isn't just an msrp issue, and find a solution that at least works for msrp, but hopefully one that is applicable to other media as well. Perhaps this is something akin to the o-line on a per-media-session basis. (The obvious thing would be a session-specific o-line, but that would require SDP changes. Adding an a-line for the same purpose would be easier.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 5 14:20:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28603 for ; Mon, 5 Jan 2004 14:20:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdaH1-0000E4-Vi for simple-archive@odin.ietf.org; Mon, 05 Jan 2004 14:20:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05JKN5l000868 for simple-archive@odin.ietf.org; Mon, 5 Jan 2004 14:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdaH1-0000Du-Ok for simple-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 14:20:23 -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 OAA28566 for ; Mon, 5 Jan 2004 14:20:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdaGu-0000tA-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 14:20:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdaAZ-0000iP-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 14:13:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ada88-0000Zl-00; Mon, 05 Jan 2004 14:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ada71-0008Rb-GO; Mon, 05 Jan 2004 14:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ada6f-0008QA-Qi for simple@optimus.ietf.org; Mon, 05 Jan 2004 14:09:41 -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 OAA28358 for ; Mon, 5 Jan 2004 14:09:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ada6Y-0000Xl-00 for simple@ietf.org; Mon, 05 Jan 2004 14:09:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ada1Y-0000P6-00 for simple@ietf.org; Mon, 05 Jan 2004 14:04:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AdZyh-0000ID-00 for simple@ietf.org; Mon, 05 Jan 2004 14:01:27 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i05J0OK6016638; Mon, 5 Jan 2004 14:00:25 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFA12145; Mon, 5 Jan 2004 14:00:23 -0500 (EST) Message-ID: <3FF9B447.7070306@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 14:00:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Paul Kyzivat wrote: > >> >> >> hisham.khartabil@nokia.com wrote: >> >>> >>> What are the use cases where an end point would end an old IM session >>> only to start a new one, where the new one is not *replacing* the old >>> one? >> >> >> >> I don't offhand have one for the simplest case, though give me some >> time and I may be able to come up with one. >> >> But I do have a slightly more complex one: >> >> - start out with call havine one MSRP session. >> >> - add a 2nd MSRP session for a file transfer. >> >> - lose connectivity on both. >> >> - decide to attempt restoration of only one. >> (perhaps because don't want to retry the file xfer automatically) >> >> - with your approach, the two original m-lines would each get a zero >> port number, and a 3rd m-line would would be used for the >> recovered session. >> >> How does the answerer know which session the new m-line replaces? >> >> As soon as there are multiple MSRP sessions the number of scenarios >> like this multiply. I think there must be some clear way for the >> endpoints to associate the new session with the old one. Note this is >> true whether lost messages are to be retransmitted or not. This >> affects the UI - does the old window, with its history of the >> conversation, get attached to the new session, or is a new window >> created? > > So, how would you deal with that if these were RTP session? I agree that this is a general problem, not just a problem for MSRP. But we have to start somewhere to deal with it. Using the same media lines for the replacement session solves the association problem for any media type - MSRP, RTP, whatever. But it also does leave the problem of distinguishing a "reconnect" offer from a "don't change anything" offer. > Back to the original question of how do we tell a "reconnect" offer from > a "don't change anything" offer: I just had an offline discussion with > Robert, where he points out that, if there is any change, the o line > version will change. So it seems like we could say that, if the active > sides sends a new offer with the same version number, it means no > change. If it has a new version number, it means reconnect. That doesn't work at all well when there are multiple media sessions in the call. Suppose I have voice and msrp sessions, and I want to put the voice call on hold. That requires a change to the SDP and its o-line. But it doesn't mean that the msrp session should reconnect. > (I note with great embarrassment that the examples in the MSRP draft are > missing o lines...) > > This does not seem to solve Paul's issue of replacing one stream, but > not another. It is not clear to me that this is an MSRP issue, > though--how would you handle it for RTP? I think we must recognize that this isn't just an msrp issue, and find a solution that at least works for msrp, but hopefully one that is applicable to other media as well. Perhaps this is something akin to the o-line on a per-media-session basis. (The obvious thing would be a session-specific o-line, but that would require SDP changes. Adding an a-line for the same purpose would be easier.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 5 15:31:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02145 for ; Mon, 5 Jan 2004 15:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbOE-0003uV-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 15:31:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbMr-0003mq-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 15:30:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdbLb-0003dT-00; Mon, 05 Jan 2004 15:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbKT-0002Rq-60; Mon, 05 Jan 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbKQ-0002Rf-4C for simple@optimus.ietf.org; Mon, 05 Jan 2004 15:27:58 -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 PAA01933 for ; Mon, 5 Jan 2004 15:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbKJ-0003bG-00 for simple@ietf.org; Mon, 05 Jan 2004 15:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbEA-0003Km-00 for simple@ietf.org; Mon, 05 Jan 2004 15:21:32 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Adb7d-00032w-00 for simple@ietf.org; Mon, 05 Jan 2004 15:14:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i05KDWEP053412; Mon, 5 Jan 2004 14:13:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FF9C55F.1070601@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> In-Reply-To: <3FF9B447.7070306@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 14:13:19 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >>> >>> >>> hisham.khartabil@nokia.com wrote: >>> >>>> >>>> What are the use cases where an end point would end an old IM >>>> session only to start a new one, where the new one is not >>>> *replacing* the old one? >>> >>> >>> >>> >>> I don't offhand have one for the simplest case, though give me some >>> time and I may be able to come up with one. >>> >>> But I do have a slightly more complex one: >>> >>> - start out with call havine one MSRP session. >>> >>> - add a 2nd MSRP session for a file transfer. >>> >>> - lose connectivity on both. >>> >>> - decide to attempt restoration of only one. >>> (perhaps because don't want to retry the file xfer automatically) >>> >>> - with your approach, the two original m-lines would each get a zero >>> port number, and a 3rd m-line would would be used for the >>> recovered session. >>> >>> How does the answerer know which session the new m-line replaces? >>> >>> As soon as there are multiple MSRP sessions the number of scenarios >>> like this multiply. I think there must be some clear way for the >>> endpoints to associate the new session with the old one. Note this is >>> true whether lost messages are to be retransmitted or not. This >>> affects the UI - does the old window, with its history of the >>> conversation, get attached to the new session, or is a new window >>> created? >> >> >> So, how would you deal with that if these were RTP session? > > > I agree that this is a general problem, not just a problem for MSRP. > But we have to start somewhere to deal with it. I agree we need to start somewhere--but if these problems are the same that you would have for any connection-oriented media, then I am not sure if the work belongs here. Why would we hold sdp use for msrp to a higher standard than we do other uses? > > Using the same media lines for the replacement session solves the > association problem for any media type - MSRP, RTP, whatever. But it > also does leave the problem of distinguishing a "reconnect" offer from a > "don't change anything" offer. > >> Back to the original question of how do we tell a "reconnect" offer >> from a "don't change anything" offer: I just had an offline discussion >> with Robert, where he points out that, if there is any change, the o >> line version will change. So it seems like we could say that, if the >> active sides sends a new offer with the same version number, it means >> no change. If it has a new version number, it means reconnect. > > > That doesn't work at all well when there are multiple media sessions in > the call. Suppose I have voice and msrp sessions, and I want to put the > voice call on hold. That requires a change to the SDP and its o-line. > But it doesn't mean that the msrp session should reconnect. > >> (I note with great embarrassment that the examples in the MSRP draft >> are missing o lines...) >> >> This does not seem to solve Paul's issue of replacing one stream, but >> not another. It is not clear to me that this is an MSRP issue, >> though--how would you handle it for RTP? > > > I think we must recognize that this isn't just an msrp issue, and find a > solution that at least works for msrp, but hopefully one that is > applicable to other media as well. > > Perhaps this is something akin to the o-line on a per-media-session > basis. (The obvious thing would be a session-specific o-line, but that > would require SDP changes. Adding an a-line for the same purpose would > be easier.) > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 5 15:32:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02187 for ; Mon, 5 Jan 2004 15:32:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbOH-0002f2-LK for simple-archive@odin.ietf.org; Mon, 05 Jan 2004 15:31:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05KVvfQ010224 for simple-archive@odin.ietf.org; Mon, 5 Jan 2004 15:31:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbOH-0002ep-IG for simple-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 15:31:57 -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 PAA02162 for ; Mon, 5 Jan 2004 15:31:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbOG-0003ui-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 15:31:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbMs-0003mx-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 15:30:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdbLb-0003dT-00; Mon, 05 Jan 2004 15:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbKT-0002Rq-60; Mon, 05 Jan 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbKQ-0002Rf-4C for simple@optimus.ietf.org; Mon, 05 Jan 2004 15:27:58 -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 PAA01933 for ; Mon, 5 Jan 2004 15:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbKJ-0003bG-00 for simple@ietf.org; Mon, 05 Jan 2004 15:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbEA-0003Km-00 for simple@ietf.org; Mon, 05 Jan 2004 15:21:32 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Adb7d-00032w-00 for simple@ietf.org; Mon, 05 Jan 2004 15:14:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i05KDWEP053412; Mon, 5 Jan 2004 14:13:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FF9C55F.1070601@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> In-Reply-To: <3FF9B447.7070306@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 14:13:19 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >>> >>> >>> hisham.khartabil@nokia.com wrote: >>> >>>> >>>> What are the use cases where an end point would end an old IM >>>> session only to start a new one, where the new one is not >>>> *replacing* the old one? >>> >>> >>> >>> >>> I don't offhand have one for the simplest case, though give me some >>> time and I may be able to come up with one. >>> >>> But I do have a slightly more complex one: >>> >>> - start out with call havine one MSRP session. >>> >>> - add a 2nd MSRP session for a file transfer. >>> >>> - lose connectivity on both. >>> >>> - decide to attempt restoration of only one. >>> (perhaps because don't want to retry the file xfer automatically) >>> >>> - with your approach, the two original m-lines would each get a zero >>> port number, and a 3rd m-line would would be used for the >>> recovered session. >>> >>> How does the answerer know which session the new m-line replaces? >>> >>> As soon as there are multiple MSRP sessions the number of scenarios >>> like this multiply. I think there must be some clear way for the >>> endpoints to associate the new session with the old one. Note this is >>> true whether lost messages are to be retransmitted or not. This >>> affects the UI - does the old window, with its history of the >>> conversation, get attached to the new session, or is a new window >>> created? >> >> >> So, how would you deal with that if these were RTP session? > > > I agree that this is a general problem, not just a problem for MSRP. > But we have to start somewhere to deal with it. I agree we need to start somewhere--but if these problems are the same that you would have for any connection-oriented media, then I am not sure if the work belongs here. Why would we hold sdp use for msrp to a higher standard than we do other uses? > > Using the same media lines for the replacement session solves the > association problem for any media type - MSRP, RTP, whatever. But it > also does leave the problem of distinguishing a "reconnect" offer from a > "don't change anything" offer. > >> Back to the original question of how do we tell a "reconnect" offer >> from a "don't change anything" offer: I just had an offline discussion >> with Robert, where he points out that, if there is any change, the o >> line version will change. So it seems like we could say that, if the >> active sides sends a new offer with the same version number, it means >> no change. If it has a new version number, it means reconnect. > > > That doesn't work at all well when there are multiple media sessions in > the call. Suppose I have voice and msrp sessions, and I want to put the > voice call on hold. That requires a change to the SDP and its o-line. > But it doesn't mean that the msrp session should reconnect. > >> (I note with great embarrassment that the examples in the MSRP draft >> are missing o lines...) >> >> This does not seem to solve Paul's issue of replacing one stream, but >> not another. It is not clear to me that this is an MSRP issue, >> though--how would you handle it for RTP? > > > I think we must recognize that this isn't just an msrp issue, and find a > solution that at least works for msrp, but hopefully one that is > applicable to other media as well. > > Perhaps this is something akin to the o-line on a per-media-session > basis. (The obvious thing would be a session-specific o-line, but that > would require SDP changes. Adding an a-line for the same purpose would > be easier.) > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 5 16:33:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05268 for ; Mon, 5 Jan 2004 16:33:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdcMD-0007OV-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 16:33:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdcJx-0007A6-00 for simple-archive@ietf.org; Mon, 05 Jan 2004 16:31:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdcF4-0006uF-00; Mon, 05 Jan 2004 16:26:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcEb-0005CN-VH; Mon, 05 Jan 2004 16:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcEN-0005Bv-Hu for simple@optimus.ietf.org; Mon, 05 Jan 2004 16:25:47 -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 QAA04840 for ; Mon, 5 Jan 2004 16:25:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdcEG-0006tc-00 for simple@ietf.org; Mon, 05 Jan 2004 16:25:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdcAg-0006cc-00 for simple@ietf.org; Mon, 05 Jan 2004 16:21:58 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Adc39-0006Jl-00 for simple@ietf.org; Mon, 05 Jan 2004 16:14:11 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i05LDkEP058692; Mon, 5 Jan 2004 15:13:57 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FF9D37D.1070400@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> In-Reply-To: <3FF9B447.7070306@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 15:13:33 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit (More comments on same email...) Paul Kyzivat wrote: [...] > > Using the same media lines for the replacement session solves the > association problem for any media type - MSRP, RTP, whatever. But it > also does leave the problem of distinguishing a "reconnect" offer from a > "don't change anything" offer. Would doing this, plus using the COMEDIA reconnect attribute help? (section 5 of current comedia draft.) > >> Back to the original question of how do we tell a "reconnect" offer >> from a "don't change anything" offer: I just had an offline discussion >> with Robert, where he points out that, if there is any change, the o >> line version will change. So it seems like we could say that, if the >> active sides sends a new offer with the same version number, it means >> no change. If it has a new version number, it means reconnect. > > > That doesn't work at all well when there are multiple media sessions in > the call. Suppose I have voice and msrp sessions, and I want to put the > voice call on hold. That requires a change to the SDP and its o-line. > But it doesn't mean that the msrp session should reconnect. Point taken. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 5 16:34:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05363 for ; Mon, 5 Jan 2004 16:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcMJ-0005Mj-Qb for simple-archive@odin.ietf.org; Mon, 05 Jan 2004 16:33:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05LXxdh020619 for simple-archive@odin.ietf.org; Mon, 5 Jan 2004 16:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcMJ-0005MU-NS for simple-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 16:33:59 -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 QAA05286 for ; Mon, 5 Jan 2004 16:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdcMH-0007P9-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 16:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdcJz-0007Al-00 for simple-web-archive@ietf.org; Mon, 05 Jan 2004 16:31:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdcF4-0006uF-00; Mon, 05 Jan 2004 16:26:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcEb-0005CN-VH; Mon, 05 Jan 2004 16:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdcEN-0005Bv-Hu for simple@optimus.ietf.org; Mon, 05 Jan 2004 16:25:47 -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 QAA04840 for ; Mon, 5 Jan 2004 16:25:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdcEG-0006tc-00 for simple@ietf.org; Mon, 05 Jan 2004 16:25:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdcAg-0006cc-00 for simple@ietf.org; Mon, 05 Jan 2004 16:21:58 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Adc39-0006Jl-00 for simple@ietf.org; Mon, 05 Jan 2004 16:14:11 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i05LDkEP058692; Mon, 5 Jan 2004 15:13:57 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FF9D37D.1070400@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> In-Reply-To: <3FF9B447.7070306@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 15:13:33 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (More comments on same email...) Paul Kyzivat wrote: [...] > > Using the same media lines for the replacement session solves the > association problem for any media type - MSRP, RTP, whatever. But it > also does leave the problem of distinguishing a "reconnect" offer from a > "don't change anything" offer. Would doing this, plus using the COMEDIA reconnect attribute help? (section 5 of current comedia draft.) > >> Back to the original question of how do we tell a "reconnect" offer >> from a "don't change anything" offer: I just had an offline discussion >> with Robert, where he points out that, if there is any change, the o >> line version will change. So it seems like we could say that, if the >> active sides sends a new offer with the same version number, it means >> no change. If it has a new version number, it means reconnect. > > > That doesn't work at all well when there are multiple media sessions in > the call. Suppose I have voice and msrp sessions, and I want to put the > voice call on hold. That requires a change to the SDP and its o-line. > But it doesn't mean that the msrp session should reconnect. Point taken. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 6 03:51:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11076 for ; Tue, 6 Jan 2004 03:51:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Admw1-0001Ws-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 03:51:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdmuH-0001Sn-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 03:49:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Admsr-0001OQ-00; Tue, 06 Jan 2004 03:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Admsc-0008R6-Mk; Tue, 06 Jan 2004 03:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmsK-0008Q5-CF for simple@optimus.ietf.org; Tue, 06 Jan 2004 03:47:44 -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 DAA10956 for ; Tue, 6 Jan 2004 03:47:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdmsH-0001Mw-00 for simple@ietf.org; Tue, 06 Jan 2004 03:47:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdmqL-0001J6-00 for simple@ietf.org; Tue, 06 Jan 2004 03:45:42 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly02a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1Admp7-0001F9-00 for simple@ietf.org; Tue, 06 Jan 2004 03:44:25 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly02a.srv.mailcontrol.com (MailControl) with SMTP id i068heYr027762; Tue, 6 Jan 2004 08:43:41 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Tue, 6 Jan 2004 08:43:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <45730E094814E44488F789C1CDED27AE0219B153@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPTv6ZFRZufGCpQTjGZeKVdIlBGaAAbt7Hw From: "Chris Boulton" To: "Paul Kyzivat" , "Ben Campbell" Cc: , X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Jan 2004 08:43:40 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > >> (I note with great embarrassment that the examples in the MSRP draft are >> missing o lines...) >> >> This does not seem to solve Paul's issue of replacing one stream, but >> not another. It is not clear to me that this is an MSRP issue, >> though--how would you handle it for RTP? > >I think we must recognize that this isn't just an msrp issue, and find a >solution that at least works for msrp, but hopefully one that is >applicable to other media as well. > >Perhaps this is something akin to the o-line on a per-media-session >basis. (The obvious thing would be a session-specific o-line, but that >would require SDP changes. Adding an a-line for the same purpose would >be easier.) > > Paul [Chris Boulton] I think we can all recognize that this is a global problem rather than msrp specific. I like Paul's idea of having an attribute e.g. 'a=3Dreconnect' to indicate the continuation of a session. Just one question, the version number in the offer will have changed, due to payload change, so how would the msrp client associate a reconnect with an existing session, if multiple exist? e.g. Client A and B currently have 2 connection, one for messaging, one for file transfer - client B is hosting. Client A detects failure in one of the connections (Client B has not detected failure) and issues a new offer via an 'update'. Client B receives the offer and realizes it's a reconnect. How does client B know which of the two connections we are attempting to reconnect? Thanks, Chris. > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 6 03:52:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11112 for ; Tue, 6 Jan 2004 03:52:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Admw5-0000BU-79 for simple-archive@odin.ietf.org; Tue, 06 Jan 2004 03:51:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i068pbUU000706 for simple-archive@odin.ietf.org; Tue, 6 Jan 2004 03:51:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Admw4-0000BJ-PZ for simple-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 03:51:36 -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 DAA11082 for ; Tue, 6 Jan 2004 03:51:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Admw2-0001Wx-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 03:51:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdmuI-0001Su-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 03:49:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Admsr-0001OQ-00; Tue, 06 Jan 2004 03:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Admsc-0008R6-Mk; Tue, 06 Jan 2004 03:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmsK-0008Q5-CF for simple@optimus.ietf.org; Tue, 06 Jan 2004 03:47:44 -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 DAA10956 for ; Tue, 6 Jan 2004 03:47:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdmsH-0001Mw-00 for simple@ietf.org; Tue, 06 Jan 2004 03:47:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdmqL-0001J6-00 for simple@ietf.org; Tue, 06 Jan 2004 03:45:42 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly02a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1Admp7-0001F9-00 for simple@ietf.org; Tue, 06 Jan 2004 03:44:25 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly02a.srv.mailcontrol.com (MailControl) with SMTP id i068heYr027762; Tue, 6 Jan 2004 08:43:41 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Tue, 6 Jan 2004 08:43:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <45730E094814E44488F789C1CDED27AE0219B153@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPTv6ZFRZufGCpQTjGZeKVdIlBGaAAbt7Hw From: "Chris Boulton" To: "Paul Kyzivat" , "Ben Campbell" Cc: , X-Scanned-By: MailControl A-01-00-04-90 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Jan 2004 08:43:40 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >> (I note with great embarrassment that the examples in the MSRP draft are >> missing o lines...) >> >> This does not seem to solve Paul's issue of replacing one stream, but >> not another. It is not clear to me that this is an MSRP issue, >> though--how would you handle it for RTP? > >I think we must recognize that this isn't just an msrp issue, and find a >solution that at least works for msrp, but hopefully one that is >applicable to other media as well. > >Perhaps this is something akin to the o-line on a per-media-session >basis. (The obvious thing would be a session-specific o-line, but that >would require SDP changes. Adding an a-line for the same purpose would >be easier.) > > Paul [Chris Boulton] I think we can all recognize that this is a global problem rather than msrp specific. I like Paul's idea of having an attribute e.g. 'a=3Dreconnect' to indicate the continuation of a session. Just one question, the version number in the offer will have changed, due to payload change, so how would the msrp client associate a reconnect with an existing session, if multiple exist? e.g. Client A and B currently have 2 connection, one for messaging, one for file transfer - client B is hosting. Client A detects failure in one of the connections (Client B has not detected failure) and issues a new offer via an 'update'. Client B receives the offer and realizes it's a reconnect. How does client B know which of the two connections we are attempting to reconnect? Thanks, Chris. > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 6 15:35:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02958 for ; Tue, 6 Jan 2004 15:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdxvV-0007IN-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 15:35:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adxtj-0007De-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 15:33:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adxs4-0007AI-00; Tue, 06 Jan 2004 15:32:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adxrt-0008Q3-9V; Tue, 06 Jan 2004 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adxrd-0008P7-Cg for simple@optimus.ietf.org; Tue, 06 Jan 2004 15:31:45 -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 PAA02844 for ; Tue, 6 Jan 2004 15:31:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adxrc-00077G-00 for simple@ietf.org; Tue, 06 Jan 2004 15:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adxpe-00071N-00 for simple@ietf.org; Tue, 06 Jan 2004 15:29:43 -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 1Adxnj-0006tr-00 for simple@ietf.org; Tue, 06 Jan 2004 15:27:43 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Jan 2004 12:34:20 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i06KR7VO017023; Tue, 6 Jan 2004 12:27:10 -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 AFA96343; Tue, 6 Jan 2004 15:27:06 -0500 (EST) Message-ID: <3FFB1A1A.90805@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 15:27:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > (More comments on same email...) > > Paul Kyzivat wrote: > > [...] > >> >> Using the same media lines for the replacement session solves the >> association problem for any media type - MSRP, RTP, whatever. But it >> also does leave the problem of distinguishing a "reconnect" offer from >> a "don't change anything" offer. > > Would doing this, plus using the COMEDIA reconnect attribute help? > (section 5 of current comedia draft.) That would probably work. The feature in comedia didn't end up as I hoped it would. While it does mean you have to do something special (add the a=reconnect) attribute to cause a reconnect, having done that once you then have to do something else (remove the a=reconnect) in a subsequent exchange. I think it would be better if there were something like a=version:nnn, which would just be a version number for a particular media session. Then whenever it changes you reconnect. If the attribute was absent it could be defaulted from the o-line. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 6 15:36:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02997 for ; Tue, 6 Jan 2004 15:36:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdxvX-00005v-LC for simple-archive@odin.ietf.org; Tue, 06 Jan 2004 15:35:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06KZlY4000362 for simple-archive@odin.ietf.org; Tue, 6 Jan 2004 15:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdxvX-00005l-HF for simple-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 15:35:47 -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 PAA02965 for ; Tue, 6 Jan 2004 15:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdxvV-0007IS-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 15:35:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adxtk-0007Dl-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 15:33:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adxs4-0007AI-00; Tue, 06 Jan 2004 15:32:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adxrt-0008Q3-9V; Tue, 06 Jan 2004 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adxrd-0008P7-Cg for simple@optimus.ietf.org; Tue, 06 Jan 2004 15:31:45 -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 PAA02844 for ; Tue, 6 Jan 2004 15:31:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adxrc-00077G-00 for simple@ietf.org; Tue, 06 Jan 2004 15:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adxpe-00071N-00 for simple@ietf.org; Tue, 06 Jan 2004 15:29:43 -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 1Adxnj-0006tr-00 for simple@ietf.org; Tue, 06 Jan 2004 15:27:43 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Jan 2004 12:34:20 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i06KR7VO017023; Tue, 6 Jan 2004 12:27:10 -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 AFA96343; Tue, 6 Jan 2004 15:27:06 -0500 (EST) Message-ID: <3FFB1A1A.90805@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 15:27:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > (More comments on same email...) > > Paul Kyzivat wrote: > > [...] > >> >> Using the same media lines for the replacement session solves the >> association problem for any media type - MSRP, RTP, whatever. But it >> also does leave the problem of distinguishing a "reconnect" offer from >> a "don't change anything" offer. > > Would doing this, plus using the COMEDIA reconnect attribute help? > (section 5 of current comedia draft.) That would probably work. The feature in comedia didn't end up as I hoped it would. While it does mean you have to do something special (add the a=reconnect) attribute to cause a reconnect, having done that once you then have to do something else (remove the a=reconnect) in a subsequent exchange. I think it would be better if there were something like a=version:nnn, which would just be a version number for a particular media session. Then whenever it changes you reconnect. If the attribute was absent it could be defaulted from the o-line. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 6 15:47:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03248 for ; Tue, 6 Jan 2004 15:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ady76-0007ga-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 15:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ady5C-0007e0-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 15:45:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ady3c-0007bR-00; Tue, 06 Jan 2004 15:44:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ady3V-0000YH-Mq; Tue, 06 Jan 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ady3D-0000Xf-B6 for simple@optimus.ietf.org; Tue, 06 Jan 2004 15:43:43 -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 PAA03162 for ; Tue, 6 Jan 2004 15:43:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ady3B-0007Zt-00 for simple@ietf.org; Tue, 06 Jan 2004 15:43:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ady1N-0007X2-00 for simple@ietf.org; Tue, 06 Jan 2004 15:41:50 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Adxzd-0007TC-00 for simple@ietf.org; Tue, 06 Jan 2004 15:40:01 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i06KdhEP069065; Tue, 6 Jan 2004 14:39:47 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFB1CFC.6030301@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> In-Reply-To: <3FFB1A1A.90805@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 14:39:24 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> (More comments on same email...) >> >> Paul Kyzivat wrote: >> >> [...] >> >>> >>> Using the same media lines for the replacement session solves the >>> association problem for any media type - MSRP, RTP, whatever. But it >>> also does leave the problem of distinguishing a "reconnect" offer >>> from a "don't change anything" offer. >> >> >> Would doing this, plus using the COMEDIA reconnect attribute help? >> (section 5 of current comedia draft.) > > > That would probably work. The feature in comedia didn't end up as I > hoped it would. While it does mean you have to do something special (add > the a=reconnect) attribute to cause a reconnect, having done that once > you then have to do something else (remove the a=reconnect) in a > subsequent exchange. > > I think it would be better if there were something like a=version:nnn, > which would just be a version number for a particular media session. > Then whenever it changes you reconnect. If the attribute was absent it > could be defaulted from the o-line. I agree that sounds like a better approach. Do you think there is any chance to convince the COMEDIA folks to follow the same approach? > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 6 15:49:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03306 for ; Tue, 6 Jan 2004 15:49: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 1Ady78-0000fO-70 for simple-archive@odin.ietf.org; Tue, 06 Jan 2004 15:47:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06KlkgU002559 for simple-archive@odin.ietf.org; Tue, 6 Jan 2004 15:47:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ady78-0000fC-2N for simple-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 15:47:46 -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 PAA03252 for ; Tue, 6 Jan 2004 15:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ady76-0007gf-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 15:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ady5D-0007e7-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 15:45:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ady3c-0007bR-00; Tue, 06 Jan 2004 15:44:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ady3V-0000YH-Mq; Tue, 06 Jan 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ady3D-0000Xf-B6 for simple@optimus.ietf.org; Tue, 06 Jan 2004 15:43:43 -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 PAA03162 for ; Tue, 6 Jan 2004 15:43:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ady3B-0007Zt-00 for simple@ietf.org; Tue, 06 Jan 2004 15:43:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ady1N-0007X2-00 for simple@ietf.org; Tue, 06 Jan 2004 15:41:50 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Adxzd-0007TC-00 for simple@ietf.org; Tue, 06 Jan 2004 15:40:01 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i06KdhEP069065; Tue, 6 Jan 2004 14:39:47 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFB1CFC.6030301@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> In-Reply-To: <3FFB1A1A.90805@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 14:39:24 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> (More comments on same email...) >> >> Paul Kyzivat wrote: >> >> [...] >> >>> >>> Using the same media lines for the replacement session solves the >>> association problem for any media type - MSRP, RTP, whatever. But it >>> also does leave the problem of distinguishing a "reconnect" offer >>> from a "don't change anything" offer. >> >> >> Would doing this, plus using the COMEDIA reconnect attribute help? >> (section 5 of current comedia draft.) > > > That would probably work. The feature in comedia didn't end up as I > hoped it would. While it does mean you have to do something special (add > the a=reconnect) attribute to cause a reconnect, having done that once > you then have to do something else (remove the a=reconnect) in a > subsequent exchange. > > I think it would be better if there were something like a=version:nnn, > which would just be a version number for a particular media session. > Then whenever it changes you reconnect. If the attribute was absent it > could be defaulted from the o-line. I agree that sounds like a better approach. Do you think there is any chance to convince the COMEDIA folks to follow the same approach? > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 6 16:16:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04122 for ; Tue, 6 Jan 2004 16:16:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyYv-0000wD-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 16:16:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyXL-0000oR-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 16:14:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdyW4-0000f4-00; Tue, 06 Jan 2004 16:13:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyVZ-0001fN-EG; Tue, 06 Jan 2004 16:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyV5-0001eZ-TM for simple@optimus.ietf.org; Tue, 06 Jan 2004 16:12:47 -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 QAA03919 for ; Tue, 6 Jan 2004 16:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyUz-0000dj-00 for simple@ietf.org; Tue, 06 Jan 2004 16:12:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyPN-0000Ry-00 for simple@ietf.org; Tue, 06 Jan 2004 16:06:38 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AdyMS-0000Iw-00 for simple@ietf.org; Tue, 06 Jan 2004 16:03:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2004 13:10:26 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i06L2pVM028127; Tue, 6 Jan 2004 13:02:52 -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 AFA99752; Tue, 6 Jan 2004 16:02:50 -0500 (EST) Message-ID: <3FFB227A.5070100@cisco.com> From: Paul Kyzivat 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: Chris Boulton CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <45730E094814E44488F789C1CDED27AE0219B153@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 16:02:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Chris Boulton wrote: > > [Chris Boulton] I think we can all recognize that this is a global > problem rather than msrp specific. I like Paul's idea of having an > attribute e.g. 'a=reconnect' to indicate the continuation of a session. > Just one question, the version number in the offer will have changed, > due to payload change, so how would the msrp client associate a > reconnect with an existing session, if multiple exist? > > e.g. Client A and B currently have 2 connection, one for messaging, one > for file transfer - client B is hosting. Client A detects failure in > one of the connections (Client B has not detected failure) and issues a > new offer via an 'update'. Client B receives the offer and realizes > it's a reconnect. How does client B know which of the two connections > we are attempting to reconnect? The attribute is associated with a particular media session. It can be inserted into the one for the session that is to be reconnected. It is inserted twice if both are to be reconnected. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both a=session:msrp://alicepc.atlanta.com:7777/iau39 a=version:1 Bob->Alice (SIP): 200 OK c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 Alice then adds another session for file transfer: Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both a=version:1 m=message 9998 msrp/tcp * a=accept-types:application/pdf a=direction:passive a=sendonly a=session:msrp://alicepc.atlanta.com:7777/iau40 a=version:1 Bob->Alice (SIP): 200 OK c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 m=message 9998 msrp/tcp * a=accept-types:application/pdf a=direction:active a=recvonly a=version:1 Bob later discovers something wrong with the file transfer: Bob->Alice (SIP): (re)INVITE sip:alice-gruu@atlanta.com c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 m=message 9999 msrp/tcp * a=accept-types:application/pdf a=direction:active a=recvonly a=version:2 Alice sees that the version for the first session is unchanged and so does nothing with it. But the version for the 2nd session is changed, so she starts listening again for a new connection, and responds: Alice->Bob (SIP): 200 OK c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:passive a=version:1 m=message 9999 msrp/tcp * a=accept-types:application/pdf a=direction:passive a=sendonly a=session:msrp://alicepc.atlanta.com:7777/iau41 a=version:2 A subsequent offer/answer that didn't want to change anything could use these same sdp bodies. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 6 16:17:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04180 for ; Tue, 6 Jan 2004 16:17:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyYy-0001wp-Bn for simple-archive@odin.ietf.org; Tue, 06 Jan 2004 16:16:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06LGWtP007481 for simple-archive@odin.ietf.org; Tue, 6 Jan 2004 16:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyYy-0001wa-8B for simple-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 16:16:32 -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 QAA04137 for ; Tue, 6 Jan 2004 16:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyYw-0000wI-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 16:16:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyXL-0000oY-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 16:14:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdyW4-0000f4-00; Tue, 06 Jan 2004 16:13:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyVZ-0001fN-EG; Tue, 06 Jan 2004 16:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyV5-0001eZ-TM for simple@optimus.ietf.org; Tue, 06 Jan 2004 16:12:47 -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 QAA03919 for ; Tue, 6 Jan 2004 16:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyUz-0000dj-00 for simple@ietf.org; Tue, 06 Jan 2004 16:12:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyPN-0000Ry-00 for simple@ietf.org; Tue, 06 Jan 2004 16:06:38 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AdyMS-0000Iw-00 for simple@ietf.org; Tue, 06 Jan 2004 16:03:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2004 13:10:26 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i06L2pVM028127; Tue, 6 Jan 2004 13:02:52 -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 AFA99752; Tue, 6 Jan 2004 16:02:50 -0500 (EST) Message-ID: <3FFB227A.5070100@cisco.com> From: Paul Kyzivat 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: Chris Boulton CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <45730E094814E44488F789C1CDED27AE0219B153@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 16:02:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris Boulton wrote: > > [Chris Boulton] I think we can all recognize that this is a global > problem rather than msrp specific. I like Paul's idea of having an > attribute e.g. 'a=reconnect' to indicate the continuation of a session. > Just one question, the version number in the offer will have changed, > due to payload change, so how would the msrp client associate a > reconnect with an existing session, if multiple exist? > > e.g. Client A and B currently have 2 connection, one for messaging, one > for file transfer - client B is hosting. Client A detects failure in > one of the connections (Client B has not detected failure) and issues a > new offer via an 'update'. Client B receives the offer and realizes > it's a reconnect. How does client B know which of the two connections > we are attempting to reconnect? The attribute is associated with a particular media session. It can be inserted into the one for the session that is to be reconnected. It is inserted twice if both are to be reconnected. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both a=session:msrp://alicepc.atlanta.com:7777/iau39 a=version:1 Bob->Alice (SIP): 200 OK c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 Alice then adds another session for file transfer: Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:both a=version:1 m=message 9998 msrp/tcp * a=accept-types:application/pdf a=direction:passive a=sendonly a=session:msrp://alicepc.atlanta.com:7777/iau40 a=version:1 Bob->Alice (SIP): 200 OK c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 m=message 9998 msrp/tcp * a=accept-types:application/pdf a=direction:active a=recvonly a=version:1 Bob later discovers something wrong with the file transfer: Bob->Alice (SIP): (re)INVITE sip:alice-gruu@atlanta.com c=IN IP4 ignorefield m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:active a=version:1 m=message 9999 msrp/tcp * a=accept-types:application/pdf a=direction:active a=recvonly a=version:2 Alice sees that the version for the first session is unchanged and so does nothing with it. But the version for the 2nd session is changed, so she starts listening again for a new connection, and responds: Alice->Bob (SIP): 200 OK c=IN IP4 fillername m=message 9999 msrp/tcp * a=accept-types:text/plain a=direction:passive a=version:1 m=message 9999 msrp/tcp * a=accept-types:application/pdf a=direction:passive a=sendonly a=session:msrp://alicepc.atlanta.com:7777/iau41 a=version:2 A subsequent offer/answer that didn't want to change anything could use these same sdp bodies. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 6 18:05:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08206 for ; Tue, 6 Jan 2004 18:05:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae0Gg-0005DI-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 18:05:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae0Em-0005AG-00 for simple-archive@ietf.org; Tue, 06 Jan 2004 18:03:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae0D8-00057p-00; Tue, 06 Jan 2004 18:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae0D4-0006FY-DX; Tue, 06 Jan 2004 18:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae0Ct-0006Ec-0G for simple@optimus.ietf.org; Tue, 06 Jan 2004 18:01:55 -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 SAA07954 for ; Tue, 6 Jan 2004 18:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae0Cq-00056S-00 for simple@ietf.org; Tue, 06 Jan 2004 18:01:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae0B3-000532-00 for simple@ietf.org; Tue, 06 Jan 2004 17:59:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ae09E-0004v3-00 for simple@ietf.org; Tue, 06 Jan 2004 17:58:04 -0500 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 i06MvSGN004526; Tue, 6 Jan 2004 14:57:28 -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 AFB09710; Tue, 6 Jan 2004 17:57:26 -0500 (EST) Message-ID: <3FFB3D56.6070900@cisco.com> From: Paul Kyzivat 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: Ben Campbell , yon@dialout.net CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 17:57:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, I'm copying David Yon on this since he is author of comedia. This probably won't make any sense out of context to him, so I will separately send him some of the earlier discussion. I don't recall what the current status of comedia is. It is currently listed as a WG draft, but there don't seem to be any goals listed for it. Paul Ben Campbell wrote: > Paul Kyzivat wrote: > >> >> >> Ben Campbell wrote: >> >>> (More comments on same email...) >>> >>> Paul Kyzivat wrote: >>> >>> [...] >>> >>>> >>>> Using the same media lines for the replacement session solves the >>>> association problem for any media type - MSRP, RTP, whatever. But it >>>> also does leave the problem of distinguishing a "reconnect" offer >>>> from a "don't change anything" offer. >>> >>> >>> >>> Would doing this, plus using the COMEDIA reconnect attribute help? >>> (section 5 of current comedia draft.) >> >> >> >> That would probably work. The feature in comedia didn't end up as I >> hoped it would. While it does mean you have to do something special >> (add the a=reconnect) attribute to cause a reconnect, having done that >> once you then have to do something else (remove the a=reconnect) in a >> subsequent exchange. >> >> I think it would be better if there were something like a=version:nnn, >> which would just be a version number for a particular media session. >> Then whenever it changes you reconnect. If the attribute was absent it >> could be defaulted from the o-line. > > > I agree that sounds like a better approach. Do you think there is any > chance to convince the COMEDIA folks to follow the same approach? > >> >> Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 6 18:06:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08284 for ; Tue, 6 Jan 2004 18:06:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae0Gj-0006Oi-Ur for simple-archive@odin.ietf.org; Tue, 06 Jan 2004 18:05:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06N5nki024588 for simple-archive@odin.ietf.org; Tue, 6 Jan 2004 18:05:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae0Gj-0006OV-QR for simple-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 18:05:49 -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 SAA08210 for ; Tue, 6 Jan 2004 18:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae0Gg-0005DN-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 18:05:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae0Em-0005AN-00 for simple-web-archive@ietf.org; Tue, 06 Jan 2004 18:03:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae0D8-00057p-00; Tue, 06 Jan 2004 18:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae0D4-0006FY-DX; Tue, 06 Jan 2004 18:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae0Ct-0006Ec-0G for simple@optimus.ietf.org; Tue, 06 Jan 2004 18:01:55 -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 SAA07954 for ; Tue, 6 Jan 2004 18:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae0Cq-00056S-00 for simple@ietf.org; Tue, 06 Jan 2004 18:01:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae0B3-000532-00 for simple@ietf.org; Tue, 06 Jan 2004 17:59:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ae09E-0004v3-00 for simple@ietf.org; Tue, 06 Jan 2004 17:58:04 -0500 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 i06MvSGN004526; Tue, 6 Jan 2004 14:57:28 -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 AFB09710; Tue, 6 Jan 2004 17:57:26 -0500 (EST) Message-ID: <3FFB3D56.6070900@cisco.com> From: Paul Kyzivat 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: Ben Campbell , yon@dialout.net CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 06 Jan 2004 17:57:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben, I'm copying David Yon on this since he is author of comedia. This probably won't make any sense out of context to him, so I will separately send him some of the earlier discussion. I don't recall what the current status of comedia is. It is currently listed as a WG draft, but there don't seem to be any goals listed for it. Paul Ben Campbell wrote: > Paul Kyzivat wrote: > >> >> >> Ben Campbell wrote: >> >>> (More comments on same email...) >>> >>> Paul Kyzivat wrote: >>> >>> [...] >>> >>>> >>>> Using the same media lines for the replacement session solves the >>>> association problem for any media type - MSRP, RTP, whatever. But it >>>> also does leave the problem of distinguishing a "reconnect" offer >>>> from a "don't change anything" offer. >>> >>> >>> >>> Would doing this, plus using the COMEDIA reconnect attribute help? >>> (section 5 of current comedia draft.) >> >> >> >> That would probably work. The feature in comedia didn't end up as I >> hoped it would. While it does mean you have to do something special >> (add the a=reconnect) attribute to cause a reconnect, having done that >> once you then have to do something else (remove the a=reconnect) in a >> subsequent exchange. >> >> I think it would be better if there were something like a=version:nnn, >> which would just be a version number for a particular media session. >> Then whenever it changes you reconnect. If the attribute was absent it >> could be defaulted from the o-line. > > > I agree that sounds like a better approach. Do you think there is any > chance to convince the COMEDIA folks to follow the same approach? > >> >> Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 7 05:00:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00847 for ; Wed, 7 Jan 2004 05:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeAUN-0006Ii-00 for simple-archive@ietf.org; Wed, 07 Jan 2004 05:00:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeASl-00066h-00 for simple-archive@ietf.org; Wed, 07 Jan 2004 04:58:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeAQJ-0005u0-03; Wed, 07 Jan 2004 04:56:24 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeADb-0005V1-7e; Wed, 07 Jan 2004 04:43:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeADO-0000iu-JR; Wed, 07 Jan 2004 04:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeACT-0000hG-5R for simple@optimus.ietf.org; Wed, 07 Jan 2004 04:42: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 EAA29862 for ; Wed, 7 Jan 2004 04:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeACQ-0005AY-00 for simple@ietf.org; Wed, 07 Jan 2004 04:42:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeAAz-00052m-00 for simple@ietf.org; Wed, 07 Jan 2004 04:40:33 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly07a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AeA8n-0004kp-00 for simple@ietf.org; Wed, 07 Jan 2004 04:38:17 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07a.srv.mailcontrol.com (MailControl) with SMTP id i079bWvX015711; Wed, 7 Jan 2004 09:37:33 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Wed, 7 Jan 2004 09:37:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <45730E094814E44488F789C1CDED27AE01E22F76@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPUmHam2lfge3o/Sd2KOS7pacWxVgAaUO1g From: "Chris Boulton" To: "Paul Kyzivat" Cc: "Ben Campbell" , , X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Jan 2004 09:37:32 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable That looks good to me ;-) Chris. >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 06 January 2004 21:03 >To: Chris Boulton >Cc: Ben Campbell; hisham.khartabil@nokia.com; simple@ietf.org >Subject: Re: [Simple] MSRP: Some thoughts on session updates > > > >Chris Boulton wrote: >> >> [Chris Boulton] I think we can all recognize that this is a global >> problem rather than msrp specific. I like Paul's idea of having an >> attribute e.g. 'a=3Dreconnect' to indicate the continuation of a session. >> Just one question, the version number in the offer will have changed, >> due to payload change, so how would the msrp client associate a >> reconnect with an existing session, if multiple exist? >> >> e.g. Client A and B currently have 2 connection, one for messaging, one >> for file transfer - client B is hosting. Client A detects failure in >> one of the connections (Client B has not detected failure) and issues a >> new offer via an 'update'. Client B receives the offer and realizes >> it's a reconnect. How does client B know which of the two connections >> we are attempting to reconnect? > >The attribute is associated with a particular media session. It can be >inserted into the one for the session that is to be reconnected. It is >inserted twice if both are to be reconnected. > > Alice->Bob (SIP): INVITE sip:bob@biloxi.com > > c=3DIN IP4 fillername > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:text/plain > a=3Ddirection:both > a=3Dsession:msrp://alicepc.atlanta.com:7777/iau39 > a=3Dversion:1 > > Bob->Alice (SIP): 200 OK > > c=3DIN IP4 ignorefield > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:text/plain > a=3Ddirection:active > a=3Dversion:1 > >Alice then adds another session for file transfer: > > Alice->Bob (SIP): INVITE sip:bob@biloxi.com > > c=3DIN IP4 fillername > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:text/plain > a=3Ddirection:both > a=3Dversion:1 > m=3Dmessage 9998 msrp/tcp * > a=3Daccept-types:application/pdf > a=3Ddirection:passive > a=3Dsendonly > a=3Dsession:msrp://alicepc.atlanta.com:7777/iau40 > a=3Dversion:1 > > Bob->Alice (SIP): 200 OK > > c=3DIN IP4 ignorefield > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:text/plain > a=3Ddirection:active > a=3Dversion:1 > m=3Dmessage 9998 msrp/tcp * > a=3Daccept-types:application/pdf > a=3Ddirection:active > a=3Drecvonly > a=3Dversion:1 > >Bob later discovers something wrong with the file transfer: > > Bob->Alice (SIP): (re)INVITE sip:alice-gruu@atlanta.com > > c=3DIN IP4 ignorefield > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:text/plain > a=3Ddirection:active > a=3Dversion:1 > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:application/pdf > a=3Ddirection:active > a=3Drecvonly > a=3Dversion:2 > >Alice sees that the version for the first session is unchanged and so >does nothing with it. But the version for the 2nd session is changed, so >she starts listening again for a new connection, and responds: > > Alice->Bob (SIP): 200 OK > > c=3DIN IP4 fillername > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:text/plain > a=3Ddirection:passive > a=3Dversion:1 > m=3Dmessage 9999 msrp/tcp * > a=3Daccept-types:application/pdf > a=3Ddirection:passive > a=3Dsendonly > a=3Dsession:msrp://alicepc.atlanta.com:7777/iau41 > a=3Dversion:2 > >A subsequent offer/answer that didn't want to change anything could use >these same sdp bodies. > > Paul > > This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 7 11:48:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18337 for ; Wed, 7 Jan 2004 11:48:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeGqk-0004ve-00 for simple-archive@ietf.org; Wed, 07 Jan 2004 11:48:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeGp7-0004s4-00 for simple-archive@ietf.org; Wed, 07 Jan 2004 11:46:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeGnv-0004m7-00; Wed, 07 Jan 2004 11:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGnn-0003oo-CX; Wed, 07 Jan 2004 11:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGn3-0003n8-4u for simple@optimus.ietf.org; Wed, 07 Jan 2004 11:44:17 -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 LAA18152 for ; Wed, 7 Jan 2004 11:44:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeGn0-0004hQ-00 for simple@ietf.org; Wed, 07 Jan 2004 11:44:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeGlM-0004bj-00 for simple@ietf.org; Wed, 07 Jan 2004 11:42:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AeGjp-0004Rp-00 for simple@ietf.org; Wed, 07 Jan 2004 11:40:57 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i07GeNLE021241; Wed, 7 Jan 2004 11:40:24 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFB52400; Wed, 7 Jan 2004 11:40:23 -0500 (EST) Message-ID: <3FFC3676.1020909@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9C55F.1070601@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Jan 2004 11:40:22 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>>> As soon as there are multiple MSRP sessions the number of scenarios >>>> like this multiply. I think there must be some clear way for the >>>> endpoints to associate the new session with the old one. Note this >>>> is true whether lost messages are to be retransmitted or not. This >>>> affects the UI - does the old window, with its history of the >>>> conversation, get attached to the new session, or is a new window >>>> created? >>> >>> So, how would you deal with that if these were RTP session? >> >> I agree that this is a general problem, not just a problem for MSRP. >> But we have to start somewhere to deal with it. > > I agree we need to start somewhere--but if these problems are the same > that you would have for any connection-oriented media, then I am not > sure if the work belongs here. Why would we hold sdp use for msrp to a > higher standard than we do other uses? Because we see the problem first here. In some sense I think the problem is that with connection oriented transports there is more to go wrong than with those based on RTP. When things go wrong with RTP the applications are likely to go on in blissful ignorance, where a TCP stack will force the application to deal with the problem. This could have been encountered with comedia. But there has been much less interest, attention, and effort placed on it. In the case of MSRP we must produce something robust to be competitive. I see nothing wrong with figuring out the solution here and then applying it to other media later. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jan 7 11:48:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18367 for ; Wed, 7 Jan 2004 11:48:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGqm-0003y8-9q for simple-archive@odin.ietf.org; Wed, 07 Jan 2004 11:48:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07Gm8n1015252 for simple-archive@odin.ietf.org; Wed, 7 Jan 2004 11:48:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGqm-0003xv-56 for simple-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 11:48:08 -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 LAA18342 for ; Wed, 7 Jan 2004 11:48:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeGqk-0004vj-00 for simple-web-archive@ietf.org; Wed, 07 Jan 2004 11:48:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeGp8-0004sB-00 for simple-web-archive@ietf.org; Wed, 07 Jan 2004 11:46:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeGnv-0004m7-00; Wed, 07 Jan 2004 11:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGnn-0003oo-CX; Wed, 07 Jan 2004 11:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeGn3-0003n8-4u for simple@optimus.ietf.org; Wed, 07 Jan 2004 11:44:17 -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 LAA18152 for ; Wed, 7 Jan 2004 11:44:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeGn0-0004hQ-00 for simple@ietf.org; Wed, 07 Jan 2004 11:44:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeGlM-0004bj-00 for simple@ietf.org; Wed, 07 Jan 2004 11:42:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AeGjp-0004Rp-00 for simple@ietf.org; Wed, 07 Jan 2004 11:40:57 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i07GeNLE021241; Wed, 7 Jan 2004 11:40:24 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFB52400; Wed, 7 Jan 2004 11:40:23 -0500 (EST) Message-ID: <3FFC3676.1020909@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9C55F.1070601@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Jan 2004 11:40:22 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>>> As soon as there are multiple MSRP sessions the number of scenarios >>>> like this multiply. I think there must be some clear way for the >>>> endpoints to associate the new session with the old one. Note this >>>> is true whether lost messages are to be retransmitted or not. This >>>> affects the UI - does the old window, with its history of the >>>> conversation, get attached to the new session, or is a new window >>>> created? >>> >>> So, how would you deal with that if these were RTP session? >> >> I agree that this is a general problem, not just a problem for MSRP. >> But we have to start somewhere to deal with it. > > I agree we need to start somewhere--but if these problems are the same > that you would have for any connection-oriented media, then I am not > sure if the work belongs here. Why would we hold sdp use for msrp to a > higher standard than we do other uses? Because we see the problem first here. In some sense I think the problem is that with connection oriented transports there is more to go wrong than with those based on RTP. When things go wrong with RTP the applications are likely to go on in blissful ignorance, where a TCP stack will force the application to deal with the problem. This could have been encountered with comedia. But there has been much less interest, attention, and effort placed on it. In the case of MSRP we must produce something robust to be competitive. I see nothing wrong with figuring out the solution here and then applying it to other media later. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 7 17:10:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09161 for ; Wed, 7 Jan 2004 17:10:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLsR-0003sl-00 for simple-archive@ietf.org; Wed, 07 Jan 2004 17:10:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLqc-0003jw-00 for simple-archive@ietf.org; Wed, 07 Jan 2004 17:08:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeLoj-0003RG-00; Wed, 07 Jan 2004 17:06:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLoO-0004ec-Vn; Wed, 07 Jan 2004 17:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLoA-0004dk-FC for simple@optimus.ietf.org; Wed, 07 Jan 2004 17:05:46 -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 RAA08464 for ; Wed, 7 Jan 2004 17:05:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLo8-0003J3-00 for simple@ietf.org; Wed, 07 Jan 2004 17:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLkl-0002jA-00 for simple@ietf.org; Wed, 07 Jan 2004 17:02:15 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AeLha-0001uz-00 for simple@ietf.org; Wed, 07 Jan 2004 16:58:58 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i07LwdEP095865; Wed, 7 Jan 2004 15:58:46 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFC8107.6030805@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9C55F.1070601@dynamicsoft.com> <3FFC3676.1020909@cisco.com> In-Reply-To: <3FFC3676.1020909@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Jan 2004 15:58:31 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >>>>> As soon as there are multiple MSRP sessions the number of scenarios >>>>> like this multiply. I think there must be some clear way for the >>>>> endpoints to associate the new session with the old one. Note this >>>>> is true whether lost messages are to be retransmitted or not. This >>>>> affects the UI - does the old window, with its history of the >>>>> conversation, get attached to the new session, or is a new window >>>>> created? >>>> >>>> >>>> So, how would you deal with that if these were RTP session? >>> >>> >>> I agree that this is a general problem, not just a problem for MSRP. >>> But we have to start somewhere to deal with it. >> >> >> I agree we need to start somewhere--but if these problems are the same >> that you would have for any connection-oriented media, then I am not >> sure if the work belongs here. Why would we hold sdp use for msrp to a >> higher standard than we do other uses? > > > Because we see the problem first here. > > In some sense I think the problem is that with connection oriented > transports there is more to go wrong than with those based on RTP. When > things go wrong with RTP the applications are likely to go on in > blissful ignorance, where a TCP stack will force the application to deal > with the problem. > > This could have been encountered with comedia. But there has been much > less interest, attention, and effort placed on it. In the case of MSRP > we must produce something robust to be competitive. > > I see nothing wrong with figuring out the solution here and then > applying it to other media later. OK, I am convinced. I do think we will need to coordinate with the Comedia work at some point, but there is no problem developing our approach here. > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jan 7 17:10:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09262 for ; Wed, 7 Jan 2004 17:10:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLsV-0005Iy-5W for simple-archive@odin.ietf.org; Wed, 07 Jan 2004 17:10:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07MAFcU020388 for simple-archive@odin.ietf.org; Wed, 7 Jan 2004 17:10:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLsV-0005Il-19 for simple-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 17:10:15 -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 RAA09172 for ; Wed, 7 Jan 2004 17:10:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLsS-0003sz-00 for simple-web-archive@ietf.org; Wed, 07 Jan 2004 17:10:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLqd-0003k5-00 for simple-web-archive@ietf.org; Wed, 07 Jan 2004 17:08:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeLoj-0003RG-00; Wed, 07 Jan 2004 17:06:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLoO-0004ec-Vn; Wed, 07 Jan 2004 17:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLoA-0004dk-FC for simple@optimus.ietf.org; Wed, 07 Jan 2004 17:05:46 -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 RAA08464 for ; Wed, 7 Jan 2004 17:05:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeLo8-0003J3-00 for simple@ietf.org; Wed, 07 Jan 2004 17:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeLkl-0002jA-00 for simple@ietf.org; Wed, 07 Jan 2004 17:02:15 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AeLha-0001uz-00 for simple@ietf.org; Wed, 07 Jan 2004 16:58:58 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i07LwdEP095865; Wed, 7 Jan 2004 15:58:46 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFC8107.6030805@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9C55F.1070601@dynamicsoft.com> <3FFC3676.1020909@cisco.com> In-Reply-To: <3FFC3676.1020909@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Jan 2004 15:58:31 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >>>>> As soon as there are multiple MSRP sessions the number of scenarios >>>>> like this multiply. I think there must be some clear way for the >>>>> endpoints to associate the new session with the old one. Note this >>>>> is true whether lost messages are to be retransmitted or not. This >>>>> affects the UI - does the old window, with its history of the >>>>> conversation, get attached to the new session, or is a new window >>>>> created? >>>> >>>> >>>> So, how would you deal with that if these were RTP session? >>> >>> >>> I agree that this is a general problem, not just a problem for MSRP. >>> But we have to start somewhere to deal with it. >> >> >> I agree we need to start somewhere--but if these problems are the same >> that you would have for any connection-oriented media, then I am not >> sure if the work belongs here. Why would we hold sdp use for msrp to a >> higher standard than we do other uses? > > > Because we see the problem first here. > > In some sense I think the problem is that with connection oriented > transports there is more to go wrong than with those based on RTP. When > things go wrong with RTP the applications are likely to go on in > blissful ignorance, where a TCP stack will force the application to deal > with the problem. > > This could have been encountered with comedia. But there has been much > less interest, attention, and effort placed on it. In the case of MSRP > we must produce something robust to be competitive. > > I see nothing wrong with figuring out the solution here and then > applying it to other media later. OK, I am convinced. I do think we will need to coordinate with the Comedia work at some point, but there is no problem developing our approach here. > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 8 07:45:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20908 for ; Thu, 8 Jan 2004 07:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZXe-0007Zq-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 07:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZVX-0007IZ-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 07:43:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeZUM-00071c-00; Thu, 08 Jan 2004 07:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZUA-0004jH-9e; Thu, 08 Jan 2004 07:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZTG-0004ed-DX for simple@optimus.ietf.org; Thu, 08 Jan 2004 07:41:06 -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 HAA20181 for ; Thu, 8 Jan 2004 07:41:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZTF-0006qV-00 for simple@ietf.org; Thu, 08 Jan 2004 07:41:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZRG-0006UA-00 for simple@ietf.org; Thu, 08 Jan 2004 07:39:04 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly07a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AeZPf-0006CA-00 for simple@ietf.org; Thu, 08 Jan 2004 07:37:23 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07a.srv.mailcontrol.com (MailControl) with SMTP id i08CaNvX014209; Thu, 8 Jan 2004 12:36:23 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 8 Jan 2004 12:36:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D5E4.06B5FB2D" Message-ID: <45730E094814E44488F789C1CDED27AE0219B15B@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Review of draft-ietf-simple-pres-filter-reqs-02 Thread-Index: AcPV5AWX80yTV0BPR5+ZfiU+n8PG+w== From: "Chris Boulton" To: Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Subject: [Simple] Review of draft-ietf-simple-pres-filter-reqs-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Jan 2004 12:36:23 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C3D5E4.06B5FB2D Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hisham, =20 Had a review of the following draft: draft-ietf-simple-pres-filter-reqs-02. Looks pretty good to me ;-) Got a couple of observations that I wouldn't mind some clarification on. Not sure how much of it is useful. =20 =20 1) NIT - In the introduction the end of the fourth paragraph reads:- =20 However, the definition of filtering was considered out of scope was left as future work. =20 And could read:- =20 However, the definition of filtering was considered out of scope and was left as work to be completed in the future. =20 2) Section 3.2=20 Are the following 2 requirements really necessary:- =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity list whose presence information a certain filter is applied to. =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity sub-list whose presence information a certain filter is applied to. =20 Should the requirement just be that it can indicate a presentity. If that happens to be a list resource then so be it. =20 3) NIT - Section 3.3 The first paragraph reads:- =20 This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to the client. =20 Could read:- =20 This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to a watcher. =20 4) Section 3.3 Is the following requirement needed:- =20 REQ xx: The triggering conditions MUST be based on the presence information. For example, the change of value of the element. =20 Would it be better for a more generic approach for all event packages and just leave only the next requirement in to cover all triggers:- =20 REQ xx: It MUST be possible to specify logical expressions based on the value of elements defined in the package for the purpose of triggering. This covers expressions (tests) related to the change of an element's value, and reaching a certain value of an element. =20 5) Section 3.4 - Should the following requirements be made generic rather than being tied to presence:- =20 REQ xx: It MUST be possible for the watcher to specify the presence information elements (XML elements and/or attributes) in [2] to be delivered in the notification. =20 REQ xx: It MUST be possible for the watcher to specify presence information in any extension to PIDF to be delivered in the notifications, based on XML elements and/or attributes. See for example [3]. =20 REQ xx: It MUST be possible for the watcher to specify presence information in any extension to be delivered in the notifications, based on namespaces. =20 6) Section 4.2 - Do we need to specify a requirement for when a subscription containing a filter expires (invalid)? Does the filter remain or is it removed also? =20 7) Section 5.1 - The requirement reads:- =20 REQ xx: It MUST be possible for a watcher to specify different filter for any individual member of a resource list in a resource list subscription. =20 If a user does specify a different filter to that of a resource list - does this override - I would say 'yes' so perhaps this needs to be mentioned. =20 Hope some of this is useful, =20 Best Regards, =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C3D5E4.06B5FB2D Content-Type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hisham,<= o:p>

 

    =         Had a review of the following draft: draft-ietf-simple-pres-f= ilter-reqs-02.  Looks pretty good to me ;-) Got a couple of observations that I wouldn’t mind some clarification on.  Not = sure how much of it is useful.

 

 

1) NIT – In the introduction the end of the fourth paragraph reads:-

 

However, the definition of filtering was considered out = of scope was left as future work.

 

And could read:-

 

However, the definition of filtering was considered out = of scope and was left as work to be completed in the future.=

 

2) Section 3.2

Are the following 2 requirements really necessary:-=

 

REQ xx: It MUST be possible for the watcher to indicate,= in the

   filter criteria, the target prese= ntity list whose presence

   information a certain filter is applied to.=

 

   REQ= xx: It MUST be possible for the watcher to indicate, in the

   filter criteria, the target prese= ntity sub-list whose presence

   information a certain filter is applied to.=

 

Should the requirement just be that it can indicate a presentity.  If that happens to be a list resou= rce then so be it.

 

3) NIT – Section 3.3

The first paragraph reads:-

 

This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to the client= .

 

Could read:-

 

This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to a watcher.=

 

4) Section 3.3

Is the following requirement needed:-<= /font>

 

REQ xx: The triggering conditions MUST be based on the presence

   information. For example, the change of value of the <status>

   element.

 

Would it be better for a more generic approach for all e= vent packages and just leave only the next requirement in to cover all triggers:= -

 

REQ xx: It MUST be possible to specify logical expressio= ns based on

   the value of elements defined in the package for the p= urpose of

   triggering. This covers expressions (tests) related to= the change of

   an element's value, and reaching a certain value of an element.

 

5) Section 3.4 - Should the following requirements be ma= de generic rather than being tied to presence:-

 

 REQ xx: It= MUST be possible for the watcher to specify the presence

   information elements (XML elements and/or attributes) = in [2] to be

   delivered in the notification.

 

   REQ= xx: It MUST be possible for the watcher to specify presence

   information in any extension to PIDF to be delivered i= n the

   notifications, based on  XML elements and/or attributes. See for

   example [3].

 

   REQ= xx: It MUST be possible for the watcher to specify presence

   information in any extension to be delivered in the notifications,

   based on  namespaces.

 

6) Section 4.2 – Do we need to specify a requireme= nt for when a subscription containing a filter expires (invalid)?  Does the filter remain or is it re= moved also?

 

7) Section 5.1 – The requirement reads:-

 

REQ xx: It MUST be possible for a watcher to specify different filter

   for any individual member of a resource list in a reso= urce list

   subscription.

 

If a user does specify a different filter to that of a resource list – does this override – I would say ‘yesR= 17; so perhaps this needs to be mentioned.

 

Hope some of this is useful,

 

Best Regards,

 

Chris.

 

 

------------------------------------------------

<= font size=3D2 color=3Dred face=3DArial>Chris Boulton

Ubiquity Soft= ware

 

Tel : +44 (0) 1633765600

Fax : +44 (0) 1633765601

------------------------------------------------

 

 



This message ha= s been scanned for viruses by MailControl, a service from BlackSpider Technologies.

=00 ------_=_NextPart_001_01C3D5E4.06B5FB2D-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 8 07:46:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20933 for ; Thu, 8 Jan 2004 07:46:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZXg-00059A-6P for simple-archive@odin.ietf.org; Thu, 08 Jan 2004 07:45:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Cjew8019780 for simple-archive@odin.ietf.org; Thu, 8 Jan 2004 07:45:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZXf-00058s-LV for simple-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 07:45:39 -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 HAA20922 for ; Thu, 8 Jan 2004 07:45:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZXe-0007Zv-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 07:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZVZ-0007Ik-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 07:43:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeZUM-00071c-00; Thu, 08 Jan 2004 07:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZUA-0004jH-9e; Thu, 08 Jan 2004 07:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeZTG-0004ed-DX for simple@optimus.ietf.org; Thu, 08 Jan 2004 07:41:06 -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 HAA20181 for ; Thu, 8 Jan 2004 07:41:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeZTF-0006qV-00 for simple@ietf.org; Thu, 08 Jan 2004 07:41:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeZRG-0006UA-00 for simple@ietf.org; Thu, 08 Jan 2004 07:39:04 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly07a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AeZPf-0006CA-00 for simple@ietf.org; Thu, 08 Jan 2004 07:37:23 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly07a.srv.mailcontrol.com (MailControl) with SMTP id i08CaNvX014209; Thu, 8 Jan 2004 12:36:23 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 8 Jan 2004 12:36:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D5E4.06B5FB2D" Message-ID: <45730E094814E44488F789C1CDED27AE0219B15B@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Review of draft-ietf-simple-pres-filter-reqs-02 Thread-Index: AcPV5AWX80yTV0BPR5+ZfiU+n8PG+w== From: "Chris Boulton" To: Cc: X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Subject: [Simple] Review of draft-ietf-simple-pres-filter-reqs-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Jan 2004 12:36:23 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format... ------_=_NextPart_001_01C3D5E4.06B5FB2D Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hisham, =20 Had a review of the following draft: draft-ietf-simple-pres-filter-reqs-02. Looks pretty good to me ;-) Got a couple of observations that I wouldn't mind some clarification on. Not sure how much of it is useful. =20 =20 1) NIT - In the introduction the end of the fourth paragraph reads:- =20 However, the definition of filtering was considered out of scope was left as future work. =20 And could read:- =20 However, the definition of filtering was considered out of scope and was left as work to be completed in the future. =20 2) Section 3.2=20 Are the following 2 requirements really necessary:- =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity list whose presence information a certain filter is applied to. =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity sub-list whose presence information a certain filter is applied to. =20 Should the requirement just be that it can indicate a presentity. If that happens to be a list resource then so be it. =20 3) NIT - Section 3.3 The first paragraph reads:- =20 This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to the client. =20 Could read:- =20 This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to a watcher. =20 4) Section 3.3 Is the following requirement needed:- =20 REQ xx: The triggering conditions MUST be based on the presence information. For example, the change of value of the element. =20 Would it be better for a more generic approach for all event packages and just leave only the next requirement in to cover all triggers:- =20 REQ xx: It MUST be possible to specify logical expressions based on the value of elements defined in the package for the purpose of triggering. This covers expressions (tests) related to the change of an element's value, and reaching a certain value of an element. =20 5) Section 3.4 - Should the following requirements be made generic rather than being tied to presence:- =20 REQ xx: It MUST be possible for the watcher to specify the presence information elements (XML elements and/or attributes) in [2] to be delivered in the notification. =20 REQ xx: It MUST be possible for the watcher to specify presence information in any extension to PIDF to be delivered in the notifications, based on XML elements and/or attributes. See for example [3]. =20 REQ xx: It MUST be possible for the watcher to specify presence information in any extension to be delivered in the notifications, based on namespaces. =20 6) Section 4.2 - Do we need to specify a requirement for when a subscription containing a filter expires (invalid)? Does the filter remain or is it removed also? =20 7) Section 5.1 - The requirement reads:- =20 REQ xx: It MUST be possible for a watcher to specify different filter for any individual member of a resource list in a resource list subscription. =20 If a user does specify a different filter to that of a resource list - does this override - I would say 'yes' so perhaps this needs to be mentioned. =20 Hope some of this is useful, =20 Best Regards, =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 This message has been scanned for viruses by MailControl - www.mailcontrol.= com ------_=_NextPart_001_01C3D5E4.06B5FB2D Content-Type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hisham,<= o:p>

 

    =         Had a review of the following draft: draft-ietf-simple-pres-f= ilter-reqs-02.  Looks pretty good to me ;-) Got a couple of observations that I wouldn’t mind some clarification on.  Not = sure how much of it is useful.

 

 

1) NIT – In the introduction the end of the fourth paragraph reads:-

 

However, the definition of filtering was considered out = of scope was left as future work.

 

And could read:-

 

However, the definition of filtering was considered out = of scope and was left as work to be completed in the future.=

 

2) Section 3.2

Are the following 2 requirements really necessary:-=

 

REQ xx: It MUST be possible for the watcher to indicate,= in the

   filter criteria, the target prese= ntity list whose presence

   information a certain filter is applied to.=

 

   REQ= xx: It MUST be possible for the watcher to indicate, in the

   filter criteria, the target prese= ntity sub-list whose presence

   information a certain filter is applied to.=

 

Should the requirement just be that it can indicate a presentity.  If that happens to be a list resou= rce then so be it.

 

3) NIT – Section 3.3

The first paragraph reads:-

 

This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to the client= .

 

Could read:-

 

This chapter presents requirements for specifying the triggering conditions that result in notifications to be sent to a watcher.=

 

4) Section 3.3

Is the following requirement needed:-<= /font>

 

REQ xx: The triggering conditions MUST be based on the presence

   information. For example, the change of value of the <status>

   element.

 

Would it be better for a more generic approach for all e= vent packages and just leave only the next requirement in to cover all triggers:= -

 

REQ xx: It MUST be possible to specify logical expressio= ns based on

   the value of elements defined in the package for the p= urpose of

   triggering. This covers expressions (tests) related to= the change of

   an element's value, and reaching a certain value of an element.

 

5) Section 3.4 - Should the following requirements be ma= de generic rather than being tied to presence:-

 

 REQ xx: It= MUST be possible for the watcher to specify the presence

   information elements (XML elements and/or attributes) = in [2] to be

   delivered in the notification.

 

   REQ= xx: It MUST be possible for the watcher to specify presence

   information in any extension to PIDF to be delivered i= n the

   notifications, based on  XML elements and/or attributes. See for

   example [3].

 

   REQ= xx: It MUST be possible for the watcher to specify presence

   information in any extension to be delivered in the notifications,

   based on  namespaces.

 

6) Section 4.2 – Do we need to specify a requireme= nt for when a subscription containing a filter expires (invalid)?  Does the filter remain or is it re= moved also?

 

7) Section 5.1 – The requirement reads:-

 

REQ xx: It MUST be possible for a watcher to specify different filter

   for any individual member of a resource list in a reso= urce list

   subscription.

 

If a user does specify a different filter to that of a resource list – does this override – I would say ‘yesR= 17; so perhaps this needs to be mentioned.

 

Hope some of this is useful,

 

Best Regards,

 

Chris.

 

 

------------------------------------------------

<= font size=3D2 color=3Dred face=3DArial>Chris Boulton

Ubiquity Soft= ware

 

Tel : +44 (0) 1633765600

Fax : +44 (0) 1633765601

------------------------------------------------

 

 



This message ha= s been scanned for viruses by MailControl, a service from BlackSpider Technologies.

=00 ------_=_NextPart_001_01C3D5E4.06B5FB2D-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 8 09:37:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24276 for ; Thu, 8 Jan 2004 09:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebHP-0005cu-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 09:36:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebCE-0005Rp-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 09:31:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeb89-0005FO-00; Thu, 08 Jan 2004 09:27:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeb7m-0001oX-69; Thu, 08 Jan 2004 09:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeb7a-0001nv-Pa for simple@optimus.ietf.org; Thu, 08 Jan 2004 09:26:54 -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 JAA24079 for ; Thu, 8 Jan 2004 09:26:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeb7U-0005EY-00 for simple@ietf.org; Thu, 08 Jan 2004 09:26:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeb5B-00054e-00 for simple@ietf.org; Thu, 08 Jan 2004 09:24:22 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeazy-0004ns-00; Thu, 08 Jan 2004 09:18:58 -0500 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 i08EHpGN011084; Thu, 8 Jan 2004 06:17:52 -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 AFC21371; Thu, 8 Jan 2004 09:17:50 -0500 (EST) Message-ID: <3FFD668E.4030709@cisco.com> From: Paul Kyzivat 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: hisham.khartabil@nokia.com CC: paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 09:17:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hisham, I have an open mind about this right now. It seems to be a matter of picking your favorite poison, since neither alternative is ideal: - ensure that the ports used are unique even though they are ignored - change SDP - something that is not very popular. So far, aside from me there are two votes, one on each side. From the point of view of SIMPLE it is of course logistically simpler to leave SDP alone. Paul P.S. It seems that simple wasn't on the mailing list, so I have added it. hisham.khartabil@nokia.com wrote: > I would hate to see exceptions like these when building a generic SDP parser with built it checks for compliancy. > Why can't MSRP just follow that rule? > > Regards, > Hisham > > >>-----Original Message----- >>From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>ext Paul E. Jones >>Sent: 07.January.2004 23:15 >>To: Paul Kyzivat; Flemming Andreasen >>Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>mgarakan@cisco.com >>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >> >> >>Paul, >> >>While that sounds most unfortunate (I'd love to see an >>example if you have >>one), I think it would be exempt from this rule, because the >>port is just a >>dummy value. >> >>Paul >> >>----- Original Message ----- >>From: "Paul Kyzivat" >>To: "Flemming Andreasen" >>Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>; "Stephen Casner" ; "Colin >>Perkins" ; ; "Mostafa, Mohamed" >>; "Abdelhamid, Hisham" ; >>; >>Sent: Wednesday, January 07, 2004 4:12 PM >>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >> >> >> >>>I recently encountered an interesting case relevant to this >> >>while making >> >>>up an example for MSRP. >>> >>>In MSRP the port number is not used, except for the >> >>distinction between >> >>>a zero and non-zero value. There is a requirement that some random >>>non-zero value be inserted and then ignored. If there are >> >>multiple MSRP >> >>>media sessions in the same SDP body, must they have differing port >> >>numbers? >> >>>Paul >>> >>>Flemming Andreasen wrote: >>> >>>>"Kumar, Rajesh" wrote: >>>> >>>> >>>> >>>>>AVT members, >>>>> >>>>>There was some confusion on this issue in the recent TIA >>>> >>TR.30.1 meeting >> >>>>>in Orlando, Florida. >>>>> >>>>>Could someone officially confirm or deny whether multiple >>>> >>"m=" lines >> >>>>>with the SAME media type (e.g. "audio") and protocol >>>> >>(e.g. RTP/AVP) >> >>>>>cannot be assigned the same port number? >>>> >>>> >>>>The consensus of this discussion is that is that they >>> >>cannot (assuming >>they >> >>>>use the same IP address). >>>> >>>>-- Flemming >>>> >>>> >>>> >>>> >>>>>If they can be assigned the >>>>>same port number, then it is possible to selectively >>>> >>associate RFC 2733 >> >>>>>FEC with some payload types such as those that carry >>>> >>voice band data. >> >>>>>Otherwise, there is a hole in SDP that does not permit selective, >>>>>payload-specific declaration of FEC. I am aware of the >>>> >>fact that in RFC >> >>>>>2733 the use of and level of FEC is a transmitter >>>> >>prerogative and that a >> >>>>>transmitter may choose to selectively utilize FEC based >>>> >>on payload type >> >>>>>transmitted. >>>>> >>>>>Thanks, >>>>> >>>>>Rajesh >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>Sent: Friday, December 12, 2003 4:21 AM >>>>>>To: Kevin Boyle >>>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>> >>mmusic@ietf.org; >> >>>>>Mostafa, Mohamed; >>>>> >>>>> >>>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>> >>same port number >> >>>>>> >>>>>> >>>>>>Kevin Boyle wrote: >>>>>> >>>>>> >>>>>> >>>>>>>All, >>>>>>> >>>>>>>Looking back at this email stream, one question remains >>>>>> >>outstanding >> >>>>>in >>>>> >>>>> >>>>>>>my mind: >>>>>>> >>>>>>>What if the two m= lines have the SAME media type? For >>>>>> >>instance: >> >>>>>>>m=audio 49232 RTP/AVP 18 >>>>>>>m=image 49233 UDPTL t38 >>>>>>>m=audio 49232 RTP/AVP 100 >>>>>>>a=rtpmap:100 PCMU/8000 >>>>>>>a=gpmd:100 vbd=yes >>>>>>> >>>>>>>For some of the SDP-based protocols, the order of appearance is >>>>>> >>>>>vital >>>>> >>>>> >>>>>>>because it announces preference. >>>>>> >>>>>>Only for the media formats within a given "m=" line. >>>>> >>Multiple "m=" >> >>>>>lines >>>>> >>>>> >>>>>>indicates a set of simultaneous media streams; not alternatives. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>So, this shows preference for T.38 fax relay over PCMU >>>>>> >>VBD for fax, >> >>>>>>>while utilizing G.729 for voice. As far as I can tell, this >>>>>> >>>>>construct >>>>> >>>>> >>>>>>>is allowed, since both m lines using the same port number use a >>>>>> >>>>>media >>>>> >>>>> >>>>>>>type of audio. >>>>>>> >>>>>>>Is my understanding correct? >>>>>>> >>>>>> >>>>>>Not quite. Each "m=" line corresponds to a separate media stream. >>>>> >>>>>Also, >>>>> >>>>> >>>>>>the consensus of this discussion has been that you are >>>>> >>*not* allowed >> >>>>>to >>>>> >>>>> >>>>>>use the same port for different media lines, regardless >>>>> >>of whether >> >>>>>they >>>>> >>>>> >>>>>>share the same top-level MIME type or not. >>>>>> >>>>>>-- Flemming >>>>>> >>>>>> >>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Stephen Casner [mailto:casner@acm.org] >>>>>>>Sent: Friday, April 25, 2003 2:57 PM >>>>>>>To: Rajesh Kumar >>>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>paulej@cisco.com >>>>>>> >>>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>> >>port number >> >>>>>>>Rajesh, >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Is the use of multiple 'm=' lines with the same port >>>>>>> >>number within >> >>>>>>>an >>>>>>> >>>>>>> >>>>>>>>SDP descriptor permitted? >>>>>>> >>>>>>>Presuming that the multiple m= lines are all RTP/AVP, >>>>>> >>then doing so >> >>>>>>>causes all of the payload formats listed on the m= >>>>>> >>lines to become >> >>>>>>>part of a single RTP session (unless they are >>>>>> >>distinguished by some >> >>>>>>>other aspect of addressing). Section 5.2 of the RTP >>>>>> >>spec addresses >> >>>>>>>NOT multiplexing different media in the same RTP session. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>> >>>>>are >>>>> >>>>> >>>>>>>of >>>>>>> >>>>>>> >>>>>>>>the same media type (e.g. audio, image, text etc.). >>>>>>>> >>>>>>>>Now consider the case in which two RTP media formats can use a >>>>>>>>destination port but are registered under different MIME types. >>>>>>> >>>>>For >>>>> >>>>> >>>>>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>>>>> >>>>>>>recourse >>>>>>> >>>>>>> >>>>>>>>except to use multiple media lines with the same port >>>>>>> >>number. For >> >>>>>>>example: >>>>>>> >>>>>>>The "can use a destination port" is the tricky part. We may not >>>>>>>agree. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>m=audio 49232 RTP/AVP 0 >>>>>>>>m=text 49232 RTP/AVP 100 >>>>>>>>a=rtpmap:100 t140 >>>>>>>> >>>>>>>>My thought is that although this is unsual, it is not >>>>>>> >>proscribed >> >>>>>by >>>>> >>>>> >>>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>> >>>>>>>I believe this is proscribed by section 5.2 of the RTP >>>>>> >>spec because >> >>>>>>>these two media should not be multiplexed in one RTP session. >>>>>>> >>>>>>>My bet is that the real example you are thinking about is fax or >>>>>> >>>>>modem >>>>> >>>>> >>>>>>>over IP. We've been there before. >>>>>>> >>>>>>> -- Steve >>>>>>> >>>>>>>_______________________________________________ >>>>>>>mmusic mailing list >>>>>>>mmusic@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>> >>>>_______________________________________________ >>>>mmusic mailing list >>>>mmusic@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 8 09:37:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24345 for ; Thu, 8 Jan 2004 09:37:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebHm-0002HY-VR for simple-archive@odin.ietf.org; Thu, 08 Jan 2004 09:37:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08EbMXl008764 for simple-archive@odin.ietf.org; Thu, 8 Jan 2004 09:37:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebHm-0002HD-G2 for simple-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 09:37:22 -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 JAA24305 for ; Thu, 8 Jan 2004 09:37:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebHf-0005dD-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 09:37:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebCF-0005Rw-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 09:31:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeb89-0005FO-00; Thu, 08 Jan 2004 09:27:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeb7m-0001oX-69; Thu, 08 Jan 2004 09:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeb7a-0001nv-Pa for simple@optimus.ietf.org; Thu, 08 Jan 2004 09:26:54 -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 JAA24079 for ; Thu, 8 Jan 2004 09:26:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeb7U-0005EY-00 for simple@ietf.org; Thu, 08 Jan 2004 09:26:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeb5B-00054e-00 for simple@ietf.org; Thu, 08 Jan 2004 09:24:22 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeazy-0004ns-00; Thu, 08 Jan 2004 09:18:58 -0500 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 i08EHpGN011084; Thu, 8 Jan 2004 06:17:52 -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 AFC21371; Thu, 8 Jan 2004 09:17:50 -0500 (EST) Message-ID: <3FFD668E.4030709@cisco.com> From: Paul Kyzivat 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: hisham.khartabil@nokia.com CC: paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 09:17:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham, I have an open mind about this right now. It seems to be a matter of picking your favorite poison, since neither alternative is ideal: - ensure that the ports used are unique even though they are ignored - change SDP - something that is not very popular. So far, aside from me there are two votes, one on each side. From the point of view of SIMPLE it is of course logistically simpler to leave SDP alone. Paul P.S. It seems that simple wasn't on the mailing list, so I have added it. hisham.khartabil@nokia.com wrote: > I would hate to see exceptions like these when building a generic SDP parser with built it checks for compliancy. > Why can't MSRP just follow that rule? > > Regards, > Hisham > > >>-----Original Message----- >>From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>ext Paul E. Jones >>Sent: 07.January.2004 23:15 >>To: Paul Kyzivat; Flemming Andreasen >>Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>mgarakan@cisco.com >>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >> >> >>Paul, >> >>While that sounds most unfortunate (I'd love to see an >>example if you have >>one), I think it would be exempt from this rule, because the >>port is just a >>dummy value. >> >>Paul >> >>----- Original Message ----- >>From: "Paul Kyzivat" >>To: "Flemming Andreasen" >>Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>; "Stephen Casner" ; "Colin >>Perkins" ; ; "Mostafa, Mohamed" >>; "Abdelhamid, Hisham" ; >>; >>Sent: Wednesday, January 07, 2004 4:12 PM >>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >> >> >> >>>I recently encountered an interesting case relevant to this >> >>while making >> >>>up an example for MSRP. >>> >>>In MSRP the port number is not used, except for the >> >>distinction between >> >>>a zero and non-zero value. There is a requirement that some random >>>non-zero value be inserted and then ignored. If there are >> >>multiple MSRP >> >>>media sessions in the same SDP body, must they have differing port >> >>numbers? >> >>>Paul >>> >>>Flemming Andreasen wrote: >>> >>>>"Kumar, Rajesh" wrote: >>>> >>>> >>>> >>>>>AVT members, >>>>> >>>>>There was some confusion on this issue in the recent TIA >>>> >>TR.30.1 meeting >> >>>>>in Orlando, Florida. >>>>> >>>>>Could someone officially confirm or deny whether multiple >>>> >>"m=" lines >> >>>>>with the SAME media type (e.g. "audio") and protocol >>>> >>(e.g. RTP/AVP) >> >>>>>cannot be assigned the same port number? >>>> >>>> >>>>The consensus of this discussion is that is that they >>> >>cannot (assuming >>they >> >>>>use the same IP address). >>>> >>>>-- Flemming >>>> >>>> >>>> >>>> >>>>>If they can be assigned the >>>>>same port number, then it is possible to selectively >>>> >>associate RFC 2733 >> >>>>>FEC with some payload types such as those that carry >>>> >>voice band data. >> >>>>>Otherwise, there is a hole in SDP that does not permit selective, >>>>>payload-specific declaration of FEC. I am aware of the >>>> >>fact that in RFC >> >>>>>2733 the use of and level of FEC is a transmitter >>>> >>prerogative and that a >> >>>>>transmitter may choose to selectively utilize FEC based >>>> >>on payload type >> >>>>>transmitted. >>>>> >>>>>Thanks, >>>>> >>>>>Rajesh >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>Sent: Friday, December 12, 2003 4:21 AM >>>>>>To: Kevin Boyle >>>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>> >>mmusic@ietf.org; >> >>>>>Mostafa, Mohamed; >>>>> >>>>> >>>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>> >>same port number >> >>>>>> >>>>>> >>>>>>Kevin Boyle wrote: >>>>>> >>>>>> >>>>>> >>>>>>>All, >>>>>>> >>>>>>>Looking back at this email stream, one question remains >>>>>> >>outstanding >> >>>>>in >>>>> >>>>> >>>>>>>my mind: >>>>>>> >>>>>>>What if the two m= lines have the SAME media type? For >>>>>> >>instance: >> >>>>>>>m=audio 49232 RTP/AVP 18 >>>>>>>m=image 49233 UDPTL t38 >>>>>>>m=audio 49232 RTP/AVP 100 >>>>>>>a=rtpmap:100 PCMU/8000 >>>>>>>a=gpmd:100 vbd=yes >>>>>>> >>>>>>>For some of the SDP-based protocols, the order of appearance is >>>>>> >>>>>vital >>>>> >>>>> >>>>>>>because it announces preference. >>>>>> >>>>>>Only for the media formats within a given "m=" line. >>>>> >>Multiple "m=" >> >>>>>lines >>>>> >>>>> >>>>>>indicates a set of simultaneous media streams; not alternatives. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>So, this shows preference for T.38 fax relay over PCMU >>>>>> >>VBD for fax, >> >>>>>>>while utilizing G.729 for voice. As far as I can tell, this >>>>>> >>>>>construct >>>>> >>>>> >>>>>>>is allowed, since both m lines using the same port number use a >>>>>> >>>>>media >>>>> >>>>> >>>>>>>type of audio. >>>>>>> >>>>>>>Is my understanding correct? >>>>>>> >>>>>> >>>>>>Not quite. Each "m=" line corresponds to a separate media stream. >>>>> >>>>>Also, >>>>> >>>>> >>>>>>the consensus of this discussion has been that you are >>>>> >>*not* allowed >> >>>>>to >>>>> >>>>> >>>>>>use the same port for different media lines, regardless >>>>> >>of whether >> >>>>>they >>>>> >>>>> >>>>>>share the same top-level MIME type or not. >>>>>> >>>>>>-- Flemming >>>>>> >>>>>> >>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Stephen Casner [mailto:casner@acm.org] >>>>>>>Sent: Friday, April 25, 2003 2:57 PM >>>>>>>To: Rajesh Kumar >>>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>paulej@cisco.com >>>>>>> >>>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>> >>port number >> >>>>>>>Rajesh, >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Is the use of multiple 'm=' lines with the same port >>>>>>> >>number within >> >>>>>>>an >>>>>>> >>>>>>> >>>>>>>>SDP descriptor permitted? >>>>>>> >>>>>>>Presuming that the multiple m= lines are all RTP/AVP, >>>>>> >>then doing so >> >>>>>>>causes all of the payload formats listed on the m= >>>>>> >>lines to become >> >>>>>>>part of a single RTP session (unless they are >>>>>> >>distinguished by some >> >>>>>>>other aspect of addressing). Section 5.2 of the RTP >>>>>> >>spec addresses >> >>>>>>>NOT multiplexing different media in the same RTP session. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>> >>>>>are >>>>> >>>>> >>>>>>>of >>>>>>> >>>>>>> >>>>>>>>the same media type (e.g. audio, image, text etc.). >>>>>>>> >>>>>>>>Now consider the case in which two RTP media formats can use a >>>>>>>>destination port but are registered under different MIME types. >>>>>>> >>>>>For >>>>> >>>>> >>>>>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>>>>> >>>>>>>recourse >>>>>>> >>>>>>> >>>>>>>>except to use multiple media lines with the same port >>>>>>> >>number. For >> >>>>>>>example: >>>>>>> >>>>>>>The "can use a destination port" is the tricky part. We may not >>>>>>>agree. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>m=audio 49232 RTP/AVP 0 >>>>>>>>m=text 49232 RTP/AVP 100 >>>>>>>>a=rtpmap:100 t140 >>>>>>>> >>>>>>>>My thought is that although this is unsual, it is not >>>>>>> >>proscribed >> >>>>>by >>>>> >>>>> >>>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>> >>>>>>>I believe this is proscribed by section 5.2 of the RTP >>>>>> >>spec because >> >>>>>>>these two media should not be multiplexed in one RTP session. >>>>>>> >>>>>>>My bet is that the real example you are thinking about is fax or >>>>>> >>>>>modem >>>>> >>>>> >>>>>>>over IP. We've been there before. >>>>>>> >>>>>>> -- Steve >>>>>>> >>>>>>>_______________________________________________ >>>>>>>mmusic mailing list >>>>>>>mmusic@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>> >>>>_______________________________________________ >>>>mmusic mailing list >>>>mmusic@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 8 09:44:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24659 for ; Thu, 8 Jan 2004 09:44:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebOd-0006KZ-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 09:44:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebMk-00065G-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 09:42:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AebKk-0005nD-00; Thu, 08 Jan 2004 09:40:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebKO-0002a2-QW; Thu, 08 Jan 2004 09:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebJt-0002Yc-9z for simple@optimus.ietf.org; Thu, 08 Jan 2004 09:39:33 -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 JAA24398 for ; Thu, 8 Jan 2004 09:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebJm-0005kG-00 for simple@ietf.org; Thu, 08 Jan 2004 09:39:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebF7-0005Yk-00 for simple@ietf.org; Thu, 08 Jan 2004 09:34:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AebBg-0005L8-00; Thu, 08 Jan 2004 09:31:04 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2004 06:30:33 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i08ETvQu011300; Thu, 8 Jan 2004 06:29:57 -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 AFC22277; Thu, 8 Jan 2004 09:29:56 -0500 (EST) Message-ID: <3FFD6964.40108@cisco.com> From: Paul Kyzivat 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: "Paul E. Jones" CC: Flemming Andreasen , mmusic@ietf.org, simple@ietf.org References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> <3FDDC7F2.4B96D69@cisco.com> <3FFC763E.3080600@cisco.com> <009701c3d563$40457c00$7f01a8c0@cisco.com> <3FFC811D.7000900@cisco.com> <01bc01c3d5ad$ccc077d0$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 09:29:56 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Comments inline. Paul P.S. I have added simple to the list, and removed most of the individual names, since my last posting was sent to the chair for screening. Paul E. Jones wrote: > Paul, > > >>>While that sounds most unfortunate >> >>What is most unfortunate? >>- that MSRP ignores the port number from the m-line >>- that different dummy port numbers might have to be used >>- ??? > > > That there is a different dummy port number inserted. Why not require that > they be consistent or just remove the port number from URL and rely on the > SDP port number when SDP is used? Is the URL used outside of SDP? From > what I've gathered, the URL is temporary and only used for session > identification. > > However, doing that does open the question that started this discussion... > would it be a problem for multiple m= lines to have the same port number. > It might be that you have two message sessions between to devices that > advertised the same TCP port, but are uniquely identified by the session > URL. Then we potentially have an SDP violation, I guess. That is a very likely scenario. >>The reason it is ignored is that an a-line containing a URL is used, and >>specifies all the addressing needed. The alternative was assembling a >>URL from pieces of the m-line, c-line, and an a-line. There really is no >>nice answer. The SDP syntax works tolerably for RTP and UDP but presents >>problems for more complex transports. > > > So, I can agree with not necessarily wanting to assemble a URL from various > pieces of data here and there. I don't want to propose that you necessarily > change the URL, but keep the port number consistent. As you point out above, keeping the port number consistent between the url and the m-line could lead to a violation. And the concept of having to put the same information in two places isn't especially appealing anyway. > I'm definitely aware of the issues with SDP "growing" to accomodate things > other than RTP and such. However, I don't have a good feel for whether > people are truly interested in making a big changed to something like SDPng > or just evolving SDP. It seems like evolving SDP is winning favor, though > I'd like to hear opinions on that. In the case that we do evolve SDP for a > number of years, we should try to do it in as consistent a manner as > possible. Certainly nobody is going to wait for SDPng to be adopted before introducing something line MSRP. There has to be a way to use it with SDP. > Now, as for this port number issue. As the document is now written, the > ports are unique and there is no violation to speak of... just confused me > when I saw it. I'd personally rather insert an exception into SDP to allow > TCP session to have the same port number than to create bogus port numbers. > A change in the SDP text along those lines would not break the spirit of the > present text and should not break anything. I guess this would be up to MMUSIC to deal with. As I mentioned in my reply to Hisham, it is probably the case that the path of least resistance for MSRP is to live with the uniqueness requirement. In any case, the two approaches don't conflict. MSRP can simply state that while the port numbers are ignored they must still conform to the SDP standard. Then if SDP changes to permit duplicate ports in this case then we are all set. >> > (I'd love to see an example if you have one), >> >>I've attached a message from the SIMPLE list. Note that the SDP is not >>intended to be complete - just the key parts needed to make the point. > > > Thanks. I also just looked at draft-ietf-simple-message-sessions-02.txt > briefly. I'm certainly not an expert on this subject matter, but I've > learned a little :) > > >> > I think it would be exempt from this rule, because the port is just a >>>dummy value. >> >>That would be nice. It may be necessary to clarify that somewhere. > > You might have already hashed all of these issues through already and I do > apologize if that is the case. (But, when I get explicitly copied on > something, I tend to pay more attention than when mailing list dialog goes > passing by.) > > I would like to hear your comments on what I've suggested and asked above. > > Thanks, > Paul > > >>Paul >> >> >>>Paul >>> >>>----- Original Message ----- >>>From: "Paul Kyzivat" >>>To: "Flemming Andreasen" >>>Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>>; "Stephen Casner" ; "Colin >>>Perkins" ; ; "Mostafa, Mohamed" >>>; "Abdelhamid, Hisham" ; >>>; >>>Sent: Wednesday, January 07, 2004 4:12 PM >>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> >>> >>>>I recently encountered an interesting case relevant to this while making >>>>up an example for MSRP. >>>> >>>>In MSRP the port number is not used, except for the distinction between >>>>a zero and non-zero value. There is a requirement that some random >>>>non-zero value be inserted and then ignored. If there are multiple MSRP >>>>media sessions in the same SDP body, must they have differing port >>> >>>numbers? >>> >>> >>>>Paul >>>> >>>>Flemming Andreasen wrote: >>>> >>>> >>>>>"Kumar, Rajesh" wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>AVT members, >>>>>> >>>>>>There was some confusion on this issue in the recent TIA TR.30.1 >>>>> > meeting > >>>>>>in Orlando, Florida. >>>>>> >>>>>>Could someone officially confirm or deny whether multiple "m=" lines >>>>>>with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) >>>>>>cannot be assigned the same port number? >>>>> >>>>> >>>>>The consensus of this discussion is that is that they cannot (assuming >>>> >>>they >>> >>> >>>>>use the same IP address). >>>>> >>>>>-- Flemming >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>If they can be assigned the >>>>>>same port number, then it is possible to selectively associate RFC >>>>> > 2733 > >>>>>>FEC with some payload types such as those that carry voice band data. >>>>>>Otherwise, there is a hole in SDP that does not permit selective, >>>>>>payload-specific declaration of FEC. I am aware of the fact that in >>>>> > RFC > >>>>>>2733 the use of and level of FEC is a transmitter prerogative and that >>>>> > a > >>>>>>transmitter may choose to selectively utilize FEC based on payload >>>>> > type > >>>>>>transmitted. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Rajesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>>Sent: Friday, December 12, 2003 4:21 AM >>>>>>>To: Kevin Boyle >>>>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; >>>>>> >>>>>>Mostafa, Mohamed; >>>>>> >>>>>> >>>>>> >>>>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port >>>>>> > number > >>>>>>> >>>>>>> >>>>>>>Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>All, >>>>>>>> >>>>>>>>Looking back at this email stream, one question remains outstanding >>>>>>> >>>>>>in >>>>>> >>>>>> >>>>>> >>>>>>>>my mind: >>>>>>>> >>>>>>>>What if the two m= lines have the SAME media type? For instance: >>>>>>>> >>>>>>>>m=audio 49232 RTP/AVP 18 >>>>>>>>m=image 49233 UDPTL t38 >>>>>>>>m=audio 49232 RTP/AVP 100 >>>>>>>>a=rtpmap:100 PCMU/8000 >>>>>>>>a=gpmd:100 vbd=yes >>>>>>>> >>>>>>>>For some of the SDP-based protocols, the order of appearance is >>>>>>> >>>>>>vital >>>>>> >>>>>> >>>>>> >>>>>>>>because it announces preference. >>>>>>> >>>>>>>Only for the media formats within a given "m=" line. Multiple "m=" >>>>>> >>>>>>lines >>>>>> >>>>>> >>>>>> >>>>>>>indicates a set of simultaneous media streams; not alternatives. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>So, this shows preference for T.38 fax relay over PCMU VBD for fax, >>>>>>>>while utilizing G.729 for voice. As far as I can tell, this >>>>>>> >>>>>>construct >>>>>> >>>>>> >>>>>> >>>>>>>>is allowed, since both m lines using the same port number use a >>>>>>> >>>>>>media >>>>>> >>>>>> >>>>>> >>>>>>>>type of audio. >>>>>>>> >>>>>>>>Is my understanding correct? >>>>>>>> >>>>>>> >>>>>>>Not quite. Each "m=" line corresponds to a separate media stream. >>>>>> >>>>>>Also, >>>>>> >>>>>> >>>>>> >>>>>>>the consensus of this discussion has been that you are *not* allowed >>>>>> >>>>>>to >>>>>> >>>>>> >>>>>> >>>>>>>use the same port for different media lines, regardless of whether >>>>>> >>>>>>they >>>>>> >>>>>> >>>>>> >>>>>>>share the same top-level MIME type or not. >>>>>>> >>>>>>>-- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Thanks, >>>>>>>> >>>>>>>>Kevin >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Stephen Casner [mailto:casner@acm.org] >>>>>>>>Sent: Friday, April 25, 2003 2:57 PM >>>>>>>>To: Rajesh Kumar >>>>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>>paulej@cisco.com >>>>>>>> >>>>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>>>>>> >>>>>>>>Rajesh, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Is the use of multiple 'm=' lines with the same port number within >>>>>>>> >>>>>>>>an >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>SDP descriptor permitted? >>>>>>>> >>>>>>>>Presuming that the multiple m= lines are all RTP/AVP, then doing so >>>>>>>>causes all of the payload formats listed on the m= lines to become >>>>>>>>part of a single RTP session (unless they are distinguished by some >>>>>>>>other aspect of addressing). Section 5.2 of the RTP spec addresses >>>>>>>>NOT multiplexing different media in the same RTP session. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>> >>>>>>are >>>>>> >>>>>> >>>>>> >>>>>>>>of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>the same media type (e.g. audio, image, text etc.). >>>>>>>>> >>>>>>>>>Now consider the case in which two RTP media formats can use a >>>>>>>>>destination port but are registered under different MIME types. >>>>>>>> >>>>>>For >>>>>> >>>>>> >>>>>> >>>>>>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>> >>>>>>>>recourse >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>except to use multiple media lines with the same port number. For >>>>>>>> >>>>>>>>example: >>>>>>>> >>>>>>>>The "can use a destination port" is the tricky part. We may not >>>>>>>>agree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>m=audio 49232 RTP/AVP 0 >>>>>>>>>m=text 49232 RTP/AVP 100 >>>>>>>>>a=rtpmap:100 t140 >>>>>>>>> >>>>>>>>>My thought is that although this is unsual, it is not proscribed >>>>>>>> >>>>>>by >>>>>> >>>>>> >>>>>> >>>>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>> >>>>>>>>I believe this is proscribed by section 5.2 of the RTP spec because >>>>>>>>these two media should not be multiplexed in one RTP session. >>>>>>>> >>>>>>>>My bet is that the real example you are thinking about is fax or >>>>>>> >>>>>>modem >>>>>> >>>>>> >>>>>> >>>>>>>>over IP. We've been there before. >>>>>>>> >>>>>>>> -- Steve >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>mmusic mailing list >>>>>>>>mmusic@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>_______________________________________________ >>>>>mmusic mailing list >>>>>mmusic@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 8 09:44:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24736 for ; Thu, 8 Jan 2004 09:44:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebOi-000312-41 for simple-archive@odin.ietf.org; Thu, 08 Jan 2004 09:44:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08EiWw6011586 for simple-archive@odin.ietf.org; Thu, 8 Jan 2004 09:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebOh-00030n-Pz for simple-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 09:44:31 -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 JAA24664 for ; Thu, 8 Jan 2004 09:44:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebOe-0006Kg-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 09:44:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebMm-00065N-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 09:42:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AebKk-0005nD-00; Thu, 08 Jan 2004 09:40:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebKO-0002a2-QW; Thu, 08 Jan 2004 09:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AebJt-0002Yc-9z for simple@optimus.ietf.org; Thu, 08 Jan 2004 09:39:33 -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 JAA24398 for ; Thu, 8 Jan 2004 09:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AebJm-0005kG-00 for simple@ietf.org; Thu, 08 Jan 2004 09:39:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AebF7-0005Yk-00 for simple@ietf.org; Thu, 08 Jan 2004 09:34:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AebBg-0005L8-00; Thu, 08 Jan 2004 09:31:04 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2004 06:30:33 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id i08ETvQu011300; Thu, 8 Jan 2004 06:29:57 -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 AFC22277; Thu, 8 Jan 2004 09:29:56 -0500 (EST) Message-ID: <3FFD6964.40108@cisco.com> From: Paul Kyzivat 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: "Paul E. Jones" CC: Flemming Andreasen , mmusic@ietf.org, simple@ietf.org References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> <3FDDC7F2.4B96D69@cisco.com> <3FFC763E.3080600@cisco.com> <009701c3d563$40457c00$7f01a8c0@cisco.com> <3FFC811D.7000900@cisco.com> <01bc01c3d5ad$ccc077d0$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 09:29:56 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments inline. Paul P.S. I have added simple to the list, and removed most of the individual names, since my last posting was sent to the chair for screening. Paul E. Jones wrote: > Paul, > > >>>While that sounds most unfortunate >> >>What is most unfortunate? >>- that MSRP ignores the port number from the m-line >>- that different dummy port numbers might have to be used >>- ??? > > > That there is a different dummy port number inserted. Why not require that > they be consistent or just remove the port number from URL and rely on the > SDP port number when SDP is used? Is the URL used outside of SDP? From > what I've gathered, the URL is temporary and only used for session > identification. > > However, doing that does open the question that started this discussion... > would it be a problem for multiple m= lines to have the same port number. > It might be that you have two message sessions between to devices that > advertised the same TCP port, but are uniquely identified by the session > URL. Then we potentially have an SDP violation, I guess. That is a very likely scenario. >>The reason it is ignored is that an a-line containing a URL is used, and >>specifies all the addressing needed. The alternative was assembling a >>URL from pieces of the m-line, c-line, and an a-line. There really is no >>nice answer. The SDP syntax works tolerably for RTP and UDP but presents >>problems for more complex transports. > > > So, I can agree with not necessarily wanting to assemble a URL from various > pieces of data here and there. I don't want to propose that you necessarily > change the URL, but keep the port number consistent. As you point out above, keeping the port number consistent between the url and the m-line could lead to a violation. And the concept of having to put the same information in two places isn't especially appealing anyway. > I'm definitely aware of the issues with SDP "growing" to accomodate things > other than RTP and such. However, I don't have a good feel for whether > people are truly interested in making a big changed to something like SDPng > or just evolving SDP. It seems like evolving SDP is winning favor, though > I'd like to hear opinions on that. In the case that we do evolve SDP for a > number of years, we should try to do it in as consistent a manner as > possible. Certainly nobody is going to wait for SDPng to be adopted before introducing something line MSRP. There has to be a way to use it with SDP. > Now, as for this port number issue. As the document is now written, the > ports are unique and there is no violation to speak of... just confused me > when I saw it. I'd personally rather insert an exception into SDP to allow > TCP session to have the same port number than to create bogus port numbers. > A change in the SDP text along those lines would not break the spirit of the > present text and should not break anything. I guess this would be up to MMUSIC to deal with. As I mentioned in my reply to Hisham, it is probably the case that the path of least resistance for MSRP is to live with the uniqueness requirement. In any case, the two approaches don't conflict. MSRP can simply state that while the port numbers are ignored they must still conform to the SDP standard. Then if SDP changes to permit duplicate ports in this case then we are all set. >> > (I'd love to see an example if you have one), >> >>I've attached a message from the SIMPLE list. Note that the SDP is not >>intended to be complete - just the key parts needed to make the point. > > > Thanks. I also just looked at draft-ietf-simple-message-sessions-02.txt > briefly. I'm certainly not an expert on this subject matter, but I've > learned a little :) > > >> > I think it would be exempt from this rule, because the port is just a >>>dummy value. >> >>That would be nice. It may be necessary to clarify that somewhere. > > You might have already hashed all of these issues through already and I do > apologize if that is the case. (But, when I get explicitly copied on > something, I tend to pay more attention than when mailing list dialog goes > passing by.) > > I would like to hear your comments on what I've suggested and asked above. > > Thanks, > Paul > > >>Paul >> >> >>>Paul >>> >>>----- Original Message ----- >>>From: "Paul Kyzivat" >>>To: "Flemming Andreasen" >>>Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>>; "Stephen Casner" ; "Colin >>>Perkins" ; ; "Mostafa, Mohamed" >>>; "Abdelhamid, Hisham" ; >>>; >>>Sent: Wednesday, January 07, 2004 4:12 PM >>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> >>> >>>>I recently encountered an interesting case relevant to this while making >>>>up an example for MSRP. >>>> >>>>In MSRP the port number is not used, except for the distinction between >>>>a zero and non-zero value. There is a requirement that some random >>>>non-zero value be inserted and then ignored. If there are multiple MSRP >>>>media sessions in the same SDP body, must they have differing port >>> >>>numbers? >>> >>> >>>>Paul >>>> >>>>Flemming Andreasen wrote: >>>> >>>> >>>>>"Kumar, Rajesh" wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>AVT members, >>>>>> >>>>>>There was some confusion on this issue in the recent TIA TR.30.1 >>>>> > meeting > >>>>>>in Orlando, Florida. >>>>>> >>>>>>Could someone officially confirm or deny whether multiple "m=" lines >>>>>>with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) >>>>>>cannot be assigned the same port number? >>>>> >>>>> >>>>>The consensus of this discussion is that is that they cannot (assuming >>>> >>>they >>> >>> >>>>>use the same IP address). >>>>> >>>>>-- Flemming >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>If they can be assigned the >>>>>>same port number, then it is possible to selectively associate RFC >>>>> > 2733 > >>>>>>FEC with some payload types such as those that carry voice band data. >>>>>>Otherwise, there is a hole in SDP that does not permit selective, >>>>>>payload-specific declaration of FEC. I am aware of the fact that in >>>>> > RFC > >>>>>>2733 the use of and level of FEC is a transmitter prerogative and that >>>>> > a > >>>>>>transmitter may choose to selectively utilize FEC based on payload >>>>> > type > >>>>>>transmitted. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Rajesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>>Sent: Friday, December 12, 2003 4:21 AM >>>>>>>To: Kevin Boyle >>>>>>>Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; >>>>>> >>>>>>Mostafa, Mohamed; >>>>>> >>>>>> >>>>>> >>>>>>>Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>>Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port >>>>>> > number > >>>>>>> >>>>>>> >>>>>>>Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>All, >>>>>>>> >>>>>>>>Looking back at this email stream, one question remains outstanding >>>>>>> >>>>>>in >>>>>> >>>>>> >>>>>> >>>>>>>>my mind: >>>>>>>> >>>>>>>>What if the two m= lines have the SAME media type? For instance: >>>>>>>> >>>>>>>>m=audio 49232 RTP/AVP 18 >>>>>>>>m=image 49233 UDPTL t38 >>>>>>>>m=audio 49232 RTP/AVP 100 >>>>>>>>a=rtpmap:100 PCMU/8000 >>>>>>>>a=gpmd:100 vbd=yes >>>>>>>> >>>>>>>>For some of the SDP-based protocols, the order of appearance is >>>>>>> >>>>>>vital >>>>>> >>>>>> >>>>>> >>>>>>>>because it announces preference. >>>>>>> >>>>>>>Only for the media formats within a given "m=" line. Multiple "m=" >>>>>> >>>>>>lines >>>>>> >>>>>> >>>>>> >>>>>>>indicates a set of simultaneous media streams; not alternatives. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>So, this shows preference for T.38 fax relay over PCMU VBD for fax, >>>>>>>>while utilizing G.729 for voice. As far as I can tell, this >>>>>>> >>>>>>construct >>>>>> >>>>>> >>>>>> >>>>>>>>is allowed, since both m lines using the same port number use a >>>>>>> >>>>>>media >>>>>> >>>>>> >>>>>> >>>>>>>>type of audio. >>>>>>>> >>>>>>>>Is my understanding correct? >>>>>>>> >>>>>>> >>>>>>>Not quite. Each "m=" line corresponds to a separate media stream. >>>>>> >>>>>>Also, >>>>>> >>>>>> >>>>>> >>>>>>>the consensus of this discussion has been that you are *not* allowed >>>>>> >>>>>>to >>>>>> >>>>>> >>>>>> >>>>>>>use the same port for different media lines, regardless of whether >>>>>> >>>>>>they >>>>>> >>>>>> >>>>>> >>>>>>>share the same top-level MIME type or not. >>>>>>> >>>>>>>-- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Thanks, >>>>>>>> >>>>>>>>Kevin >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Stephen Casner [mailto:casner@acm.org] >>>>>>>>Sent: Friday, April 25, 2003 2:57 PM >>>>>>>>To: Rajesh Kumar >>>>>>>>Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>>mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>>paulej@cisco.com >>>>>>>> >>>>>>>>Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>>>>>> >>>>>>>>Rajesh, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Is the use of multiple 'm=' lines with the same port number within >>>>>>>> >>>>>>>>an >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>SDP descriptor permitted? >>>>>>>> >>>>>>>>Presuming that the multiple m= lines are all RTP/AVP, then doing so >>>>>>>>causes all of the payload formats listed on the m= lines to become >>>>>>>>part of a single RTP session (unless they are distinguished by some >>>>>>>>other aspect of addressing). Section 5.2 of the RTP spec addresses >>>>>>>>NOT multiplexing different media in the same RTP session. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>> >>>>>>are >>>>>> >>>>>> >>>>>> >>>>>>>>of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>the same media type (e.g. audio, image, text etc.). >>>>>>>>> >>>>>>>>>Now consider the case in which two RTP media formats can use a >>>>>>>>>destination port but are registered under different MIME types. >>>>>>>> >>>>>>For >>>>>> >>>>>> >>>>>> >>>>>>>>>example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>> >>>>>>>>recourse >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>except to use multiple media lines with the same port number. For >>>>>>>> >>>>>>>>example: >>>>>>>> >>>>>>>>The "can use a destination port" is the tricky part. We may not >>>>>>>>agree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>m=audio 49232 RTP/AVP 0 >>>>>>>>>m=text 49232 RTP/AVP 100 >>>>>>>>>a=rtpmap:100 t140 >>>>>>>>> >>>>>>>>>My thought is that although this is unsual, it is not proscribed >>>>>>>> >>>>>>by >>>>>> >>>>>> >>>>>> >>>>>>>>>SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>> >>>>>>>>I believe this is proscribed by section 5.2 of the RTP spec because >>>>>>>>these two media should not be multiplexed in one RTP session. >>>>>>>> >>>>>>>>My bet is that the real example you are thinking about is fax or >>>>>>> >>>>>>modem >>>>>> >>>>>> >>>>>> >>>>>>>>over IP. We've been there before. >>>>>>>> >>>>>>>> -- Steve >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>mmusic mailing list >>>>>>>>mmusic@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>_______________________________________________ >>>>>mmusic mailing list >>>>>mmusic@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 8 14:30:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07206 for ; Thu, 8 Jan 2004 14:30:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AefrW-00018C-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 14:30:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aefpo-00013e-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 14:28:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aefo8-0000xT-00; Thu, 08 Jan 2004 14:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aefo5-0000rj-5a; Thu, 08 Jan 2004 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aefni-0000pz-Im for simple@optimus.ietf.org; Thu, 08 Jan 2004 14:26:38 -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 OAA07021 for ; Thu, 8 Jan 2004 14:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aefng-0000tM-00 for simple@ietf.org; Thu, 08 Jan 2004 14:26:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeflt-0000nr-00 for simple@ietf.org; Thu, 08 Jan 2004 14:24:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AeflI-0000im-00 for simple@ietf.org; Thu, 08 Jan 2004 14:24:08 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i08JNjgW000755; Thu, 8 Jan 2004 13:23:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFDAE3D.1080205@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG References: <3FB94605.6020501@dynamicsoft.com> In-Reply-To: <3FB94605.6020501@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Open Issues Revisited Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 13:23:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I sent this out back in November. We have had good discussion on some, but not all. I have added status comments for each item. It is entirely possible (and even likely) that I have miremembered some point, so please feel free to correct. Ben Campbell wrote: > Here is the list of significant issues and to-do's from the IETF58 > meeting. At least, it is the list that I am aware of. Please send me > anything I may have missed. (Numbers are for naming purposes, and do not > indicate priority--with the exception of 1, of course. 3 Also seems high > priority due to the number of items that depend on it) > > I plan to have a new rev of the base spec out before the end of > December. That rev will include the removal of relays, and the other > issues that we have closure on. Items that require more discussion will > depend on the status of the discussion. > > ------------------------------------------------- > 1. Remove relays from the base spec. (Saving relay text for relay > specific work, of course...) Does this mean that we have to rename the > protocol? Will be handled in an update I will send out in a day or two. > > 2. Remove text suggesting re-sending failed messages on the same > connection. Instead, we should close the connection and re-connect. (See > item 3...) I think we have closed on this. Will be reflected in aformentioned revision. > > 3. Close on handling of broken TCP connection. We discussed in the > meeting that we should be able to reconnect without having to re-signal. > (I remember now that we had discussed this before, and had a good reason > at that time _not_ to do this--I will attempt to further remember the > details so we can decide what currently makes sense.) > I think we have closed on this. Connections cannot be re-established without a new sdp exchange. Will be reflected in aformentioned revision. > 3.5 Determine if we need explicity un-visit (interacts with 3.) I think this is still open. However, with the conclusions on 3, I am leaning towards saying we do not need it. > > 4. Do we need a cross-connection duplicate suggestion mechanism? I think > we said yes, if the new connection is part of the same session as the > old. (Needs further list discussion as it interacts with 3...) > I think we have agreement we need it, but not necessarily on how it works. This will be an open issue in the aformentioned revision. > 5. Generalize MIME handling to include mime version and allow arbitrary > MIME headers. We have agreement to do this. It will probably not be complete in forthcoming version, but will come soon after. > > 6. Add text specifying use of sdp send-only attributes to identify > sessions intended for one-way delivery of large content. Done in aformentioned revision. > > 7. Close on keep-alive handling--needs more list discussion. In > particular, do keep-alives need to be bi-directional? > More discussion needed. It is not clear to me that we need this at all without relays. Can we push this entirely into the relay solution? > 8. Add more verbiage in security considerations, particularly > considering TLS certificate usage, self-signed certificates, and > interactions between TLS and digest authentication. (Cullen volunteered > to send text on TLS cert usage.) (This also interacts with 3.) > Waiting for promised text. > 9. A number of nits and editorial fixes. > Most will be traded in for new and novel nits in the forthcoming revision. Also, Hisham added the following item: 10. We need normative text about how to construct a second SDP offer/answer exchange. We have had lots of discussion on this, and have converged on most of it. We realized we had a problem where there is no good way for the active party to indicate whether an MSRP stream should be reconnected when sending a new SDP offer. Paul proposed adding a version attribute a-line, which seems like it would solve the problem. However, it is different than the current COMEDIA proposal for the same problem (a "reconnect" a-line attribute.) The upcoming revision will capture this discussion, but there will have an open issue on the version vs. reconnect attribute. I personally lean towards Paul's proposal, but I want to make sure everyone thinks through the fact that MSRP and COMEDIA may take different approaches to solve the same problem. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 8 14:31:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07244 for ; Thu, 8 Jan 2004 14:31:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aefra-000108-9F for simple-archive@odin.ietf.org; Thu, 08 Jan 2004 14:30:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08JUcGW003848 for simple-archive@odin.ietf.org; Thu, 8 Jan 2004 14:30:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aefra-0000zz-4B for simple-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:30:38 -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 OAA07209 for ; Thu, 8 Jan 2004 14:30:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AefrX-00018H-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 14:30:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aefpp-00013l-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 14:28:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aefo8-0000xT-00; Thu, 08 Jan 2004 14:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aefo5-0000rj-5a; Thu, 08 Jan 2004 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aefni-0000pz-Im for simple@optimus.ietf.org; Thu, 08 Jan 2004 14:26:38 -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 OAA07021 for ; Thu, 8 Jan 2004 14:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aefng-0000tM-00 for simple@ietf.org; Thu, 08 Jan 2004 14:26:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeflt-0000nr-00 for simple@ietf.org; Thu, 08 Jan 2004 14:24:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AeflI-0000im-00 for simple@ietf.org; Thu, 08 Jan 2004 14:24:08 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i08JNjgW000755; Thu, 8 Jan 2004 13:23:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFDAE3D.1080205@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG References: <3FB94605.6020501@dynamicsoft.com> In-Reply-To: <3FB94605.6020501@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Open Issues Revisited Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 13:23:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I sent this out back in November. We have had good discussion on some, but not all. I have added status comments for each item. It is entirely possible (and even likely) that I have miremembered some point, so please feel free to correct. Ben Campbell wrote: > Here is the list of significant issues and to-do's from the IETF58 > meeting. At least, it is the list that I am aware of. Please send me > anything I may have missed. (Numbers are for naming purposes, and do not > indicate priority--with the exception of 1, of course. 3 Also seems high > priority due to the number of items that depend on it) > > I plan to have a new rev of the base spec out before the end of > December. That rev will include the removal of relays, and the other > issues that we have closure on. Items that require more discussion will > depend on the status of the discussion. > > ------------------------------------------------- > 1. Remove relays from the base spec. (Saving relay text for relay > specific work, of course...) Does this mean that we have to rename the > protocol? Will be handled in an update I will send out in a day or two. > > 2. Remove text suggesting re-sending failed messages on the same > connection. Instead, we should close the connection and re-connect. (See > item 3...) I think we have closed on this. Will be reflected in aformentioned revision. > > 3. Close on handling of broken TCP connection. We discussed in the > meeting that we should be able to reconnect without having to re-signal. > (I remember now that we had discussed this before, and had a good reason > at that time _not_ to do this--I will attempt to further remember the > details so we can decide what currently makes sense.) > I think we have closed on this. Connections cannot be re-established without a new sdp exchange. Will be reflected in aformentioned revision. > 3.5 Determine if we need explicity un-visit (interacts with 3.) I think this is still open. However, with the conclusions on 3, I am leaning towards saying we do not need it. > > 4. Do we need a cross-connection duplicate suggestion mechanism? I think > we said yes, if the new connection is part of the same session as the > old. (Needs further list discussion as it interacts with 3...) > I think we have agreement we need it, but not necessarily on how it works. This will be an open issue in the aformentioned revision. > 5. Generalize MIME handling to include mime version and allow arbitrary > MIME headers. We have agreement to do this. It will probably not be complete in forthcoming version, but will come soon after. > > 6. Add text specifying use of sdp send-only attributes to identify > sessions intended for one-way delivery of large content. Done in aformentioned revision. > > 7. Close on keep-alive handling--needs more list discussion. In > particular, do keep-alives need to be bi-directional? > More discussion needed. It is not clear to me that we need this at all without relays. Can we push this entirely into the relay solution? > 8. Add more verbiage in security considerations, particularly > considering TLS certificate usage, self-signed certificates, and > interactions between TLS and digest authentication. (Cullen volunteered > to send text on TLS cert usage.) (This also interacts with 3.) > Waiting for promised text. > 9. A number of nits and editorial fixes. > Most will be traded in for new and novel nits in the forthcoming revision. Also, Hisham added the following item: 10. We need normative text about how to construct a second SDP offer/answer exchange. We have had lots of discussion on this, and have converged on most of it. We realized we had a problem where there is no good way for the active party to indicate whether an MSRP stream should be reconnected when sending a new SDP offer. Paul proposed adding a version attribute a-line, which seems like it would solve the problem. However, it is different than the current COMEDIA proposal for the same problem (a "reconnect" a-line attribute.) The upcoming revision will capture this discussion, but there will have an open issue on the version vs. reconnect attribute. I personally lean towards Paul's proposal, but I want to make sure everyone thinks through the fact that MSRP and COMEDIA may take different approaches to solve the same problem. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 8 15:00:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08387 for ; Thu, 8 Jan 2004 15:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegKV-0002aF-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 15:00:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegIf-0002WP-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 14:58:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AegHE-0002SN-00; Thu, 08 Jan 2004 14:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegH7-00032K-F7; Thu, 08 Jan 2004 14:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegGk-00030z-TN for simple@optimus.ietf.org; Thu, 08 Jan 2004 14:56:38 -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 OAA08213 for ; Thu, 8 Jan 2004 14:56:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegGi-0002Px-00 for simple@ietf.org; Thu, 08 Jan 2004 14:56:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegEo-0002Lt-00 for simple@ietf.org; Thu, 08 Jan 2004 14:54:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AegD1-0002E7-00 for simple@ietf.org; Thu, 08 Jan 2004 14:52:47 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08JqDLE017158; Thu, 8 Jan 2004 14:52:13 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFC55204; Thu, 8 Jan 2004 14:52:12 -0500 (EST) Message-ID: <3FFDB4EC.1060507@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP Open Issues Revisited References: <3FB94605.6020501@dynamicsoft.com> <3FFDAE3D.1080205@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 14:52:12 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sounds good. One comment below. Paul Ben Campbell wrote: > >> 7. Close on keep-alive handling--needs more list discussion. In >> particular, do keep-alives need to be bi-directional? >> > > More discussion needed. It is not clear to me that we need this at all > without relays. Can we push this entirely into the relay solution? I agree that without relays keep alives probably aren't needed. (If you get a hankering to know if the other end is still paying attention you can send an empty message, but no protocol machinery is needed for that.) But clearly the way we were going keep alives were needed when relays were present. When we add relays later, we will either be faced with having to change the endpoints to send keepalives or else we will have to find a different solution that doesn't require them. So, it seems likely that the addition of relays will impact all prior implementations. That is a downside to partitioning the work this way. But maybe it is still worth it. >> 8. Add more verbiage in security considerations, particularly >> considering TLS certificate usage, self-signed certificates, and >> interactions between TLS and digest authentication. (Cullen >> volunteered to send text on TLS cert usage.) (This also interacts with >> 3.) >> > > Waiting for promised text. > >> 9. A number of nits and editorial fixes. >> > > Most will be traded in for new and novel nits in the forthcoming revision. > > Also, Hisham added the following item: > > 10. We need normative text about how to construct a second SDP > offer/answer exchange. > > We have had lots of discussion on this, and have converged on most of > it. We realized we had a problem where there is no good way for the > active party to indicate whether an MSRP stream should be reconnected > when sending a new SDP offer. Paul proposed adding a version attribute > a-line, which seems like it would solve the problem. However, it is > different than the current COMEDIA proposal for the same problem (a > "reconnect" a-line attribute.) > > The upcoming revision will capture this discussion, but there will have > an open issue on the version vs. reconnect attribute. I personally lean > towards Paul's proposal, but I want to make sure everyone thinks through > the fact that MSRP and COMEDIA may take different approaches to solve > the same problem. > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 8 15:01:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08422 for ; Thu, 8 Jan 2004 15:01:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegKY-0003BP-JS for simple-archive@odin.ietf.org; Thu, 08 Jan 2004 15:00:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08K0Y2I012235 for simple-archive@odin.ietf.org; Thu, 8 Jan 2004 15:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegKY-0003BG-FG for simple-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 15:00:34 -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 PAA08391 for ; Thu, 8 Jan 2004 15:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegKV-0002aK-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 15:00:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegIg-0002WW-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 14:58:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AegHE-0002SN-00; Thu, 08 Jan 2004 14:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegH7-00032K-F7; Thu, 08 Jan 2004 14:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegGk-00030z-TN for simple@optimus.ietf.org; Thu, 08 Jan 2004 14:56:38 -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 OAA08213 for ; Thu, 8 Jan 2004 14:56:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegGi-0002Px-00 for simple@ietf.org; Thu, 08 Jan 2004 14:56:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegEo-0002Lt-00 for simple@ietf.org; Thu, 08 Jan 2004 14:54:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AegD1-0002E7-00 for simple@ietf.org; Thu, 08 Jan 2004 14:52:47 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08JqDLE017158; Thu, 8 Jan 2004 14:52:13 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFC55204; Thu, 8 Jan 2004 14:52:12 -0500 (EST) Message-ID: <3FFDB4EC.1060507@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP Open Issues Revisited References: <3FB94605.6020501@dynamicsoft.com> <3FFDAE3D.1080205@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 14:52:12 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sounds good. One comment below. Paul Ben Campbell wrote: > >> 7. Close on keep-alive handling--needs more list discussion. In >> particular, do keep-alives need to be bi-directional? >> > > More discussion needed. It is not clear to me that we need this at all > without relays. Can we push this entirely into the relay solution? I agree that without relays keep alives probably aren't needed. (If you get a hankering to know if the other end is still paying attention you can send an empty message, but no protocol machinery is needed for that.) But clearly the way we were going keep alives were needed when relays were present. When we add relays later, we will either be faced with having to change the endpoints to send keepalives or else we will have to find a different solution that doesn't require them. So, it seems likely that the addition of relays will impact all prior implementations. That is a downside to partitioning the work this way. But maybe it is still worth it. >> 8. Add more verbiage in security considerations, particularly >> considering TLS certificate usage, self-signed certificates, and >> interactions between TLS and digest authentication. (Cullen >> volunteered to send text on TLS cert usage.) (This also interacts with >> 3.) >> > > Waiting for promised text. > >> 9. A number of nits and editorial fixes. >> > > Most will be traded in for new and novel nits in the forthcoming revision. > > Also, Hisham added the following item: > > 10. We need normative text about how to construct a second SDP > offer/answer exchange. > > We have had lots of discussion on this, and have converged on most of > it. We realized we had a problem where there is no good way for the > active party to indicate whether an MSRP stream should be reconnected > when sending a new SDP offer. Paul proposed adding a version attribute > a-line, which seems like it would solve the problem. However, it is > different than the current COMEDIA proposal for the same problem (a > "reconnect" a-line attribute.) > > The upcoming revision will capture this discussion, but there will have > an open issue on the version vs. reconnect attribute. I personally lean > towards Paul's proposal, but I want to make sure everyone thinks through > the fact that MSRP and COMEDIA may take different approaches to solve > the same problem. > > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 8 15:10:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09179 for ; Thu, 8 Jan 2004 15:10:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegUM-0002yj-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 15:10:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegSP-0002ti-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 15:08:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AegQo-0002pb-00; Thu, 08 Jan 2004 15:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegQm-0003IG-Qw; Thu, 08 Jan 2004 15:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegQM-0003Hj-Ua for simple@optimus.ietf.org; Thu, 08 Jan 2004 15:06:34 -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 PAA08808 for ; Thu, 8 Jan 2004 15:06:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegQJ-0002nP-00 for simple@ietf.org; Thu, 08 Jan 2004 15:06:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegOP-0002jB-00 for simple@ietf.org; Thu, 08 Jan 2004 15:04:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AegO4-0002gN-00 for simple@ietf.org; Thu, 08 Jan 2004 15:04:12 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i08K47gW004301; Thu, 8 Jan 2004 14:04:08 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFDB7B3.5010501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Simple WG Subject: Re: [Simple] MSRP Open Issues Revisited References: <3FB94605.6020501@dynamicsoft.com> <3FFDAE3D.1080205@dynamicsoft.com> <3FFDB4EC.1060507@cisco.com> In-Reply-To: <3FFDB4EC.1060507@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 14:04:03 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Sounds good. One comment below. > > Paul > > Ben Campbell wrote: > >> >>> 7. Close on keep-alive handling--needs more list discussion. In >>> particular, do keep-alives need to be bi-directional? >>> >> >> More discussion needed. It is not clear to me that we need this at all >> without relays. Can we push this entirely into the relay solution? > > > I agree that without relays keep alives probably aren't needed. > (If you get a hankering to know if the other end is still paying > attention you can send an empty message, but no protocol machinery is > needed for that.) > > But clearly the way we were going keep alives were needed when relays > were present. When we add relays later, we will either be faced with > having to change the endpoints to send keepalives or else we will have > to find a different solution that doesn't require them. > > So, it seems likely that the addition of relays will impact all prior > implementations. That is a downside to partitioning the work this way. > But maybe it is still worth it. We had a fairly long discussion about a different topic where we discussed that relays will be an extension, and endpoints will have to know about the extension to use it. Do you see this case as different? > >>> 8. Add more verbiage in security considerations, particularly >>> considering TLS certificate usage, self-signed certificates, and >>> interactions between TLS and digest authentication. (Cullen >>> volunteered to send text on TLS cert usage.) (This also interacts >>> with 3.) >>> >> >> Waiting for promised text. >> >>> 9. A number of nits and editorial fixes. >>> >> >> Most will be traded in for new and novel nits in the forthcoming >> revision. >> >> Also, Hisham added the following item: >> >> 10. We need normative text about how to construct a second SDP >> offer/answer exchange. >> >> We have had lots of discussion on this, and have converged on most of >> it. We realized we had a problem where there is no good way for the >> active party to indicate whether an MSRP stream should be reconnected >> when sending a new SDP offer. Paul proposed adding a version attribute >> a-line, which seems like it would solve the problem. However, it is >> different than the current COMEDIA proposal for the same problem (a >> "reconnect" a-line attribute.) >> >> The upcoming revision will capture this discussion, but there will >> have an open issue on the version vs. reconnect attribute. I >> personally lean towards Paul's proposal, but I want to make sure >> everyone thinks through the fact that MSRP and COMEDIA may take >> different approaches to solve the same problem. >> >> >> >> >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 8 15:11:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09268 for ; Thu, 8 Jan 2004 15:11:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegUR-0003ql-2y for simple-archive@odin.ietf.org; Thu, 08 Jan 2004 15:10:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08KAlqE014798 for simple-archive@odin.ietf.org; Thu, 8 Jan 2004 15:10:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegUQ-0003qb-Ta for simple-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 15:10:46 -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 PAA09200 for ; Thu, 8 Jan 2004 15:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegUN-0002yp-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 15:10:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegSP-0002tp-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 15:08:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AegQo-0002pb-00; Thu, 08 Jan 2004 15:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegQm-0003IG-Qw; Thu, 08 Jan 2004 15:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegQM-0003Hj-Ua for simple@optimus.ietf.org; Thu, 08 Jan 2004 15:06:34 -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 PAA08808 for ; Thu, 8 Jan 2004 15:06:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegQJ-0002nP-00 for simple@ietf.org; Thu, 08 Jan 2004 15:06:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegOP-0002jB-00 for simple@ietf.org; Thu, 08 Jan 2004 15:04:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AegO4-0002gN-00 for simple@ietf.org; Thu, 08 Jan 2004 15:04:12 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i08K47gW004301; Thu, 8 Jan 2004 14:04:08 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FFDB7B3.5010501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Simple WG Subject: Re: [Simple] MSRP Open Issues Revisited References: <3FB94605.6020501@dynamicsoft.com> <3FFDAE3D.1080205@dynamicsoft.com> <3FFDB4EC.1060507@cisco.com> In-Reply-To: <3FFDB4EC.1060507@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 14:04:03 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Sounds good. One comment below. > > Paul > > Ben Campbell wrote: > >> >>> 7. Close on keep-alive handling--needs more list discussion. In >>> particular, do keep-alives need to be bi-directional? >>> >> >> More discussion needed. It is not clear to me that we need this at all >> without relays. Can we push this entirely into the relay solution? > > > I agree that without relays keep alives probably aren't needed. > (If you get a hankering to know if the other end is still paying > attention you can send an empty message, but no protocol machinery is > needed for that.) > > But clearly the way we were going keep alives were needed when relays > were present. When we add relays later, we will either be faced with > having to change the endpoints to send keepalives or else we will have > to find a different solution that doesn't require them. > > So, it seems likely that the addition of relays will impact all prior > implementations. That is a downside to partitioning the work this way. > But maybe it is still worth it. We had a fairly long discussion about a different topic where we discussed that relays will be an extension, and endpoints will have to know about the extension to use it. Do you see this case as different? > >>> 8. Add more verbiage in security considerations, particularly >>> considering TLS certificate usage, self-signed certificates, and >>> interactions between TLS and digest authentication. (Cullen >>> volunteered to send text on TLS cert usage.) (This also interacts >>> with 3.) >>> >> >> Waiting for promised text. >> >>> 9. A number of nits and editorial fixes. >>> >> >> Most will be traded in for new and novel nits in the forthcoming >> revision. >> >> Also, Hisham added the following item: >> >> 10. We need normative text about how to construct a second SDP >> offer/answer exchange. >> >> We have had lots of discussion on this, and have converged on most of >> it. We realized we had a problem where there is no good way for the >> active party to indicate whether an MSRP stream should be reconnected >> when sending a new SDP offer. Paul proposed adding a version attribute >> a-line, which seems like it would solve the problem. However, it is >> different than the current COMEDIA proposal for the same problem (a >> "reconnect" a-line attribute.) >> >> The upcoming revision will capture this discussion, but there will >> have an open issue on the version vs. reconnect attribute. I >> personally lean towards Paul's proposal, but I want to make sure >> everyone thinks through the fact that MSRP and COMEDIA may take >> different approaches to solve the same problem. >> >> >> >> >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 8 15:20:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10176 for ; Thu, 8 Jan 2004 15:20:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aegdq-0003YL-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 15:20:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegcD-0003UA-00 for simple-archive@ietf.org; Thu, 08 Jan 2004 15:18:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AegaW-0003Oa-00; Thu, 08 Jan 2004 15:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegaS-000450-Jq; Thu, 08 Jan 2004 15:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegaN-00044g-13 for simple@optimus.ietf.org; Thu, 08 Jan 2004 15:16:55 -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 PAA09870 for ; Thu, 8 Jan 2004 15:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegaL-0003Mh-00 for simple@ietf.org; Thu, 08 Jan 2004 15:16:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegYZ-0003Ep-00 for simple@ietf.org; Thu, 08 Jan 2004 15:15:04 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AegXm-00037S-00 for simple@ietf.org; Thu, 08 Jan 2004 15:14:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Jan 2004 12:21:36 +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 i08KDdGN001031; Thu, 8 Jan 2004 12:13:40 -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 AFC57580; Thu, 8 Jan 2004 15:13:38 -0500 (EST) Message-ID: <3FFDB9F2.3020303@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP Open Issues Revisited References: <3FB94605.6020501@dynamicsoft.com> <3FFDAE3D.1080205@dynamicsoft.com> <3FFDB4EC.1060507@cisco.com> <3FFDB7B3.5010501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 15:13:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Paul Kyzivat wrote: > >> Sounds good. One comment below. >> >> Paul >> >> Ben Campbell wrote: >> >>> >>>> 7. Close on keep-alive handling--needs more list discussion. In >>>> particular, do keep-alives need to be bi-directional? >>>> >>> >>> More discussion needed. It is not clear to me that we need this at >>> all without relays. Can we push this entirely into the relay solution? >> >> >> >> I agree that without relays keep alives probably aren't needed. >> (If you get a hankering to know if the other end is still paying >> attention you can send an empty message, but no protocol machinery is >> needed for that.) >> >> But clearly the way we were going keep alives were needed when relays >> were present. When we add relays later, we will either be faced with >> having to change the endpoints to send keepalives or else we will have >> to find a different solution that doesn't require them. >> >> So, it seems likely that the addition of relays will impact all prior >> implementations. That is a downside to partitioning the work this way. >> But maybe it is still worth it. > > We had a fairly long discussion about a different topic where we > discussed that relays will be an extension, and endpoints will have to > know about the extension to use it. Do you see this case as different? I suppose not. But I imagine there might be an expectation that only one party in a conversation need know about relays for them to be used. But this is a tolerable issue in order to make progress. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 8 15:21:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10224 for ; Thu, 8 Jan 2004 15:21:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aegdu-0004L2-SD for simple-archive@odin.ietf.org; Thu, 08 Jan 2004 15:20:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08KKYNG016666 for simple-archive@odin.ietf.org; Thu, 8 Jan 2004 15:20:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aegds-0004KZ-ON for simple-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 15:20:32 -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 PAA10181 for ; Thu, 8 Jan 2004 15:20:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aegdr-0003YQ-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 15:20:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegcE-0003UH-00 for simple-web-archive@ietf.org; Thu, 08 Jan 2004 15:18:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AegaW-0003Oa-00; Thu, 08 Jan 2004 15:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegaS-000450-Jq; Thu, 08 Jan 2004 15:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AegaN-00044g-13 for simple@optimus.ietf.org; Thu, 08 Jan 2004 15:16:55 -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 PAA09870 for ; Thu, 8 Jan 2004 15:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AegaL-0003Mh-00 for simple@ietf.org; Thu, 08 Jan 2004 15:16:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AegYZ-0003Ep-00 for simple@ietf.org; Thu, 08 Jan 2004 15:15:04 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AegXm-00037S-00 for simple@ietf.org; Thu, 08 Jan 2004 15:14:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Jan 2004 12:21:36 +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 i08KDdGN001031; Thu, 8 Jan 2004 12:13:40 -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 AFC57580; Thu, 8 Jan 2004 15:13:38 -0500 (EST) Message-ID: <3FFDB9F2.3020303@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP Open Issues Revisited References: <3FB94605.6020501@dynamicsoft.com> <3FFDAE3D.1080205@dynamicsoft.com> <3FFDB4EC.1060507@cisco.com> <3FFDB7B3.5010501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 Jan 2004 15:13:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Paul Kyzivat wrote: > >> Sounds good. One comment below. >> >> Paul >> >> Ben Campbell wrote: >> >>> >>>> 7. Close on keep-alive handling--needs more list discussion. In >>>> particular, do keep-alives need to be bi-directional? >>>> >>> >>> More discussion needed. It is not clear to me that we need this at >>> all without relays. Can we push this entirely into the relay solution? >> >> >> >> I agree that without relays keep alives probably aren't needed. >> (If you get a hankering to know if the other end is still paying >> attention you can send an empty message, but no protocol machinery is >> needed for that.) >> >> But clearly the way we were going keep alives were needed when relays >> were present. When we add relays later, we will either be faced with >> having to change the endpoints to send keepalives or else we will have >> to find a different solution that doesn't require them. >> >> So, it seems likely that the addition of relays will impact all prior >> implementations. That is a downside to partitioning the work this way. >> But maybe it is still worth it. > > We had a fairly long discussion about a different topic where we > discussed that relays will be an extension, and endpoints will have to > know about the extension to use it. Do you see this case as different? I suppose not. But I imagine there might be an expectation that only one party in a conversation need know about relays for them to be used. But this is a tolerable issue in order to make progress. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 9 04:27:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19025 for ; Fri, 9 Jan 2004 04:27:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aesv6-00004w-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 04:27:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AestG-0007jE-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 04:25:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AessW-0007ap-00; Fri, 09 Jan 2004 04:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AessV-0003UB-H3; Fri, 09 Jan 2004 04:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AesjX-0003ET-8L for simple@optimus.ietf.org; Fri, 09 Jan 2004 04:15:11 -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 EAA18648 for ; Fri, 9 Jan 2004 04:15:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AesjU-0007Du-00 for simple@ietf.org; Fri, 09 Jan 2004 04:15:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aesi0-00076t-00 for simple@ietf.org; Fri, 09 Jan 2004 04:13:37 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly04a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1Aesge-0006s0-00 for simple@ietf.org; Fri, 09 Jan 2004 04:12:12 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly04a.srv.mailcontrol.com (MailControl) with SMTP id i099BOXv009762; Fri, 9 Jan 2004 09:11:24 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Fri, 9 Jan 2004 09:11:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Open Issues Revisited Message-ID: <45730E094814E44488F789C1CDED27AE01E22F99@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MSRP Open Issues Revisited Thread-Index: AcPWHWmzKZkUAQ1HRwq2vZO82xsbhAAcxX+g From: "Chris Boulton" To: "Ben Campbell" Cc: "Simple WG" X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Jan 2004 09:11:23 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable >I sent this out back in November. We have had good discussion on some,=20 >but not all. I have added status comments for each item. It is entirely >possible (and even likely) that I have miremembered some point, so=20 >please feel free to correct. > >Ben Campbell wrote: > >> Here is the list of significant issues and to-do's from the IETF58=20 >> meeting. At least, it is the list that I am aware of. Please send me=20 >> anything I may have missed. (Numbers are for naming purposes, and do=20 >> not indicate priority--with the exception of 1, of course. 3 Also=20 >> seems high priority due to the number of items that depend on it) >> >> I plan to have a new rev of the base spec out before the end of=20 >> December. That rev will include the removal of relays, and the other=20 >> issues that we have closure on. Items that require more discussion=20 >> will depend on the status of the discussion. >> >> ------------------------------------------------- >> 1. Remove relays from the base spec. (Saving relay text for relay=20 >> specific work, of course...) Does this mean that we have to rename=20 >> the protocol? > >Will be handled in an update I will send out in a day or two. > >> >> 2. Remove text suggesting re-sending failed messages on the same=20 >> connection. Instead, we should close the connection and re-connect.=20 >> (See item 3...) > >I think we have closed on this. Will be reflected in aformentioned=20 >revision. > >> >> 3. Close on handling of broken TCP connection. We discussed in the=20 >> meeting that we should be able to reconnect without having to=20 >> re-signal. (I remember now that we had discussed this before, and had >> a good reason at that time _not_ to do this--I will attempt to=20 >> further remember the details so we can decide what currently makes=20 >> sense.) >> > >I think we have closed on this. Connections cannot be re-established=20 >without a new sdp exchange. Will be reflected in aformentioned=20 >revision. > >> 3.5 Determine if we need explicity un-visit (interacts with 3.) > >I think this is still open. However, with the conclusions on 3, I am=20 >leaning towards saying we do not need it. [Chris Boulton]I agree - If a hosting endpoint identifies a reconnect - it would just locally 'un-visit' the client.=20 > >> >> 4. Do we need a cross-connection duplicate suggestion mechanism? I=20 >> think we said yes, if the new connection is part of the same session=20 >> as the old. (Needs further list discussion as it interacts with 3...) >> > >I think we have agreement we need it, but not necessarily on how it=20 >works. This will be an open issue in the aformentioned revision. > > >> 5. Generalize MIME handling to include mime version and allow=20 >> arbitrary MIME headers. > >We have agreement to do this. It will probably not be complete in=20 >forthcoming version, but will come soon after. > >> >> 6. Add text specifying use of sdp send-only attributes to identify=20 >> sessions intended for one-way delivery of large content. > >Done in aformentioned revision. > >> >> 7. Close on keep-alive handling--needs more list discussion. In=20 >> particular, do keep-alives need to be bi-directional? >> > >More discussion needed. It is not clear to me that we need this at all=20 >without relays. Can we push this entirely into the relay solution? [Chris Boulton]I'm more than happy for it to be pushed into a relay solution. The only reason I can think that this would be required in a non-relay solution would be for more efficient connection failure detection.=20=20 > >> 8. Add more verbiage in security considerations, particularly=20 >> considering TLS certificate usage, self-signed certificates, and=20 >> interactions between TLS and digest authentication. (Cullen=20 >> volunteered to send text on TLS cert usage.) (This also interacts=20 >> with 3.) >> > >Waiting for promised text. > >> 9. A number of nits and editorial fixes. >> > >Most will be traded in for new and novel nits in the forthcoming=20 >revision. > >Also, Hisham added the following item: > >10. We need normative text about how to construct a second SDP=20 >offer/answer exchange. > >We have had lots of discussion on this, and have converged on most of=20 >it. We realized we had a problem where there is no good way for the=20 >active party to indicate whether an MSRP stream should be reconnected=20 >when sending a new SDP offer. Paul proposed adding a version attribute=20 >a-line, which seems like it would solve the problem. However, it is=20 >different than the current COMEDIA proposal for the same problem (a=20 >"reconnect" a-line attribute.) > >The upcoming revision will capture this discussion, but there will have >an open issue on the version vs. reconnect attribute. I personally lean >towards Paul's proposal, but I want to make sure everyone thinks=20 >through the fact that MSRP and COMEDIA may take different approaches to >solve the same problem. > > This message has been scanned for viruses by MailControl - www.mailcontrol.= com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 9 10:37:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06175 for ; Fri, 9 Jan 2004 10:37:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeyhV-0000cb-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 10:37:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyfl-0000OO-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 10:35:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeyeL-00007I-00; Fri, 09 Jan 2004 10:34:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeyeB-0002ea-31; Fri, 09 Jan 2004 10:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeydT-0002T8-JY for simple@optimus.ietf.org; Fri, 09 Jan 2004 10:33:19 -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 KAA05090 for ; Fri, 9 Jan 2004 10:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeydR-00004S-00 for simple@ietf.org; Fri, 09 Jan 2004 10:33:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyag-0007dd-00 for simple@ietf.org; Fri, 09 Jan 2004 10:30:27 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AeyaO-0007X3-00 for simple@ietf.org; Fri, 09 Jan 2004 10:30:08 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i09FU7429357 for ; Fri, 9 Jan 2004 17:30:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 9 Jan 2004 17:30:06 +0200 Received: from nokia.com ([172.21.11.4]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 9 Jan 2004 17:30:06 +0200 Message-ID: <3FFEC8FD.1080402@nokia.com> From: "Niemi Aki (Nokia-M/Helsinki)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2004 15:30:06.0141 (UTC) FILETIME=[754D56D0:01C3D6C5] Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 17:30:05 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, Here are some comments to the filtering requirements. As with the winfo reqs, I don't think there's anything major, just a bit of tweaking the format and language. Cheers, Aki --- - Overall, the draft suffers from the same thing as the winfo-reqs - it needs a chapter that explains the model and defines terms that then are used throughout the rest of the document. - Overall nit, requirement labels lack numbers - In 3.2, 1st and 2nd req, if we replace "presentity" with "resource" in the 1sr req, then the second one becomes obsolete, no? - In 3.2, 3rd req, what is a sub-list? If it means a presence list that is nested insiode another list, then the above bullet should cover that as well. - In 3.2, 4th req is really hard to understand. - In 3.3, 1st sentence, this goes to my overall comment about model and terms, "triggering conditions" is not self-explanatory enough for me to understand immediately what were talking about here. - In 3.3, 2nd req, if not on the presence information, what would the triggering be based on? - In 3.3, 3rd req is hard to parse, suggest rewording similar to one I suggested for winfo filtering reqs. - In 4.1.2, 2nd req, the server default here being "no filter"? - In 4.2, 4th req, how about: It MUST be possible for the server to terminate a subscription if a filter is no longer acceptable, e.g., due to policy change or server load. - In 5.1, last req is confusing. Is this needed at all? - Move 5.3 to Security requirements. - In 6, 1st req contradicts earlier requirement on client receiving ack/nack from installing a filter. - In 6, 2nd requirement has no CAPS, what is the strength of this requirement? - In 6, last req is hard to understand. Suggest rewording, and using "SHOULD NOT convey information..." --- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 9 10:38:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06376 for ; Fri, 9 Jan 2004 10:38:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeyhb-0003NT-Ia for simple-archive@odin.ietf.org; Fri, 09 Jan 2004 10:37:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09FbYhQ012967 for simple-archive@odin.ietf.org; Fri, 9 Jan 2004 10:37:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeyhZ-0003N4-Uj for simple-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 10:37:33 -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 KAA06202 for ; Fri, 9 Jan 2004 10:37:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeyhX-0000co-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 10:37:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyfm-0000OV-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 10:35:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeyeL-00007I-00; Fri, 09 Jan 2004 10:34:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeyeB-0002ea-31; Fri, 09 Jan 2004 10:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeydT-0002T8-JY for simple@optimus.ietf.org; Fri, 09 Jan 2004 10:33:19 -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 KAA05090 for ; Fri, 9 Jan 2004 10:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeydR-00004S-00 for simple@ietf.org; Fri, 09 Jan 2004 10:33:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyag-0007dd-00 for simple@ietf.org; Fri, 09 Jan 2004 10:30:27 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AeyaO-0007X3-00 for simple@ietf.org; Fri, 09 Jan 2004 10:30:08 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i09FU7429357 for ; Fri, 9 Jan 2004 17:30:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 9 Jan 2004 17:30:06 +0200 Received: from nokia.com ([172.21.11.4]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 9 Jan 2004 17:30:06 +0200 Message-ID: <3FFEC8FD.1080402@nokia.com> From: "Niemi Aki (Nokia-M/Helsinki)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2004 15:30:06.0141 (UTC) FILETIME=[754D56D0:01C3D6C5] Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 17:30:05 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, Here are some comments to the filtering requirements. As with the winfo reqs, I don't think there's anything major, just a bit of tweaking the format and language. Cheers, Aki --- - Overall, the draft suffers from the same thing as the winfo-reqs - it needs a chapter that explains the model and defines terms that then are used throughout the rest of the document. - Overall nit, requirement labels lack numbers - In 3.2, 1st and 2nd req, if we replace "presentity" with "resource" in the 1sr req, then the second one becomes obsolete, no? - In 3.2, 3rd req, what is a sub-list? If it means a presence list that is nested insiode another list, then the above bullet should cover that as well. - In 3.2, 4th req is really hard to understand. - In 3.3, 1st sentence, this goes to my overall comment about model and terms, "triggering conditions" is not self-explanatory enough for me to understand immediately what were talking about here. - In 3.3, 2nd req, if not on the presence information, what would the triggering be based on? - In 3.3, 3rd req is hard to parse, suggest rewording similar to one I suggested for winfo filtering reqs. - In 4.1.2, 2nd req, the server default here being "no filter"? - In 4.2, 4th req, how about: It MUST be possible for the server to terminate a subscription if a filter is no longer acceptable, e.g., due to policy change or server load. - In 5.1, last req is confusing. Is this needed at all? - Move 5.3 to Security requirements. - In 6, 1st req contradicts earlier requirement on client receiving ack/nack from installing a filter. - In 6, 2nd requirement has no CAPS, what is the strength of this requirement? - In 6, last req is hard to understand. Suggest rewording, and using "SHOULD NOT convey information..." --- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 9 10:38:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06586 for ; Fri, 9 Jan 2004 10:38:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeyiy-0000ns-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 10:39:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyhf-0000eL-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 10:37:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeyg6-0000Pd-00; Fri, 09 Jan 2004 10:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeyg6-00032u-UM; Fri, 09 Jan 2004 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeyfZ-00030s-MZ for simple@optimus.ietf.org; Fri, 09 Jan 2004 10:35:29 -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 KAA05670 for ; Fri, 9 Jan 2004 10:35:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeyd1-0007fq-00 for simple@ietf.org; Fri, 09 Jan 2004 10:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeyOy-0006uG-00 for simple@ietf.org; Fri, 09 Jan 2004 10:18:21 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeyK2-0006dT-00 for simple@ietf.org; Fri, 09 Jan 2004 10:13:14 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i09FD3600760 for ; Fri, 9 Jan 2004 17:13:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 9 Jan 2004 17:13:03 +0200 Received: from nokia.com ([172.21.11.4]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 9 Jan 2004 17:13:03 +0200 Message-ID: <3FFEC4FF.6050409@nokia.com> From: "Niemi Aki (Nokia-M/Helsinki)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2004 15:13:03.0875 (UTC) FILETIME=[13FBED30:01C3D6C3] Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 17:13:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, I read the draft and here are some comments. Nothing major on the requirements themselves (I think they're pretty straightforward anyway) but some on the content/formatting of the draft. Cheers, Aki --- - Overall, I think the draft suffers from not having a section that clearly lays out the model, and defines the used terms. For example, it now uses "filters", "rules", "tests", "settings" pretty much interchangeably, which hurts readability. My suggestion is to write a short chapter with maybe a diagram that explains the model, the actors, and the objects that they exchange - then use that terminology throughout the draft. - The requirements could be labeled, as in "REQ-1:", but it isn't that important here. - In 3.1, 2nd s., possible -> able - In 3.2, 1st s., this is really awkward language. How about: The client MUST be able to indicate the event package to which the filter applies. - In 3.3, 1st s., bu "user" I think should be "resource" or "presentity"? - In 3.4, 2nd p., does it mean elements specifically, or any XML elements in winfo? - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I guessed what it means, but there must be a better way to state this requirement... It MUST be possible to define a set of conditions for the values of certain elements in a winfo document that determine which elements to send in notifications. - In 3.4.1, "have a specific status" instead of "are in a specific status" - Overall, section 3.4 could be summarized as: It MUST be possible to qualify content in a winfo notification based on any XML element, and specifically: * Watcher * Watcher status * Event causing a change in status * Subscription expiration * Subscription duration In addition, it MUST be possible to construct locigal expressions for values of certain elements that when evaluated to TRUE, will result in an element qualifying to be delivered in a notification. In addition, this should probably include XML namespaces, similar to presence filtering. - In 4.1.2, 2nd p., I guess the default here means "no installed filter"? - Requirement in 4.2 is quite similar to the top level requirement at the start of ch 4 -> combine? - In 6., example 4, I don't think this is a relevant example, how about replacing it with: A presentity requests information on watchers that have their status as "waiting", for authorization purposes. --- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 9 10:39:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06665 for ; Fri, 9 Jan 2004 10:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeyj2-0003bc-Ik for simple-archive@odin.ietf.org; Fri, 09 Jan 2004 10:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Fd43x013854 for simple-archive@odin.ietf.org; Fri, 9 Jan 2004 10:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeyj2-0003bN-Ci for simple-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 10:39:04 -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 KAA06589 for ; Fri, 9 Jan 2004 10:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeyiy-0000nx-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 10:39:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeyhf-0000eS-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 10:37:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeyg6-0000Pd-00; Fri, 09 Jan 2004 10:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeyg6-00032u-UM; Fri, 09 Jan 2004 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeyfZ-00030s-MZ for simple@optimus.ietf.org; Fri, 09 Jan 2004 10:35:29 -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 KAA05670 for ; Fri, 9 Jan 2004 10:35:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeyd1-0007fq-00 for simple@ietf.org; Fri, 09 Jan 2004 10:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeyOy-0006uG-00 for simple@ietf.org; Fri, 09 Jan 2004 10:18:21 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeyK2-0006dT-00 for simple@ietf.org; Fri, 09 Jan 2004 10:13:14 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i09FD3600760 for ; Fri, 9 Jan 2004 17:13:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 9 Jan 2004 17:13:03 +0200 Received: from nokia.com ([172.21.11.4]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 9 Jan 2004 17:13:03 +0200 Message-ID: <3FFEC4FF.6050409@nokia.com> From: "Niemi Aki (Nokia-M/Helsinki)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2004 15:13:03.0875 (UTC) FILETIME=[13FBED30:01C3D6C3] Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 17:13:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, I read the draft and here are some comments. Nothing major on the requirements themselves (I think they're pretty straightforward anyway) but some on the content/formatting of the draft. Cheers, Aki --- - Overall, I think the draft suffers from not having a section that clearly lays out the model, and defines the used terms. For example, it now uses "filters", "rules", "tests", "settings" pretty much interchangeably, which hurts readability. My suggestion is to write a short chapter with maybe a diagram that explains the model, the actors, and the objects that they exchange - then use that terminology throughout the draft. - The requirements could be labeled, as in "REQ-1:", but it isn't that important here. - In 3.1, 2nd s., possible -> able - In 3.2, 1st s., this is really awkward language. How about: The client MUST be able to indicate the event package to which the filter applies. - In 3.3, 1st s., bu "user" I think should be "resource" or "presentity"? - In 3.4, 2nd p., does it mean elements specifically, or any XML elements in winfo? - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I guessed what it means, but there must be a better way to state this requirement... It MUST be possible to define a set of conditions for the values of certain elements in a winfo document that determine which elements to send in notifications. - In 3.4.1, "have a specific status" instead of "are in a specific status" - Overall, section 3.4 could be summarized as: It MUST be possible to qualify content in a winfo notification based on any XML element, and specifically: * Watcher * Watcher status * Event causing a change in status * Subscription expiration * Subscription duration In addition, it MUST be possible to construct locigal expressions for values of certain elements that when evaluated to TRUE, will result in an element qualifying to be delivered in a notification. In addition, this should probably include XML namespaces, similar to presence filtering. - In 4.1.2, 2nd p., I guess the default here means "no installed filter"? - Requirement in 4.2 is quite similar to the top level requirement at the start of ch 4 -> combine? - In 6., example 4, I don't think this is a relevant example, how about replacing it with: A presentity requests information on watchers that have their status as "waiting", for authorization purposes. --- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 9 11:13:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10125 for ; Fri, 9 Jan 2004 11:13:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AezGL-0002Uj-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 11:13:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AezA1-0002CO-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 11:06:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aez3o-0001ux-00; Fri, 09 Jan 2004 11:00:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez3L-0003zk-Qb; Fri, 09 Jan 2004 11:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez2b-0003yZ-E5 for simple@optimus.ietf.org; Fri, 09 Jan 2004 10:59:17 -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 KAA09418 for ; Fri, 9 Jan 2004 10:59:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aez2O-0001oJ-00 for simple@ietf.org; Fri, 09 Jan 2004 10:59:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeywC-0001et-00 for simple@ietf.org; Fri, 09 Jan 2004 10:52:41 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeyvl-0001ZV-00; Fri, 09 Jan 2004 10:52:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i09Fpad26878; Fri, 9 Jan 2004 09:51:36 -0600 From: Robert Sparks To: sip@ietf.org, simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1073663495.943.48.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIPIT 14 registration closes next Friday Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 09:51:35 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Registration for SIPIT 14 closes in 7 days. See http://www.etsi.org/plugtests/SIPIT14.htm to register if you are planning to attend. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 9 11:14:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10255 for ; Fri, 9 Jan 2004 11:14:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AezGu-0004qw-6d for simple-archive@odin.ietf.org; Fri, 09 Jan 2004 11:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09GE4Cw018648 for simple-archive@odin.ietf.org; Fri, 9 Jan 2004 11:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AezGt-0004qh-VA for simple-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 11:14:03 -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 LAA10147 for ; Fri, 9 Jan 2004 11:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AezGe-0002VG-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 11:13:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AezA2-0002CV-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 11:06:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aez3o-0001ux-00; Fri, 09 Jan 2004 11:00:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez3L-0003zk-Qb; Fri, 09 Jan 2004 11:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez2b-0003yZ-E5 for simple@optimus.ietf.org; Fri, 09 Jan 2004 10:59:17 -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 KAA09418 for ; Fri, 9 Jan 2004 10:59:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aez2O-0001oJ-00 for simple@ietf.org; Fri, 09 Jan 2004 10:59:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeywC-0001et-00 for simple@ietf.org; Fri, 09 Jan 2004 10:52:41 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeyvl-0001ZV-00; Fri, 09 Jan 2004 10:52:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i09Fpad26878; Fri, 9 Jan 2004 09:51:36 -0600 From: Robert Sparks To: sip@ietf.org, simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1073663495.943.48.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIPIT 14 registration closes next Friday Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 09:51:35 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Registration for SIPIT 14 closes in 7 days. See http://www.etsi.org/plugtests/SIPIT14.htm to register if you are planning to attend. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 9 11:24:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11122 for ; Fri, 9 Jan 2004 11:24:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AezRD-0003UP-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 11:24:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AezO3-00034G-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 11:21:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AezJJ-0002eu-00; Fri, 09 Jan 2004 11:16:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AezIn-0004vn-4i; Fri, 09 Jan 2004 11:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AezIg-0004ut-Nu for simple@optimus.ietf.org; Fri, 09 Jan 2004 11:15:54 -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 LAA10323 for ; Fri, 9 Jan 2004 11:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AezIV-0002bk-00 for simple@ietf.org; Fri, 09 Jan 2004 11:15:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AezAM-0002Fk-00 for simple@ietf.org; Fri, 09 Jan 2004 11:07:19 -0500 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1Aez5P-0001xY-00 for simple@ietf.org; Fri, 09 Jan 2004 11:02:12 -0500 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Fri, 09 Jan 2004 21:41:15 +0530 Delivered-To: ipgen-india.com-jijo@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 532 invoked by uid 7010); Fri Jan 9 21:29:47 2004 Received: (sifymail 527 invoked by uid 7010); 9 Jan 2004 21:29:47 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 9 Jan 2004 21:29:47 +0530 Received: (sifymail 19139 invoked by uid 7005); 9 Jan 2004 21:29:48 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 9 Jan 2004 21:29:48 +0530 Received: (sifymail 19125 invoked by uid 7005); 9 Jan 2004 21:29:45 +0530 Received: from 132.151.6.22 (HELO optimus.ietf.org) (132.151.6.22) by 202.144.76.19 with SMTP; 9 Jan 2004 21:29:45 +0530 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez3N-0003zs-HM; Fri, 09 Jan 2004 11:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aez2h-0003yg-2w for sip@optimus.ietf.org; Fri, 09 Jan 2004 10:59:23 -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 KAA09424 for ; Fri, 9 Jan 2004 10:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aez2U-0001oN-00 for sip@ietf.org; Fri, 09 Jan 2004 10:59:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeywD-0001f1-00 for sip@ietf.org; Fri, 09 Jan 2004 10:52:42 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeyvl-0001ZV-00; Fri, 09 Jan 2004 10:52:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id i09Fpad26878; Fri, 9 Jan 2004 09:51:36 -0600 From: Robert Sparks To: sip@ietf.org, simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Message-Id: <1073663495.943.48.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip] SIPIT 14 registration closes next Friday Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 09:51:35 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Registration for SIPIT 14 closes in 7 days. See http://www.etsi.org/plugtests/SIPIT14.htm to register if you are planning to attend. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 9 14:58:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29989 for ; Fri, 9 Jan 2004 14:58:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af2bg-0003FA-RN for simple-archive@odin.ietf.org; Fri, 09 Jan 2004 14:47:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09JliCE012464 for simple-archive@odin.ietf.org; Fri, 9 Jan 2004 14:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af2bg-0003Et-Mz for simple-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 14:47:44 -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 OAA28965 for ; Fri, 9 Jan 2004 14:41:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af2W7-0007HT-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 14:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af1fg-0005W5-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 13:47:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af1G0-00076b-01 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 13:21:16 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af0nb-00071Q-QJ for simple-web-archive@ietf.org; Fri, 09 Jan 2004 12:51:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0na-0001OL-MZ for simple-web-archive@ietf.org; Fri, 09 Jan 2004 12:51:54 -0500 Date: Fri, 09 Jan 2004 12:51:54 -0500 Message-ID: <20040109175154.9164.7120.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-web-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org fuasex https://www1.ietf.org/mailman/options/simple/simple-web-archive%40ietf.org From mailman-admin@ietf.org Fri Jan 9 15:36:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05539 for ; Fri, 9 Jan 2004 15:08:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af2vX-0006Ol-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 15:08:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af2Pn-0004zj-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 14:35:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af1Ye-0003mh-01 for simple-archive@ietf.org; Fri, 09 Jan 2004 13:40:33 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af0px-00079C-Dy for simple-archive@ietf.org; Fri, 09 Jan 2004 12:54:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0pm-0003zK-0y for simple-archive@ietf.org; Fri, 09 Jan 2004 12:54:10 -0500 Date: Fri, 09 Jan 2004 12:54:10 -0500 Message-ID: <20040109175410.9164.15161.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From simple-admin@ietf.org Fri Jan 9 15:37:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12533 for ; Fri, 9 Jan 2004 15:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3NO-00034m-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 15:37:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3Je-0001yZ-00 for simple-archive@ietf.org; Fri, 09 Jan 2004 15:33:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af3Cz-0000a5-00; Fri, 09 Jan 2004 15:26:17 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af3D0-0003eh-IW; Fri, 09 Jan 2004 15:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Cm-0004gZ-Od; Fri, 09 Jan 2004 15:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3CX-0004d1-Hg for simple@optimus.ietf.org; Fri, 09 Jan 2004 15:25:49 -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 PAA09457 for ; Fri, 9 Jan 2004 15:25:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3CR-0000PC-00 for simple@ietf.org; Fri, 09 Jan 2004 15:25:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af2eZ-00033O-00 for simple@ietf.org; Fri, 09 Jan 2004 14:50:45 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1Af2Eb-0001h8-00 for simple@ietf.org; Fri, 09 Jan 2004 14:23:53 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i09JNKLS009324; Fri, 9 Jan 2004 13:23:21 -0600 (CST) Message-ID: <3FFEFFA7.C39B140@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Helsinki)" CC: simple@ietf.org Subject: Re: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 References: <3FFEC4FF.6050409@nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 13:23:19 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Aki, Hasn't this draft been superseeded by draft-ietf-simple-pres-filter-reqs-02.txt? Regards, Alex. "Niemi Aki (Nokia-M/Helsinki)" wrote: > All, > > I read the draft and here are some comments. Nothing major on the > requirements themselves (I think they're pretty straightforward anyway) > but some on the content/formatting of the draft. > > Cheers, > Aki > > --- > > - Overall, I think the draft suffers from not having a section that > clearly lays out the model, and defines the used terms. For example, it > now uses "filters", "rules", "tests", "settings" pretty much > interchangeably, which hurts readability. My suggestion is to write a > short chapter with maybe a diagram that explains the model, the actors, > and the objects that they exchange - then use that terminology > throughout the draft. > > - The requirements could be labeled, as in "REQ-1:", but it isn't that > important here. > > - In 3.1, 2nd s., possible -> able > > - In 3.2, 1st s., this is really awkward language. How about: > > The client MUST be able to indicate the event package > to which the filter applies. > > - In 3.3, 1st s., bu "user" I think should be "resource" or "presentity"? > > - In 3.4, 2nd p., does it mean elements specifically, or any > XML elements in winfo? > > - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I > guessed what it means, but there must be a better way to state this > requirement... > > It MUST be possible to define a set of conditions > for the values of certain elements in a winfo document > that determine which elements to send in notifications. > > - In 3.4.1, "have a specific status" instead of "are in a specific status" > > - Overall, section 3.4 could be summarized as: > > It MUST be possible to qualify content in a winfo > notification based on any XML element, and > specifically: > > * Watcher > * Watcher status > * Event causing a change in status > * Subscription expiration > * Subscription duration > > In addition, it MUST be possible to construct locigal > expressions for values of certain elements that when > evaluated to TRUE, will result in an element qualifying > to be delivered in a notification. > > In addition, this should probably include XML namespaces, similar to > presence filtering. > > - In 4.1.2, 2nd p., I guess the default here means "no installed filter"? > > - Requirement in 4.2 is quite similar to the top level requirement at > the start of ch 4 -> combine? > > - In 6., example 4, I don't think this is a relevant example, how about > replacing it with: > > A presentity requests information on watchers that > have their status as "waiting", for authorization > purposes. > > --- > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 9 15:37:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12774 for ; Fri, 9 Jan 2004 15:37:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3NV-0005du-W1 for simple-archive@odin.ietf.org; Fri, 09 Jan 2004 15:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Kb8tN021676 for simple-archive@odin.ietf.org; Fri, 9 Jan 2004 15:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3NT-0005dU-D0 for simple-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 15:37:07 -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 PAA12546 for ; Fri, 9 Jan 2004 15:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3NO-00034z-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 15:37:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3Jh-0001yw-00 for simple-web-archive@ietf.org; Fri, 09 Jan 2004 15:33:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af3Cz-0000a5-00; Fri, 09 Jan 2004 15:26:17 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af3D0-0003eh-IW; Fri, 09 Jan 2004 15:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Cm-0004gZ-Od; Fri, 09 Jan 2004 15:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3CX-0004d1-Hg for simple@optimus.ietf.org; Fri, 09 Jan 2004 15:25:49 -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 PAA09457 for ; Fri, 9 Jan 2004 15:25:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3CR-0000PC-00 for simple@ietf.org; Fri, 09 Jan 2004 15:25:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af2eZ-00033O-00 for simple@ietf.org; Fri, 09 Jan 2004 14:50:45 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1Af2Eb-0001h8-00 for simple@ietf.org; Fri, 09 Jan 2004 14:23:53 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i09JNKLS009324; Fri, 9 Jan 2004 13:23:21 -0600 (CST) Message-ID: <3FFEFFA7.C39B140@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niemi Aki (Nokia-M/Helsinki)" CC: simple@ietf.org Subject: Re: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 References: <3FFEC4FF.6050409@nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 09 Jan 2004 13:23:19 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki, Hasn't this draft been superseeded by draft-ietf-simple-pres-filter-reqs-02.txt? Regards, Alex. "Niemi Aki (Nokia-M/Helsinki)" wrote: > All, > > I read the draft and here are some comments. Nothing major on the > requirements themselves (I think they're pretty straightforward anyway) > but some on the content/formatting of the draft. > > Cheers, > Aki > > --- > > - Overall, I think the draft suffers from not having a section that > clearly lays out the model, and defines the used terms. For example, it > now uses "filters", "rules", "tests", "settings" pretty much > interchangeably, which hurts readability. My suggestion is to write a > short chapter with maybe a diagram that explains the model, the actors, > and the objects that they exchange - then use that terminology > throughout the draft. > > - The requirements could be labeled, as in "REQ-1:", but it isn't that > important here. > > - In 3.1, 2nd s., possible -> able > > - In 3.2, 1st s., this is really awkward language. How about: > > The client MUST be able to indicate the event package > to which the filter applies. > > - In 3.3, 1st s., bu "user" I think should be "resource" or "presentity"? > > - In 3.4, 2nd p., does it mean elements specifically, or any > XML elements in winfo? > > - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I > guessed what it means, but there must be a better way to state this > requirement... > > It MUST be possible to define a set of conditions > for the values of certain elements in a winfo document > that determine which elements to send in notifications. > > - In 3.4.1, "have a specific status" instead of "are in a specific status" > > - Overall, section 3.4 could be summarized as: > > It MUST be possible to qualify content in a winfo > notification based on any XML element, and > specifically: > > * Watcher > * Watcher status > * Event causing a change in status > * Subscription expiration > * Subscription duration > > In addition, it MUST be possible to construct locigal > expressions for values of certain elements that when > evaluated to TRUE, will result in an element qualifying > to be delivered in a notification. > > In addition, this should probably include XML namespaces, similar to > presence filtering. > > - In 4.1.2, 2nd p., I guess the default here means "no installed filter"? > > - Requirement in 4.2 is quite similar to the top level requirement at > the start of ch 4 -> combine? > > - In 6., example 4, I don't think this is a relevant example, how about > replacing it with: > > A presentity requests information on watchers that > have their status as "waiting", for authorization > purposes. > > --- > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 12 08:46:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26233 for ; Mon, 12 Jan 2004 08:46:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag2Ol-0001nO-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 08:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag2Ic-0001an-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 08:40:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag2E9-0001Ph-00; Mon, 12 Jan 2004 08:35:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag2Dd-00033g-GQ; Mon, 12 Jan 2004 08:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag2DN-00033Q-V7 for simple@optimus.ietf.org; Mon, 12 Jan 2004 08:34:45 -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 IAA25977 for ; Mon, 12 Jan 2004 08:34:44 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag2DH-0001Nw-00 for simple@ietf.org; Mon, 12 Jan 2004 08:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag28G-0001Fn-00 for simple@ietf.org; Mon, 12 Jan 2004 08:29:29 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ag24c-00019M-00 for simple@ietf.org; Mon, 12 Jan 2004 08:25:42 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0CDPF615370 for ; Mon, 12 Jan 2004 15:25:15 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 12 Jan 2004 15:25:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 12 Jan 2004 15:25:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017975A6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 thread-index: AcPW7uc0etwPhpxuTDWcLwYEsYgFcgCIH4MQ To: , Cc: X-OriginalArrivalTime: 12 Jan 2004 13:25:15.0278 (UTC) FILETIME=[83A39AE0:01C3D90F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 15:25:14 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable No, both drafts still exist and present different requirements for = filtering different event packages. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Alex Audu > Sent: 09.January.2004 21:23 > To: Niemi Aki (Nokia-M/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on=20 > draft-ietf-simple-winfo-filter-reqs-00 >=20 >=20 > Aki, >=20 > Hasn't this draft been superseeded by > draft-ietf-simple-pres-filter-reqs-02.txt? >=20 > Regards, > Alex. >=20 >=20 > "Niemi Aki (Nokia-M/Helsinki)" wrote: >=20 > > All, > > > > I read the draft and here are some comments. Nothing major on the > > requirements themselves (I think they're pretty=20 > straightforward anyway) > > but some on the content/formatting of the draft. > > > > Cheers, > > Aki > > > > --- > > > > - Overall, I think the draft suffers from not having a section that > > clearly lays out the model, and defines the used terms. For=20 > example, it > > now uses "filters", "rules", "tests", "settings" pretty much > > interchangeably, which hurts readability. My suggestion is=20 > to write a > > short chapter with maybe a diagram that explains the model,=20 > the actors, > > and the objects that they exchange - then use that terminology > > throughout the draft. > > > > - The requirements could be labeled, as in "REQ-1:", but it=20 > isn't that > > important here. > > > > - In 3.1, 2nd s., possible -> able > > > > - In 3.2, 1st s., this is really awkward language. How about: > > > > The client MUST be able to indicate the event package > > to which the filter applies. > > > > - In 3.3, 1st s., bu "user" I think should be "resource" or=20 > "presentity"? > > > > - In 3.4, 2nd p., does it mean elements=20 > specifically, or any > > XML elements in winfo? > > > > - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I > > guessed what it means, but there must be a better way to state this > > requirement... > > > > It MUST be possible to define a set of conditions > > for the values of certain elements in a winfo document > > that determine which elements to send in notifications. > > > > - In 3.4.1, "have a specific status" instead of "are in a=20 > specific status" > > > > - Overall, section 3.4 could be summarized as: > > > > It MUST be possible to qualify content in a winfo > > notification based on any XML element, and > > specifically: > > > > * Watcher > > * Watcher status > > * Event causing a change in status > > * Subscription expiration > > * Subscription duration > > > > In addition, it MUST be possible to construct locigal > > expressions for values of certain elements that when > > evaluated to TRUE, will result in an element qualifying > > to be delivered in a notification. > > > > In addition, this should probably include XML=20 > namespaces, similar to > > presence filtering. > > > > - In 4.1.2, 2nd p., I guess the default here means "no=20 > installed filter"? > > > > - Requirement in 4.2 is quite similar to the top level=20 > requirement at > > the start of ch 4 -> combine? > > > > - In 6., example 4, I don't think this is a relevant=20 > example, how about > > replacing it with: > > > > A presentity requests information on watchers that > > have their status as "waiting", for authorization > > purposes. > > > > --- > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 12 08:47:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26271 for ; Mon, 12 Jan 2004 08:47: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 1Ag2P7-0003eS-1d for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 08:46:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CDkrWm014037 for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 08:46:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag2P6-0003eK-Lb for simple-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 08:46:52 -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 IAA26236 for ; Mon, 12 Jan 2004 08:46:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag2Ol-0001nP-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 08:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag2Ic-0001au-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 08:40:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag2E9-0001Ph-00; Mon, 12 Jan 2004 08:35:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag2Dd-00033g-GQ; Mon, 12 Jan 2004 08:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag2DN-00033Q-V7 for simple@optimus.ietf.org; Mon, 12 Jan 2004 08:34:45 -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 IAA25977 for ; Mon, 12 Jan 2004 08:34:44 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag2DH-0001Nw-00 for simple@ietf.org; Mon, 12 Jan 2004 08:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag28G-0001Fn-00 for simple@ietf.org; Mon, 12 Jan 2004 08:29:29 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ag24c-00019M-00 for simple@ietf.org; Mon, 12 Jan 2004 08:25:42 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0CDPF615370 for ; Mon, 12 Jan 2004 15:25:15 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 12 Jan 2004 15:25:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 12 Jan 2004 15:25:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017975A6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 thread-index: AcPW7uc0etwPhpxuTDWcLwYEsYgFcgCIH4MQ To: , Cc: X-OriginalArrivalTime: 12 Jan 2004 13:25:15.0278 (UTC) FILETIME=[83A39AE0:01C3D90F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 15:25:14 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable No, both drafts still exist and present different requirements for = filtering different event packages. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Alex Audu > Sent: 09.January.2004 21:23 > To: Niemi Aki (Nokia-M/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on=20 > draft-ietf-simple-winfo-filter-reqs-00 >=20 >=20 > Aki, >=20 > Hasn't this draft been superseeded by > draft-ietf-simple-pres-filter-reqs-02.txt? >=20 > Regards, > Alex. >=20 >=20 > "Niemi Aki (Nokia-M/Helsinki)" wrote: >=20 > > All, > > > > I read the draft and here are some comments. Nothing major on the > > requirements themselves (I think they're pretty=20 > straightforward anyway) > > but some on the content/formatting of the draft. > > > > Cheers, > > Aki > > > > --- > > > > - Overall, I think the draft suffers from not having a section that > > clearly lays out the model, and defines the used terms. For=20 > example, it > > now uses "filters", "rules", "tests", "settings" pretty much > > interchangeably, which hurts readability. My suggestion is=20 > to write a > > short chapter with maybe a diagram that explains the model,=20 > the actors, > > and the objects that they exchange - then use that terminology > > throughout the draft. > > > > - The requirements could be labeled, as in "REQ-1:", but it=20 > isn't that > > important here. > > > > - In 3.1, 2nd s., possible -> able > > > > - In 3.2, 1st s., this is really awkward language. How about: > > > > The client MUST be able to indicate the event package > > to which the filter applies. > > > > - In 3.3, 1st s., bu "user" I think should be "resource" or=20 > "presentity"? > > > > - In 3.4, 2nd p., does it mean elements=20 > specifically, or any > > XML elements in winfo? > > > > - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I > > guessed what it means, but there must be a better way to state this > > requirement... > > > > It MUST be possible to define a set of conditions > > for the values of certain elements in a winfo document > > that determine which elements to send in notifications. > > > > - In 3.4.1, "have a specific status" instead of "are in a=20 > specific status" > > > > - Overall, section 3.4 could be summarized as: > > > > It MUST be possible to qualify content in a winfo > > notification based on any XML element, and > > specifically: > > > > * Watcher > > * Watcher status > > * Event causing a change in status > > * Subscription expiration > > * Subscription duration > > > > In addition, it MUST be possible to construct locigal > > expressions for values of certain elements that when > > evaluated to TRUE, will result in an element qualifying > > to be delivered in a notification. > > > > In addition, this should probably include XML=20 > namespaces, similar to > > presence filtering. > > > > - In 4.1.2, 2nd p., I guess the default here means "no=20 > installed filter"? > > > > - Requirement in 4.2 is quite similar to the top level=20 > requirement at > > the start of ch 4 -> combine? > > > > - In 6., example 4, I don't think this is a relevant=20 > example, how about > > replacing it with: > > > > A presentity requests information on watchers that > > have their status as "waiting", for authorization > > purposes. > > > > --- > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 12 10:13:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01268 for ; Mon, 12 Jan 2004 10:13:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3kg-0006rX-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 10:13:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3iq-0006my-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 10:11:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag3hz-0006iG-00; Mon, 12 Jan 2004 10:10:28 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ag3hz-0003ZE-Gx; Mon, 12 Jan 2004 10:10:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3hd-0007VZ-08; Mon, 12 Jan 2004 10:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3gy-0007PN-Ou for simple@optimus.ietf.org; Mon, 12 Jan 2004 10:09:24 -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 KAA00735 for ; Mon, 12 Jan 2004 10:09:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3gw-0006gl-00 for simple@ietf.org; Mon, 12 Jan 2004 10:09:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3f6-0006cV-00 for simple@ietf.org; Mon, 12 Jan 2004 10:07:28 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag3eU-0006TD-00; Mon, 12 Jan 2004 10:06:51 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Jan 2004 07:08:38 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0CF6EVO008153; Mon, 12 Jan 2004 07:06:17 -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 AFE24930; Mon, 12 Jan 2004 10:06:13 -0500 (EST) Message-ID: <4002B7E5.8090700@cisco.com> From: Paul Kyzivat 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: simple@ietf.org, mmusic@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 10:06:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit My attempts to reach David Yon at the address he has listed in the comedia draft (yon@dialout.net) have bounced. Does anybody know whether he is still at Dialout.Net, or even if Dialout.Net still exists? Paul Paul Kyzivat wrote: > Ben, > > I'm copying David Yon on this since he is author of comedia. This > probably won't make any sense out of context to him, so I will > separately send him some of the earlier discussion. > > I don't recall what the current status of comedia is. It is currently > listed as a WG draft, but there don't seem to be any goals listed for it. > > Paul > > Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >>> >>> >>> Ben Campbell wrote: >>> >>>> (More comments on same email...) >>>> >>>> Paul Kyzivat wrote: >>>> >>>> [...] >>>> >>>>> >>>>> Using the same media lines for the replacement session solves the >>>>> association problem for any media type - MSRP, RTP, whatever. But >>>>> it also does leave the problem of distinguishing a "reconnect" >>>>> offer from a "don't change anything" offer. >>>> >>>> >>>> >>>> >>>> Would doing this, plus using the COMEDIA reconnect attribute help? >>>> (section 5 of current comedia draft.) >>> >>> >>> >>> >>> That would probably work. The feature in comedia didn't end up as I >>> hoped it would. While it does mean you have to do something special >>> (add the a=reconnect) attribute to cause a reconnect, having done >>> that once you then have to do something else (remove the a=reconnect) >>> in a subsequent exchange. >>> >>> I think it would be better if there were something like >>> a=version:nnn, which would just be a version number for a particular >>> media session. Then whenever it changes you reconnect. If the >>> attribute was absent it could be defaulted from the o-line. >> >> >> >> I agree that sounds like a better approach. Do you think there is any >> chance to convince the COMEDIA folks to follow the same approach? >> >>> >>> Paul >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 12 10:13:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01381 for ; Mon, 12 Jan 2004 10:13:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3kj-0007nU-C3 for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 10:13:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CFDHhE029966 for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 10:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3kj-0007nF-8h for simple-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 10:13:17 -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 KAA01286 for ; Mon, 12 Jan 2004 10:13:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3kh-0006rc-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 10:13:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3ir-0006n5-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 10:11:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag3hz-0006iG-00; Mon, 12 Jan 2004 10:10:28 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ag3hz-0003ZE-Gx; Mon, 12 Jan 2004 10:10:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3hd-0007VZ-08; Mon, 12 Jan 2004 10:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3gy-0007PN-Ou for simple@optimus.ietf.org; Mon, 12 Jan 2004 10:09:24 -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 KAA00735 for ; Mon, 12 Jan 2004 10:09:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3gw-0006gl-00 for simple@ietf.org; Mon, 12 Jan 2004 10:09:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3f6-0006cV-00 for simple@ietf.org; Mon, 12 Jan 2004 10:07:28 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag3eU-0006TD-00; Mon, 12 Jan 2004 10:06:51 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Jan 2004 07:08:38 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0CF6EVO008153; Mon, 12 Jan 2004 07:06:17 -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 AFE24930; Mon, 12 Jan 2004 10:06:13 -0500 (EST) Message-ID: <4002B7E5.8090700@cisco.com> From: Paul Kyzivat 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: simple@ietf.org, mmusic@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 10:06:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My attempts to reach David Yon at the address he has listed in the comedia draft (yon@dialout.net) have bounced. Does anybody know whether he is still at Dialout.Net, or even if Dialout.Net still exists? Paul Paul Kyzivat wrote: > Ben, > > I'm copying David Yon on this since he is author of comedia. This > probably won't make any sense out of context to him, so I will > separately send him some of the earlier discussion. > > I don't recall what the current status of comedia is. It is currently > listed as a WG draft, but there don't seem to be any goals listed for it. > > Paul > > Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >>> >>> >>> Ben Campbell wrote: >>> >>>> (More comments on same email...) >>>> >>>> Paul Kyzivat wrote: >>>> >>>> [...] >>>> >>>>> >>>>> Using the same media lines for the replacement session solves the >>>>> association problem for any media type - MSRP, RTP, whatever. But >>>>> it also does leave the problem of distinguishing a "reconnect" >>>>> offer from a "don't change anything" offer. >>>> >>>> >>>> >>>> >>>> Would doing this, plus using the COMEDIA reconnect attribute help? >>>> (section 5 of current comedia draft.) >>> >>> >>> >>> >>> That would probably work. The feature in comedia didn't end up as I >>> hoped it would. While it does mean you have to do something special >>> (add the a=reconnect) attribute to cause a reconnect, having done >>> that once you then have to do something else (remove the a=reconnect) >>> in a subsequent exchange. >>> >>> I think it would be better if there were something like >>> a=version:nnn, which would just be a version number for a particular >>> media session. Then whenever it changes you reconnect. If the >>> attribute was absent it could be defaulted from the o-line. >> >> >> >> I agree that sounds like a better approach. Do you think there is any >> chance to convince the COMEDIA folks to follow the same approach? >> >>> >>> Paul >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 12 13:21:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09430 for ; Mon, 12 Jan 2004 13:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag6hF-0007Gt-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 13:21:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag6fP-0007DL-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 13:20:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag6dZ-0007A9-00; Mon, 12 Jan 2004 13:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6dW-0007fD-7V; Mon, 12 Jan 2004 13:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6dU-0007eb-8s for simple@optimus.ietf.org; Mon, 12 Jan 2004 13:18:00 -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 NAA09311 for ; Mon, 12 Jan 2004 13:17:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag6dS-00078u-00 for simple@ietf.org; Mon, 12 Jan 2004 13:17:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag6bj-00076s-00 for simple@ietf.org; Mon, 12 Jan 2004 13:16:12 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag6bB-00074D-00; Mon, 12 Jan 2004 13:15:37 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0CIEhVO006307; Mon, 12 Jan 2004 10:15:04 -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 AFE43989; Mon, 12 Jan 2004 13:14:42 -0500 (EST) Message-ID: <4002E412.2070608@cisco.com> From: Paul Kyzivat 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: David Yon CC: simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 13:14:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit David Yon wrote: > Here I am! :-) > > Dialout.Net is defunct, but at the moment I am still willing to support > the comedia draft, although I have much less time available to me for it. I was suspecting Dialout might be gone because attempts to access the web site timed out. Glad to hear that you are still around. Maybe you should submit a new version of comedia just to update your address. > My only concern with a "version" attribute is that it causes a > reconnection by inference. I'm afraid that it would be rife with > temptation to use it to version-stamp the session for other reasons that > do not imply the impetus to reconnect. Is there some tangible scenario > where "version" is superior to "reconnect"? I can see how you might consider reconnection by inference to be a negative. But in my view that is also its appeal. The point is to preserve the behavior that reuse of unchanged SDP acts as a no-op. Once you introduce the a=reconnect attribute, a subsequent offer/answer cycle that reuses sdp containing that will cause another reconnect, which isn't a no-op. By using a=version, it is the detection of a revised version number that causes the reconnect. So a subsequent offer/answer cycle using the same sdp will not see a change in version number and so will not cause another reconnect. This is of significance whenever there might be components that manipulate offers and answers in a generic way. For instance, if you have a UA that manages multiple media streams, there may be one component that decomposes the sdp and then interacts with a separate component in the UA for each stream. If there is a need to make a change in one stream, it may simply want to make a change in the description of the affected stream without dealing with the components responsible for other streams. In general, with the exception of a=reconnect, it can do this. I am not especially attached to the name "version". I am certainly willing to entertain some other name for the attribute that is clearer and less prone to invite abuse. E.g. we might consider a=reconnect:NNN. Paul > At 10:06 AM 1/12/2004, Paul Kyzivat wrote: > >> My attempts to reach David Yon at the address he has listed in the >> comedia draft (yon@dialout.net) have bounced. Does anybody know >> whether he is still at Dialout.Net, or even if Dialout.Net still exists? >> >> Paul >> >> Paul Kyzivat wrote: >> >>> Ben, >>> I'm copying David Yon on this since he is author of comedia. This >>> probably won't make any sense out of context to him, so I will >>> separately send him some of the earlier discussion. >>> I don't recall what the current status of comedia is. It is currently >>> listed as a WG draft, but there don't seem to be any goals listed for >>> it. >>> Paul >>> Ben Campbell wrote: >>> >>>> Paul Kyzivat wrote: >>>> >>>>> >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> (More comments on same email...) >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>>> >>>>>>> Using the same media lines for the replacement session solves the >>>>>>> association problem for any media type - MSRP, RTP, whatever. But >>>>>>> it also does leave the problem of distinguishing a "reconnect" >>>>>>> offer from a "don't change anything" offer. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>> (section 5 of current comedia draft.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> That would probably work. The feature in comedia didn't end up as I >>>>> hoped it would. While it does mean you have to do something special >>>>> (add the a=reconnect) attribute to cause a reconnect, having done >>>>> that once you then have to do something else (remove the >>>>> a=reconnect) in a subsequent exchange. >>>>> >>>>> I think it would be better if there were something like >>>>> a=version:nnn, which would just be a version number for a >>>>> particular media session. Then whenever it changes you reconnect. >>>>> If the attribute was absent it could be defaulted from the o-line. >>>> >>>> >>>> >>>> >>>> I agree that sounds like a better approach. Do you think there is >>>> any chance to convince the COMEDIA folks to follow the same approach? >>>> >>>>> >>>>> Paul >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 12 13:22:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09466 for ; Mon, 12 Jan 2004 13:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6hI-0007rA-NY for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 13:21:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CILuxH030196 for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 13:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6hI-0007qu-IR for simple-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 13:21:56 -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 NAA09448 for ; Mon, 12 Jan 2004 13:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag6hG-0007Gz-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 13:21:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag6fQ-0007DT-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 13:20:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag6dZ-0007A9-00; Mon, 12 Jan 2004 13:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6dW-0007fD-7V; Mon, 12 Jan 2004 13:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag6dU-0007eb-8s for simple@optimus.ietf.org; Mon, 12 Jan 2004 13:18:00 -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 NAA09311 for ; Mon, 12 Jan 2004 13:17:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag6dS-00078u-00 for simple@ietf.org; Mon, 12 Jan 2004 13:17:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag6bj-00076s-00 for simple@ietf.org; Mon, 12 Jan 2004 13:16:12 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ag6bB-00074D-00; Mon, 12 Jan 2004 13:15:37 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0CIEhVO006307; Mon, 12 Jan 2004 10:15:04 -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 AFE43989; Mon, 12 Jan 2004 13:14:42 -0500 (EST) Message-ID: <4002E412.2070608@cisco.com> From: Paul Kyzivat 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: David Yon CC: simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 13:14:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Yon wrote: > Here I am! :-) > > Dialout.Net is defunct, but at the moment I am still willing to support > the comedia draft, although I have much less time available to me for it. I was suspecting Dialout might be gone because attempts to access the web site timed out. Glad to hear that you are still around. Maybe you should submit a new version of comedia just to update your address. > My only concern with a "version" attribute is that it causes a > reconnection by inference. I'm afraid that it would be rife with > temptation to use it to version-stamp the session for other reasons that > do not imply the impetus to reconnect. Is there some tangible scenario > where "version" is superior to "reconnect"? I can see how you might consider reconnection by inference to be a negative. But in my view that is also its appeal. The point is to preserve the behavior that reuse of unchanged SDP acts as a no-op. Once you introduce the a=reconnect attribute, a subsequent offer/answer cycle that reuses sdp containing that will cause another reconnect, which isn't a no-op. By using a=version, it is the detection of a revised version number that causes the reconnect. So a subsequent offer/answer cycle using the same sdp will not see a change in version number and so will not cause another reconnect. This is of significance whenever there might be components that manipulate offers and answers in a generic way. For instance, if you have a UA that manages multiple media streams, there may be one component that decomposes the sdp and then interacts with a separate component in the UA for each stream. If there is a need to make a change in one stream, it may simply want to make a change in the description of the affected stream without dealing with the components responsible for other streams. In general, with the exception of a=reconnect, it can do this. I am not especially attached to the name "version". I am certainly willing to entertain some other name for the attribute that is clearer and less prone to invite abuse. E.g. we might consider a=reconnect:NNN. Paul > At 10:06 AM 1/12/2004, Paul Kyzivat wrote: > >> My attempts to reach David Yon at the address he has listed in the >> comedia draft (yon@dialout.net) have bounced. Does anybody know >> whether he is still at Dialout.Net, or even if Dialout.Net still exists? >> >> Paul >> >> Paul Kyzivat wrote: >> >>> Ben, >>> I'm copying David Yon on this since he is author of comedia. This >>> probably won't make any sense out of context to him, so I will >>> separately send him some of the earlier discussion. >>> I don't recall what the current status of comedia is. It is currently >>> listed as a WG draft, but there don't seem to be any goals listed for >>> it. >>> Paul >>> Ben Campbell wrote: >>> >>>> Paul Kyzivat wrote: >>>> >>>>> >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> (More comments on same email...) >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>>> >>>>>>> Using the same media lines for the replacement session solves the >>>>>>> association problem for any media type - MSRP, RTP, whatever. But >>>>>>> it also does leave the problem of distinguishing a "reconnect" >>>>>>> offer from a "don't change anything" offer. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>> (section 5 of current comedia draft.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> That would probably work. The feature in comedia didn't end up as I >>>>> hoped it would. While it does mean you have to do something special >>>>> (add the a=reconnect) attribute to cause a reconnect, having done >>>>> that once you then have to do something else (remove the >>>>> a=reconnect) in a subsequent exchange. >>>>> >>>>> I think it would be better if there were something like >>>>> a=version:nnn, which would just be a version number for a >>>>> particular media session. Then whenever it changes you reconnect. >>>>> If the attribute was absent it could be defaulted from the o-line. >>>> >>>> >>>> >>>> >>>> I agree that sounds like a better approach. Do you think there is >>>> any chance to convince the COMEDIA folks to follow the same approach? >>>> >>>>> >>>>> Paul >>>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 12 15:45:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18272 for ; Mon, 12 Jan 2004 15:45:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8wA-00071J-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 15:45:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8ve-0006sM-00 for simple-archive@ietf.org; Mon, 12 Jan 2004 15:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag8tu-0006gZ-00; Mon, 12 Jan 2004 15:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8tp-0004Dc-7W; Mon, 12 Jan 2004 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8t0-0004CO-QR for simple@optimus.ietf.org; Mon, 12 Jan 2004 15:42:10 -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 PAA17873 for ; Mon, 12 Jan 2004 15:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8sz-0006Zn-00 for simple@ietf.org; Mon, 12 Jan 2004 15:42:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8rJ-0006Ud-00 for simple@ietf.org; Mon, 12 Jan 2004 15:40:26 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8q0-0006PP-00; Mon, 12 Jan 2004 15:39:04 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2004 12:38:49 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0CKcULE022719; Mon, 12 Jan 2004 15:38:31 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFE61034; Mon, 12 Jan 2004 15:38:29 -0500 (EST) Message-ID: <400305C5.10009@cisco.com> From: Paul Kyzivat 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: David Yon CC: simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 15:38:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit David Yon wrote: > > "reconnect:NNN" would probably be a useful enhancement to "reconnect", > and if connection reestablishment was the goal of "version", then I > would vote for that. That is certainly the driving force behind it at the moment. Unless someone can envision another use then I am happy to go along with this. > The only issue would be that of the original SDP exchange. It hardly > seems appropriate to include a "reconnect" attribute in the initial > exchange, but then when you want to negotiate a new connection and > suddenly this attribute appears, what's the appropriate value for NNN? > A couple of possibilities: > > a) Don't worry about "a=reconnect:0" being an odd inclusion, and make it > mandatory. > > b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". > Therefore the first reconnection negotiation would have "a=reconnect:1". > > c) Make the omission imply "a=reconnect:", such that the first > appearance of "reconnect" would be "a=reconnect:0". > > I would guess that (a) makes the most sense. Thoughts? That seems reasonable. In practice the number doesn't mean much except that it change. It would work as well if it were an opaque token. When considered as a version number it makes more sense as an increasing number. How about a=connection:NNN? (With a default of 1.) This numbers the connections used to convey the media stream. This is clearly associated with connections, so it isn't prone to abuse, and it also conveys a clear semantic for the number. > Also, are there any possibilities of race conditions where the NNN would > get out of sync between the two endpoints? If so, how would that be > resolved? I don't believe there are any race conditions, though there is always the possibility of buggy endpoint getting confused. I don't think there are any race conditions because NNN isn't negotiated - it is always managed by one end and conveyed to the other end. In an offer/answer exchange, each side could conceivably provide its own value for a=reconnect:NNN. It is only meaningful when provided by a passive end to an active end, because it determines whether the active end should reconnect. In the case of MSRP, there is only one connection, so reconnection only makes sense in the direction of the original connection. In the case of comedia there could conceivably be two connections, one in each direction. If so, it is conceivable that an offer/answer exchange could have a=reconnect=NNN going both ways, and resulting in zero, one, or two reconnections. > What about the additional state that must be tracked (the reconnection > number)? I don't think that comedia-05 represents any additional state > over connectionless media, which wouldn't be true for "reconnect:NNN". There is extra implicit state in comedia. It must remember active, passive, or both, whether still listening if passive, whether connected if active, and ultimately the connection itself must be remembered as state. This adds a number that must be associated with the connection. Doesn't seem like a big burden. >> Paul >> >>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>> >>>> My attempts to reach David Yon at the address he has listed in the >>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>> exists? >>>> >>>> Paul >>>> >>>> Paul Kyzivat wrote: >>>> >>>>> Ben, >>>>> I'm copying David Yon on this since he is author of comedia. This >>>>> probably won't make any sense out of context to him, so I will >>>>> separately send him some of the earlier discussion. >>>>> I don't recall what the current status of comedia is. It is >>>>> currently listed as a WG draft, but there don't seem to be any >>>>> goals listed for it. >>>>> Paul >>>>> Ben Campbell wrote: >>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Ben Campbell wrote: >>>>>>> >>>>>>>> (More comments on same email...) >>>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>>> >>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>> whatever. But it also does leave the problem of distinguishing >>>>>>>>> a "reconnect" offer from a "don't change anything" offer. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>> help? (section 5 of current comedia draft.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> That would probably work. The feature in comedia didn't end up as >>>>>>> I hoped it would. While it does mean you have to do something >>>>>>> special (add the a=reconnect) attribute to cause a reconnect, >>>>>>> having done that once you then have to do something else (remove >>>>>>> the a=reconnect) in a subsequent exchange. >>>>>>> >>>>>>> I think it would be better if there were something like >>>>>>> a=version:nnn, which would just be a version number for a >>>>>>> particular media session. Then whenever it changes you reconnect. >>>>>>> If the attribute was absent it could be defaulted from the o-line. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I agree that sounds like a better approach. Do you think there is >>>>>> any chance to convince the COMEDIA folks to follow the same approach? >>>>>> >>>>>>> >>>>>>> Paul >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 12 15:46:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18396 for ; Mon, 12 Jan 2004 15:46:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8wP-0004RF-S7 for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 15:45:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CKjfhx017057 for simple-archive@odin.ietf.org; Mon, 12 Jan 2004 15:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8wP-0004R2-OQ for simple-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 15:45:41 -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 PAA18338 for ; Mon, 12 Jan 2004 15:45:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8wO-00072J-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 15:45:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8vm-0006uz-00 for simple-web-archive@ietf.org; Mon, 12 Jan 2004 15:45:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag8tu-0006gZ-00; Mon, 12 Jan 2004 15:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8tp-0004Dc-7W; Mon, 12 Jan 2004 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8t0-0004CO-QR for simple@optimus.ietf.org; Mon, 12 Jan 2004 15:42:10 -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 PAA17873 for ; Mon, 12 Jan 2004 15:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8sz-0006Zn-00 for simple@ietf.org; Mon, 12 Jan 2004 15:42:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8rJ-0006Ud-00 for simple@ietf.org; Mon, 12 Jan 2004 15:40:26 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8q0-0006PP-00; Mon, 12 Jan 2004 15:39:04 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2004 12:38:49 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0CKcULE022719; Mon, 12 Jan 2004 15:38:31 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFE61034; Mon, 12 Jan 2004 15:38:29 -0500 (EST) Message-ID: <400305C5.10009@cisco.com> From: Paul Kyzivat 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: David Yon CC: simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 15:38:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Yon wrote: > > "reconnect:NNN" would probably be a useful enhancement to "reconnect", > and if connection reestablishment was the goal of "version", then I > would vote for that. That is certainly the driving force behind it at the moment. Unless someone can envision another use then I am happy to go along with this. > The only issue would be that of the original SDP exchange. It hardly > seems appropriate to include a "reconnect" attribute in the initial > exchange, but then when you want to negotiate a new connection and > suddenly this attribute appears, what's the appropriate value for NNN? > A couple of possibilities: > > a) Don't worry about "a=reconnect:0" being an odd inclusion, and make it > mandatory. > > b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". > Therefore the first reconnection negotiation would have "a=reconnect:1". > > c) Make the omission imply "a=reconnect:", such that the first > appearance of "reconnect" would be "a=reconnect:0". > > I would guess that (a) makes the most sense. Thoughts? That seems reasonable. In practice the number doesn't mean much except that it change. It would work as well if it were an opaque token. When considered as a version number it makes more sense as an increasing number. How about a=connection:NNN? (With a default of 1.) This numbers the connections used to convey the media stream. This is clearly associated with connections, so it isn't prone to abuse, and it also conveys a clear semantic for the number. > Also, are there any possibilities of race conditions where the NNN would > get out of sync between the two endpoints? If so, how would that be > resolved? I don't believe there are any race conditions, though there is always the possibility of buggy endpoint getting confused. I don't think there are any race conditions because NNN isn't negotiated - it is always managed by one end and conveyed to the other end. In an offer/answer exchange, each side could conceivably provide its own value for a=reconnect:NNN. It is only meaningful when provided by a passive end to an active end, because it determines whether the active end should reconnect. In the case of MSRP, there is only one connection, so reconnection only makes sense in the direction of the original connection. In the case of comedia there could conceivably be two connections, one in each direction. If so, it is conceivable that an offer/answer exchange could have a=reconnect=NNN going both ways, and resulting in zero, one, or two reconnections. > What about the additional state that must be tracked (the reconnection > number)? I don't think that comedia-05 represents any additional state > over connectionless media, which wouldn't be true for "reconnect:NNN". There is extra implicit state in comedia. It must remember active, passive, or both, whether still listening if passive, whether connected if active, and ultimately the connection itself must be remembered as state. This adds a number that must be associated with the connection. Doesn't seem like a big burden. >> Paul >> >>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>> >>>> My attempts to reach David Yon at the address he has listed in the >>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>> exists? >>>> >>>> Paul >>>> >>>> Paul Kyzivat wrote: >>>> >>>>> Ben, >>>>> I'm copying David Yon on this since he is author of comedia. This >>>>> probably won't make any sense out of context to him, so I will >>>>> separately send him some of the earlier discussion. >>>>> I don't recall what the current status of comedia is. It is >>>>> currently listed as a WG draft, but there don't seem to be any >>>>> goals listed for it. >>>>> Paul >>>>> Ben Campbell wrote: >>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Ben Campbell wrote: >>>>>>> >>>>>>>> (More comments on same email...) >>>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>>> >>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>> whatever. But it also does leave the problem of distinguishing >>>>>>>>> a "reconnect" offer from a "don't change anything" offer. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>> help? (section 5 of current comedia draft.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> That would probably work. The feature in comedia didn't end up as >>>>>>> I hoped it would. While it does mean you have to do something >>>>>>> special (add the a=reconnect) attribute to cause a reconnect, >>>>>>> having done that once you then have to do something else (remove >>>>>>> the a=reconnect) in a subsequent exchange. >>>>>>> >>>>>>> I think it would be better if there were something like >>>>>>> a=version:nnn, which would just be a version number for a >>>>>>> particular media session. Then whenever it changes you reconnect. >>>>>>> If the attribute was absent it could be defaulted from the o-line. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I agree that sounds like a better approach. Do you think there is >>>>>> any chance to convince the COMEDIA folks to follow the same approach? >>>>>> >>>>>>> >>>>>>> Paul >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 15 09:59:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09252 for ; Thu, 15 Jan 2004 09:59:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8y3-0006Lz-00 for simple-archive@ietf.org; Thu, 15 Jan 2004 09:59:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8x6-0006Jj-00 for simple-archive@ietf.org; Thu, 15 Jan 2004 09:58:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8we-0006IU-00; Thu, 15 Jan 2004 09:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8wb-0004FG-Ev; Thu, 15 Jan 2004 09:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8wA-0004Cy-7P for simple@optimus.ietf.org; Thu, 15 Jan 2004 09:57:34 -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 JAA09195 for ; Thu, 15 Jan 2004 09:57:31 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8w8-0006Hi-00 for simple@ietf.org; Thu, 15 Jan 2004 09:57:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8vG-0006GD-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:40 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8uk-0006E9-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FEu4Y15948 for ; Thu, 15 Jan 2004 16:56:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 16:56:01 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 16:56:02 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DB77.B17E5CC7" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B171@esebe019.ntc.nokia.com> Thread-Topic: Review of draft-ietf-simple-pres-filter-reqs-02 Thread-Index: AcPV5AWX80yTV0BPR5+ZfiU+n8PG+wFcH/5Q To: Cc: X-OriginalArrivalTime: 15 Jan 2004 14:56:02.0585 (UTC) FILETIME=[B1B9F090:01C3DB77] Subject: [Simple] RE: Review of draft-ietf-simple-pres-filter-reqs-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Jan 2004 16:56:02 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DB77.B17E5CC7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chris, =20 Thanks for the comments. Some comments inline... -----Original Message----- From: ext Chris Boulton [mailto:cboulton@ubiquity.net] Sent: 08.January.2004 14:36 To: Khartabil Hisham (Nokia-TP/Helsinki) Cc: simple@ietf.org Subject: Review of draft-ietf-simple-pres-filter-reqs-02 =20 2) Section 3.2=20 Are the following 2 requirements really necessary:- =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity list whose presence information a certain filter is applied to. =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity sub-list whose presence information a certain filter is applied to. =20 Should the requirement just be that it can indicate a presentity. If = that happens to be a list resource then so be it.=20 =20 I think it is necessary to make sure that filtering also works with = event lists. Different parts of the network handle filters depending on = the nature of the subscription. For example a Resource List Server would = most likely handle filters to an event list and therefore requiring the = filtering to work for event lists is needed.=20 =20 4) Section 3.3 Is the following requirement needed:- =20 REQ xx: The triggering conditions MUST be based on the presence information. For example, the change of value of the element.=20 =20 I think it is needed. There may be other external triggers for a = notification to be sent. The filtering solution must not define those, = but concentrate on triggers in changes to the presence information = document only.=20 =20 Would it be better for a more generic approach for all event packages = and just leave only the next requirement in to cover all triggers:-=20 =20 Remember these are presence filtering requirements. We originally had a = general filtering requirements document, but it was decided a couple of = IETF meeting ago to write separate filtering requirements for each event = package. =20 REQ xx: It MUST be possible to specify logical expressions based on the value of elements defined in the package for the purpose of triggering. This covers expressions (tests) related to the change of an element's value, and reaching a certain value of an element. =20 5) Section 3.4 - Should the following requirements be made generic = rather than being tied to presence:-=20 =20 Please see above.=20 =20 =20 6) Section 4.2 - Do we need to specify a requirement for when a = subscription containing a filter expires (invalid)? Does the filter = remain or is it removed also?=20 =20 Added: It MUST NOT be required for a watcher to explicitly remove a = filter f the subscription was terminated or has expired. I.e. The = filter is automatically removed with the subscription. =20 7) Section 5.1 - The requirement reads:- =20 REQ xx: It MUST be possible for a watcher to specify different filter for any individual member of a resource list in a resource list subscription. =20 If a user does specify a different filter to that of a resource list - = does this override - I would say 'yes' so perhaps this needs to be = mentioned.=20 =20 It is most likely that the event list filter is handled by the RLS while = the individual resource filter is handled at that resource's presence = server. Therefore no need to mention which one overrides. I added this = requirement though: =20 It MUST be possible to specify a filter for an event list and a filters = for resources within that list in the same subscription request.=20 =20 Thanks again for the comments. /Hisham =20 Hope some of this is useful, =20 Best Regards, =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 This message has been scanned for viruses by = MailControl, a service from = BlackSpider Technologies. ------_=_NextPart_001_01C3DB77.B17E5CC7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Chris,
 
Thanks=20 for the comments. Some comments inline...
-----Original Message-----
From: ext Chris Boulton=20 [mailto:cboulton@ubiquity.net]
Sent: 08.January.2004=20 14:36
To: Khartabil Hisham (Nokia-TP/Helsinki)
Cc: = simple@ietf.org
Subject: Review of=20 draft-ietf-simple-pres-filter-reqs-02

 

2) Section 3.2=20

Are the following 2 = requirements=20 really necessary:-

 

REQ xx: It MUST be = possible for=20 the watcher to indicate, in the

   filter=20 criteria, the target presentity list whose = presence

   information a certain filter is applied=20 to.

 

   REQ xx: It MUST be = possible for=20 the watcher to indicate, in the

   filter=20 criteria, the target presentity sub-list = whose=20 presence

   information a certain filter is applied=20 to.

 

Should=20 the requirement just be that it can indicate a = presentity. =20 If that happens to be a list resource then so be it. 

 

I think it is = necessary to make=20 sure that filtering also works with event lists. Different parts = of the=20 network handle filters depending on the nature of the subscription. = For=20 example a Resource List Server would most likely handle filters to an = event=20 list and therefore requiring the filtering to work for event lists is=20 needed. 

 

4) Section=20 3.3

Is the following = requirement=20 needed:-

 

REQ xx: The triggering = conditions=20 MUST be based on the presence

   information. For example, the change of value of = the=20 <status>

   element. 

 

I think it is needed. = There may=20 be other external triggers for a notification to be sent. The = filtering=20 solution must not define those, but concentrate on triggers in changes = to the=20 presence information document = only. 

 

Would it=20 be better for a more generic approach for all event packages and just = leave=20 only the next requirement in to cover all triggers:- 

 

Remember these are = presence=20 filtering requirements. We originally had a general filtering = requirements=20 document, but it was decided a couple of IETF meeting ago to write = separate=20 filtering requirements for each event = package.

 

REQ xx: It MUST be = possible to=20 specify logical expressions based on

   the=20 value of elements defined in the package for the purpose=20 of

   triggering. This covers expressions (tests) = related to the=20 change of

   an=20 element's value, and reaching a certain value of an=20 element.

 

5)=20 Section 3.4 - Should the following requirements be made generic rather = than=20 being tied to presence:- 

 

Please see=20 above. 

 

  

6)=20 Section 4.2 – Do we need to specify a requirement for when a = subscription=20 containing a filter expires (invalid)? =20 Does the filter remain or is it removed also? 

 

Added: It MUST NOT = be required=20 for a watcher to explicitly remove a filter f the subscription = was=20 terminated or has expired.  I.e. The filter is automatically = removed with=20 the subscription.

 

7) Section 5.1 – = The requirement=20 reads:-

 

REQ xx: It MUST be = possible for a=20 watcher to specify different filter

   for any=20 individual member of a resource list in a resource=20 list

   subscription.

 

If a user=20 does specify a different filter to that of a resource list – = does this=20 override – I would say ‘yes’ so perhaps this needs = to be mentioned. 

 

It is most likely that the event list filter = is handled=20 by the RLS while the individual resource filter is handled at that = resource's=20 presence server. Therefore no need to mention which one overrides. I = added=20 this requirement though:

 

 It MUST be possible to specify a filter = for an=20 event list and a filters for resources within that list in the same=20 subscription request.

 

Thanks again for the = comments.

/Hisham

 

Hope some of this is=20 useful,

 

Best=20 Regards,

 

Chris.

 

 

------------------------------------------------

Chris=20 Boulton

Ubiquity=20 Software

 

Tel : = +44 (0)=20 1633765600

Fax : = +44 (0)=20 1633765601

------------------------------------------------

 

 



This = message has been=20 scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C3DB77.B17E5CC7-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 15 09:59:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09290 for ; Thu, 15 Jan 2004 09:59:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8y6-0006MQ-00 for simple-archive@ietf.org; Thu, 15 Jan 2004 09:59:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8xB-0006K1-00 for simple-archive@ietf.org; Thu, 15 Jan 2004 09:58:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8we-0006IV-00; Thu, 15 Jan 2004 09:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8wa-0004F6-Vt; Thu, 15 Jan 2004 09:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8w6-0004Ct-KX for simple@optimus.ietf.org; Thu, 15 Jan 2004 09:57:30 -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 JAA09186 for ; Thu, 15 Jan 2004 09:57:27 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8w4-0006HC-00 for simple@ietf.org; Thu, 15 Jan 2004 09:57:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8v7-0006Et-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:29 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8uA-0006Cf-00 for simple@ietf.org; Thu, 15 Jan 2004 09:55:30 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FEtRY15071 for ; Thu, 15 Jan 2004 16:55:28 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 16:55:25 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 16:55:24 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: Review of the filtering requirements work Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B170@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: Review of the filtering requirements work Thread-Index: AcOy37r4g8MRBYaYRJqKBrmG+4t1VAoZznzg To: , Cc: X-OriginalArrivalTime: 15 Jan 2004 14:55:24.0996 (UTC) FILETIME=[9B525040:01C3DB77] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Jan 2004 16:55:23 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Paul, Thanks for the comments, and apologies for the delay in responding. The = requirements will be updated with most of your comments taken into = account. There is 1 comment below... > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 25.November.2003 01:06 > To: Robert Sparks > Cc: simple@ietf.org > Subject: [Simple] Re: Review of the filtering requirements work >=20 >=20 > - draft-ietf-simple-pres-filter-reqs-02.txt >=20 > Section 3.3, first REQ: I don't find this entirely clear. I=20 > think it is=20 > trying to say that filter criteria may only reference=20 > elements that the=20 > subscriber is permitted to request as notification content.=20 > If I'm right=20 > you could improve the requirement by saying that. If I'm=20 > wrong, then the=20 > requirement really didn't work for me. You are wrong :) I think I will remove this requirement in any case = since I believe it does not require anything from the filtering format, = but is more if an implementation issue.=20 About your suggestion: The watcher most likely will not know what he is = permitted to see. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 15 10:00:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09346 for ; Thu, 15 Jan 2004 10:00:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8y7-0004UR-LX for simple-archive@odin.ietf.org; Thu, 15 Jan 2004 09:59:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FExZRp017256 for simple-archive@odin.ietf.org; Thu, 15 Jan 2004 09:59:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8y7-0004UF-GS for simple-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 09:59:35 -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 JAA09287 for ; Thu, 15 Jan 2004 09:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8y5-0006MH-00 for simple-web-archive@ietf.org; Thu, 15 Jan 2004 09:59:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8x8-0006Js-00 for simple-web-archive@ietf.org; Thu, 15 Jan 2004 09:58:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8we-0006IU-00; Thu, 15 Jan 2004 09:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8wb-0004FG-Ev; Thu, 15 Jan 2004 09:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8wA-0004Cy-7P for simple@optimus.ietf.org; Thu, 15 Jan 2004 09:57:34 -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 JAA09195 for ; Thu, 15 Jan 2004 09:57:31 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8w8-0006Hi-00 for simple@ietf.org; Thu, 15 Jan 2004 09:57:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8vG-0006GD-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:40 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8uk-0006E9-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FEu4Y15948 for ; Thu, 15 Jan 2004 16:56:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 16:56:01 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 16:56:02 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DB77.B17E5CC7" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B171@esebe019.ntc.nokia.com> Thread-Topic: Review of draft-ietf-simple-pres-filter-reqs-02 Thread-Index: AcPV5AWX80yTV0BPR5+ZfiU+n8PG+wFcH/5Q To: Cc: X-OriginalArrivalTime: 15 Jan 2004 14:56:02.0585 (UTC) FILETIME=[B1B9F090:01C3DB77] Subject: [Simple] RE: Review of draft-ietf-simple-pres-filter-reqs-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Jan 2004 16:56:02 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DB77.B17E5CC7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chris, =20 Thanks for the comments. Some comments inline... -----Original Message----- From: ext Chris Boulton [mailto:cboulton@ubiquity.net] Sent: 08.January.2004 14:36 To: Khartabil Hisham (Nokia-TP/Helsinki) Cc: simple@ietf.org Subject: Review of draft-ietf-simple-pres-filter-reqs-02 =20 2) Section 3.2=20 Are the following 2 requirements really necessary:- =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity list whose presence information a certain filter is applied to. =20 REQ xx: It MUST be possible for the watcher to indicate, in the filter criteria, the target presentity sub-list whose presence information a certain filter is applied to. =20 Should the requirement just be that it can indicate a presentity. If = that happens to be a list resource then so be it.=20 =20 I think it is necessary to make sure that filtering also works with = event lists. Different parts of the network handle filters depending on = the nature of the subscription. For example a Resource List Server would = most likely handle filters to an event list and therefore requiring the = filtering to work for event lists is needed.=20 =20 4) Section 3.3 Is the following requirement needed:- =20 REQ xx: The triggering conditions MUST be based on the presence information. For example, the change of value of the element.=20 =20 I think it is needed. There may be other external triggers for a = notification to be sent. The filtering solution must not define those, = but concentrate on triggers in changes to the presence information = document only.=20 =20 Would it be better for a more generic approach for all event packages = and just leave only the next requirement in to cover all triggers:-=20 =20 Remember these are presence filtering requirements. We originally had a = general filtering requirements document, but it was decided a couple of = IETF meeting ago to write separate filtering requirements for each event = package. =20 REQ xx: It MUST be possible to specify logical expressions based on the value of elements defined in the package for the purpose of triggering. This covers expressions (tests) related to the change of an element's value, and reaching a certain value of an element. =20 5) Section 3.4 - Should the following requirements be made generic = rather than being tied to presence:-=20 =20 Please see above.=20 =20 =20 6) Section 4.2 - Do we need to specify a requirement for when a = subscription containing a filter expires (invalid)? Does the filter = remain or is it removed also?=20 =20 Added: It MUST NOT be required for a watcher to explicitly remove a = filter f the subscription was terminated or has expired. I.e. The = filter is automatically removed with the subscription. =20 7) Section 5.1 - The requirement reads:- =20 REQ xx: It MUST be possible for a watcher to specify different filter for any individual member of a resource list in a resource list subscription. =20 If a user does specify a different filter to that of a resource list - = does this override - I would say 'yes' so perhaps this needs to be = mentioned.=20 =20 It is most likely that the event list filter is handled by the RLS while = the individual resource filter is handled at that resource's presence = server. Therefore no need to mention which one overrides. I added this = requirement though: =20 It MUST be possible to specify a filter for an event list and a filters = for resources within that list in the same subscription request.=20 =20 Thanks again for the comments. /Hisham =20 Hope some of this is useful, =20 Best Regards, =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 This message has been scanned for viruses by = MailControl, a service from = BlackSpider Technologies. ------_=_NextPart_001_01C3DB77.B17E5CC7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Chris,
 
Thanks=20 for the comments. Some comments inline...
-----Original Message-----
From: ext Chris Boulton=20 [mailto:cboulton@ubiquity.net]
Sent: 08.January.2004=20 14:36
To: Khartabil Hisham (Nokia-TP/Helsinki)
Cc: = simple@ietf.org
Subject: Review of=20 draft-ietf-simple-pres-filter-reqs-02

 

2) Section 3.2=20

Are the following 2 = requirements=20 really necessary:-

 

REQ xx: It MUST be = possible for=20 the watcher to indicate, in the

   filter=20 criteria, the target presentity list whose = presence

   information a certain filter is applied=20 to.

 

   REQ xx: It MUST be = possible for=20 the watcher to indicate, in the

   filter=20 criteria, the target presentity sub-list = whose=20 presence

   information a certain filter is applied=20 to.

 

Should=20 the requirement just be that it can indicate a = presentity. =20 If that happens to be a list resource then so be it. 

 

I think it is = necessary to make=20 sure that filtering also works with event lists. Different parts = of the=20 network handle filters depending on the nature of the subscription. = For=20 example a Resource List Server would most likely handle filters to an = event=20 list and therefore requiring the filtering to work for event lists is=20 needed. 

 

4) Section=20 3.3

Is the following = requirement=20 needed:-

 

REQ xx: The triggering = conditions=20 MUST be based on the presence

   information. For example, the change of value of = the=20 <status>

   element. 

 

I think it is needed. = There may=20 be other external triggers for a notification to be sent. The = filtering=20 solution must not define those, but concentrate on triggers in changes = to the=20 presence information document = only. 

 

Would it=20 be better for a more generic approach for all event packages and just = leave=20 only the next requirement in to cover all triggers:- 

 

Remember these are = presence=20 filtering requirements. We originally had a general filtering = requirements=20 document, but it was decided a couple of IETF meeting ago to write = separate=20 filtering requirements for each event = package.

 

REQ xx: It MUST be = possible to=20 specify logical expressions based on

   the=20 value of elements defined in the package for the purpose=20 of

   triggering. This covers expressions (tests) = related to the=20 change of

   an=20 element's value, and reaching a certain value of an=20 element.

 

5)=20 Section 3.4 - Should the following requirements be made generic rather = than=20 being tied to presence:- 

 

Please see=20 above. 

 

  

6)=20 Section 4.2 – Do we need to specify a requirement for when a = subscription=20 containing a filter expires (invalid)? =20 Does the filter remain or is it removed also? 

 

Added: It MUST NOT = be required=20 for a watcher to explicitly remove a filter f the subscription = was=20 terminated or has expired.  I.e. The filter is automatically = removed with=20 the subscription.

 

7) Section 5.1 – = The requirement=20 reads:-

 

REQ xx: It MUST be = possible for a=20 watcher to specify different filter

   for any=20 individual member of a resource list in a resource=20 list

   subscription.

 

If a user=20 does specify a different filter to that of a resource list – = does this=20 override – I would say ‘yes’ so perhaps this needs = to be mentioned. 

 

It is most likely that the event list filter = is handled=20 by the RLS while the individual resource filter is handled at that = resource's=20 presence server. Therefore no need to mention which one overrides. I = added=20 this requirement though:

 

 It MUST be possible to specify a filter = for an=20 event list and a filters for resources within that list in the same=20 subscription request.

 

Thanks again for the = comments.

/Hisham

 

Hope some of this is=20 useful,

 

Best=20 Regards,

 

Chris.

 

 

------------------------------------------------

Chris=20 Boulton

Ubiquity=20 Software

 

Tel : = +44 (0)=20 1633765600

Fax : = +44 (0)=20 1633765601

------------------------------------------------

 

 



This = message has been=20 scanned for viruses by MailControl, a service from BlackSpider Technologies.

------_=_NextPart_001_01C3DB77.B17E5CC7-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 15 10:00:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09359 for ; Thu, 15 Jan 2004 10:00:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8y9-0004Vc-KZ for simple-archive@odin.ietf.org; Thu, 15 Jan 2004 09:59:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FExbdg017326 for simple-archive@odin.ietf.org; Thu, 15 Jan 2004 09:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8y9-0004VN-HO for simple-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 09:59:37 -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 JAA09309 for ; Thu, 15 Jan 2004 09:59:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8y7-0006Md-00 for simple-web-archive@ietf.org; Thu, 15 Jan 2004 09:59:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8xB-0006KA-00 for simple-web-archive@ietf.org; Thu, 15 Jan 2004 09:58:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8we-0006IV-00; Thu, 15 Jan 2004 09:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8wa-0004F6-Vt; Thu, 15 Jan 2004 09:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8w6-0004Ct-KX for simple@optimus.ietf.org; Thu, 15 Jan 2004 09:57:30 -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 JAA09186 for ; Thu, 15 Jan 2004 09:57:27 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8w4-0006HC-00 for simple@ietf.org; Thu, 15 Jan 2004 09:57:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8v7-0006Et-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:29 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8uA-0006Cf-00 for simple@ietf.org; Thu, 15 Jan 2004 09:55:30 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FEtRY15071 for ; Thu, 15 Jan 2004 16:55:28 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 16:55:25 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 16:55:24 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: Review of the filtering requirements work Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B170@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Re: Review of the filtering requirements work Thread-Index: AcOy37r4g8MRBYaYRJqKBrmG+4t1VAoZznzg To: , Cc: X-OriginalArrivalTime: 15 Jan 2004 14:55:24.0996 (UTC) FILETIME=[9B525040:01C3DB77] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Jan 2004 16:55:23 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paul, Thanks for the comments, and apologies for the delay in responding. The = requirements will be updated with most of your comments taken into = account. There is 1 comment below... > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 25.November.2003 01:06 > To: Robert Sparks > Cc: simple@ietf.org > Subject: [Simple] Re: Review of the filtering requirements work >=20 >=20 > - draft-ietf-simple-pres-filter-reqs-02.txt >=20 > Section 3.3, first REQ: I don't find this entirely clear. I=20 > think it is=20 > trying to say that filter criteria may only reference=20 > elements that the=20 > subscriber is permitted to request as notification content.=20 > If I'm right=20 > you could improve the requirement by saying that. If I'm=20 > wrong, then the=20 > requirement really didn't work for me. You are wrong :) I think I will remove this requirement in any case = since I believe it does not require anything from the filtering format, = but is more if an implementation issue.=20 About your suggestion: The watcher most likely will not know what he is = permitted to see. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 15 10:00:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09413 for ; Thu, 15 Jan 2004 10:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8z8-0006Qd-00 for simple-archive@ietf.org; Thu, 15 Jan 2004 10:00:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8yE-0006Nk-00 for simple-archive@ietf.org; Thu, 15 Jan 2004 09:59:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8xZ-0006L3-00; Thu, 15 Jan 2004 09:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8xZ-0004Oc-3B; Thu, 15 Jan 2004 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8x4-0004Ix-R0 for simple@optimus.ietf.org; Thu, 15 Jan 2004 09:58:30 -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 JAA09217 for ; Thu, 15 Jan 2004 09:58:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8x2-0006JD-00 for simple@ietf.org; Thu, 15 Jan 2004 09:58:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8w8-0006Hn-00 for simple@ietf.org; Thu, 15 Jan 2004 09:57:33 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8vI-0006GI-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:40 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FEuc202437 for ; Thu, 15 Jan 2004 16:56:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 16:56:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 16:56:38 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B172@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 Thread-Index: AcPWxiDEeZ/ATbs0QVaMgRePH3lanAEkrxKw To: , X-OriginalArrivalTime: 15 Jan 2004 14:56:38.0433 (UTC) FILETIME=[C717E910:01C3DB77] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Jan 2004 16:56:37 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Aki, Thanks for the comments. Some replies inline... > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Niemi Aki (Nokia-M/Helsinki) > Sent: 09.January.2004 17:30 > To: simple@ietf.org > Subject: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 >=20 >=20 > All, >=20 > Here are some comments to the filtering requirements. As with=20 > the winfo=20 > reqs, I don't think there's anything major, just a bit of=20 > tweaking the=20 > format and language. >=20 > Cheers, > Aki >=20 > --- >=20 > - Overall, the draft suffers from the same thing as the=20 > winfo-reqs - it=20 > needs a chapter that explains the model and defines terms=20 > that then are=20 > used throughout the rest of the document. Done. >=20 > - Overall nit, requirement labels lack numbers Now requirements include numbers. >=20 > - In 3.2, 1st and 2nd req, if we replace "presentity" with=20 > "resource" in=20 > the 1sr req, then the second one becomes obsolete, no? I don't know. Is a resource the same as a resource list? >=20 > - In 3.2, 3rd req, what is a sub-list? If it means a presence=20 > list that=20 > is nested insiode another list, then the above bullet should=20 > cover that=20 > as well. I would like to keep requirements from event list and individual = presentities separate in order to make sure the solution works for both. >=20 > - In 3.2, 4th req is really hard to understand. Reworded. >=20 > - In 3.3, 1st sentence, this goes to my overall comment about=20 > model and=20 > terms, "triggering conditions" is not self-explanatory enough=20 > for me to=20 > understand immediately what were talking about here. >=20 > - In 3.3, 2nd req, if not on the presence information, what would the=20 > triggering be based on? Some external triggers. I can make a filter that triggers notifications = to be sent using time of day. This is outside the scope of this work. >=20 > - In 3.3, 3rd req is hard to parse, suggest rewording similar=20 > to one I=20 > suggested for winfo filtering reqs. Reworded. >=20 > - In 4.1.2, 2nd req, the server default here being "no filter"? means full state notification in presence case. In winfo, it could mean = first NOTIFY after a subscription carries full state, and subsequent = notfications carrying partial state. >=20 > - In 4.2, 4th req, how about: >=20 > It MUST be possible for the server to terminate a > subscription if a filter is no longer acceptable, > e.g., due to policy change or server load. That works. >=20 > - In 5.1, last req is confusing. Is this needed at all? Reworded. I think it is needed just to make sure that the solution works = with nested event lists. >=20 > - Move 5.3 to Security requirements. Moved.=20 >=20 > - In 6, 1st req contradicts earlier requirement on client receiving=20 > ack/nack from installing a filter. Added "if the server policy allows" to the earlier requirement (section = 4). >=20 > - In 6, 2nd requirement has no CAPS, what is the strength of this=20 > requirement? Fixed. >=20 > - In 6, last req is hard to understand. Suggest rewording, and using=20 > "SHOULD NOT convey information..." Reworded. Thanks again. Hisham >=20 > --- >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 15 10:01:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09472 for ; Thu, 15 Jan 2004 10:01:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8zC-0004hy-01 for simple-archive@odin.ietf.org; Thu, 15 Jan 2004 10:00:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FF0ffK018092 for simple-archive@odin.ietf.org; Thu, 15 Jan 2004 10:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8zB-0004hj-Sp for simple-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 10:00:41 -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 KAA09420 for ; Thu, 15 Jan 2004 10:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8z9-0006Qi-00 for simple-web-archive@ietf.org; Thu, 15 Jan 2004 10:00:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8yF-0006Nr-00 for simple-web-archive@ietf.org; Thu, 15 Jan 2004 09:59:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8xZ-0006L3-00; Thu, 15 Jan 2004 09:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8xZ-0004Oc-3B; Thu, 15 Jan 2004 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8x4-0004Ix-R0 for simple@optimus.ietf.org; Thu, 15 Jan 2004 09:58:30 -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 JAA09217 for ; Thu, 15 Jan 2004 09:58:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8x2-0006JD-00 for simple@ietf.org; Thu, 15 Jan 2004 09:58:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8w8-0006Hn-00 for simple@ietf.org; Thu, 15 Jan 2004 09:57:33 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8vI-0006GI-00 for simple@ietf.org; Thu, 15 Jan 2004 09:56:40 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FEuc202437 for ; Thu, 15 Jan 2004 16:56:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 16:56:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 16:56:38 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B172@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 Thread-Index: AcPWxiDEeZ/ATbs0QVaMgRePH3lanAEkrxKw To: , X-OriginalArrivalTime: 15 Jan 2004 14:56:38.0433 (UTC) FILETIME=[C717E910:01C3DB77] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Jan 2004 16:56:37 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Aki, Thanks for the comments. Some replies inline... > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Niemi Aki (Nokia-M/Helsinki) > Sent: 09.January.2004 17:30 > To: simple@ietf.org > Subject: [Simple] Comments on draft-ietf-simple-pres-filter-reqs-02 >=20 >=20 > All, >=20 > Here are some comments to the filtering requirements. As with=20 > the winfo=20 > reqs, I don't think there's anything major, just a bit of=20 > tweaking the=20 > format and language. >=20 > Cheers, > Aki >=20 > --- >=20 > - Overall, the draft suffers from the same thing as the=20 > winfo-reqs - it=20 > needs a chapter that explains the model and defines terms=20 > that then are=20 > used throughout the rest of the document. Done. >=20 > - Overall nit, requirement labels lack numbers Now requirements include numbers. >=20 > - In 3.2, 1st and 2nd req, if we replace "presentity" with=20 > "resource" in=20 > the 1sr req, then the second one becomes obsolete, no? I don't know. Is a resource the same as a resource list? >=20 > - In 3.2, 3rd req, what is a sub-list? If it means a presence=20 > list that=20 > is nested insiode another list, then the above bullet should=20 > cover that=20 > as well. I would like to keep requirements from event list and individual = presentities separate in order to make sure the solution works for both. >=20 > - In 3.2, 4th req is really hard to understand. Reworded. >=20 > - In 3.3, 1st sentence, this goes to my overall comment about=20 > model and=20 > terms, "triggering conditions" is not self-explanatory enough=20 > for me to=20 > understand immediately what were talking about here. >=20 > - In 3.3, 2nd req, if not on the presence information, what would the=20 > triggering be based on? Some external triggers. I can make a filter that triggers notifications = to be sent using time of day. This is outside the scope of this work. >=20 > - In 3.3, 3rd req is hard to parse, suggest rewording similar=20 > to one I=20 > suggested for winfo filtering reqs. Reworded. >=20 > - In 4.1.2, 2nd req, the server default here being "no filter"? means full state notification in presence case. In winfo, it could mean = first NOTIFY after a subscription carries full state, and subsequent = notfications carrying partial state. >=20 > - In 4.2, 4th req, how about: >=20 > It MUST be possible for the server to terminate a > subscription if a filter is no longer acceptable, > e.g., due to policy change or server load. That works. >=20 > - In 5.1, last req is confusing. Is this needed at all? Reworded. I think it is needed just to make sure that the solution works = with nested event lists. >=20 > - Move 5.3 to Security requirements. Moved.=20 >=20 > - In 6, 1st req contradicts earlier requirement on client receiving=20 > ack/nack from installing a filter. Added "if the server policy allows" to the earlier requirement (section = 4). >=20 > - In 6, 2nd requirement has no CAPS, what is the strength of this=20 > requirement? Fixed. >=20 > - In 6, last req is hard to understand. Suggest rewording, and using=20 > "SHOULD NOT convey information..." Reworded. Thanks again. Hisham >=20 > --- >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 16 12:32:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22394 for ; Fri, 16 Jan 2004 12:32:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXpf-0002C1-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 12:32:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXop-00028I-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 12:31:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhXoK-00024R-00; Fri, 16 Jan 2004 12:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXoD-0006fC-VJ; Fri, 16 Jan 2004 12:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXnf-0006cQ-EN for simple@optimus.ietf.org; Fri, 16 Jan 2004 12:30:27 -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 MAA22305 for ; Fri, 16 Jan 2004 12:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXnd-00022j-00 for simple@ietf.org; Fri, 16 Jan 2004 12:30:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXml-0001zK-00 for simple@ietf.org; Fri, 16 Jan 2004 12:29:33 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhXmK-0001vr-00; Fri, 16 Jan 2004 12:29:05 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GHSkgW007554; Fri, 16 Jan 2004 11:28:53 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40081F49.9080204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> <3FFD668E.4030709@cisco.com> In-Reply-To: <3FFD668E.4030709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Jan 2004 11:28:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sorry for the late reply--for some reason this just showed up in my inbox. (Or I just noticed it, anyway.) I don't see it as a problem to have MSRP mention that the ports must be distinct. We currently have a standard dummy value, rather than a random value. With this restriction, I think the answer is to say the sender can choose any legal non-zero value, and if multiple MSRP m-lines exist, they must have different port values. Is this sufficient? I don't see any reason to care about how a particular implementation goes about generating them. Paul Kyzivat wrote: > Hisham, > > I have an open mind about this right now. It seems to be a matter of > picking your favorite poison, since neither alternative is ideal: > - ensure that the ports used are unique even though they are ignored > - change SDP - something that is not very popular. > > So far, aside from me there are two votes, one on each side. From the > point of view of SIMPLE it is of course logistically simpler to leave > SDP alone. > > Paul > > P.S. It seems that simple wasn't on the mailing list, so I have added it. > > hisham.khartabil@nokia.com wrote: > >> I would hate to see exceptions like these when building a generic SDP >> parser with built it checks for compliancy. >> Why can't MSRP just follow that rule? >> >> Regards, >> Hisham >> >> >>> -----Original Message----- >>> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>> ext Paul E. Jones >>> Sent: 07.January.2004 23:15 >>> To: Paul Kyzivat; Flemming Andreasen >>> Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>> mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>> mgarakan@cisco.com >>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> Paul, >>> >>> While that sounds most unfortunate (I'd love to see an example if you >>> have >>> one), I think it would be exempt from this rule, because the port is >>> just a >>> dummy value. >>> >>> Paul >>> >>> ----- Original Message ----- From: "Paul Kyzivat" >>> To: "Flemming Andreasen" >>> Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>> ; "Stephen Casner" ; "Colin >>> Perkins" ; ; "Mostafa, Mohamed" >>> ; "Abdelhamid, Hisham" ; >>> ; >>> Sent: Wednesday, January 07, 2004 4:12 PM >>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> >>>> I recently encountered an interesting case relevant to this >>> >>> >>> while making >>> >>>> up an example for MSRP. >>>> >>>> In MSRP the port number is not used, except for the >>> >>> >>> distinction between >>> >>>> a zero and non-zero value. There is a requirement that some random >>>> non-zero value be inserted and then ignored. If there are >>> >>> >>> multiple MSRP >>> >>>> media sessions in the same SDP body, must they have differing port >>> >>> >>> numbers? >>> >>>> Paul >>>> >>>> Flemming Andreasen wrote: >>>> >>>>> "Kumar, Rajesh" wrote: >>>>> >>>>> >>>>> >>>>>> AVT members, >>>>>> >>>>>> There was some confusion on this issue in the recent TIA >>>>> >>>>> >>> TR.30.1 meeting >>> >>>>>> in Orlando, Florida. >>>>>> >>>>>> Could someone officially confirm or deny whether multiple >>>>> >>>>> >>> "m=" lines >>> >>>>>> with the SAME media type (e.g. "audio") and protocol >>>>> >>>>> >>> (e.g. RTP/AVP) >>> >>>>>> cannot be assigned the same port number? >>>>> >>>>> >>>>> >>>>> The consensus of this discussion is that is that they >>>> >>>> >>> cannot (assuming >>> they >>> >>>>> use the same IP address). >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> >>>>> >>>>>> If they can be assigned the >>>>>> same port number, then it is possible to selectively >>>>> >>>>> >>> associate RFC 2733 >>> >>>>>> FEC with some payload types such as those that carry >>>>> >>>>> >>> voice band data. >>> >>>>>> Otherwise, there is a hole in SDP that does not permit selective, >>>>>> payload-specific declaration of FEC. I am aware of the >>>>> >>>>> >>> fact that in RFC >>> >>>>>> 2733 the use of and level of FEC is a transmitter >>>>> >>>>> >>> prerogative and that a >>> >>>>>> transmitter may choose to selectively utilize FEC based >>>>> >>>>> >>> on payload type >>> >>>>>> transmitted. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Rajesh >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>> Sent: Friday, December 12, 2003 4:21 AM >>>>>>> To: Kevin Boyle >>>>>>> Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>>> >>>>>> >>> mmusic@ietf.org; >>> >>>>>> Mostafa, Mohamed; >>>>>> >>>>>> >>>>>>> Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>>> >>>>>> >>> same port number >>> >>>>>>> >>>>>>> >>>>>>> Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Looking back at this email stream, one question remains >>>>>>> >>>>>>> >>> outstanding >>> >>>>>> in >>>>>> >>>>>> >>>>>>>> my mind: >>>>>>>> >>>>>>>> What if the two m= lines have the SAME media type? For >>>>>>> >>>>>>> >>> instance: >>> >>>>>>>> m=audio 49232 RTP/AVP 18 >>>>>>>> m=image 49233 UDPTL t38 >>>>>>>> m=audio 49232 RTP/AVP 100 >>>>>>>> a=rtpmap:100 PCMU/8000 >>>>>>>> a=gpmd:100 vbd=yes >>>>>>>> >>>>>>>> For some of the SDP-based protocols, the order of appearance is >>>>>>> >>>>>>> >>>>>> vital >>>>>> >>>>>> >>>>>>>> because it announces preference. >>>>>>> >>>>>>> >>>>>>> Only for the media formats within a given "m=" line. >>>>>> >>>>>> >>> Multiple "m=" >>> >>>>>> lines >>>>>> >>>>>> >>>>>>> indicates a set of simultaneous media streams; not alternatives. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> So, this shows preference for T.38 fax relay over PCMU >>>>>>> >>>>>>> >>> VBD for fax, >>> >>>>>>>> while utilizing G.729 for voice. As far as I can tell, this >>>>>>> >>>>>>> >>>>>> construct >>>>>> >>>>>> >>>>>>>> is allowed, since both m lines using the same port number use a >>>>>>> >>>>>>> >>>>>> media >>>>>> >>>>>> >>>>>>>> type of audio. >>>>>>>> >>>>>>>> Is my understanding correct? >>>>>>>> >>>>>>> >>>>>>> Not quite. Each "m=" line corresponds to a separate media stream. >>>>>> >>>>>> >>>>>> Also, >>>>>> >>>>>> >>>>>>> the consensus of this discussion has been that you are >>>>>> >>>>>> >>> *not* allowed >>> >>>>>> to >>>>>> >>>>>> >>>>>>> use the same port for different media lines, regardless >>>>>> >>>>>> >>> of whether >>> >>>>>> they >>>>>> >>>>>> >>>>>>> share the same top-level MIME type or not. >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Kevin >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Stephen Casner [mailto:casner@acm.org] >>>>>>>> Sent: Friday, April 25, 2003 2:57 PM >>>>>>>> To: Rajesh Kumar >>>>>>>> Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>> mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>> paulej@cisco.com >>>>>>>> >>>>>>>> Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>>> >>>>>>> >>> port number >>> >>>>>>>> Rajesh, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Is the use of multiple 'm=' lines with the same port >>>>>>>> >>>>>>>> >>> number within >>> >>>>>>>> an >>>>>>>> >>>>>>>> >>>>>>>>> SDP descriptor permitted? >>>>>>>> >>>>>>>> >>>>>>>> Presuming that the multiple m= lines are all RTP/AVP, >>>>>>> >>>>>>> >>> then doing so >>> >>>>>>>> causes all of the payload formats listed on the m= >>>>>>> >>>>>>> >>> lines to become >>> >>>>>>>> part of a single RTP session (unless they are >>>>>>> >>>>>>> >>> distinguished by some >>> >>>>>>>> other aspect of addressing). Section 5.2 of the RTP >>>>>>> >>>>>>> >>> spec addresses >>> >>>>>>>> NOT multiplexing different media in the same RTP session. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>> >>>>>>>> >>>>>> are >>>>>> >>>>>> >>>>>>>> of >>>>>>>> >>>>>>>> >>>>>>>>> the same media type (e.g. audio, image, text etc.). >>>>>>>>> >>>>>>>>> Now consider the case in which two RTP media formats can use a >>>>>>>>> destination port but are registered under different MIME types. >>>>>>>> >>>>>>>> >>>>>> For >>>>>> >>>>>> >>>>>>>>> example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>> >>>>>>>> >>>>>>>> recourse >>>>>>>> >>>>>>>> >>>>>>>>> except to use multiple media lines with the same port >>>>>>>> >>>>>>>> >>> number. For >>> >>>>>>>> example: >>>>>>>> >>>>>>>> The "can use a destination port" is the tricky part. We may not >>>>>>>> agree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> m=audio 49232 RTP/AVP 0 >>>>>>>>> m=text 49232 RTP/AVP 100 >>>>>>>>> a=rtpmap:100 t140 >>>>>>>>> >>>>>>>>> My thought is that although this is unsual, it is not >>>>>>>> >>>>>>>> >>> proscribed >>> >>>>>> by >>>>>> >>>>>> >>>>>>>>> SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>> >>>>>>>> >>>>>>>> I believe this is proscribed by section 5.2 of the RTP >>>>>>> >>>>>>> >>> spec because >>> >>>>>>>> these two media should not be multiplexed in one RTP session. >>>>>>>> >>>>>>>> My bet is that the real example you are thinking about is fax or >>>>>>> >>>>>>> >>>>>> modem >>>>>> >>>>>> >>>>>>>> over IP. We've been there before. >>>>>>>> >>>>>>>> -- Steve >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 16 12:33:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22417 for ; Fri, 16 Jan 2004 12:33:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXpi-0006rT-BA for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 12:32:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GHWYu4026371 for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 12:32:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXpi-0006rG-6Q for simple-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 12:32:34 -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 MAA22405 for ; Fri, 16 Jan 2004 12:32:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXpg-0002C7-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 12:32:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXoq-00028Q-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 12:31:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhXoK-00024R-00; Fri, 16 Jan 2004 12:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXoD-0006fC-VJ; Fri, 16 Jan 2004 12:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXnf-0006cQ-EN for simple@optimus.ietf.org; Fri, 16 Jan 2004 12:30:27 -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 MAA22305 for ; Fri, 16 Jan 2004 12:30:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXnd-00022j-00 for simple@ietf.org; Fri, 16 Jan 2004 12:30:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXml-0001zK-00 for simple@ietf.org; Fri, 16 Jan 2004 12:29:33 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhXmK-0001vr-00; Fri, 16 Jan 2004 12:29:05 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GHSkgW007554; Fri, 16 Jan 2004 11:28:53 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40081F49.9080204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> <3FFD668E.4030709@cisco.com> In-Reply-To: <3FFD668E.4030709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Jan 2004 11:28:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for the late reply--for some reason this just showed up in my inbox. (Or I just noticed it, anyway.) I don't see it as a problem to have MSRP mention that the ports must be distinct. We currently have a standard dummy value, rather than a random value. With this restriction, I think the answer is to say the sender can choose any legal non-zero value, and if multiple MSRP m-lines exist, they must have different port values. Is this sufficient? I don't see any reason to care about how a particular implementation goes about generating them. Paul Kyzivat wrote: > Hisham, > > I have an open mind about this right now. It seems to be a matter of > picking your favorite poison, since neither alternative is ideal: > - ensure that the ports used are unique even though they are ignored > - change SDP - something that is not very popular. > > So far, aside from me there are two votes, one on each side. From the > point of view of SIMPLE it is of course logistically simpler to leave > SDP alone. > > Paul > > P.S. It seems that simple wasn't on the mailing list, so I have added it. > > hisham.khartabil@nokia.com wrote: > >> I would hate to see exceptions like these when building a generic SDP >> parser with built it checks for compliancy. >> Why can't MSRP just follow that rule? >> >> Regards, >> Hisham >> >> >>> -----Original Message----- >>> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>> ext Paul E. Jones >>> Sent: 07.January.2004 23:15 >>> To: Paul Kyzivat; Flemming Andreasen >>> Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>> mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>> mgarakan@cisco.com >>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> Paul, >>> >>> While that sounds most unfortunate (I'd love to see an example if you >>> have >>> one), I think it would be exempt from this rule, because the port is >>> just a >>> dummy value. >>> >>> Paul >>> >>> ----- Original Message ----- From: "Paul Kyzivat" >>> To: "Flemming Andreasen" >>> Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>> ; "Stephen Casner" ; "Colin >>> Perkins" ; ; "Mostafa, Mohamed" >>> ; "Abdelhamid, Hisham" ; >>> ; >>> Sent: Wednesday, January 07, 2004 4:12 PM >>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>> >>> >>> >>>> I recently encountered an interesting case relevant to this >>> >>> >>> while making >>> >>>> up an example for MSRP. >>>> >>>> In MSRP the port number is not used, except for the >>> >>> >>> distinction between >>> >>>> a zero and non-zero value. There is a requirement that some random >>>> non-zero value be inserted and then ignored. If there are >>> >>> >>> multiple MSRP >>> >>>> media sessions in the same SDP body, must they have differing port >>> >>> >>> numbers? >>> >>>> Paul >>>> >>>> Flemming Andreasen wrote: >>>> >>>>> "Kumar, Rajesh" wrote: >>>>> >>>>> >>>>> >>>>>> AVT members, >>>>>> >>>>>> There was some confusion on this issue in the recent TIA >>>>> >>>>> >>> TR.30.1 meeting >>> >>>>>> in Orlando, Florida. >>>>>> >>>>>> Could someone officially confirm or deny whether multiple >>>>> >>>>> >>> "m=" lines >>> >>>>>> with the SAME media type (e.g. "audio") and protocol >>>>> >>>>> >>> (e.g. RTP/AVP) >>> >>>>>> cannot be assigned the same port number? >>>>> >>>>> >>>>> >>>>> The consensus of this discussion is that is that they >>>> >>>> >>> cannot (assuming >>> they >>> >>>>> use the same IP address). >>>>> >>>>> -- Flemming >>>>> >>>>> >>>>> >>>>> >>>>>> If they can be assigned the >>>>>> same port number, then it is possible to selectively >>>>> >>>>> >>> associate RFC 2733 >>> >>>>>> FEC with some payload types such as those that carry >>>>> >>>>> >>> voice band data. >>> >>>>>> Otherwise, there is a hole in SDP that does not permit selective, >>>>>> payload-specific declaration of FEC. I am aware of the >>>>> >>>>> >>> fact that in RFC >>> >>>>>> 2733 the use of and level of FEC is a transmitter >>>>> >>>>> >>> prerogative and that a >>> >>>>>> transmitter may choose to selectively utilize FEC based >>>>> >>>>> >>> on payload type >>> >>>>>> transmitted. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Rajesh >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>> Sent: Friday, December 12, 2003 4:21 AM >>>>>>> To: Kevin Boyle >>>>>>> Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>>> >>>>>> >>> mmusic@ietf.org; >>> >>>>>> Mostafa, Mohamed; >>>>>> >>>>>> >>>>>>> Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>>> >>>>>> >>> same port number >>> >>>>>>> >>>>>>> >>>>>>> Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Looking back at this email stream, one question remains >>>>>>> >>>>>>> >>> outstanding >>> >>>>>> in >>>>>> >>>>>> >>>>>>>> my mind: >>>>>>>> >>>>>>>> What if the two m= lines have the SAME media type? For >>>>>>> >>>>>>> >>> instance: >>> >>>>>>>> m=audio 49232 RTP/AVP 18 >>>>>>>> m=image 49233 UDPTL t38 >>>>>>>> m=audio 49232 RTP/AVP 100 >>>>>>>> a=rtpmap:100 PCMU/8000 >>>>>>>> a=gpmd:100 vbd=yes >>>>>>>> >>>>>>>> For some of the SDP-based protocols, the order of appearance is >>>>>>> >>>>>>> >>>>>> vital >>>>>> >>>>>> >>>>>>>> because it announces preference. >>>>>>> >>>>>>> >>>>>>> Only for the media formats within a given "m=" line. >>>>>> >>>>>> >>> Multiple "m=" >>> >>>>>> lines >>>>>> >>>>>> >>>>>>> indicates a set of simultaneous media streams; not alternatives. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> So, this shows preference for T.38 fax relay over PCMU >>>>>>> >>>>>>> >>> VBD for fax, >>> >>>>>>>> while utilizing G.729 for voice. As far as I can tell, this >>>>>>> >>>>>>> >>>>>> construct >>>>>> >>>>>> >>>>>>>> is allowed, since both m lines using the same port number use a >>>>>>> >>>>>>> >>>>>> media >>>>>> >>>>>> >>>>>>>> type of audio. >>>>>>>> >>>>>>>> Is my understanding correct? >>>>>>>> >>>>>>> >>>>>>> Not quite. Each "m=" line corresponds to a separate media stream. >>>>>> >>>>>> >>>>>> Also, >>>>>> >>>>>> >>>>>>> the consensus of this discussion has been that you are >>>>>> >>>>>> >>> *not* allowed >>> >>>>>> to >>>>>> >>>>>> >>>>>>> use the same port for different media lines, regardless >>>>>> >>>>>> >>> of whether >>> >>>>>> they >>>>>> >>>>>> >>>>>>> share the same top-level MIME type or not. >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Kevin >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Stephen Casner [mailto:casner@acm.org] >>>>>>>> Sent: Friday, April 25, 2003 2:57 PM >>>>>>>> To: Rajesh Kumar >>>>>>>> Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>> mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>> paulej@cisco.com >>>>>>>> >>>>>>>> Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>>> >>>>>>> >>> port number >>> >>>>>>>> Rajesh, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Is the use of multiple 'm=' lines with the same port >>>>>>>> >>>>>>>> >>> number within >>> >>>>>>>> an >>>>>>>> >>>>>>>> >>>>>>>>> SDP descriptor permitted? >>>>>>>> >>>>>>>> >>>>>>>> Presuming that the multiple m= lines are all RTP/AVP, >>>>>>> >>>>>>> >>> then doing so >>> >>>>>>>> causes all of the payload formats listed on the m= >>>>>>> >>>>>>> >>> lines to become >>> >>>>>>>> part of a single RTP session (unless they are >>>>>>> >>>>>>> >>> distinguished by some >>> >>>>>>>> other aspect of addressing). Section 5.2 of the RTP >>>>>>> >>>>>>> >>> spec addresses >>> >>>>>>>> NOT multiplexing different media in the same RTP session. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>> >>>>>>>> >>>>>> are >>>>>> >>>>>> >>>>>>>> of >>>>>>>> >>>>>>>> >>>>>>>>> the same media type (e.g. audio, image, text etc.). >>>>>>>>> >>>>>>>>> Now consider the case in which two RTP media formats can use a >>>>>>>>> destination port but are registered under different MIME types. >>>>>>>> >>>>>>>> >>>>>> For >>>>>> >>>>>> >>>>>>>>> example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>> >>>>>>>> >>>>>>>> recourse >>>>>>>> >>>>>>>> >>>>>>>>> except to use multiple media lines with the same port >>>>>>>> >>>>>>>> >>> number. For >>> >>>>>>>> example: >>>>>>>> >>>>>>>> The "can use a destination port" is the tricky part. We may not >>>>>>>> agree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> m=audio 49232 RTP/AVP 0 >>>>>>>>> m=text 49232 RTP/AVP 100 >>>>>>>>> a=rtpmap:100 t140 >>>>>>>>> >>>>>>>>> My thought is that although this is unsual, it is not >>>>>>>> >>>>>>>> >>> proscribed >>> >>>>>> by >>>>>> >>>>>> >>>>>>>>> SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>> >>>>>>>> >>>>>>>> I believe this is proscribed by section 5.2 of the RTP >>>>>>> >>>>>>> >>> spec because >>> >>>>>>>> these two media should not be multiplexed in one RTP session. >>>>>>>> >>>>>>>> My bet is that the real example you are thinking about is fax or >>>>>>> >>>>>>> >>>>>> modem >>>>>> >>>>>> >>>>>>>> over IP. We've been there before. >>>>>>>> >>>>>>>> -- Steve >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 16 14:30:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25805 for ; Fri, 16 Jan 2004 14:30:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZfo-0000H7-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:30:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZes-0000E1-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:29:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZeP-0000Bd-00; Fri, 16 Jan 2004 14:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZeP-00064r-6W; Fri, 16 Jan 2004 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZdq-000644-Q7 for simple@optimus.ietf.org; Fri, 16 Jan 2004 14:28:26 -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 OAA25722 for ; Fri, 16 Jan 2004 14:28:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZdo-0000AC-00 for simple@ietf.org; Fri, 16 Jan 2004 14:28:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZcs-000074-00 for simple@ietf.org; Fri, 16 Jan 2004 14:27:27 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhZc3-00003J-00; Fri, 16 Jan 2004 14:26:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GJQ4gW018022; Fri, 16 Jan 2004 13:26:15 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40083AC6.4000101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> In-Reply-To: <400305C5.10009@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Jan 2004 13:25:58 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I am fond of the choice of "connection:xx" if we are going to include it in the initial SDP--simply because it does not offer quite as much cognitive dissonance as discovering a "reconnect:xx" when one has not yet connected for the first time. Paul Kyzivat wrote: > > > David Yon wrote: > >> >> "reconnect:NNN" would probably be a useful enhancement to "reconnect", >> and if connection reestablishment was the goal of "version", then I >> would vote for that. > > > That is certainly the driving force behind it at the moment. > Unless someone can envision another use then I am happy to go along with > this. > >> The only issue would be that of the original SDP exchange. It hardly >> seems appropriate to include a "reconnect" attribute in the initial >> exchange, but then when you want to negotiate a new connection and >> suddenly this attribute appears, what's the appropriate value for >> NNN? A couple of possibilities: >> >> a) Don't worry about "a=reconnect:0" being an odd inclusion, and make >> it mandatory. >> >> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >> Therefore the first reconnection negotiation would have "a=reconnect:1". >> >> c) Make the omission imply "a=reconnect:", such that the first >> appearance of "reconnect" would be "a=reconnect:0". >> >> I would guess that (a) makes the most sense. Thoughts? > > > That seems reasonable. > > In practice the number doesn't mean much except that it change. It would > work as well if it were an opaque token. > > When considered as a version number it makes more sense as an increasing > number. > > How about a=connection:NNN? (With a default of 1.) This numbers the > connections used to convey the media stream. This is clearly associated > with connections, so it isn't prone to abuse, and it also conveys a > clear semantic for the number. > >> Also, are there any possibilities of race conditions where the NNN >> would get out of sync between the two endpoints? If so, how would >> that be resolved? > > > I don't believe there are any race conditions, though there is always > the possibility of buggy endpoint getting confused. > > I don't think there are any race conditions because NNN isn't negotiated > - it is always managed by one end and conveyed to the other end. In an > offer/answer exchange, each side could conceivably provide its own value > for a=reconnect:NNN. It is only meaningful when provided by a passive > end to an active end, because it determines whether the active end > should reconnect. > > In the case of MSRP, there is only one connection, so reconnection only > makes sense in the direction of the original connection. > > In the case of comedia there could conceivably be two connections, one > in each direction. If so, it is conceivable that an offer/answer > exchange could have a=reconnect=NNN going both ways, and resulting in > zero, one, or two reconnections. > >> What about the additional state that must be tracked (the reconnection >> number)? I don't think that comedia-05 represents any additional >> state over connectionless media, which wouldn't be true for >> "reconnect:NNN". > > > There is extra implicit state in comedia. It must remember active, > passive, or both, whether still listening if passive, whether connected > if active, and ultimately the connection itself must be remembered as > state. This adds a number that must be associated with the connection. > Doesn't seem like a big burden. > >>> Paul >>> >>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>> >>>>> My attempts to reach David Yon at the address he has listed in the >>>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>>> exists? >>>>> >>>>> Paul >>>>> >>>>> Paul Kyzivat wrote: >>>>> >>>>>> Ben, >>>>>> I'm copying David Yon on this since he is author of comedia. This >>>>>> probably won't make any sense out of context to him, so I will >>>>>> separately send him some of the earlier discussion. >>>>>> I don't recall what the current status of comedia is. It is >>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>> goals listed for it. >>>>>> Paul >>>>>> Ben Campbell wrote: >>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ben Campbell wrote: >>>>>>>> >>>>>>>>> (More comments on same email...) >>>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>>> whatever. But it also does leave the problem of distinguishing >>>>>>>>>> a "reconnect" offer from a "don't change anything" offer. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>> as I hoped it would. While it does mean you have to do something >>>>>>>> special (add the a=reconnect) attribute to cause a reconnect, >>>>>>>> having done that once you then have to do something else (remove >>>>>>>> the a=reconnect) in a subsequent exchange. >>>>>>>> >>>>>>>> I think it would be better if there were something like >>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>> particular media session. Then whenever it changes you >>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>> from the o-line. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree that sounds like a better approach. Do you think there is >>>>>>> any chance to convince the COMEDIA folks to follow the same >>>>>>> approach? >>>>>>> >>>>>>>> >>>>>>>> Paul >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 16 14:31:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25828 for ; Fri, 16 Jan 2004 14:31:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZfs-0006DX-4l for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:30:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GJUWhj023895 for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:30:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZfs-0006DK-1L for simple-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 14:30:32 -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 OAA25820 for ; Fri, 16 Jan 2004 14:30:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZfp-0000HC-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:30:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZet-0000EA-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:29:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZeP-0000Bd-00; Fri, 16 Jan 2004 14:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZeP-00064r-6W; Fri, 16 Jan 2004 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZdq-000644-Q7 for simple@optimus.ietf.org; Fri, 16 Jan 2004 14:28:26 -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 OAA25722 for ; Fri, 16 Jan 2004 14:28:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZdo-0000AC-00 for simple@ietf.org; Fri, 16 Jan 2004 14:28:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZcs-000074-00 for simple@ietf.org; Fri, 16 Jan 2004 14:27:27 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhZc3-00003J-00; Fri, 16 Jan 2004 14:26:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GJQ4gW018022; Fri, 16 Jan 2004 13:26:15 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40083AC6.4000101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> In-Reply-To: <400305C5.10009@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Jan 2004 13:25:58 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am fond of the choice of "connection:xx" if we are going to include it in the initial SDP--simply because it does not offer quite as much cognitive dissonance as discovering a "reconnect:xx" when one has not yet connected for the first time. Paul Kyzivat wrote: > > > David Yon wrote: > >> >> "reconnect:NNN" would probably be a useful enhancement to "reconnect", >> and if connection reestablishment was the goal of "version", then I >> would vote for that. > > > That is certainly the driving force behind it at the moment. > Unless someone can envision another use then I am happy to go along with > this. > >> The only issue would be that of the original SDP exchange. It hardly >> seems appropriate to include a "reconnect" attribute in the initial >> exchange, but then when you want to negotiate a new connection and >> suddenly this attribute appears, what's the appropriate value for >> NNN? A couple of possibilities: >> >> a) Don't worry about "a=reconnect:0" being an odd inclusion, and make >> it mandatory. >> >> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >> Therefore the first reconnection negotiation would have "a=reconnect:1". >> >> c) Make the omission imply "a=reconnect:", such that the first >> appearance of "reconnect" would be "a=reconnect:0". >> >> I would guess that (a) makes the most sense. Thoughts? > > > That seems reasonable. > > In practice the number doesn't mean much except that it change. It would > work as well if it were an opaque token. > > When considered as a version number it makes more sense as an increasing > number. > > How about a=connection:NNN? (With a default of 1.) This numbers the > connections used to convey the media stream. This is clearly associated > with connections, so it isn't prone to abuse, and it also conveys a > clear semantic for the number. > >> Also, are there any possibilities of race conditions where the NNN >> would get out of sync between the two endpoints? If so, how would >> that be resolved? > > > I don't believe there are any race conditions, though there is always > the possibility of buggy endpoint getting confused. > > I don't think there are any race conditions because NNN isn't negotiated > - it is always managed by one end and conveyed to the other end. In an > offer/answer exchange, each side could conceivably provide its own value > for a=reconnect:NNN. It is only meaningful when provided by a passive > end to an active end, because it determines whether the active end > should reconnect. > > In the case of MSRP, there is only one connection, so reconnection only > makes sense in the direction of the original connection. > > In the case of comedia there could conceivably be two connections, one > in each direction. If so, it is conceivable that an offer/answer > exchange could have a=reconnect=NNN going both ways, and resulting in > zero, one, or two reconnections. > >> What about the additional state that must be tracked (the reconnection >> number)? I don't think that comedia-05 represents any additional >> state over connectionless media, which wouldn't be true for >> "reconnect:NNN". > > > There is extra implicit state in comedia. It must remember active, > passive, or both, whether still listening if passive, whether connected > if active, and ultimately the connection itself must be remembered as > state. This adds a number that must be associated with the connection. > Doesn't seem like a big burden. > >>> Paul >>> >>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>> >>>>> My attempts to reach David Yon at the address he has listed in the >>>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>>> exists? >>>>> >>>>> Paul >>>>> >>>>> Paul Kyzivat wrote: >>>>> >>>>>> Ben, >>>>>> I'm copying David Yon on this since he is author of comedia. This >>>>>> probably won't make any sense out of context to him, so I will >>>>>> separately send him some of the earlier discussion. >>>>>> I don't recall what the current status of comedia is. It is >>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>> goals listed for it. >>>>>> Paul >>>>>> Ben Campbell wrote: >>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ben Campbell wrote: >>>>>>>> >>>>>>>>> (More comments on same email...) >>>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>>> whatever. But it also does leave the problem of distinguishing >>>>>>>>>> a "reconnect" offer from a "don't change anything" offer. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>> as I hoped it would. While it does mean you have to do something >>>>>>>> special (add the a=reconnect) attribute to cause a reconnect, >>>>>>>> having done that once you then have to do something else (remove >>>>>>>> the a=reconnect) in a subsequent exchange. >>>>>>>> >>>>>>>> I think it would be better if there were something like >>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>> particular media session. Then whenever it changes you >>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>> from the o-line. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree that sounds like a better approach. Do you think there is >>>>>>> any chance to convince the COMEDIA folks to follow the same >>>>>>> approach? >>>>>>> >>>>>>>> >>>>>>>> Paul >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 16 14:39:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26222 for ; Fri, 16 Jan 2004 14:39:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZoU-0000h2-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:39:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZnZ-0000eS-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:38:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZnA-0000cF-00; Fri, 16 Jan 2004 14:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZn9-0006le-AF; Fri, 16 Jan 2004 14:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4PF-00013q-Ee for simple@optimus.ietf.org; Mon, 12 Jan 2004 10:55:10 -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 KAA03415 for ; Mon, 12 Jan 2004 10:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4PC-0000my-00 for simple@ietf.org; Mon, 12 Jan 2004 10:55:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4NN-0000l1-00 for simple@ietf.org; Mon, 12 Jan 2004 10:53:14 -0500 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag4Mh-0000hx-00; Mon, 12 Jan 2004 10:52:31 -0500 Received: from yon-lattitude.rfdsoftware.com (rt314.tactical-sw.com [216.41.119.98]) (authenticated) by [216.41.119.110] (8.10.2/8.10.2) with ESMTP id i0CFs2Z20692; Mon, 12 Jan 2004 10:54:02 -0500 Message-Id: <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Paul Kyzivat , simple@ietf.org, mmusic@ietf.org From: David Yon Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates In-Reply-To: <4002B7E5.8090700@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 10:51:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Here I am! :-) Dialout.Net is defunct, but at the moment I am still willing to support the comedia draft, although I have much less time available to me for it. My only concern with a "version" attribute is that it causes a reconnection by inference. I'm afraid that it would be rife with temptation to use it to version-stamp the session for other reasons that do not imply the impetus to reconnect. Is there some tangible scenario where "version" is superior to "reconnect"? At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >My attempts to reach David Yon at the address he has listed in the comedia >draft (yon@dialout.net) have bounced. Does anybody know whether he is >still at Dialout.Net, or even if Dialout.Net still exists? > > Paul > >Paul Kyzivat wrote: >>Ben, >>I'm copying David Yon on this since he is author of comedia. This >>probably won't make any sense out of context to him, so I will separately >>send him some of the earlier discussion. >>I don't recall what the current status of comedia is. It is currently >>listed as a WG draft, but there don't seem to be any goals listed for it. >> Paul >>Ben Campbell wrote: >> >>>Paul Kyzivat wrote: >>> >>>> >>>> >>>>Ben Campbell wrote: >>>> >>>>>(More comments on same email...) >>>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>[...] >>>>> >>>>>> >>>>>>Using the same media lines for the replacement session solves the >>>>>>association problem for any media type - MSRP, RTP, whatever. But it >>>>>>also does leave the problem of distinguishing a "reconnect" offer >>>>>>from a "don't change anything" offer. >>>>> >>>>> >>>>> >>>>> >>>>>Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>(section 5 of current comedia draft.) >>>> >>>> >>>> >>>> >>>>That would probably work. The feature in comedia didn't end up as I >>>>hoped it would. While it does mean you have to do something special >>>>(add the a=reconnect) attribute to cause a reconnect, having done that >>>>once you then have to do something else (remove the a=reconnect) in a >>>>subsequent exchange. >>>> >>>>I think it would be better if there were something like a=version:nnn, >>>>which would just be a version number for a particular media session. >>>>Then whenever it changes you reconnect. If the attribute was absent it >>>>could be defaulted from the o-line. >>> >>> >>> >>>I agree that sounds like a better approach. Do you think there is any >>>chance to convince the COMEDIA folks to follow the same approach? >>> >>>> >>>> Paul >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 16 14:39:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26244 for ; Fri, 16 Jan 2004 14:39:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZod-0000hU-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:39:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZna-0000ei-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:38:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZnA-0000cG-00; Fri, 16 Jan 2004 14:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZnA-0006lm-0C; Fri, 16 Jan 2004 14:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag86b-0002Mb-Hw for simple@optimus.ietf.org; Mon, 12 Jan 2004 14:52:09 -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 OAA13525 for ; Mon, 12 Jan 2004 14:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag86Y-0003a7-00 for simple@ietf.org; Mon, 12 Jan 2004 14:52:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag84i-0003Ud-00 for simple@ietf.org; Mon, 12 Jan 2004 14:50:13 -0500 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag83A-0003NS-00; Mon, 12 Jan 2004 14:48:37 -0500 Received: from yon-lattitude.rfdsoftware.com (rt314.tactical-sw.com [216.41.119.98]) (authenticated) by [216.41.119.110] (8.10.2/8.10.2) with ESMTP id i0CJoPZ31001; Mon, 12 Jan 2004 14:50:25 -0500 Message-Id: <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Paul Kyzivat From: David Yon Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates Cc: simple@ietf.org, mmusic@ietf.org In-Reply-To: <4002E412.2070608@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 14:48:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 01:14 PM 1/12/2004, Paul Kyzivat wrote: >David Yon wrote: >>Here I am! :-) >>Dialout.Net is defunct, but at the moment I am still willing to support >>the comedia draft, although I have much less time available to me for it. > >I was suspecting Dialout might be gone because attempts to access the web >site timed out. Glad to hear that you are still around. Maybe you should >submit a new version of comedia just to update your address. Yeah, I was waiting for other excuses to freshen comedia, but there are a couple of issues that have kept it deadlocked. While not all issues for an upcoming comedia-06 have been resolved, it would probably be worthwhile to spin it just to get discussion going again, even if there are known flaws. >>My only concern with a "version" attribute is that it causes a >>reconnection by inference. I'm afraid that it would be rife with >>temptation to use it to version-stamp the session for other reasons that >>do not imply the impetus to reconnect. Is there some tangible scenario >>where "version" is superior to "reconnect"? > >I can see how you might consider reconnection by inference to be a >negative. But in my view that is also its appeal. > >The point is to preserve the behavior that reuse of unchanged SDP acts as >a no-op. Once you introduce the a=reconnect attribute, a subsequent >offer/answer cycle that reuses sdp containing that will cause another >reconnect, which isn't a no-op. > >By using a=version, it is the detection of a revised version number that >causes the reconnect. So a subsequent offer/answer cycle using the same >sdp will not see a change in version number and so will not cause another >reconnect. > >This is of significance whenever there might be components that manipulate >offers and answers in a generic way. For instance, if you have a UA that >manages multiple media streams, there may be one component that decomposes >the sdp and then interacts with a separate component in the UA for each >stream. If there is a need to make a change in one stream, it may simply >want to make a change in the description of the affected stream without >dealing with the components responsible for other streams. In general, >with the exception of a=reconnect, it can do this. > >I am not especially attached to the name "version". I am certainly willing >to entertain some other name for the attribute that is clearer and less >prone to invite abuse. E.g. we might consider a=reconnect:NNN. "reconnect:NNN" would probably be a useful enhancement to "reconnect", and if connection reestablishment was the goal of "version", then I would vote for that. The only issue would be that of the original SDP exchange. It hardly seems appropriate to include a "reconnect" attribute in the initial exchange, but then when you want to negotiate a new connection and suddenly this attribute appears, what's the appropriate value for NNN? A couple of possibilities: a) Don't worry about "a=reconnect:0" being an odd inclusion, and make it mandatory. b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". Therefore the first reconnection negotiation would have "a=reconnect:1". c) Make the omission imply "a=reconnect:", such that the first appearance of "reconnect" would be "a=reconnect:0". I would guess that (a) makes the most sense. Thoughts? Also, are there any possibilities of race conditions where the NNN would get out of sync between the two endpoints? If so, how would that be resolved? What about the additional state that must be tracked (the reconnection number)? I don't think that comedia-05 represents any additional state over connectionless media, which wouldn't be true for "reconnect:NNN". > Paul > >>At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >> >>>My attempts to reach David Yon at the address he has listed in the >>>comedia draft (yon@dialout.net) have bounced. Does anybody know whether >>>he is still at Dialout.Net, or even if Dialout.Net still exists? >>> >>> Paul >>> >>>Paul Kyzivat wrote: >>> >>>>Ben, >>>>I'm copying David Yon on this since he is author of comedia. This >>>>probably won't make any sense out of context to him, so I will >>>>separately send him some of the earlier discussion. >>>>I don't recall what the current status of comedia is. It is currently >>>>listed as a WG draft, but there don't seem to be any goals listed for it. >>>> Paul >>>>Ben Campbell wrote: >>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>> >>>>>> >>>>>>Ben Campbell wrote: >>>>>> >>>>>>>(More comments on same email...) >>>>>>> >>>>>>>Paul Kyzivat wrote: >>>>>>> >>>>>>>[...] >>>>>>> >>>>>>>> >>>>>>>>Using the same media lines for the replacement session solves the >>>>>>>>association problem for any media type - MSRP, RTP, whatever. But >>>>>>>>it also does leave the problem of distinguishing a "reconnect" >>>>>>>>offer from a "don't change anything" offer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>>>(section 5 of current comedia draft.) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>That would probably work. The feature in comedia didn't end up as I >>>>>>hoped it would. While it does mean you have to do something special >>>>>>(add the a=reconnect) attribute to cause a reconnect, having done >>>>>>that once you then have to do something else (remove the a=reconnect) >>>>>>in a subsequent exchange. >>>>>> >>>>>>I think it would be better if there were something like >>>>>>a=version:nnn, which would just be a version number for a particular >>>>>>media session. Then whenever it changes you reconnect. If the >>>>>>attribute was absent it could be defaulted from the o-line. >>>>> >>>>> >>>>> >>>>> >>>>>I agree that sounds like a better approach. Do you think there is any >>>>>chance to convince the COMEDIA folks to follow the same approach? >>>>> >>>>>> >>>>>> Paul >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 16 14:39:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26267 for ; Fri, 16 Jan 2004 14:39:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZoY-0006zN-JP for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:39:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GJdUfn026865 for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:39:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZoY-0006z2-4A for simple-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 14:39:30 -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 OAA26240 for ; Fri, 16 Jan 2004 14:39:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZoV-0000h7-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:39:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZnZ-0000ea-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:38:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZnA-0000cF-00; Fri, 16 Jan 2004 14:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZn9-0006le-AF; Fri, 16 Jan 2004 14:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4PF-00013q-Ee for simple@optimus.ietf.org; Mon, 12 Jan 2004 10:55:10 -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 KAA03415 for ; Mon, 12 Jan 2004 10:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4PC-0000my-00 for simple@ietf.org; Mon, 12 Jan 2004 10:55:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4NN-0000l1-00 for simple@ietf.org; Mon, 12 Jan 2004 10:53:14 -0500 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag4Mh-0000hx-00; Mon, 12 Jan 2004 10:52:31 -0500 Received: from yon-lattitude.rfdsoftware.com (rt314.tactical-sw.com [216.41.119.98]) (authenticated) by [216.41.119.110] (8.10.2/8.10.2) with ESMTP id i0CFs2Z20692; Mon, 12 Jan 2004 10:54:02 -0500 Message-Id: <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Paul Kyzivat , simple@ietf.org, mmusic@ietf.org From: David Yon Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates In-Reply-To: <4002B7E5.8090700@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 10:51:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Here I am! :-) Dialout.Net is defunct, but at the moment I am still willing to support the comedia draft, although I have much less time available to me for it. My only concern with a "version" attribute is that it causes a reconnection by inference. I'm afraid that it would be rife with temptation to use it to version-stamp the session for other reasons that do not imply the impetus to reconnect. Is there some tangible scenario where "version" is superior to "reconnect"? At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >My attempts to reach David Yon at the address he has listed in the comedia >draft (yon@dialout.net) have bounced. Does anybody know whether he is >still at Dialout.Net, or even if Dialout.Net still exists? > > Paul > >Paul Kyzivat wrote: >>Ben, >>I'm copying David Yon on this since he is author of comedia. This >>probably won't make any sense out of context to him, so I will separately >>send him some of the earlier discussion. >>I don't recall what the current status of comedia is. It is currently >>listed as a WG draft, but there don't seem to be any goals listed for it. >> Paul >>Ben Campbell wrote: >> >>>Paul Kyzivat wrote: >>> >>>> >>>> >>>>Ben Campbell wrote: >>>> >>>>>(More comments on same email...) >>>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>[...] >>>>> >>>>>> >>>>>>Using the same media lines for the replacement session solves the >>>>>>association problem for any media type - MSRP, RTP, whatever. But it >>>>>>also does leave the problem of distinguishing a "reconnect" offer >>>>>>from a "don't change anything" offer. >>>>> >>>>> >>>>> >>>>> >>>>>Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>(section 5 of current comedia draft.) >>>> >>>> >>>> >>>> >>>>That would probably work. The feature in comedia didn't end up as I >>>>hoped it would. While it does mean you have to do something special >>>>(add the a=reconnect) attribute to cause a reconnect, having done that >>>>once you then have to do something else (remove the a=reconnect) in a >>>>subsequent exchange. >>>> >>>>I think it would be better if there were something like a=version:nnn, >>>>which would just be a version number for a particular media session. >>>>Then whenever it changes you reconnect. If the attribute was absent it >>>>could be defaulted from the o-line. >>> >>> >>> >>>I agree that sounds like a better approach. Do you think there is any >>>chance to convince the COMEDIA folks to follow the same approach? >>> >>>> >>>> Paul >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 16 14:40:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26285 for ; Fri, 16 Jan 2004 14:40:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZoh-00070l-Nu for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:39:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GJddj6026945 for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:39:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZoh-00070W-D8 for simple-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 14:39:39 -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 OAA26247 for ; Fri, 16 Jan 2004 14:39:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZoe-0000ha-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:39:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZnc-0000eq-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:38:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZnA-0000cG-00; Fri, 16 Jan 2004 14:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZnA-0006lm-0C; Fri, 16 Jan 2004 14:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag86b-0002Mb-Hw for simple@optimus.ietf.org; Mon, 12 Jan 2004 14:52:09 -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 OAA13525 for ; Mon, 12 Jan 2004 14:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag86Y-0003a7-00 for simple@ietf.org; Mon, 12 Jan 2004 14:52:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag84i-0003Ud-00 for simple@ietf.org; Mon, 12 Jan 2004 14:50:13 -0500 Received: from host106.216.41.119.conversent.net ([216.41.119.106] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag83A-0003NS-00; Mon, 12 Jan 2004 14:48:37 -0500 Received: from yon-lattitude.rfdsoftware.com (rt314.tactical-sw.com [216.41.119.98]) (authenticated) by [216.41.119.110] (8.10.2/8.10.2) with ESMTP id i0CJoPZ31001; Mon, 12 Jan 2004 14:50:25 -0500 Message-Id: <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Paul Kyzivat From: David Yon Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates Cc: simple@ietf.org, mmusic@ietf.org In-Reply-To: <4002E412.2070608@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 14:48:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 01:14 PM 1/12/2004, Paul Kyzivat wrote: >David Yon wrote: >>Here I am! :-) >>Dialout.Net is defunct, but at the moment I am still willing to support >>the comedia draft, although I have much less time available to me for it. > >I was suspecting Dialout might be gone because attempts to access the web >site timed out. Glad to hear that you are still around. Maybe you should >submit a new version of comedia just to update your address. Yeah, I was waiting for other excuses to freshen comedia, but there are a couple of issues that have kept it deadlocked. While not all issues for an upcoming comedia-06 have been resolved, it would probably be worthwhile to spin it just to get discussion going again, even if there are known flaws. >>My only concern with a "version" attribute is that it causes a >>reconnection by inference. I'm afraid that it would be rife with >>temptation to use it to version-stamp the session for other reasons that >>do not imply the impetus to reconnect. Is there some tangible scenario >>where "version" is superior to "reconnect"? > >I can see how you might consider reconnection by inference to be a >negative. But in my view that is also its appeal. > >The point is to preserve the behavior that reuse of unchanged SDP acts as >a no-op. Once you introduce the a=reconnect attribute, a subsequent >offer/answer cycle that reuses sdp containing that will cause another >reconnect, which isn't a no-op. > >By using a=version, it is the detection of a revised version number that >causes the reconnect. So a subsequent offer/answer cycle using the same >sdp will not see a change in version number and so will not cause another >reconnect. > >This is of significance whenever there might be components that manipulate >offers and answers in a generic way. For instance, if you have a UA that >manages multiple media streams, there may be one component that decomposes >the sdp and then interacts with a separate component in the UA for each >stream. If there is a need to make a change in one stream, it may simply >want to make a change in the description of the affected stream without >dealing with the components responsible for other streams. In general, >with the exception of a=reconnect, it can do this. > >I am not especially attached to the name "version". I am certainly willing >to entertain some other name for the attribute that is clearer and less >prone to invite abuse. E.g. we might consider a=reconnect:NNN. "reconnect:NNN" would probably be a useful enhancement to "reconnect", and if connection reestablishment was the goal of "version", then I would vote for that. The only issue would be that of the original SDP exchange. It hardly seems appropriate to include a "reconnect" attribute in the initial exchange, but then when you want to negotiate a new connection and suddenly this attribute appears, what's the appropriate value for NNN? A couple of possibilities: a) Don't worry about "a=reconnect:0" being an odd inclusion, and make it mandatory. b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". Therefore the first reconnection negotiation would have "a=reconnect:1". c) Make the omission imply "a=reconnect:", such that the first appearance of "reconnect" would be "a=reconnect:0". I would guess that (a) makes the most sense. Thoughts? Also, are there any possibilities of race conditions where the NNN would get out of sync between the two endpoints? If so, how would that be resolved? What about the additional state that must be tracked (the reconnection number)? I don't think that comedia-05 represents any additional state over connectionless media, which wouldn't be true for "reconnect:NNN". > Paul > >>At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >> >>>My attempts to reach David Yon at the address he has listed in the >>>comedia draft (yon@dialout.net) have bounced. Does anybody know whether >>>he is still at Dialout.Net, or even if Dialout.Net still exists? >>> >>> Paul >>> >>>Paul Kyzivat wrote: >>> >>>>Ben, >>>>I'm copying David Yon on this since he is author of comedia. This >>>>probably won't make any sense out of context to him, so I will >>>>separately send him some of the earlier discussion. >>>>I don't recall what the current status of comedia is. It is currently >>>>listed as a WG draft, but there don't seem to be any goals listed for it. >>>> Paul >>>>Ben Campbell wrote: >>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>> >>>>>> >>>>>>Ben Campbell wrote: >>>>>> >>>>>>>(More comments on same email...) >>>>>>> >>>>>>>Paul Kyzivat wrote: >>>>>>> >>>>>>>[...] >>>>>>> >>>>>>>> >>>>>>>>Using the same media lines for the replacement session solves the >>>>>>>>association problem for any media type - MSRP, RTP, whatever. But >>>>>>>>it also does leave the problem of distinguishing a "reconnect" >>>>>>>>offer from a "don't change anything" offer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Would doing this, plus using the COMEDIA reconnect attribute help? >>>>>>>(section 5 of current comedia draft.) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>That would probably work. The feature in comedia didn't end up as I >>>>>>hoped it would. While it does mean you have to do something special >>>>>>(add the a=reconnect) attribute to cause a reconnect, having done >>>>>>that once you then have to do something else (remove the a=reconnect) >>>>>>in a subsequent exchange. >>>>>> >>>>>>I think it would be better if there were something like >>>>>>a=version:nnn, which would just be a version number for a particular >>>>>>media session. Then whenever it changes you reconnect. If the >>>>>>attribute was absent it could be defaulted from the o-line. >>>>> >>>>> >>>>> >>>>> >>>>>I agree that sounds like a better approach. Do you think there is any >>>>>chance to convince the COMEDIA folks to follow the same approach? >>>>> >>>>>> >>>>>> Paul >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 16 14:45:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26527 for ; Fri, 16 Jan 2004 14:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZuU-00017D-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZtf-00013j-00 for simple-archive@ietf.org; Fri, 16 Jan 2004 14:44:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZsw-0000z1-00; Fri, 16 Jan 2004 14:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZsu-0007Lu-Vu; Fri, 16 Jan 2004 14:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZsc-0007C4-9e for simple@optimus.ietf.org; Fri, 16 Jan 2004 14:43:42 -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 OAA26393 for ; Fri, 16 Jan 2004 14:43:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZsZ-0000xS-00 for simple@ietf.org; Fri, 16 Jan 2004 14:43:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZra-0000sl-00 for simple@ietf.org; Fri, 16 Jan 2004 14:42:39 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhZqh-0000pA-00; Fri, 16 Jan 2004 14:41:43 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GJfWgW019444; Fri, 16 Jan 2004 13:41:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40083E66.3020903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> <40083AC6.4000101@dynamicsoft.com> In-Reply-To: <40083AC6.4000101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Jan 2004 13:41:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit However, on reflection, I wonder why we would make this a separate a-line attribute, rather than a parameter on the direction attribute. The whole purpose of the direction attribute is to specify how the connection is set up. Indicating a desire for a new connection seems to fit well into that purpose. Ben Campbell wrote: > I am fond of the choice of "connection:xx" if we are going to include it > in the initial SDP--simply because it does not offer quite as much > cognitive dissonance as discovering a "reconnect:xx" when one has not > yet connected for the first time. > > Paul Kyzivat wrote: > >> >> >> David Yon wrote: >> >>> >>> "reconnect:NNN" would probably be a useful enhancement to >>> "reconnect", and if connection reestablishment was the goal of >>> "version", then I would vote for that. >> >> >> >> That is certainly the driving force behind it at the moment. >> Unless someone can envision another use then I am happy to go along >> with this. >> >>> The only issue would be that of the original SDP exchange. It hardly >>> seems appropriate to include a "reconnect" attribute in the initial >>> exchange, but then when you want to negotiate a new connection and >>> suddenly this attribute appears, what's the appropriate value for >>> NNN? A couple of possibilities: >>> >>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and make >>> it mandatory. >>> >>> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >>> Therefore the first reconnection negotiation would have "a=reconnect:1". >>> >>> c) Make the omission imply "a=reconnect:", such that the first >>> appearance of "reconnect" would be "a=reconnect:0". >>> >>> I would guess that (a) makes the most sense. Thoughts? >> >> >> >> That seems reasonable. >> >> In practice the number doesn't mean much except that it change. It >> would work as well if it were an opaque token. >> >> When considered as a version number it makes more sense as an >> increasing number. >> >> How about a=connection:NNN? (With a default of 1.) This numbers the >> connections used to convey the media stream. This is clearly >> associated with connections, so it isn't prone to abuse, and it also >> conveys a clear semantic for the number. >> >>> Also, are there any possibilities of race conditions where the NNN >>> would get out of sync between the two endpoints? If so, how would >>> that be resolved? >> >> >> >> I don't believe there are any race conditions, though there is always >> the possibility of buggy endpoint getting confused. >> >> I don't think there are any race conditions because NNN isn't >> negotiated - it is always managed by one end and conveyed to the other >> end. In an offer/answer exchange, each side could conceivably provide >> its own value for a=reconnect:NNN. It is only meaningful when provided >> by a passive end to an active end, because it determines whether the >> active end should reconnect. >> >> In the case of MSRP, there is only one connection, so reconnection >> only makes sense in the direction of the original connection. >> >> In the case of comedia there could conceivably be two connections, one >> in each direction. If so, it is conceivable that an offer/answer >> exchange could have a=reconnect=NNN going both ways, and resulting in >> zero, one, or two reconnections. >> >>> What about the additional state that must be tracked (the >>> reconnection number)? I don't think that comedia-05 represents any >>> additional state over connectionless media, which wouldn't be true >>> for "reconnect:NNN". >> >> >> >> There is extra implicit state in comedia. It must remember active, >> passive, or both, whether still listening if passive, whether >> connected if active, and ultimately the connection itself must be >> remembered as state. This adds a number that must be associated with >> the connection. Doesn't seem like a big burden. >> >>>> Paul >>>> >>>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>>> >>>>>> My attempts to reach David Yon at the address he has listed in the >>>>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>>>> exists? >>>>>> >>>>>> Paul >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> Ben, >>>>>>> I'm copying David Yon on this since he is author of comedia. This >>>>>>> probably won't make any sense out of context to him, so I will >>>>>>> separately send him some of the earlier discussion. >>>>>>> I don't recall what the current status of comedia is. It is >>>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>>> goals listed for it. >>>>>>> Paul >>>>>>> Ben Campbell wrote: >>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ben Campbell wrote: >>>>>>>>> >>>>>>>>>> (More comments on same email...) >>>>>>>>>> >>>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>>>> whatever. But it also does leave the problem of >>>>>>>>>>> distinguishing a "reconnect" offer from a "don't change >>>>>>>>>>> anything" offer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>>> as I hoped it would. While it does mean you have to do >>>>>>>>> something special (add the a=reconnect) attribute to cause a >>>>>>>>> reconnect, having done that once you then have to do something >>>>>>>>> else (remove the a=reconnect) in a subsequent exchange. >>>>>>>>> >>>>>>>>> I think it would be better if there were something like >>>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>>> particular media session. Then whenever it changes you >>>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>>> from the o-line. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I agree that sounds like a better approach. Do you think there >>>>>>>> is any chance to convince the COMEDIA folks to follow the same >>>>>>>> approach? >>>>>>>> >>>>>>>>> >>>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 16 14:46:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26557 for ; Fri, 16 Jan 2004 14:46:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZuY-0007Xw-AH for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:45:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GJjgnC029002 for simple-archive@odin.ietf.org; Fri, 16 Jan 2004 14:45:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZuY-0007Xh-5i for simple-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 14:45:42 -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 OAA26546 for ; Fri, 16 Jan 2004 14:45:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZuV-00017I-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:45:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZtg-00013r-00 for simple-web-archive@ietf.org; Fri, 16 Jan 2004 14:44:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhZsw-0000z1-00; Fri, 16 Jan 2004 14:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZsu-0007Lu-Vu; Fri, 16 Jan 2004 14:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhZsc-0007C4-9e for simple@optimus.ietf.org; Fri, 16 Jan 2004 14:43:42 -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 OAA26393 for ; Fri, 16 Jan 2004 14:43:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZsZ-0000xS-00 for simple@ietf.org; Fri, 16 Jan 2004 14:43:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhZra-0000sl-00 for simple@ietf.org; Fri, 16 Jan 2004 14:42:39 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AhZqh-0000pA-00; Fri, 16 Jan 2004 14:41:43 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id i0GJfWgW019444; Fri, 16 Jan 2004 13:41:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <40083E66.3020903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> <40083AC6.4000101@dynamicsoft.com> In-Reply-To: <40083AC6.4000101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Jan 2004 13:41:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit However, on reflection, I wonder why we would make this a separate a-line attribute, rather than a parameter on the direction attribute. The whole purpose of the direction attribute is to specify how the connection is set up. Indicating a desire for a new connection seems to fit well into that purpose. Ben Campbell wrote: > I am fond of the choice of "connection:xx" if we are going to include it > in the initial SDP--simply because it does not offer quite as much > cognitive dissonance as discovering a "reconnect:xx" when one has not > yet connected for the first time. > > Paul Kyzivat wrote: > >> >> >> David Yon wrote: >> >>> >>> "reconnect:NNN" would probably be a useful enhancement to >>> "reconnect", and if connection reestablishment was the goal of >>> "version", then I would vote for that. >> >> >> >> That is certainly the driving force behind it at the moment. >> Unless someone can envision another use then I am happy to go along >> with this. >> >>> The only issue would be that of the original SDP exchange. It hardly >>> seems appropriate to include a "reconnect" attribute in the initial >>> exchange, but then when you want to negotiate a new connection and >>> suddenly this attribute appears, what's the appropriate value for >>> NNN? A couple of possibilities: >>> >>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and make >>> it mandatory. >>> >>> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >>> Therefore the first reconnection negotiation would have "a=reconnect:1". >>> >>> c) Make the omission imply "a=reconnect:", such that the first >>> appearance of "reconnect" would be "a=reconnect:0". >>> >>> I would guess that (a) makes the most sense. Thoughts? >> >> >> >> That seems reasonable. >> >> In practice the number doesn't mean much except that it change. It >> would work as well if it were an opaque token. >> >> When considered as a version number it makes more sense as an >> increasing number. >> >> How about a=connection:NNN? (With a default of 1.) This numbers the >> connections used to convey the media stream. This is clearly >> associated with connections, so it isn't prone to abuse, and it also >> conveys a clear semantic for the number. >> >>> Also, are there any possibilities of race conditions where the NNN >>> would get out of sync between the two endpoints? If so, how would >>> that be resolved? >> >> >> >> I don't believe there are any race conditions, though there is always >> the possibility of buggy endpoint getting confused. >> >> I don't think there are any race conditions because NNN isn't >> negotiated - it is always managed by one end and conveyed to the other >> end. In an offer/answer exchange, each side could conceivably provide >> its own value for a=reconnect:NNN. It is only meaningful when provided >> by a passive end to an active end, because it determines whether the >> active end should reconnect. >> >> In the case of MSRP, there is only one connection, so reconnection >> only makes sense in the direction of the original connection. >> >> In the case of comedia there could conceivably be two connections, one >> in each direction. If so, it is conceivable that an offer/answer >> exchange could have a=reconnect=NNN going both ways, and resulting in >> zero, one, or two reconnections. >> >>> What about the additional state that must be tracked (the >>> reconnection number)? I don't think that comedia-05 represents any >>> additional state over connectionless media, which wouldn't be true >>> for "reconnect:NNN". >> >> >> >> There is extra implicit state in comedia. It must remember active, >> passive, or both, whether still listening if passive, whether >> connected if active, and ultimately the connection itself must be >> remembered as state. This adds a number that must be associated with >> the connection. Doesn't seem like a big burden. >> >>>> Paul >>>> >>>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>>> >>>>>> My attempts to reach David Yon at the address he has listed in the >>>>>> comedia draft (yon@dialout.net) have bounced. Does anybody know >>>>>> whether he is still at Dialout.Net, or even if Dialout.Net still >>>>>> exists? >>>>>> >>>>>> Paul >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> Ben, >>>>>>> I'm copying David Yon on this since he is author of comedia. This >>>>>>> probably won't make any sense out of context to him, so I will >>>>>>> separately send him some of the earlier discussion. >>>>>>> I don't recall what the current status of comedia is. It is >>>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>>> goals listed for it. >>>>>>> Paul >>>>>>> Ben Campbell wrote: >>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ben Campbell wrote: >>>>>>>>> >>>>>>>>>> (More comments on same email...) >>>>>>>>>> >>>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Using the same media lines for the replacement session solves >>>>>>>>>>> the association problem for any media type - MSRP, RTP, >>>>>>>>>>> whatever. But it also does leave the problem of >>>>>>>>>>> distinguishing a "reconnect" offer from a "don't change >>>>>>>>>>> anything" offer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>>> as I hoped it would. While it does mean you have to do >>>>>>>>> something special (add the a=reconnect) attribute to cause a >>>>>>>>> reconnect, having done that once you then have to do something >>>>>>>>> else (remove the a=reconnect) in a subsequent exchange. >>>>>>>>> >>>>>>>>> I think it would be better if there were something like >>>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>>> particular media session. Then whenever it changes you >>>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>>> from the o-line. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I agree that sounds like a better approach. Do you think there >>>>>>>> is any chance to convince the COMEDIA folks to follow the same >>>>>>>> approach? >>>>>>>> >>>>>>>>> >>>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 19 08:33:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16058 for ; Mon, 19 Jan 2004 08:33:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiZWY-0004C3-00 for simple-archive@ietf.org; Mon, 19 Jan 2004 08:33:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiZQz-0003xe-00 for simple-archive@ietf.org; Mon, 19 Jan 2004 08:27:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AiZP7-0003m7-00; Mon, 19 Jan 2004 08:25:21 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AiZOe-0007dv-0g; Mon, 19 Jan 2004 08:24:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiZNq-000119-Ll; Mon, 19 Jan 2004 08:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiYRU-0006xx-Lm for simple@optimus.ietf.org; Mon, 19 Jan 2004 07:23:44 -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 HAA14128 for ; Mon, 19 Jan 2004 07:23:43 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiYRP-0000mI-00 for simple@ietf.org; Mon, 19 Jan 2004 07:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiYO6-0000ah-00 for simple@ietf.org; Mon, 19 Jan 2004 07:20:15 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AiYKf-0000O1-00 for simple@ietf.org; Mon, 19 Jan 2004 07:16:41 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0JCGAV07777 for ; Mon, 19 Jan 2004 14:16:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 19 Jan 2004 14:16:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 19 Jan 2004 14:16:10 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B178@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Thread-Index: AcPWxlI2ddIrlgbqSIq9/TbO6Nso9gHq/IEA To: , X-OriginalArrivalTime: 19 Jan 2004 12:16:10.0647 (UTC) FILETIME=[06235A70:01C3DE86] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 14:16:09 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Aki, Thanks for the comments. All suggestions were taken into consideration. = Some answers to your questions below.. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Niemi Aki (Nokia-M/Helsinki) > Sent: 09.January.2004 17:13 > To: simple@ietf.org > Subject: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 >=20 > >=20 > - In 3.4, 2nd p., does it mean elements=20 > specifically, or any=20 > XML elements in winfo? Any. I'll clarify. >=20 > - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I=20 > guessed what it means, but there must be a better way to state this=20 > requirement... >=20 > It MUST be possible to define a set of conditions > for the values of certain elements in a winfo document > that determine which elements to send in notifications. >=20 > - In 3.4.1, "have a specific status" instead of "are in a=20 > specific status" I changed status to state and clarified the requirement. >=20 > - In 4.1.2, 2nd p., I guess the default here means "no=20 > installed filter"? In winfo, it could mean first NOTIFY after a subscription carries full = state, and subsequent notfications carrying partial state. (but you are = right, it means no filter set by subscriber). >=20 > - Requirement in 4.2 is quite similar to the top level requirement at=20 > the start of ch 4 -> combine? 4.2 talks about the server not understanding the format of the filter = (the MIME type). The req at the start of section 4 talks about the = server understanding the filter but rejecting it. Regards, Hisham=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 19 08:33:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16120 for ; Mon, 19 Jan 2004 08:33:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiZWi-0001p7-4G for simple-archive@odin.ietf.org; Mon, 19 Jan 2004 08:33:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JDXC87007005 for simple-archive@odin.ietf.org; Mon, 19 Jan 2004 08:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiZWi-0001ou-1D for simple-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 08:33:12 -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 IAA16079 for ; Mon, 19 Jan 2004 08:33:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiZWb-0004C9-00 for simple-web-archive@ietf.org; Mon, 19 Jan 2004 08:33:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiZR1-0003xo-00 for simple-web-archive@ietf.org; Mon, 19 Jan 2004 08:27:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AiZP7-0003m7-00; Mon, 19 Jan 2004 08:25:21 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AiZOe-0007dv-0g; Mon, 19 Jan 2004 08:24:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiZNq-000119-Ll; Mon, 19 Jan 2004 08:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiYRU-0006xx-Lm for simple@optimus.ietf.org; Mon, 19 Jan 2004 07:23:44 -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 HAA14128 for ; Mon, 19 Jan 2004 07:23:43 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiYRP-0000mI-00 for simple@ietf.org; Mon, 19 Jan 2004 07:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiYO6-0000ah-00 for simple@ietf.org; Mon, 19 Jan 2004 07:20:15 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AiYKf-0000O1-00 for simple@ietf.org; Mon, 19 Jan 2004 07:16:41 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0JCGAV07777 for ; Mon, 19 Jan 2004 14:16:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 19 Jan 2004 14:16:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 19 Jan 2004 14:16:10 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B178@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 Thread-Index: AcPWxlI2ddIrlgbqSIq9/TbO6Nso9gHq/IEA To: , X-OriginalArrivalTime: 19 Jan 2004 12:16:10.0647 (UTC) FILETIME=[06235A70:01C3DE86] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 14:16:09 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Aki, Thanks for the comments. All suggestions were taken into consideration. = Some answers to your questions below.. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Niemi Aki (Nokia-M/Helsinki) > Sent: 09.January.2004 17:13 > To: simple@ietf.org > Subject: [Simple] Comments on draft-ietf-simple-winfo-filter-reqs-00 >=20 > >=20 > - In 3.4, 2nd p., does it mean elements=20 > specifically, or any=20 > XML elements in winfo? Any. I'll clarify. >=20 > - In 3.4, 3rd p. and 4th p., this is really hard to parse. I think I=20 > guessed what it means, but there must be a better way to state this=20 > requirement... >=20 > It MUST be possible to define a set of conditions > for the values of certain elements in a winfo document > that determine which elements to send in notifications. >=20 > - In 3.4.1, "have a specific status" instead of "are in a=20 > specific status" I changed status to state and clarified the requirement. >=20 > - In 4.1.2, 2nd p., I guess the default here means "no=20 > installed filter"? In winfo, it could mean first NOTIFY after a subscription carries full = state, and subsequent notfications carrying partial state. (but you are = right, it means no filter set by subscriber). >=20 > - Requirement in 4.2 is quite similar to the top level requirement at=20 > the start of ch 4 -> combine? 4.2 talks about the server not understanding the format of the filter = (the MIME type). The req at the start of section 4 talks about the = server understanding the filter but rejecting it. Regards, Hisham=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 19 13:58:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02213 for ; Mon, 19 Jan 2004 13:58:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiebh-0003zZ-00 for simple-archive@ietf.org; Mon, 19 Jan 2004 13:58:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aieam-0003xB-00 for simple-archive@ietf.org; Mon, 19 Jan 2004 13:57:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiea9-0003vW-00; Mon, 19 Jan 2004 13:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiea5-0004Nl-6e; Mon, 19 Jan 2004 13:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieZn-0004NA-Ql for simple@optimus.ietf.org; Mon, 19 Jan 2004 13:56:43 -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 NAA02085 for ; Mon, 19 Jan 2004 13:56:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AieZl-0003uG-00 for simple@ietf.org; Mon, 19 Jan 2004 13:56:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieYm-0003pw-00 for simple@ietf.org; Mon, 19 Jan 2004 13:55:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AieXp-0003ia-00; Mon, 19 Jan 2004 13:54:41 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0JIs5K8009376; Mon, 19 Jan 2004 13:54:07 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ03756; Mon, 19 Jan 2004 13:54:05 -0500 (EST) Message-ID: <400C27CC.3030307@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> <3FFD668E.4030709@cisco.com> <40081F49.9080204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 13:54:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, I am inclined to agree that this is the most expedient way forward and not worth doing anything more. It offends my sense of elegance to require a value that is intended to be ignored, and offends it futher to insist that multiple instances must be distinct to be valid even though ignored. But still it is the lesser evil. Paul Ben Campbell wrote: > Sorry for the late reply--for some reason this just showed up in my > inbox. (Or I just noticed it, anyway.) > > I don't see it as a problem to have MSRP mention that the ports must be > distinct. We currently have a standard dummy value, rather than a random > value. With this restriction, I think the answer is to say the sender > can choose any legal non-zero value, and if multiple MSRP m-lines exist, > they must have different port values. Is this sufficient? I don't see > any reason to care about how a particular implementation goes about > generating them. > > Paul Kyzivat wrote: > >> Hisham, >> >> I have an open mind about this right now. It seems to be a matter of >> picking your favorite poison, since neither alternative is ideal: >> - ensure that the ports used are unique even though they are ignored >> - change SDP - something that is not very popular. >> >> So far, aside from me there are two votes, one on each side. From the >> point of view of SIMPLE it is of course logistically simpler to leave >> SDP alone. >> >> Paul >> >> P.S. It seems that simple wasn't on the mailing list, so I have added it. >> >> hisham.khartabil@nokia.com wrote: >> >>> I would hate to see exceptions like these when building a generic SDP >>> parser with built it checks for compliancy. >>> Why can't MSRP just follow that rule? >>> >>> Regards, >>> Hisham >>> >>> >>>> -----Original Message----- >>>> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>>> ext Paul E. Jones >>>> Sent: 07.January.2004 23:15 >>>> To: Paul Kyzivat; Flemming Andreasen >>>> Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>>> mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>>> mgarakan@cisco.com >>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>> >>>> >>>> Paul, >>>> >>>> While that sounds most unfortunate (I'd love to see an example if >>>> you have >>>> one), I think it would be exempt from this rule, because the port is >>>> just a >>>> dummy value. >>>> >>>> Paul >>>> >>>> ----- Original Message ----- From: "Paul Kyzivat" >>>> To: "Flemming Andreasen" >>>> Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>>> ; "Stephen Casner" ; "Colin >>>> Perkins" ; ; "Mostafa, Mohamed" >>>> ; "Abdelhamid, Hisham" ; >>>> ; >>>> Sent: Wednesday, January 07, 2004 4:12 PM >>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>> >>>> >>>> >>>>> I recently encountered an interesting case relevant to this >>>> >>>> >>>> >>>> while making >>>> >>>>> up an example for MSRP. >>>>> >>>>> In MSRP the port number is not used, except for the >>>> >>>> >>>> >>>> distinction between >>>> >>>>> a zero and non-zero value. There is a requirement that some random >>>>> non-zero value be inserted and then ignored. If there are >>>> >>>> >>>> >>>> multiple MSRP >>>> >>>>> media sessions in the same SDP body, must they have differing port >>>> >>>> >>>> >>>> numbers? >>>> >>>>> Paul >>>>> >>>>> Flemming Andreasen wrote: >>>>> >>>>>> "Kumar, Rajesh" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> AVT members, >>>>>>> >>>>>>> There was some confusion on this issue in the recent TIA >>>>>> >>>>>> >>>>>> >>>> TR.30.1 meeting >>>> >>>>>>> in Orlando, Florida. >>>>>>> >>>>>>> Could someone officially confirm or deny whether multiple >>>>>> >>>>>> >>>>>> >>>> "m=" lines >>>> >>>>>>> with the SAME media type (e.g. "audio") and protocol >>>>>> >>>>>> >>>>>> >>>> (e.g. RTP/AVP) >>>> >>>>>>> cannot be assigned the same port number? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The consensus of this discussion is that is that they >>>>> >>>>> >>>>> >>>> cannot (assuming >>>> they >>>> >>>>>> use the same IP address). >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> If they can be assigned the >>>>>>> same port number, then it is possible to selectively >>>>>> >>>>>> >>>>>> >>>> associate RFC 2733 >>>> >>>>>>> FEC with some payload types such as those that carry >>>>>> >>>>>> >>>>>> >>>> voice band data. >>>> >>>>>>> Otherwise, there is a hole in SDP that does not permit selective, >>>>>>> payload-specific declaration of FEC. I am aware of the >>>>>> >>>>>> >>>>>> >>>> fact that in RFC >>>> >>>>>>> 2733 the use of and level of FEC is a transmitter >>>>>> >>>>>> >>>>>> >>>> prerogative and that a >>>> >>>>>>> transmitter may choose to selectively utilize FEC based >>>>>> >>>>>> >>>>>> >>>> on payload type >>>> >>>>>>> transmitted. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Rajesh >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>>> Sent: Friday, December 12, 2003 4:21 AM >>>>>>>> To: Kevin Boyle >>>>>>>> Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>>>> >>>>>>> >>>>>>> >>>> mmusic@ietf.org; >>>> >>>>>>> Mostafa, Mohamed; >>>>>>> >>>>>>> >>>>>>>> Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>>>> >>>>>>> >>>>>>> >>>> same port number >>>> >>>>>>>> >>>>>>>> >>>>>>>> Kevin Boyle wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Looking back at this email stream, one question remains >>>>>>>> >>>>>>>> >>>>>>>> >>>> outstanding >>>> >>>>>>> in >>>>>>> >>>>>>> >>>>>>>>> my mind: >>>>>>>>> >>>>>>>>> What if the two m= lines have the SAME media type? For >>>>>>>> >>>>>>>> >>>>>>>> >>>> instance: >>>> >>>>>>>>> m=audio 49232 RTP/AVP 18 >>>>>>>>> m=image 49233 UDPTL t38 >>>>>>>>> m=audio 49232 RTP/AVP 100 >>>>>>>>> a=rtpmap:100 PCMU/8000 >>>>>>>>> a=gpmd:100 vbd=yes >>>>>>>>> >>>>>>>>> For some of the SDP-based protocols, the order of appearance is >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> vital >>>>>>> >>>>>>> >>>>>>>>> because it announces preference. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Only for the media formats within a given "m=" line. >>>>>>> >>>>>>> >>>>>>> >>>> Multiple "m=" >>>> >>>>>>> lines >>>>>>> >>>>>>> >>>>>>>> indicates a set of simultaneous media streams; not alternatives. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> So, this shows preference for T.38 fax relay over PCMU >>>>>>>> >>>>>>>> >>>>>>>> >>>> VBD for fax, >>>> >>>>>>>>> while utilizing G.729 for voice. As far as I can tell, this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> construct >>>>>>> >>>>>>> >>>>>>>>> is allowed, since both m lines using the same port number use a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> media >>>>>>> >>>>>>> >>>>>>>>> type of audio. >>>>>>>>> >>>>>>>>> Is my understanding correct? >>>>>>>>> >>>>>>>> >>>>>>>> Not quite. Each "m=" line corresponds to a separate media stream. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also, >>>>>>> >>>>>>> >>>>>>>> the consensus of this discussion has been that you are >>>>>>> >>>>>>> >>>>>>> >>>> *not* allowed >>>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>>> use the same port for different media lines, regardless >>>>>>> >>>>>>> >>>>>>> >>>> of whether >>>> >>>>>>> they >>>>>>> >>>>>>> >>>>>>>> share the same top-level MIME type or not. >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Kevin >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Stephen Casner [mailto:casner@acm.org] >>>>>>>>> Sent: Friday, April 25, 2003 2:57 PM >>>>>>>>> To: Rajesh Kumar >>>>>>>>> Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>>> mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>>> paulej@cisco.com >>>>>>>>> >>>>>>>>> Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>>>> >>>>>>>> >>>>>>>> >>>> port number >>>> >>>>>>>>> Rajesh, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Is the use of multiple 'm=' lines with the same port >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> number within >>>> >>>>>>>>> an >>>>>>>>> >>>>>>>>> >>>>>>>>>> SDP descriptor permitted? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Presuming that the multiple m= lines are all RTP/AVP, >>>>>>>> >>>>>>>> >>>>>>>> >>>> then doing so >>>> >>>>>>>>> causes all of the payload formats listed on the m= >>>>>>>> >>>>>>>> >>>>>>>> >>>> lines to become >>>> >>>>>>>>> part of a single RTP session (unless they are >>>>>>>> >>>>>>>> >>>>>>>> >>>> distinguished by some >>>> >>>>>>>>> other aspect of addressing). Section 5.2 of the RTP >>>>>>>> >>>>>>>> >>>>>>>> >>>> spec addresses >>>> >>>>>>>>> NOT multiplexing different media in the same RTP session. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> are >>>>>>> >>>>>>> >>>>>>>>> of >>>>>>>>> >>>>>>>>> >>>>>>>>>> the same media type (e.g. audio, image, text etc.). >>>>>>>>>> >>>>>>>>>> Now consider the case in which two RTP media formats can use a >>>>>>>>>> destination port but are registered under different MIME types. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> For >>>>>>> >>>>>>> >>>>>>>>>> example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> recourse >>>>>>>>> >>>>>>>>> >>>>>>>>>> except to use multiple media lines with the same port >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> number. For >>>> >>>>>>>>> example: >>>>>>>>> >>>>>>>>> The "can use a destination port" is the tricky part. We may not >>>>>>>>> agree. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> m=audio 49232 RTP/AVP 0 >>>>>>>>>> m=text 49232 RTP/AVP 100 >>>>>>>>>> a=rtpmap:100 t140 >>>>>>>>>> >>>>>>>>>> My thought is that although this is unsual, it is not >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> proscribed >>>> >>>>>>> by >>>>>>> >>>>>>> >>>>>>>>>> SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I believe this is proscribed by section 5.2 of the RTP >>>>>>>> >>>>>>>> >>>>>>>> >>>> spec because >>>> >>>>>>>>> these two media should not be multiplexed in one RTP session. >>>>>>>>> >>>>>>>>> My bet is that the real example you are thinking about is fax or >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> modem >>>>>>> >>>>>>> >>>>>>>>> over IP. We've been there before. >>>>>>>>> >>>>>>>>> -- Steve >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mmusic mailing list >>>>>>>>> mmusic@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 19 13:59:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02265 for ; Mon, 19 Jan 2004 13:59:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiebx-0004cu-4n for simple-archive@odin.ietf.org; Mon, 19 Jan 2004 13:58:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JIwvwi017783 for simple-archive@odin.ietf.org; Mon, 19 Jan 2004 13:58:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiebx-0004ck-1X for simple-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 13:58:57 -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 NAA02244 for ; Mon, 19 Jan 2004 13:58:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiebi-0003zf-00 for simple-web-archive@ietf.org; Mon, 19 Jan 2004 13:58:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiean-0003xJ-00 for simple-web-archive@ietf.org; Mon, 19 Jan 2004 13:57:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiea9-0003vW-00; Mon, 19 Jan 2004 13:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiea5-0004Nl-6e; Mon, 19 Jan 2004 13:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AieZn-0004NA-Ql for simple@optimus.ietf.org; Mon, 19 Jan 2004 13:56:43 -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 NAA02085 for ; Mon, 19 Jan 2004 13:56:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AieZl-0003uG-00 for simple@ietf.org; Mon, 19 Jan 2004 13:56:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieYm-0003pw-00 for simple@ietf.org; Mon, 19 Jan 2004 13:55:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AieXp-0003ia-00; Mon, 19 Jan 2004 13:54:41 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0JIs5K8009376; Mon, 19 Jan 2004 13:54:07 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ03756; Mon, 19 Jan 2004 13:54:05 -0500 (EST) Message-ID: <400C27CC.3030307@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: hisham.khartabil@nokia.com, paulej@cisco.com, fandreas@cisco.com, mmusic@ietf.org, simple@ietf.org Subject: Re: [Simple] Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <2038BCC78B1AD641891A0D1AE133DBB70179758B@esebe019.ntc.nokia.com> <3FFD668E.4030709@cisco.com> <40081F49.9080204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 13:54:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben, I am inclined to agree that this is the most expedient way forward and not worth doing anything more. It offends my sense of elegance to require a value that is intended to be ignored, and offends it futher to insist that multiple instances must be distinct to be valid even though ignored. But still it is the lesser evil. Paul Ben Campbell wrote: > Sorry for the late reply--for some reason this just showed up in my > inbox. (Or I just noticed it, anyway.) > > I don't see it as a problem to have MSRP mention that the ports must be > distinct. We currently have a standard dummy value, rather than a random > value. With this restriction, I think the answer is to say the sender > can choose any legal non-zero value, and if multiple MSRP m-lines exist, > they must have different port values. Is this sufficient? I don't see > any reason to care about how a particular implementation goes about > generating them. > > Paul Kyzivat wrote: > >> Hisham, >> >> I have an open mind about this right now. It seems to be a matter of >> picking your favorite poison, since neither alternative is ideal: >> - ensure that the ports used are unique even though they are ignored >> - change SDP - something that is not very popular. >> >> So far, aside from me there are two votes, one on each side. From the >> point of view of SIMPLE it is of course logistically simpler to leave >> SDP alone. >> >> Paul >> >> P.S. It seems that simple wasn't on the mailing list, so I have added it. >> >> hisham.khartabil@nokia.com wrote: >> >>> I would hate to see exceptions like these when building a generic SDP >>> parser with built it checks for compliancy. >>> Why can't MSRP just follow that rule? >>> >>> Regards, >>> Hisham >>> >>> >>>> -----Original Message----- >>>> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >>>> ext Paul E. Jones >>>> Sent: 07.January.2004 23:15 >>>> To: Paul Kyzivat; Flemming Andreasen >>>> Cc: Kumar, Rajesh; Kevin Boyle; Stephen Casner; Colin Perkins; >>>> mmusic@ietf.org; Mostafa, Mohamed; Abdelhamid, Hisham; >>>> mgarakan@cisco.com >>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>> >>>> >>>> Paul, >>>> >>>> While that sounds most unfortunate (I'd love to see an example if >>>> you have >>>> one), I think it would be exempt from this rule, because the port is >>>> just a >>>> dummy value. >>>> >>>> Paul >>>> >>>> ----- Original Message ----- From: "Paul Kyzivat" >>>> To: "Flemming Andreasen" >>>> Cc: "Kumar, Rajesh" ; "Kevin Boyle" >>>> ; "Stephen Casner" ; "Colin >>>> Perkins" ; ; "Mostafa, Mohamed" >>>> ; "Abdelhamid, Hisham" ; >>>> ; >>>> Sent: Wednesday, January 07, 2004 4:12 PM >>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >>>> >>>> >>>> >>>>> I recently encountered an interesting case relevant to this >>>> >>>> >>>> >>>> while making >>>> >>>>> up an example for MSRP. >>>>> >>>>> In MSRP the port number is not used, except for the >>>> >>>> >>>> >>>> distinction between >>>> >>>>> a zero and non-zero value. There is a requirement that some random >>>>> non-zero value be inserted and then ignored. If there are >>>> >>>> >>>> >>>> multiple MSRP >>>> >>>>> media sessions in the same SDP body, must they have differing port >>>> >>>> >>>> >>>> numbers? >>>> >>>>> Paul >>>>> >>>>> Flemming Andreasen wrote: >>>>> >>>>>> "Kumar, Rajesh" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> AVT members, >>>>>>> >>>>>>> There was some confusion on this issue in the recent TIA >>>>>> >>>>>> >>>>>> >>>> TR.30.1 meeting >>>> >>>>>>> in Orlando, Florida. >>>>>>> >>>>>>> Could someone officially confirm or deny whether multiple >>>>>> >>>>>> >>>>>> >>>> "m=" lines >>>> >>>>>>> with the SAME media type (e.g. "audio") and protocol >>>>>> >>>>>> >>>>>> >>>> (e.g. RTP/AVP) >>>> >>>>>>> cannot be assigned the same port number? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The consensus of this discussion is that is that they >>>>> >>>>> >>>>> >>>> cannot (assuming >>>> they >>>> >>>>>> use the same IP address). >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> If they can be assigned the >>>>>>> same port number, then it is possible to selectively >>>>>> >>>>>> >>>>>> >>>> associate RFC 2733 >>>> >>>>>>> FEC with some payload types such as those that carry >>>>>> >>>>>> >>>>>> >>>> voice band data. >>>> >>>>>>> Otherwise, there is a hole in SDP that does not permit selective, >>>>>>> payload-specific declaration of FEC. I am aware of the >>>>>> >>>>>> >>>>>> >>>> fact that in RFC >>>> >>>>>>> 2733 the use of and level of FEC is a transmitter >>>>>> >>>>>> >>>>>> >>>> prerogative and that a >>>> >>>>>>> transmitter may choose to selectively utilize FEC based >>>>>> >>>>>> >>>>>> >>>> on payload type >>>> >>>>>>> transmitted. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Rajesh >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Flemming Andreasen [mailto:fandreas@cisco.com] >>>>>>>> Sent: Friday, December 12, 2003 4:21 AM >>>>>>>> To: Kevin Boyle >>>>>>>> Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; >>>>>>> >>>>>>> >>>>>>> >>>> mmusic@ietf.org; >>>> >>>>>>> Mostafa, Mohamed; >>>>>>> >>>>>>> >>>>>>>> Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com >>>>>>>> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the >>>>>>> >>>>>>> >>>>>>> >>>> same port number >>>> >>>>>>>> >>>>>>>> >>>>>>>> Kevin Boyle wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Looking back at this email stream, one question remains >>>>>>>> >>>>>>>> >>>>>>>> >>>> outstanding >>>> >>>>>>> in >>>>>>> >>>>>>> >>>>>>>>> my mind: >>>>>>>>> >>>>>>>>> What if the two m= lines have the SAME media type? For >>>>>>>> >>>>>>>> >>>>>>>> >>>> instance: >>>> >>>>>>>>> m=audio 49232 RTP/AVP 18 >>>>>>>>> m=image 49233 UDPTL t38 >>>>>>>>> m=audio 49232 RTP/AVP 100 >>>>>>>>> a=rtpmap:100 PCMU/8000 >>>>>>>>> a=gpmd:100 vbd=yes >>>>>>>>> >>>>>>>>> For some of the SDP-based protocols, the order of appearance is >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> vital >>>>>>> >>>>>>> >>>>>>>>> because it announces preference. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Only for the media formats within a given "m=" line. >>>>>>> >>>>>>> >>>>>>> >>>> Multiple "m=" >>>> >>>>>>> lines >>>>>>> >>>>>>> >>>>>>>> indicates a set of simultaneous media streams; not alternatives. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> So, this shows preference for T.38 fax relay over PCMU >>>>>>>> >>>>>>>> >>>>>>>> >>>> VBD for fax, >>>> >>>>>>>>> while utilizing G.729 for voice. As far as I can tell, this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> construct >>>>>>> >>>>>>> >>>>>>>>> is allowed, since both m lines using the same port number use a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> media >>>>>>> >>>>>>> >>>>>>>>> type of audio. >>>>>>>>> >>>>>>>>> Is my understanding correct? >>>>>>>>> >>>>>>>> >>>>>>>> Not quite. Each "m=" line corresponds to a separate media stream. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also, >>>>>>> >>>>>>> >>>>>>>> the consensus of this discussion has been that you are >>>>>>> >>>>>>> >>>>>>> >>>> *not* allowed >>>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>>> use the same port for different media lines, regardless >>>>>>> >>>>>>> >>>>>>> >>>> of whether >>>> >>>>>>> they >>>>>>> >>>>>>> >>>>>>>> share the same top-level MIME type or not. >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Kevin >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Stephen Casner [mailto:casner@acm.org] >>>>>>>>> Sent: Friday, April 25, 2003 2:57 PM >>>>>>>>> To: Rajesh Kumar >>>>>>>>> Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; >>>>>>>>> mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; >>>>>>>>> paulej@cisco.com >>>>>>>>> >>>>>>>>> Subject: [MMUSIC] Re: Multiple 'm' lines with the same >>>>>>>> >>>>>>>> >>>>>>>> >>>> port number >>>> >>>>>>>>> Rajesh, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Is the use of multiple 'm=' lines with the same port >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> number within >>>> >>>>>>>>> an >>>>>>>>> >>>>>>>>> >>>>>>>>>> SDP descriptor permitted? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Presuming that the multiple m= lines are all RTP/AVP, >>>>>>>> >>>>>>>> >>>>>>>> >>>> then doing so >>>> >>>>>>>>> causes all of the payload formats listed on the m= >>>>>>>> >>>>>>>> >>>>>>>> >>>> lines to become >>>> >>>>>>>>> part of a single RTP session (unless they are >>>>>>>> >>>>>>>> >>>>>>>> >>>> distinguished by some >>>> >>>>>>>>> other aspect of addressing). Section 5.2 of the RTP >>>>>>>> >>>>>>>> >>>>>>>> >>>> spec addresses >>>> >>>>>>>>> NOT multiplexing different media in the same RTP session. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In SDP, as it is defined, all the media formats on an 'm=' line >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> are >>>>>>> >>>>>>> >>>>>>>>> of >>>>>>>>> >>>>>>>>> >>>>>>>>>> the same media type (e.g. audio, image, text etc.). >>>>>>>>>> >>>>>>>>>> Now consider the case in which two RTP media formats can use a >>>>>>>>>> destination port but are registered under different MIME types. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> For >>>>>>> >>>>>>> >>>>>>>>>> example, text/t140 and audio/PCMU. In this case, there is no >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> recourse >>>>>>>>> >>>>>>>>> >>>>>>>>>> except to use multiple media lines with the same port >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> number. For >>>> >>>>>>>>> example: >>>>>>>>> >>>>>>>>> The "can use a destination port" is the tricky part. We may not >>>>>>>>> agree. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> m=audio 49232 RTP/AVP 0 >>>>>>>>>> m=text 49232 RTP/AVP 100 >>>>>>>>>> a=rtpmap:100 t140 >>>>>>>>>> >>>>>>>>>> My thought is that although this is unsual, it is not >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> proscribed >>>> >>>>>>> by >>>>>>> >>>>>>> >>>>>>>>>> SDP syntax in RFC 2327 or in its latest internet draft. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I believe this is proscribed by section 5.2 of the RTP >>>>>>>> >>>>>>>> >>>>>>>> >>>> spec because >>>> >>>>>>>>> these two media should not be multiplexed in one RTP session. >>>>>>>>> >>>>>>>>> My bet is that the real example you are thinking about is fax or >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> modem >>>>>>> >>>>>>> >>>>>>>>> over IP. We've been there before. >>>>>>>>> >>>>>>>>> -- Steve >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mmusic mailing list >>>>>>>>> mmusic@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Jan 19 14:24:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03357 for ; Mon, 19 Jan 2004 14:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aif15-0005wt-00 for simple-archive@ietf.org; Mon, 19 Jan 2004 14:24:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiew0-0005XQ-00 for simple-archive@ietf.org; Mon, 19 Jan 2004 14:19:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiest-0005Dr-00; Mon, 19 Jan 2004 14:16:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiesT-0005Xc-Q4; Mon, 19 Jan 2004 14:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiesK-0005X2-63 for simple@optimus.ietf.org; Mon, 19 Jan 2004 14:15:57 -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 OAA03007 for ; Mon, 19 Jan 2004 14:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiesC-0005Af-00 for simple@ietf.org; Mon, 19 Jan 2004 14:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieoK-0004tI-00 for simple@ietf.org; Mon, 19 Jan 2004 14:11:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AiekM-0004YM-00; Mon, 19 Jan 2004 14:07:38 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2004 11:07:16 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0JJ6QLE024772; Mon, 19 Jan 2004 14:06:27 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ05149; Mon, 19 Jan 2004 14:06:23 -0500 (EST) Message-ID: <400C2AAF.1060703@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> <40083AC6.4000101@dynamicsoft.com> <40083E66.3020903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 14:06:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > However, on reflection, I wonder why we would make this a separate > a-line attribute, rather than a parameter on the direction attribute. > The whole purpose of the direction attribute is to specify how the > connection is set up. Indicating a desire for a new connection seems to > fit well into that purpose. If we use the same semantics as with a=connection:NNN then I am quite fine with it being bundled into the direction attribute. We will have to find some way to fit in the value NNN and disambiguate it from a timeout value. Complicated because I think both are optional. Or we could make NNN be mandatory. That isn't so annoying in this form. Paul > Ben Campbell wrote: > >> I am fond of the choice of "connection:xx" if we are going to include >> it in the initial SDP--simply because it does not offer quite as much >> cognitive dissonance as discovering a "reconnect:xx" when one has not >> yet connected for the first time. >> >> Paul Kyzivat wrote: >> >>> >>> >>> David Yon wrote: >>> >>>> >>>> "reconnect:NNN" would probably be a useful enhancement to >>>> "reconnect", and if connection reestablishment was the goal of >>>> "version", then I would vote for that. >>> >>> >>> >>> >>> That is certainly the driving force behind it at the moment. >>> Unless someone can envision another use then I am happy to go along >>> with this. >>> >>>> The only issue would be that of the original SDP exchange. It >>>> hardly seems appropriate to include a "reconnect" attribute in the >>>> initial exchange, but then when you want to negotiate a new >>>> connection and suddenly this attribute appears, what's the >>>> appropriate value for NNN? A couple of possibilities: >>>> >>>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and >>>> make it mandatory. >>>> >>>> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >>>> Therefore the first reconnection negotiation would have >>>> "a=reconnect:1". >>>> >>>> c) Make the omission imply "a=reconnect:", such that the first >>>> appearance of "reconnect" would be "a=reconnect:0". >>>> >>>> I would guess that (a) makes the most sense. Thoughts? >>> >>> >>> >>> >>> That seems reasonable. >>> >>> In practice the number doesn't mean much except that it change. It >>> would work as well if it were an opaque token. >>> >>> When considered as a version number it makes more sense as an >>> increasing number. >>> >>> How about a=connection:NNN? (With a default of 1.) This numbers the >>> connections used to convey the media stream. This is clearly >>> associated with connections, so it isn't prone to abuse, and it also >>> conveys a clear semantic for the number. >>> >>>> Also, are there any possibilities of race conditions where the NNN >>>> would get out of sync between the two endpoints? If so, how would >>>> that be resolved? >>> >>> >>> >>> >>> I don't believe there are any race conditions, though there is always >>> the possibility of buggy endpoint getting confused. >>> >>> I don't think there are any race conditions because NNN isn't >>> negotiated - it is always managed by one end and conveyed to the >>> other end. In an offer/answer exchange, each side could conceivably >>> provide its own value for a=reconnect:NNN. It is only meaningful when >>> provided by a passive end to an active end, because it determines >>> whether the active end should reconnect. >>> >>> In the case of MSRP, there is only one connection, so reconnection >>> only makes sense in the direction of the original connection. >>> >>> In the case of comedia there could conceivably be two connections, >>> one in each direction. If so, it is conceivable that an offer/answer >>> exchange could have a=reconnect=NNN going both ways, and resulting in >>> zero, one, or two reconnections. >>> >>>> What about the additional state that must be tracked (the >>>> reconnection number)? I don't think that comedia-05 represents any >>>> additional state over connectionless media, which wouldn't be true >>>> for "reconnect:NNN". >>> >>> >>> >>> >>> There is extra implicit state in comedia. It must remember active, >>> passive, or both, whether still listening if passive, whether >>> connected if active, and ultimately the connection itself must be >>> remembered as state. This adds a number that must be associated with >>> the connection. Doesn't seem like a big burden. >>> >>>>> Paul >>>>> >>>>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>>>> >>>>>>> My attempts to reach David Yon at the address he has listed in >>>>>>> the comedia draft (yon@dialout.net) have bounced. Does anybody >>>>>>> know whether he is still at Dialout.Net, or even if Dialout.Net >>>>>>> still exists? >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>>> Ben, >>>>>>>> I'm copying David Yon on this since he is author of comedia. >>>>>>>> This probably won't make any sense out of context to him, so I >>>>>>>> will separately send him some of the earlier discussion. >>>>>>>> I don't recall what the current status of comedia is. It is >>>>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>>>> goals listed for it. >>>>>>>> Paul >>>>>>>> Ben Campbell wrote: >>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ben Campbell wrote: >>>>>>>>>> >>>>>>>>>>> (More comments on same email...) >>>>>>>>>>> >>>>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>>> >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Using the same media lines for the replacement session >>>>>>>>>>>> solves the association problem for any media type - MSRP, >>>>>>>>>>>> RTP, whatever. But it also does leave the problem of >>>>>>>>>>>> distinguishing a "reconnect" offer from a "don't change >>>>>>>>>>>> anything" offer. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>>>> as I hoped it would. While it does mean you have to do >>>>>>>>>> something special (add the a=reconnect) attribute to cause a >>>>>>>>>> reconnect, having done that once you then have to do something >>>>>>>>>> else (remove the a=reconnect) in a subsequent exchange. >>>>>>>>>> >>>>>>>>>> I think it would be better if there were something like >>>>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>>>> particular media session. Then whenever it changes you >>>>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>>>> from the o-line. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that sounds like a better approach. Do you think there >>>>>>>>> is any chance to convince the COMEDIA folks to follow the same >>>>>>>>> approach? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Simple mailing list >>>>>>>> Simple@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Jan 19 14:25:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03398 for ; Mon, 19 Jan 2004 14:25:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif1I-0006E6-PW for simple-archive@odin.ietf.org; Mon, 19 Jan 2004 14:25:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JJP8fc023928 for simple-archive@odin.ietf.org; Mon, 19 Jan 2004 14:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif1I-0006Dr-Li for simple-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 14:25:08 -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 OAA03375 for ; Mon, 19 Jan 2004 14:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aif1B-0005xb-00 for simple-web-archive@ietf.org; Mon, 19 Jan 2004 14:25:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiew2-0005Xt-00 for simple-web-archive@ietf.org; Mon, 19 Jan 2004 14:19:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiest-0005Dr-00; Mon, 19 Jan 2004 14:16:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiesT-0005Xc-Q4; Mon, 19 Jan 2004 14:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiesK-0005X2-63 for simple@optimus.ietf.org; Mon, 19 Jan 2004 14:15:57 -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 OAA03007 for ; Mon, 19 Jan 2004 14:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiesC-0005Af-00 for simple@ietf.org; Mon, 19 Jan 2004 14:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieoK-0004tI-00 for simple@ietf.org; Mon, 19 Jan 2004 14:11:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AiekM-0004YM-00; Mon, 19 Jan 2004 14:07:38 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2004 11:07:16 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0JJ6QLE024772; Mon, 19 Jan 2004 14:06:27 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFJ05149; Mon, 19 Jan 2004 14:06:23 -0500 (EST) Message-ID: <400C2AAF.1060703@cisco.com> From: Paul Kyzivat 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: Ben Campbell CC: David Yon , simple@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> <3FE369B3.6040709@dynamicsoft.com> <3FF9B447.7070306@cisco.com> <3FF9D37D.1070400@dynamicsoft.com> <3FFB1A1A.90805@cisco.com> <3FFB1CFC.6030301@dynamicsoft.com> <3FFB3D56.6070900@cisco.com> <5.1.1.6.0.20040112104514.02fa9eb0@mail.rfdsoftware.com> <5.1.1.6.0.20040112143747.02fa9eb0@mail.rfdsoftware.com> <400305C5.10009@cisco.com> <40083AC6.4000101@dynamicsoft.com> <40083E66.3020903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 14:06:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > However, on reflection, I wonder why we would make this a separate > a-line attribute, rather than a parameter on the direction attribute. > The whole purpose of the direction attribute is to specify how the > connection is set up. Indicating a desire for a new connection seems to > fit well into that purpose. If we use the same semantics as with a=connection:NNN then I am quite fine with it being bundled into the direction attribute. We will have to find some way to fit in the value NNN and disambiguate it from a timeout value. Complicated because I think both are optional. Or we could make NNN be mandatory. That isn't so annoying in this form. Paul > Ben Campbell wrote: > >> I am fond of the choice of "connection:xx" if we are going to include >> it in the initial SDP--simply because it does not offer quite as much >> cognitive dissonance as discovering a "reconnect:xx" when one has not >> yet connected for the first time. >> >> Paul Kyzivat wrote: >> >>> >>> >>> David Yon wrote: >>> >>>> >>>> "reconnect:NNN" would probably be a useful enhancement to >>>> "reconnect", and if connection reestablishment was the goal of >>>> "version", then I would vote for that. >>> >>> >>> >>> >>> That is certainly the driving force behind it at the moment. >>> Unless someone can envision another use then I am happy to go along >>> with this. >>> >>>> The only issue would be that of the original SDP exchange. It >>>> hardly seems appropriate to include a "reconnect" attribute in the >>>> initial exchange, but then when you want to negotiate a new >>>> connection and suddenly this attribute appears, what's the >>>> appropriate value for NNN? A couple of possibilities: >>>> >>>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and >>>> make it mandatory. >>>> >>>> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0". >>>> Therefore the first reconnection negotiation would have >>>> "a=reconnect:1". >>>> >>>> c) Make the omission imply "a=reconnect:", such that the first >>>> appearance of "reconnect" would be "a=reconnect:0". >>>> >>>> I would guess that (a) makes the most sense. Thoughts? >>> >>> >>> >>> >>> That seems reasonable. >>> >>> In practice the number doesn't mean much except that it change. It >>> would work as well if it were an opaque token. >>> >>> When considered as a version number it makes more sense as an >>> increasing number. >>> >>> How about a=connection:NNN? (With a default of 1.) This numbers the >>> connections used to convey the media stream. This is clearly >>> associated with connections, so it isn't prone to abuse, and it also >>> conveys a clear semantic for the number. >>> >>>> Also, are there any possibilities of race conditions where the NNN >>>> would get out of sync between the two endpoints? If so, how would >>>> that be resolved? >>> >>> >>> >>> >>> I don't believe there are any race conditions, though there is always >>> the possibility of buggy endpoint getting confused. >>> >>> I don't think there are any race conditions because NNN isn't >>> negotiated - it is always managed by one end and conveyed to the >>> other end. In an offer/answer exchange, each side could conceivably >>> provide its own value for a=reconnect:NNN. It is only meaningful when >>> provided by a passive end to an active end, because it determines >>> whether the active end should reconnect. >>> >>> In the case of MSRP, there is only one connection, so reconnection >>> only makes sense in the direction of the original connection. >>> >>> In the case of comedia there could conceivably be two connections, >>> one in each direction. If so, it is conceivable that an offer/answer >>> exchange could have a=reconnect=NNN going both ways, and resulting in >>> zero, one, or two reconnections. >>> >>>> What about the additional state that must be tracked (the >>>> reconnection number)? I don't think that comedia-05 represents any >>>> additional state over connectionless media, which wouldn't be true >>>> for "reconnect:NNN". >>> >>> >>> >>> >>> There is extra implicit state in comedia. It must remember active, >>> passive, or both, whether still listening if passive, whether >>> connected if active, and ultimately the connection itself must be >>> remembered as state. This adds a number that must be associated with >>> the connection. Doesn't seem like a big burden. >>> >>>>> Paul >>>>> >>>>>> At 10:06 AM 1/12/2004, Paul Kyzivat wrote: >>>>>> >>>>>>> My attempts to reach David Yon at the address he has listed in >>>>>>> the comedia draft (yon@dialout.net) have bounced. Does anybody >>>>>>> know whether he is still at Dialout.Net, or even if Dialout.Net >>>>>>> still exists? >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>>> Ben, >>>>>>>> I'm copying David Yon on this since he is author of comedia. >>>>>>>> This probably won't make any sense out of context to him, so I >>>>>>>> will separately send him some of the earlier discussion. >>>>>>>> I don't recall what the current status of comedia is. It is >>>>>>>> currently listed as a WG draft, but there don't seem to be any >>>>>>>> goals listed for it. >>>>>>>> Paul >>>>>>>> Ben Campbell wrote: >>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ben Campbell wrote: >>>>>>>>>> >>>>>>>>>>> (More comments on same email...) >>>>>>>>>>> >>>>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>>> >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Using the same media lines for the replacement session >>>>>>>>>>>> solves the association problem for any media type - MSRP, >>>>>>>>>>>> RTP, whatever. But it also does leave the problem of >>>>>>>>>>>> distinguishing a "reconnect" offer from a "don't change >>>>>>>>>>>> anything" offer. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute >>>>>>>>>>> help? (section 5 of current comedia draft.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That would probably work. The feature in comedia didn't end up >>>>>>>>>> as I hoped it would. While it does mean you have to do >>>>>>>>>> something special (add the a=reconnect) attribute to cause a >>>>>>>>>> reconnect, having done that once you then have to do something >>>>>>>>>> else (remove the a=reconnect) in a subsequent exchange. >>>>>>>>>> >>>>>>>>>> I think it would be better if there were something like >>>>>>>>>> a=version:nnn, which would just be a version number for a >>>>>>>>>> particular media session. Then whenever it changes you >>>>>>>>>> reconnect. If the attribute was absent it could be defaulted >>>>>>>>>> from the o-line. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that sounds like a better approach. Do you think there >>>>>>>>> is any chance to convince the COMEDIA folks to follow the same >>>>>>>>> approach? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Simple mailing list >>>>>>>> Simple@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 20 20:48:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05978 for ; Tue, 20 Jan 2004 20:48:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj7U0-0005RB-00 for simple-archive@ietf.org; Tue, 20 Jan 2004 20:48:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj7T3-0005PN-00 for simple-archive@ietf.org; Tue, 20 Jan 2004 20:47:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj7ST-0005Nq-00; Tue, 20 Jan 2004 20:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj7SP-0007H6-ET; Tue, 20 Jan 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj7SA-0007Gp-2h for simple@optimus.ietf.org; Tue, 20 Jan 2004 20:46:46 -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 UAA05946 for ; Tue, 20 Jan 2004 20:46:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj7S7-0005NP-00 for simple@ietf.org; Tue, 20 Jan 2004 20:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj7RC-0005L8-00 for simple@ietf.org; Tue, 20 Jan 2004 20:45:46 -0500 Received: from adsl-66-123-193-125.dsl.snfc21.pacbell.net ([66.123.193.125] helo=mail1.sonimtech.com) by ietf-mx with esmtp (Exim 4.12) id 1Aj7QR-0005Gk-00 for simple@ietf.org; Tue, 20 Jan 2004 20:44:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> Thread-Topic: Subscribing to different PResentities Thread-Index: AcPfwD8Ilz25wrtKR6m+jtbWk4Iv2A== From: "Kamal Gupta" To: Content-Transfer-Encoding: quoted-printable Subject: [Simple] Subscribing to different PResentities Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 17:45:28 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I was wondering if it is allowed to Subscribe to 2 different = Presentities in the same dialog for the same event. I understand this = leads to putting a different "To" url in the request. And as the dialog = includes : the from-tag, to-tag, call-id, Is it OK to put a different = "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 20 20:49:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06004 for ; Tue, 20 Jan 2004 20:49:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj7U4-0007WP-2B for simple-archive@odin.ietf.org; Tue, 20 Jan 2004 20:48:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L1mi11028909 for simple-archive@odin.ietf.org; Tue, 20 Jan 2004 20:48:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj7U3-0007WC-S6 for simple-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 20:48:43 -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 UAA05998 for ; Tue, 20 Jan 2004 20:48:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj7U1-0005RG-00 for simple-web-archive@ietf.org; Tue, 20 Jan 2004 20:48:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj7T3-0005PU-00 for simple-web-archive@ietf.org; Tue, 20 Jan 2004 20:47:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj7ST-0005Nq-00; Tue, 20 Jan 2004 20:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj7SP-0007H6-ET; Tue, 20 Jan 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj7SA-0007Gp-2h for simple@optimus.ietf.org; Tue, 20 Jan 2004 20:46:46 -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 UAA05946 for ; Tue, 20 Jan 2004 20:46:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj7S7-0005NP-00 for simple@ietf.org; Tue, 20 Jan 2004 20:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj7RC-0005L8-00 for simple@ietf.org; Tue, 20 Jan 2004 20:45:46 -0500 Received: from adsl-66-123-193-125.dsl.snfc21.pacbell.net ([66.123.193.125] helo=mail1.sonimtech.com) by ietf-mx with esmtp (Exim 4.12) id 1Aj7QR-0005Gk-00 for simple@ietf.org; Tue, 20 Jan 2004 20:44:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> Thread-Topic: Subscribing to different PResentities Thread-Index: AcPfwD8Ilz25wrtKR6m+jtbWk4Iv2A== From: "Kamal Gupta" To: Content-Transfer-Encoding: quoted-printable Subject: [Simple] Subscribing to different PResentities Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 17:45:28 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I was wondering if it is allowed to Subscribe to 2 different = Presentities in the same dialog for the same event. I understand this = leads to putting a different "To" url in the request. And as the dialog = includes : the from-tag, to-tag, call-id, Is it OK to put a different = "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 21 04:21:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13419 for ; Wed, 21 Jan 2004 04:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjEYh-0000ck-00 for simple-archive@ietf.org; Wed, 21 Jan 2004 04:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjEXg-0000aa-00 for simple-archive@ietf.org; Wed, 21 Jan 2004 04:20:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjEWs-0000Yj-00; Wed, 21 Jan 2004 04:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEWn-0005QI-5v; Wed, 21 Jan 2004 04:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEVt-0005P0-E0 for simple@optimus.ietf.org; Wed, 21 Jan 2004 04:19: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 EAA13366 for ; Wed, 21 Jan 2004 04:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjEVq-0000WQ-00 for simple@ietf.org; Wed, 21 Jan 2004 04:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjEUp-0000UV-00 for simple@ietf.org; Wed, 21 Jan 2004 04:17:59 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AjEUC-0000Ph-00 for simple@ietf.org; Wed, 21 Jan 2004 04:17:20 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0L9Gu9W006362; Wed, 21 Jan 2004 04:16:58 -0500 (EST) Message-ID: <400E437B.7080403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kamal Gupta CC: simple@ietf.org Subject: Re: [Simple] Subscribing to different PResentities References: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> In-Reply-To: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 04:16:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I dont think it makes sense to do this. There is no way to know whether or not the second presentity exists at the end of the first dialog. -Jonathan R. Kamal Gupta wrote: > Hi, > > I was wondering if it is allowed to Subscribe to 2 different > Presentities in the same dialog for the same event. I understand > this leads to putting a different "To" url in the request. And as > the dialog includes : the from-tag, to-tag, call-id, Is it OK to > put a different "To" url in 2 Subscribe messages within a dialog ?? > > > Thanks. KG > > > > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jan 21 04:22:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13440 for ; Wed, 21 Jan 2004 04:22:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEYm-0005Zm-75 for simple-archive@odin.ietf.org; Wed, 21 Jan 2004 04:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L9M44F021431 for simple-archive@odin.ietf.org; Wed, 21 Jan 2004 04:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEYl-0005Za-GC for simple-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 04:22:03 -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 EAA13437 for ; Wed, 21 Jan 2004 04:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjEYi-0000cx-00 for simple-web-archive@ietf.org; Wed, 21 Jan 2004 04:22:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjEXh-0000ah-00 for simple-web-archive@ietf.org; Wed, 21 Jan 2004 04:20:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjEWs-0000Yj-00; Wed, 21 Jan 2004 04:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEWn-0005QI-5v; Wed, 21 Jan 2004 04:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEVt-0005P0-E0 for simple@optimus.ietf.org; Wed, 21 Jan 2004 04:19: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 EAA13366 for ; Wed, 21 Jan 2004 04:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjEVq-0000WQ-00 for simple@ietf.org; Wed, 21 Jan 2004 04:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjEUp-0000UV-00 for simple@ietf.org; Wed, 21 Jan 2004 04:17:59 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AjEUC-0000Ph-00 for simple@ietf.org; Wed, 21 Jan 2004 04:17:20 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0L9Gu9W006362; Wed, 21 Jan 2004 04:16:58 -0500 (EST) Message-ID: <400E437B.7080403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kamal Gupta CC: simple@ietf.org Subject: Re: [Simple] Subscribing to different PResentities References: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> In-Reply-To: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 04:16:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I dont think it makes sense to do this. There is no way to know whether or not the second presentity exists at the end of the first dialog. -Jonathan R. Kamal Gupta wrote: > Hi, > > I was wondering if it is allowed to Subscribe to 2 different > Presentities in the same dialog for the same event. I understand > this leads to putting a different "To" url in the request. And as > the dialog includes : the from-tag, to-tag, call-id, Is it OK to > put a different "To" url in 2 Subscribe messages within a dialog ?? > > > Thanks. KG > > > > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 21 11:05:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27445 for ; Wed, 21 Jan 2004 11:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKqp-0004xX-00 for simple-archive@ietf.org; Wed, 21 Jan 2004 11:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKps-0004tg-00 for simple-archive@ietf.org; Wed, 21 Jan 2004 11:04:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjKov-0004qy-00; Wed, 21 Jan 2004 11:03:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKom-0000jN-VA; Wed, 21 Jan 2004 11:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKny-0000dI-5c for simple@optimus.ietf.org; Wed, 21 Jan 2004 11:02:10 -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 LAA27352 for ; Wed, 21 Jan 2004 11:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKnv-0004o5-00 for simple@ietf.org; Wed, 21 Jan 2004 11:02:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKmw-0004l7-00 for simple@ietf.org; Wed, 21 Jan 2004 11:01:06 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AjKlx-0004hj-00 for simple@ietf.org; Wed, 21 Jan 2004 11:00:06 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2004 08:03:41 +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 i0LFxWNM007476; Wed, 21 Jan 2004 07:59:32 -0800 (PST) Received: from cisco.com (dhcp-10-86-165-201.cisco.com [10.86.165.201]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFK60488; Wed, 21 Jan 2004 10:59:31 -0500 (EST) Message-ID: <400EA1E2.8000200@cisco.com> From: Paul Kyzivat 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: Kamal Gupta CC: simple@ietf.org Subject: Re: [Simple] Subscribing to different PResentities References: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 10:59:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Kamal Gupta wrote: > Hi, > > I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? No. Its not a matter of "allowed" - it is impossible by definition. The subscription target is initially defined by the request URI. This becomes the dialog target. Effectively, the target of the dialog defines the presentity you are subscribed to. Any other subscription thru the same dialog will be associated with the same presentity. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jan 21 11:05:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27498 for ; Wed, 21 Jan 2004 11:05:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKqt-0000vL-0k for simple-archive@odin.ietf.org; Wed, 21 Jan 2004 11:05:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LG5A97003550 for simple-archive@odin.ietf.org; Wed, 21 Jan 2004 11:05:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKqs-0000vB-TS for simple-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:05:10 -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 LAA27448 for ; Wed, 21 Jan 2004 11:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKqq-0004xc-00 for simple-web-archive@ietf.org; Wed, 21 Jan 2004 11:05:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKpt-0004tn-00 for simple-web-archive@ietf.org; Wed, 21 Jan 2004 11:04:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjKov-0004qy-00; Wed, 21 Jan 2004 11:03:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKom-0000jN-VA; Wed, 21 Jan 2004 11:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKny-0000dI-5c for simple@optimus.ietf.org; Wed, 21 Jan 2004 11:02:10 -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 LAA27352 for ; Wed, 21 Jan 2004 11:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKnv-0004o5-00 for simple@ietf.org; Wed, 21 Jan 2004 11:02:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKmw-0004l7-00 for simple@ietf.org; Wed, 21 Jan 2004 11:01:06 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AjKlx-0004hj-00 for simple@ietf.org; Wed, 21 Jan 2004 11:00:06 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2004 08:03:41 +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 i0LFxWNM007476; Wed, 21 Jan 2004 07:59:32 -0800 (PST) Received: from cisco.com (dhcp-10-86-165-201.cisco.com [10.86.165.201]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFK60488; Wed, 21 Jan 2004 10:59:31 -0500 (EST) Message-ID: <400EA1E2.8000200@cisco.com> From: Paul Kyzivat 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: Kamal Gupta CC: simple@ietf.org Subject: Re: [Simple] Subscribing to different PResentities References: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA8F@mail1.sonimtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 10:59:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kamal Gupta wrote: > Hi, > > I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? No. Its not a matter of "allowed" - it is impossible by definition. The subscription target is initially defined by the request URI. This becomes the dialog target. Effectively, the target of the dialog defines the presentity you are subscribed to. Any other subscription thru the same dialog will be associated with the same presentity. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 21 16:29:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09739 for ; Wed, 21 Jan 2004 16:29:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPud-0002U3-00 for simple-archive@ietf.org; Wed, 21 Jan 2004 16:29:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPti-0002RJ-00 for simple-archive@ietf.org; Wed, 21 Jan 2004 16:28:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPtP-0002Or-00; Wed, 21 Jan 2004 16:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPtJ-0005el-9Z; Wed, 21 Jan 2004 16:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPsV-0005Nn-VY for simple@optimus.ietf.org; Wed, 21 Jan 2004 16:27:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09553; Wed, 21 Jan 2004 16:27:09 -0500 (EST) Message-Id: <200401212127.QAA09553@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 16:27:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Partial Notification of Presence Information Author(s) : M. Lonnfors Filename : draft-ietf-simple-partial-notify-01.txt Pages : 17 Date : 2004-1-21 A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase efficiency, by introducing a mechanism called partial notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-21164315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-21164315.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jan 21 16:29:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09791 for ; Wed, 21 Jan 2004 16:29:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPug-0005vn-66 for simple-archive@odin.ietf.org; Wed, 21 Jan 2004 16:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLTQop022793 for simple-archive@odin.ietf.org; Wed, 21 Jan 2004 16:29:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPug-0005vY-1c for simple-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:29:26 -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 QAA09754 for ; Wed, 21 Jan 2004 16:29:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPue-0002U8-00 for simple-web-archive@ietf.org; Wed, 21 Jan 2004 16:29:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPtj-0002RQ-00 for simple-web-archive@ietf.org; Wed, 21 Jan 2004 16:28:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPtP-0002Or-00; Wed, 21 Jan 2004 16:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPtJ-0005el-9Z; Wed, 21 Jan 2004 16:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPsV-0005Nn-VY for simple@optimus.ietf.org; Wed, 21 Jan 2004 16:27:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09553; Wed, 21 Jan 2004 16:27:09 -0500 (EST) Message-Id: <200401212127.QAA09553@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 16:27:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Partial Notification of Presence Information Author(s) : M. Lonnfors Filename : draft-ietf-simple-partial-notify-01.txt Pages : 17 Date : 2004-1-21 A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase efficiency, by introducing a mechanism called partial notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-21164315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-21164315.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 22 21:19:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24946 for ; Thu, 22 Jan 2004 21:19:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjqvJ-0004zb-00 for simple-archive@ietf.org; Thu, 22 Jan 2004 21:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajqsl-0004ui-00 for simple-archive@ietf.org; Thu, 22 Jan 2004 21:17:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajqq4-0004pz-00; Thu, 22 Jan 2004 21:14:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqpd-0005fP-Eg; Thu, 22 Jan 2004 21: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 1Ajqox-0005dz-CL for simple@optimus.ietf.org; Thu, 22 Jan 2004 21:13:24 -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 VAA24790 for ; Thu, 22 Jan 2004 21:13:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajqop-0004mC-00 for simple@ietf.org; Thu, 22 Jan 2004 21:13:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjqlC-0004ip-00 for simple@ietf.org; Thu, 22 Jan 2004 21:09:27 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AjqkT-0004fG-00 for simple@ietf.org; Thu, 22 Jan 2004 21:08:41 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jan 2004 18:07:39 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jan 2004 18:07:34 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 22 Jan 2004 18:07:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Subscribing to different PResentities Message-ID: Thread-Topic: [Simple] Subscribing to different PResentities Thread-Index: AcPfwD8Ilz25wrtKR6m+jtbWk4Iv2ABk1M+A From: "Orit Levin" To: "Kamal Gupta" , X-OriginalArrivalTime: 23 Jan 2004 02:07:52.0572 (UTC) FILETIME=[B53E13C0:01C3E155] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 18:07:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I am surprised by the previous answers. Although the whole scenario hasn't been standardized yet, but the required pieces to achieve this functionality are well identified. You can SUBSCRIBE to a URI which points to a list of presentities of your interest and get their statuses within a SINGLE DIALOG as per http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt. You can either preconfigure the list on your presence server or use something along the lines of http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt to build it dynamically using the SUBSCRIBE dialog. Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Kamal Gupta Sent: Tuesday, January 20, 2004 5:45 PM To: simple@ietf.org Subject: [Simple] Subscribing to different PResentities Hi, I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 22 21:20:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24980 for ; Thu, 22 Jan 2004 21:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqvj-0006JV-GP for simple-archive@odin.ietf.org; Thu, 22 Jan 2004 21:20:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N2KJEV024269 for simple-archive@odin.ietf.org; Thu, 22 Jan 2004 21:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqvj-0006JM-Da for simple-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 21:20:19 -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 VAA24971 for ; Thu, 22 Jan 2004 21:20:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajqvb-0004zs-00 for simple-web-archive@ietf.org; Thu, 22 Jan 2004 21:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajqsm-0004up-00 for simple-web-archive@ietf.org; Thu, 22 Jan 2004 21:17:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajqq4-0004pz-00; Thu, 22 Jan 2004 21:14:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqpd-0005fP-Eg; Thu, 22 Jan 2004 21: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 1Ajqox-0005dz-CL for simple@optimus.ietf.org; Thu, 22 Jan 2004 21:13:24 -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 VAA24790 for ; Thu, 22 Jan 2004 21:13:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajqop-0004mC-00 for simple@ietf.org; Thu, 22 Jan 2004 21:13:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjqlC-0004ip-00 for simple@ietf.org; Thu, 22 Jan 2004 21:09:27 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AjqkT-0004fG-00 for simple@ietf.org; Thu, 22 Jan 2004 21:08:41 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jan 2004 18:07:39 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jan 2004 18:07:34 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 22 Jan 2004 18:07:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Subscribing to different PResentities Message-ID: Thread-Topic: [Simple] Subscribing to different PResentities Thread-Index: AcPfwD8Ilz25wrtKR6m+jtbWk4Iv2ABk1M+A From: "Orit Levin" To: "Kamal Gupta" , X-OriginalArrivalTime: 23 Jan 2004 02:07:52.0572 (UTC) FILETIME=[B53E13C0:01C3E155] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 18:07:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I am surprised by the previous answers. Although the whole scenario hasn't been standardized yet, but the required pieces to achieve this functionality are well identified. You can SUBSCRIBE to a URI which points to a list of presentities of your interest and get their statuses within a SINGLE DIALOG as per http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt. You can either preconfigure the list on your presence server or use something along the lines of http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt to build it dynamically using the SUBSCRIBE dialog. Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Kamal Gupta Sent: Tuesday, January 20, 2004 5:45 PM To: simple@ietf.org Subject: [Simple] Subscribing to different PResentities Hi, I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 22 21:48:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25805 for ; Thu, 22 Jan 2004 21:48:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrMm-00069s-00 for simple-archive@ietf.org; Thu, 22 Jan 2004 21:48:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjrM3-00068v-00 for simple-archive@ietf.org; Thu, 22 Jan 2004 21:47:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjrLa-00067k-00; Thu, 22 Jan 2004 21:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrLZ-0007qR-9Q; Thu, 22 Jan 2004 21:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrKr-0007q5-PX for simple@optimus.ietf.org; Thu, 22 Jan 2004 21:46:17 -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 VAA25773 for ; Thu, 22 Jan 2004 21:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrKo-00066q-00 for simple@ietf.org; Thu, 22 Jan 2004 21:46:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjrK2-00066B-00 for simple@ietf.org; Thu, 22 Jan 2004 21:45:27 -0500 Received: from adsl-66-123-193-125.dsl.snfc21.pacbell.net ([66.123.193.125] helo=mail1.sonimtech.com) by ietf-mx with esmtp (Exim 4.12) id 1AjrJB-00064O-00 for simple@ietf.org; Thu, 22 Jan 2004 21:44:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Subscribing to different PResentities Message-ID: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA93@mail1.sonimtech.com> Thread-Topic: [Simple] Subscribing to different PResentities Thread-Index: AcPfwD8Ilz25wrtKR6m+jtbWk4Iv2ABk1M+AAAGpicA= From: "Kamal Gupta" To: "Orit Levin" , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 18:44:57 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Thanks Orit. But my question was not Subscribing to a list where List consists of = number of Presentities and one can Subscribe to all the Presentities in = one shot by subscribing to list. I had the scenario where User needs to Subscribe to a List (consisting = of number or Users/Presentities) and also need to Subscribe to another = List/Group consisting of different set of users/Presentities. In that case I agree to earlier answers and it is required to have = separate dialogs for each subscription. Thanks. KG -----Original Message----- From: Orit Levin [mailto:oritl@microsoft.com] Sent: Thursday, January 22, 2004 6:08 PM To: Kamal Gupta; simple@ietf.org Subject: RE: [Simple] Subscribing to different PResentities I am surprised by the previous answers. Although the whole scenario hasn't been standardized yet, but the required pieces to achieve this functionality are well identified. You can SUBSCRIBE to a URI which points to a list of presentities of your interest and get their statuses within a SINGLE DIALOG as per http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt. You can either preconfigure the list on your presence server or use something along the lines of http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt to build it dynamically using the SUBSCRIBE dialog. Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Kamal Gupta Sent: Tuesday, January 20, 2004 5:45 PM To: simple@ietf.org Subject: [Simple] Subscribing to different PResentities Hi, I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 22 21:48:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25845 for ; Thu, 22 Jan 2004 21:48:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrMq-00080o-7B for simple-archive@odin.ietf.org; Thu, 22 Jan 2004 21:48:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N2mKwL030792 for simple-archive@odin.ietf.org; Thu, 22 Jan 2004 21:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrMp-00080Y-W3 for simple-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 21:48:20 -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 VAA25818 for ; Thu, 22 Jan 2004 21:48:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrMm-00069x-00 for simple-web-archive@ietf.org; Thu, 22 Jan 2004 21:48:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjrM4-000692-00 for simple-web-archive@ietf.org; Thu, 22 Jan 2004 21:47:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjrLa-00067k-00; Thu, 22 Jan 2004 21:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrLZ-0007qR-9Q; Thu, 22 Jan 2004 21:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrKr-0007q5-PX for simple@optimus.ietf.org; Thu, 22 Jan 2004 21:46:17 -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 VAA25773 for ; Thu, 22 Jan 2004 21:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrKo-00066q-00 for simple@ietf.org; Thu, 22 Jan 2004 21:46:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjrK2-00066B-00 for simple@ietf.org; Thu, 22 Jan 2004 21:45:27 -0500 Received: from adsl-66-123-193-125.dsl.snfc21.pacbell.net ([66.123.193.125] helo=mail1.sonimtech.com) by ietf-mx with esmtp (Exim 4.12) id 1AjrJB-00064O-00 for simple@ietf.org; Thu, 22 Jan 2004 21:44:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Subscribing to different PResentities Message-ID: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA93@mail1.sonimtech.com> Thread-Topic: [Simple] Subscribing to different PResentities Thread-Index: AcPfwD8Ilz25wrtKR6m+jtbWk4Iv2ABk1M+AAAGpicA= From: "Kamal Gupta" To: "Orit Levin" , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 18:44:57 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Orit. But my question was not Subscribing to a list where List consists of = number of Presentities and one can Subscribe to all the Presentities in = one shot by subscribing to list. I had the scenario where User needs to Subscribe to a List (consisting = of number or Users/Presentities) and also need to Subscribe to another = List/Group consisting of different set of users/Presentities. In that case I agree to earlier answers and it is required to have = separate dialogs for each subscription. Thanks. KG -----Original Message----- From: Orit Levin [mailto:oritl@microsoft.com] Sent: Thursday, January 22, 2004 6:08 PM To: Kamal Gupta; simple@ietf.org Subject: RE: [Simple] Subscribing to different PResentities I am surprised by the previous answers. Although the whole scenario hasn't been standardized yet, but the required pieces to achieve this functionality are well identified. You can SUBSCRIBE to a URI which points to a list of presentities of your interest and get their statuses within a SINGLE DIALOG as per http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt. You can either preconfigure the list on your presence server or use something along the lines of http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt to build it dynamically using the SUBSCRIBE dialog. Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Kamal Gupta Sent: Tuesday, January 20, 2004 5:45 PM To: simple@ietf.org Subject: [Simple] Subscribing to different PResentities Hi, I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 23 04:39:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21178 for ; Fri, 23 Jan 2004 04:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajxmr-0001i3-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 04:39:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjxkD-00018b-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 04:36:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjxhT-0000Wh-00; Fri, 23 Jan 2004 04:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjxhR-0007th-6x; Fri, 23 Jan 2004 04:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajxh4-0007qh-7l for simple@optimus.ietf.org; Fri, 23 Jan 2004 04:33:38 -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 EAA20563 for ; Fri, 23 Jan 2004 04:33:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajxh1-0000PY-00 for simple@ietf.org; Fri, 23 Jan 2004 04:33:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjxdI-0007dy-00 for simple@ietf.org; Fri, 23 Jan 2004 04:29:45 -0500 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 1AjxV1-00078r-00 for simple@ietf.org; Fri, 23 Jan 2004 04:21:11 -0500 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id i0N9KBQg021069; Fri, 23 Jan 2004 18:20:11 +0900 (JST) Received: from mip2.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HRX00LU2R9NCL@ntt.com>; Fri, 23 Jan 2004 18:20:11 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" Subject: Re: [Simple] Subscribing to different PResentities To: "Kamal Gupta" , "Orit Levin" , simple@ietf.org Message-id: <007701c3e191$815e6320$d444320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA93@mail1.sonimtech.com> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 18:15:55 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit A list can contain multiple lists. Can't it? Ashir ----- Original Message ----- From: "Kamal Gupta" To: "Orit Levin" ; Sent: Friday, January 23, 2004 11:44 AM Subject: RE: [Simple] Subscribing to different PResentities Thanks Orit. But my question was not Subscribing to a list where List consists of number of Presentities and one can Subscribe to all the Presentities in one shot by subscribing to list. I had the scenario where User needs to Subscribe to a List (consisting of number or Users/Presentities) and also need to Subscribe to another List/Group consisting of different set of users/Presentities. In that case I agree to earlier answers and it is required to have separate dialogs for each subscription. Thanks. KG -----Original Message----- From: Orit Levin [mailto:oritl@microsoft.com] Sent: Thursday, January 22, 2004 6:08 PM To: Kamal Gupta; simple@ietf.org Subject: RE: [Simple] Subscribing to different PResentities I am surprised by the previous answers. Although the whole scenario hasn't been standardized yet, but the required pieces to achieve this functionality are well identified. You can SUBSCRIBE to a URI which points to a list of presentities of your interest and get their statuses within a SINGLE DIALOG as per http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt. You can either preconfigure the list on your presence server or use something along the lines of http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt to build it dynamically using the SUBSCRIBE dialog. Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Kamal Gupta Sent: Tuesday, January 20, 2004 5:45 PM To: simple@ietf.org Subject: [Simple] Subscribing to different PResentities Hi, I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 23 04:40:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21291 for ; Fri, 23 Jan 2004 04:40:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajxmx-0000JK-0q for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 04:39:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N9dgZn001193 for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 04:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajxmw-0000JA-D7 for simple-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 04:39:42 -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 EAA21202 for ; Fri, 23 Jan 2004 04:39:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajxmt-0001iS-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 04:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjxkF-000199-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 04:36:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjxhT-0000Wh-00; Fri, 23 Jan 2004 04:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjxhR-0007th-6x; Fri, 23 Jan 2004 04:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajxh4-0007qh-7l for simple@optimus.ietf.org; Fri, 23 Jan 2004 04:33:38 -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 EAA20563 for ; Fri, 23 Jan 2004 04:33:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajxh1-0000PY-00 for simple@ietf.org; Fri, 23 Jan 2004 04:33:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjxdI-0007dy-00 for simple@ietf.org; Fri, 23 Jan 2004 04:29:45 -0500 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 1AjxV1-00078r-00 for simple@ietf.org; Fri, 23 Jan 2004 04:21:11 -0500 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id i0N9KBQg021069; Fri, 23 Jan 2004 18:20:11 +0900 (JST) Received: from mip2.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HRX00LU2R9NCL@ntt.com>; Fri, 23 Jan 2004 18:20:11 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" Subject: Re: [Simple] Subscribing to different PResentities To: "Kamal Gupta" , "Orit Levin" , simple@ietf.org Message-id: <007701c3e191$815e6320$d444320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <6A72F4F5EC7C1541A3FD8CD6FEBE36640BCA93@mail1.sonimtech.com> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 18:15:55 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A list can contain multiple lists. Can't it? Ashir ----- Original Message ----- From: "Kamal Gupta" To: "Orit Levin" ; Sent: Friday, January 23, 2004 11:44 AM Subject: RE: [Simple] Subscribing to different PResentities Thanks Orit. But my question was not Subscribing to a list where List consists of number of Presentities and one can Subscribe to all the Presentities in one shot by subscribing to list. I had the scenario where User needs to Subscribe to a List (consisting of number or Users/Presentities) and also need to Subscribe to another List/Group consisting of different set of users/Presentities. In that case I agree to earlier answers and it is required to have separate dialogs for each subscription. Thanks. KG -----Original Message----- From: Orit Levin [mailto:oritl@microsoft.com] Sent: Thursday, January 22, 2004 6:08 PM To: Kamal Gupta; simple@ietf.org Subject: RE: [Simple] Subscribing to different PResentities I am surprised by the previous answers. Although the whole scenario hasn't been standardized yet, but the required pieces to achieve this functionality are well identified. You can SUBSCRIBE to a URI which points to a list of presentities of your interest and get their statuses within a SINGLE DIALOG as per http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-04.txt. You can either preconfigure the list on your presence server or use something along the lines of http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt to build it dynamically using the SUBSCRIBE dialog. Orit. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Kamal Gupta Sent: Tuesday, January 20, 2004 5:45 PM To: simple@ietf.org Subject: [Simple] Subscribing to different PResentities Hi, I was wondering if it is allowed to Subscribe to 2 different Presentities in the same dialog for the same event. I understand this leads to putting a different "To" url in the request. And as the dialog includes : the from-tag, to-tag, call-id, Is it OK to put a different "To" url in 2 Subscribe messages within a dialog ?? Thanks. KG _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 23 08:56:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00689 for ; Fri, 23 Jan 2004 08:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1nl-0006XH-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 08:56:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1mq-0006Re-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 08:55:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak1m5-0006Oe-00; Fri, 23 Jan 2004 08:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1m2-0005gr-0A; Fri, 23 Jan 2004 08:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1lo-0005gA-Lu for simple@optimus.ietf.org; Fri, 23 Jan 2004 08:54:48 -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 IAA00574 for ; Fri, 23 Jan 2004 08:54:45 -0500 (EST) From: hector.berna@vodafone.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1ln-0006N9-00 for simple@ietf.org; Fri, 23 Jan 2004 08:54:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1kw-0006KM-00 for simple@ietf.org; Fri, 23 Jan 2004 08:53:54 -0500 Received: from [212.166.209.12] (helo=m2-pasarela3.airtel.es) by ietf-mx with esmtp (Exim 4.12) id 1Ak1ka-0006H6-00 for simple@ietf.org; Fri, 23 Jan 2004 08:53:33 -0500 To: simple@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.11 |July 24, 2002) at 01/23/2004 02:53:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RFCs / Drafts for Presence Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 14:52:59 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hello, I would like to know which RFCs or drafts are availables to study the S= Ip Presence. I have found the RFC 2778: A Model for Presence and Instant Messaging a= nd the draft-ietf-simple-presence-10.txt: A Presence Event Package for the Ses= sion Initiation Protocol (SIP). I was in the following weg page that has Presence Drafts, but almost al= l the links are olds: http://www.cs.columbia.edu/sip/drafts_presence.html Is there any more RFCs or Drafts? Thanks in advance, Hector .......................................................................= .......................................................................= .......................................................................= ............. Confidencialidad Este correo electr=F3nico y, en su caso, cualquier fichero anexo al= mismo, contiene informaci=F3n de car=E1cter confidencial exclusivamente dirigida a su destinatario= o destinatarios y propiedad de Vodafone Espa=F1a. Queda prohibida su divulgaci=F3n, copia o dist= ribuci=F3n a terceros sin la previa autorizaci=F3n escrita de Vodafone Espa=F1a, en virtud de la legisla= ci=F3n vigente. En el caso de haber recibido este correo electr=F3nico por error, se ruega notificar in= mediatamente esta circunstancia mediante reenv=EDo a la direcci=F3n electr=F3nica del remitente y la de= strucci=F3n del mismo. Confidentiality The information in this e-mail and in any attachments is classified as= Vodafone Espa=F1a Confidential and Proprietary Information and solely for the attention and use of th= e named addressee(s). You are hereby notified that any dissemination, distribution or copy of thi= s communication is prohibited without the prior written consent of Vodafone Espa=F1a and it is str= ictly prohibited by law. If you have received this communication by error, please, notify the sender by= replying e-mail. = _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 23 08:57:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00725 for ; Fri, 23 Jan 2004 08:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1no-0005o1-Kh for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 08:56:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NDuq8s022311 for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 08:56:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1no-0005nm-Eu for simple-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 08:56:52 -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 IAA00699 for ; Fri, 23 Jan 2004 08:56:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1nm-0006XN-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 08:56:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1mr-0006Rl-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 08:55:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak1m5-0006Oe-00; Fri, 23 Jan 2004 08:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1m2-0005gr-0A; Fri, 23 Jan 2004 08:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1lo-0005gA-Lu for simple@optimus.ietf.org; Fri, 23 Jan 2004 08:54:48 -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 IAA00574 for ; Fri, 23 Jan 2004 08:54:45 -0500 (EST) From: hector.berna@vodafone.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1ln-0006N9-00 for simple@ietf.org; Fri, 23 Jan 2004 08:54:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1kw-0006KM-00 for simple@ietf.org; Fri, 23 Jan 2004 08:53:54 -0500 Received: from [212.166.209.12] (helo=m2-pasarela3.airtel.es) by ietf-mx with esmtp (Exim 4.12) id 1Ak1ka-0006H6-00 for simple@ietf.org; Fri, 23 Jan 2004 08:53:33 -0500 To: simple@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.11 |July 24, 2002) at 01/23/2004 02:53:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RFCs / Drafts for Presence Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 14:52:59 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, I would like to know which RFCs or drafts are availables to study the S= Ip Presence. I have found the RFC 2778: A Model for Presence and Instant Messaging a= nd the draft-ietf-simple-presence-10.txt: A Presence Event Package for the Ses= sion Initiation Protocol (SIP). I was in the following weg page that has Presence Drafts, but almost al= l the links are olds: http://www.cs.columbia.edu/sip/drafts_presence.html Is there any more RFCs or Drafts? Thanks in advance, Hector .......................................................................= .......................................................................= .......................................................................= ............. Confidencialidad Este correo electr=F3nico y, en su caso, cualquier fichero anexo al= mismo, contiene informaci=F3n de car=E1cter confidencial exclusivamente dirigida a su destinatario= o destinatarios y propiedad de Vodafone Espa=F1a. Queda prohibida su divulgaci=F3n, copia o dist= ribuci=F3n a terceros sin la previa autorizaci=F3n escrita de Vodafone Espa=F1a, en virtud de la legisla= ci=F3n vigente. En el caso de haber recibido este correo electr=F3nico por error, se ruega notificar in= mediatamente esta circunstancia mediante reenv=EDo a la direcci=F3n electr=F3nica del remitente y la de= strucci=F3n del mismo. Confidentiality The information in this e-mail and in any attachments is classified as= Vodafone Espa=F1a Confidential and Proprietary Information and solely for the attention and use of th= e named addressee(s). You are hereby notified that any dissemination, distribution or copy of thi= s communication is prohibited without the prior written consent of Vodafone Espa=F1a and it is str= ictly prohibited by law. If you have received this communication by error, please, notify the sender by= replying e-mail. = _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 23 09:51:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02917 for ; Fri, 23 Jan 2004 09:51:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2eq-0001K8-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 09:51:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2dt-0001It-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 09:50:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak2dI-0001I4-00; Fri, 23 Jan 2004 09:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2dH-00017k-1c; Fri, 23 Jan 2004 09:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2cv-000170-Ar for simple@optimus.ietf.org; Fri, 23 Jan 2004 09:49:41 -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 JAA02903 for ; Fri, 23 Jan 2004 09:49:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2ct-0001HO-00 for simple@ietf.org; Fri, 23 Jan 2004 09:49:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2bz-0001Gm-00 for simple@ietf.org; Fri, 23 Jan 2004 09:48:44 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak2bg-0001Fi-00 for simple@ietf.org; Fri, 23 Jan 2004 09:48:24 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0NEls9W007754; Fri, 23 Jan 2004 09:47:56 -0500 (EST) Message-ID: <40113410.9020103@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hector.berna@vodafone.com CC: simple@ietf.org Subject: Re: [Simple] RFCs / Drafts for Presence References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i0NEls9W007754 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 09:47:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable You can find a list at: http://www.ietf.org/html.charters/simple-charter.html -Jonathan R. hector.berna@vodafone.com wrote: > Hello, >=20 > I would like to know which RFCs or drafts are availables to study the S= Ip Presence. >=20 > I have found the RFC 2778: A Model for Presence and Instant Messaging a= nd the > draft-ietf-simple-presence-10.txt: A Presence Event Package for the Ses= sion Initiation Protocol > (SIP). >=20 > I was in the following weg page that has Presence Drafts, but almost al= l the links are olds: > http://www.cs.columbia.edu/sip/drafts_presence.html >=20 > Is there any more RFCs or Drafts? >=20 > Thanks in advance, >=20 > Hector >=20 >=20 > .......................................................................= .........................................................................= .........................................................................= ......... >=20 >=20 > Confidencialidad >=20 >=20 > Este correo electr=F3nico y, en su caso, cualquier fichero anexo al= mismo, contiene informaci=F3n de > car=E1cter confidencial exclusivamente dirigida a su destinatario= o destinatarios y propiedad de > Vodafone Espa=F1a. Queda prohibida su divulgaci=F3n, copia o dist= ribuci=F3n a terceros sin la previa > autorizaci=F3n escrita de Vodafone Espa=F1a, en virtud de la legisla= ci=F3n vigente. En el caso de haber > recibido este correo electr=F3nico por error, se ruega notificar in= mediatamente esta circunstancia > mediante reenv=EDo a la direcci=F3n electr=F3nica del remitente y la de= strucci=F3n del mismo. >=20 >=20 > Confidentiality >=20 >=20 > The information in this e-mail and in any attachments is classified as= Vodafone Espa=F1a Confidential > and Proprietary Information and solely for the attention and use of th= e named addressee(s). You are > hereby notified that any dissemination, distribution or copy of thi= s communication is prohibited > without the prior written consent of Vodafone Espa=F1a and it is str= ictly prohibited by law. If you > have received this communication by error, please, notify the sender by= replying e-mail. >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 23 09:52:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02943 for ; Fri, 23 Jan 2004 09:52:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2et-0001Ef-A2 for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 09:51:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NEphVk004743 for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 09:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2et-0001EQ-6p for simple-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 09:51:43 -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 JAA02932 for ; Fri, 23 Jan 2004 09:51:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2er-0001KD-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 09:51:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2du-0001J0-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 09:50:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak2dI-0001I4-00; Fri, 23 Jan 2004 09:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2dH-00017k-1c; Fri, 23 Jan 2004 09:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2cv-000170-Ar for simple@optimus.ietf.org; Fri, 23 Jan 2004 09:49:41 -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 JAA02903 for ; Fri, 23 Jan 2004 09:49:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2ct-0001HO-00 for simple@ietf.org; Fri, 23 Jan 2004 09:49:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2bz-0001Gm-00 for simple@ietf.org; Fri, 23 Jan 2004 09:48:44 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak2bg-0001Fi-00 for simple@ietf.org; Fri, 23 Jan 2004 09:48:24 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0NEls9W007754; Fri, 23 Jan 2004 09:47:56 -0500 (EST) Message-ID: <40113410.9020103@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hector.berna@vodafone.com CC: simple@ietf.org Subject: Re: [Simple] RFCs / Drafts for Presence References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i0NEls9W007754 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 09:47:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You can find a list at: http://www.ietf.org/html.charters/simple-charter.html -Jonathan R. hector.berna@vodafone.com wrote: > Hello, >=20 > I would like to know which RFCs or drafts are availables to study the S= Ip Presence. >=20 > I have found the RFC 2778: A Model for Presence and Instant Messaging a= nd the > draft-ietf-simple-presence-10.txt: A Presence Event Package for the Ses= sion Initiation Protocol > (SIP). >=20 > I was in the following weg page that has Presence Drafts, but almost al= l the links are olds: > http://www.cs.columbia.edu/sip/drafts_presence.html >=20 > Is there any more RFCs or Drafts? >=20 > Thanks in advance, >=20 > Hector >=20 >=20 > .......................................................................= .........................................................................= .........................................................................= ......... >=20 >=20 > Confidencialidad >=20 >=20 > Este correo electr=F3nico y, en su caso, cualquier fichero anexo al= mismo, contiene informaci=F3n de > car=E1cter confidencial exclusivamente dirigida a su destinatario= o destinatarios y propiedad de > Vodafone Espa=F1a. Queda prohibida su divulgaci=F3n, copia o dist= ribuci=F3n a terceros sin la previa > autorizaci=F3n escrita de Vodafone Espa=F1a, en virtud de la legisla= ci=F3n vigente. En el caso de haber > recibido este correo electr=F3nico por error, se ruega notificar in= mediatamente esta circunstancia > mediante reenv=EDo a la direcci=F3n electr=F3nica del remitente y la de= strucci=F3n del mismo. >=20 >=20 > Confidentiality >=20 >=20 > The information in this e-mail and in any attachments is classified as= Vodafone Espa=F1a Confidential > and Proprietary Information and solely for the attention and use of th= e named addressee(s). You are > hereby notified that any dissemination, distribution or copy of thi= s communication is prohibited > without the prior written consent of Vodafone Espa=F1a and it is str= ictly prohibited by law. If you > have received this communication by error, please, notify the sender by= replying e-mail. >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 23 10:23:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04806 for ; Fri, 23 Jan 2004 10:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3A0-0002fp-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 10:23:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak396-0002cE-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 10:22:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak38L-0002ZO-00; Fri, 23 Jan 2004 10:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak38C-0006zX-Ro; Fri, 23 Jan 2004 10:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak37w-0006xG-PJ for simple@optimus.ietf.org; Fri, 23 Jan 2004 10:21:44 -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 KAA04616 for ; Fri, 23 Jan 2004 10:21:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak37u-0002W6-00 for simple@ietf.org; Fri, 23 Jan 2004 10:21:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak371-0002UM-00 for simple@ietf.org; Fri, 23 Jan 2004 10:20:48 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ak36m-0002Sk-00 for simple@ietf.org; Fri, 23 Jan 2004 10:20:32 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i0NFKV704486 for ; Fri, 23 Jan 2004 16:20:31 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i0NFKUA12417 for ; Fri, 23 Jan 2004 16:20:30 +0100 (MET) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA16129 for ; Fri, 23 Jan 2004 16:20:17 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jan 2004 16:20:28 +0100 Message-ID: <76592C4D3DA1AC4FB8424084D10D31A8D5CEB2@mchh2c4e.mchh.siemens.de> From: Heil Franca Marcelo To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E1C4.6DECE66C" Subject: [Simple] Sender identification in MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 16:20:27 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E1C4.6DECE66C Content-Type: text/plain Hello, Considering a multiparty session-based messaging using a tightly-coupled conferencing model, where a central conference server maintains MSRP sessions (setup via SIP) with each participant and forwards the data received in one MSRP session from a participant to other participants: Is there a way for a participant on the conference to find out who was the original sender of the data it receives in the MSRP session with the conference server? (e. g. as it is posssible via the CNAME/SSRC/CSRC fields in RTCP/RTP for media channels using RTP transport) Is this a topic to be handled in the MSRP draft? Would a new header in the MSRP SEND command be necessary for that? Marcelo ------_=_NextPart_001_01C3E1C4.6DECE66C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Sender identification in MSRP

Hello,

Considering a multiparty session-based = messaging using a tightly-coupled conferencing model, where a central = conference server maintains MSRP sessions (setup via SIP) with each = participant and forwards the data received in one MSRP session from a = participant to other participants:

Is there a way for a participant on = the conference to find out who was the original sender of the data it = receives in the MSRP session with the conference server? (e. g. as it = is posssible via the CNAME/SSRC/CSRC fields in RTCP/RTP for media = channels using RTP transport)

Is this a topic to be handled in the = MSRP draft? Would a new header in the MSRP SEND command be necessary = for that?

Marcelo

------_=_NextPart_001_01C3E1C4.6DECE66C-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 23 10:24:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04860 for ; Fri, 23 Jan 2004 10:24:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3A4-0007Qi-Gb for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 10:23:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFNuJg028559 for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 10:23:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3A4-0007QY-BB for simple-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:23:56 -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 KAA04825 for ; Fri, 23 Jan 2004 10:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3A1-0002g2-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 10:23:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak397-0002cP-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 10:22:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak38L-0002ZO-00; Fri, 23 Jan 2004 10:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak38C-0006zX-Ro; Fri, 23 Jan 2004 10:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak37w-0006xG-PJ for simple@optimus.ietf.org; Fri, 23 Jan 2004 10:21:44 -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 KAA04616 for ; Fri, 23 Jan 2004 10:21:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak37u-0002W6-00 for simple@ietf.org; Fri, 23 Jan 2004 10:21:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak371-0002UM-00 for simple@ietf.org; Fri, 23 Jan 2004 10:20:48 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ak36m-0002Sk-00 for simple@ietf.org; Fri, 23 Jan 2004 10:20:32 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i0NFKV704486 for ; Fri, 23 Jan 2004 16:20:31 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i0NFKUA12417 for ; Fri, 23 Jan 2004 16:20:30 +0100 (MET) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA16129 for ; Fri, 23 Jan 2004 16:20:17 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jan 2004 16:20:28 +0100 Message-ID: <76592C4D3DA1AC4FB8424084D10D31A8D5CEB2@mchh2c4e.mchh.siemens.de> From: Heil Franca Marcelo To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E1C4.6DECE66C" Subject: [Simple] Sender identification in MSRP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 16:20:27 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E1C4.6DECE66C Content-Type: text/plain Hello, Considering a multiparty session-based messaging using a tightly-coupled conferencing model, where a central conference server maintains MSRP sessions (setup via SIP) with each participant and forwards the data received in one MSRP session from a participant to other participants: Is there a way for a participant on the conference to find out who was the original sender of the data it receives in the MSRP session with the conference server? (e. g. as it is posssible via the CNAME/SSRC/CSRC fields in RTCP/RTP for media channels using RTP transport) Is this a topic to be handled in the MSRP draft? Would a new header in the MSRP SEND command be necessary for that? Marcelo ------_=_NextPart_001_01C3E1C4.6DECE66C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Sender identification in MSRP

Hello,

Considering a multiparty session-based = messaging using a tightly-coupled conferencing model, where a central = conference server maintains MSRP sessions (setup via SIP) with each = participant and forwards the data received in one MSRP session from a = participant to other participants:

Is there a way for a participant on = the conference to find out who was the original sender of the data it = receives in the MSRP session with the conference server? (e. g. as it = is posssible via the CNAME/SSRC/CSRC fields in RTCP/RTP for media = channels using RTP transport)

Is this a topic to be handled in the = MSRP draft? Would a new header in the MSRP SEND command be necessary = for that?

Marcelo

------_=_NextPart_001_01C3E1C4.6DECE66C-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 23 10:25:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05087 for ; Fri, 23 Jan 2004 10:25:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Bp-0002om-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 10:25:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3B1-0002le-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 10:24:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak3AB-0002hq-00; Fri, 23 Jan 2004 10:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3AC-0007SE-45; Fri, 23 Jan 2004 10:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak39b-0007N7-9m for simple@optimus.ietf.org; Fri, 23 Jan 2004 10:23:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04759; Fri, 23 Jan 2004 10:23:23 -0500 (EST) Message-Id: <200401231523.KAA04759@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 10:23:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors Filename : draft-ietf-simple-partial-pidf-format-00.txt Pages : 14 Date : 2004-1-22 Presence Information Document Format (PIDF) specifies baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-23104744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-23104744.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 23 10:26:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05152 for ; Fri, 23 Jan 2004 10:26:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Bt-00085J-Hq for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 10:25:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFPnTZ031071 for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 10:25:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Bt-000854-ER for simple-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:25:49 -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 KAA05115 for ; Fri, 23 Jan 2004 10:25:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Br-0002p6-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 10:25:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3B2-0002lq-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 10:24:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak3AB-0002hq-00; Fri, 23 Jan 2004 10:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3AC-0007SE-45; Fri, 23 Jan 2004 10:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak39b-0007N7-9m for simple@optimus.ietf.org; Fri, 23 Jan 2004 10:23:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04759; Fri, 23 Jan 2004 10:23:23 -0500 (EST) Message-Id: <200401231523.KAA04759@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 10:23:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors Filename : draft-ietf-simple-partial-pidf-format-00.txt Pages : 14 Date : 2004-1-22 Presence Information Document Format (PIDF) specifies baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-23104744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-23104744.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 23 10:57:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06798 for ; Fri, 23 Jan 2004 10:57:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3gI-0004Nn-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 10:57:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3eb-00044L-00 for simple-archive@ietf.org; Fri, 23 Jan 2004 10:55:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3dE-0003ow-00; Fri, 23 Jan 2004 10:54:04 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak3Pm-0007Bl-Lh; Fri, 23 Jan 2004 10:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Pe-00024z-4s; Fri, 23 Jan 2004 10:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3PJ-00024D-GS for simple@optimus.ietf.org; Fri, 23 Jan 2004 10:39:41 -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 KAA06035 for ; Fri, 23 Jan 2004 10:39:37 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3PH-0003Ng-00 for simple@ietf.org; Fri, 23 Jan 2004 10:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3OI-0003Mr-00 for simple@ietf.org; Fri, 23 Jan 2004 10:38:39 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3NT-0003LY-00 for simple@ietf.org; Fri, 23 Jan 2004 10:37:48 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0NFbiY24743 for ; Fri, 23 Jan 2004 17:37:44 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 23 Jan 2004 17:37:44 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 17:37:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E1C6.D84B8EB5" Subject: RE: [Simple] Sender identification in MSRP Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9312@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Sender identification in MSRP Thread-Index: AcPhxLr9hTIi0jzbQ/SDrchfSTx02QAAY7jg To: X-OriginalArrivalTime: 23 Jan 2004 15:37:44.0655 (UTC) FILETIME=[D86185F0:01C3E1C6] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 17:37:44 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E1C6.D84B8EB5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Marcelo, =20 The current thinking is that To/From headers in "message/cpim" are used = for conveying this information. The conference focus would insist all = participants use message/cpim as the top level MIME wrapper. = Message/cpim format is mandatory to support in the current MSRP draft. =20 Cheers, Aki -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = ext Heil Franca Marcelo Sent: 23 January, 2004 17:20 To: 'simple@ietf.org' Subject: [Simple] Sender identification in MSRP Hello,=20 Considering a multiparty session-based messaging using a tightly-coupled = conferencing model, where a central conference server maintains MSRP = sessions (setup via SIP) with each participant and forwards the data = received in one MSRP session from a participant to other participants: Is there a way for a participant on the conference to find out who was = the original sender of the data it receives in the MSRP session with the = conference server? (e. g. as it is posssible via the CNAME/SSRC/CSRC = fields in RTCP/RTP for media channels using RTP transport) Is this a topic to be handled in the MSRP draft? Would a new header in = the MSRP SEND command be necessary for that?=20 Marcelo=20 ------_=_NextPart_001_01C3E1C6.D84B8EB5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender identification in MSRP
Hi=20 Marcelo,
 
The=20 current thinking is that To/From headers in "message/cpim" are used for=20 conveying this information. The conference focus would insist all = participants=20 use message/cpim as the top level MIME wrapper. Message/cpim format = is=20 mandatory to support in the current MSRP draft.
 
Cheers,
Aki
-----Original Message-----
From: = simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of ext Heil Franca=20 Marcelo
Sent: 23 January, 2004 17:20
To:=20 'simple@ietf.org'
Subject: [Simple] Sender identification in = MSRP

Hello,

Considering a multiparty session-based = messaging=20 using a tightly-coupled conferencing model, where a central conference = server=20 maintains MSRP sessions (setup via SIP) with each participant and = forwards the=20 data received in one MSRP session from a participant to other=20 participants:

Is there a way for a participant on the = conference=20 to find out who was the original sender of the data it receives in the = MSRP=20 session with the conference server? (e. g. as it is posssible via the=20 CNAME/SSRC/CSRC fields in RTCP/RTP for media channels using RTP=20 transport)

Is this a topic to be handled in the = MSRP draft?=20 Would a new header in the MSRP SEND command be necessary for that? =

Marcelo =

------_=_NextPart_001_01C3E1C6.D84B8EB5-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 23 10:57:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06938 for ; Fri, 23 Jan 2004 10:57:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3gM-0003SS-Ei for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 10:57:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFvI3p013291 for simple-archive@odin.ietf.org; Fri, 23 Jan 2004 10:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3gM-0003SI-BL for simple-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:57:18 -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 KAA06821 for ; Fri, 23 Jan 2004 10:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3gJ-0004Ns-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 10:57:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3ec-00044T-00 for simple-web-archive@ietf.org; Fri, 23 Jan 2004 10:55:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3dE-0003ow-00; Fri, 23 Jan 2004 10:54:04 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak3Pm-0007Bl-Lh; Fri, 23 Jan 2004 10:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Pe-00024z-4s; Fri, 23 Jan 2004 10:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3PJ-00024D-GS for simple@optimus.ietf.org; Fri, 23 Jan 2004 10:39:41 -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 KAA06035 for ; Fri, 23 Jan 2004 10:39:37 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3PH-0003Ng-00 for simple@ietf.org; Fri, 23 Jan 2004 10:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3OI-0003Mr-00 for simple@ietf.org; Fri, 23 Jan 2004 10:38:39 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3NT-0003LY-00 for simple@ietf.org; Fri, 23 Jan 2004 10:37:48 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0NFbiY24743 for ; Fri, 23 Jan 2004 17:37:44 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 23 Jan 2004 17:37:44 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 17:37:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E1C6.D84B8EB5" Subject: RE: [Simple] Sender identification in MSRP Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9312@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Sender identification in MSRP Thread-Index: AcPhxLr9hTIi0jzbQ/SDrchfSTx02QAAY7jg To: X-OriginalArrivalTime: 23 Jan 2004 15:37:44.0655 (UTC) FILETIME=[D86185F0:01C3E1C6] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Jan 2004 17:37:44 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E1C6.D84B8EB5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Marcelo, =20 The current thinking is that To/From headers in "message/cpim" are used = for conveying this information. The conference focus would insist all = participants use message/cpim as the top level MIME wrapper. = Message/cpim format is mandatory to support in the current MSRP draft. =20 Cheers, Aki -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of = ext Heil Franca Marcelo Sent: 23 January, 2004 17:20 To: 'simple@ietf.org' Subject: [Simple] Sender identification in MSRP Hello,=20 Considering a multiparty session-based messaging using a tightly-coupled = conferencing model, where a central conference server maintains MSRP = sessions (setup via SIP) with each participant and forwards the data = received in one MSRP session from a participant to other participants: Is there a way for a participant on the conference to find out who was = the original sender of the data it receives in the MSRP session with the = conference server? (e. g. as it is posssible via the CNAME/SSRC/CSRC = fields in RTCP/RTP for media channels using RTP transport) Is this a topic to be handled in the MSRP draft? Would a new header in = the MSRP SEND command be necessary for that?=20 Marcelo=20 ------_=_NextPart_001_01C3E1C6.D84B8EB5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender identification in MSRP
Hi=20 Marcelo,
 
The=20 current thinking is that To/From headers in "message/cpim" are used for=20 conveying this information. The conference focus would insist all = participants=20 use message/cpim as the top level MIME wrapper. Message/cpim format = is=20 mandatory to support in the current MSRP draft.
 
Cheers,
Aki
-----Original Message-----
From: = simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of ext Heil Franca=20 Marcelo
Sent: 23 January, 2004 17:20
To:=20 'simple@ietf.org'
Subject: [Simple] Sender identification in = MSRP

Hello,

Considering a multiparty session-based = messaging=20 using a tightly-coupled conferencing model, where a central conference = server=20 maintains MSRP sessions (setup via SIP) with each participant and = forwards the=20 data received in one MSRP session from a participant to other=20 participants:

Is there a way for a participant on the = conference=20 to find out who was the original sender of the data it receives in the = MSRP=20 session with the conference server? (e. g. as it is posssible via the=20 CNAME/SSRC/CSRC fields in RTCP/RTP for media channels using RTP=20 transport)

Is this a topic to be handled in the = MSRP draft?=20 Would a new header in the MSRP SEND command be necessary for that? =

Marcelo =

------_=_NextPart_001_01C3E1C6.D84B8EB5-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 27 07:41:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02769 for ; Tue, 27 Jan 2004 07:41:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlSXJ-0006Bv-00 for simple-archive@ietf.org; Tue, 27 Jan 2004 07:41:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlSWS-000684-00 for simple-archive@ietf.org; Tue, 27 Jan 2004 07:40:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlSVj-00064c-00; Tue, 27 Jan 2004 07:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlSVd-0004cU-Ni; Tue, 27 Jan 2004 07:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlSVJ-0004ba-Cv for simple@optimus.ietf.org; Tue, 27 Jan 2004 07:39:41 -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 HAA02699 for ; Tue, 27 Jan 2004 07:39:39 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlSVI-000624-00 for simple@ietf.org; Tue, 27 Jan 2004 07:39:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlSUN-0005zX-00 for simple@ietf.org; Tue, 27 Jan 2004 07:38:44 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AlSTa-0005xR-00 for simple@ietf.org; Tue, 27 Jan 2004 07:37:54 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0RCbqV26531 for ; Tue, 27 Jan 2004 14:37:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 27 Jan 2004 14:37:49 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 27 Jan 2004 14:37:49 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on xcap-list-usage Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797653@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on xcap-list-usage Thread-Index: AcOpxt4tRSAqrTVoR7WMfU48P58s1Q7CxAvA To: Cc: X-OriginalArrivalTime: 27 Jan 2004 12:37:49.0286 (UTC) FILETIME=[5F7DF060:01C3E4D2] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Jan 2004 14:37:48 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I would like to follow up on this issue since I faced the same problem = while updating the XCAP usage for CPCP. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 13.November.2003 11:14 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on xcap-list-usage >=20 > hisham.khartabil@nokia.com wrote: > >=20 > > - If the "uri" attribute is absent in a document, but the > > "subscribeable" flag is set to true. the XCAP server must allocate > > a URI. But what if the URI is present but conflicts with an already > > existing URI? How does the server react? Does it reject the request > > or does it just rewrite the URI? >=20 > Great question. >=20 > I think it should return an error. The reason is that the document=20 > would be in violation of one of the non-schema data constraints. >=20 > The real question is, how does the client know that it should retry=20 > with a different URI? >=20 > I see no obvious answer. There are a few possibilities: >=20 > * disallow clients from setting the URI > * invent a new error resposne code > * add a body to the 409 that describes the condition >=20 I think the easiest and fastest thing to do is disallow the client from = setting the URI. Any other opinions? Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 27 07:42:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02795 for ; Tue, 27 Jan 2004 07:42:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlSXM-0004mk-PG for simple-archive@odin.ietf.org; Tue, 27 Jan 2004 07:41:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RCfmDY018390 for simple-archive@odin.ietf.org; Tue, 27 Jan 2004 07:41:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlSXM-0004mX-Jq for simple-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 07:41:48 -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 HAA02789 for ; Tue, 27 Jan 2004 07:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlSXL-0006CK-00 for simple-web-archive@ietf.org; Tue, 27 Jan 2004 07:41:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlSWT-00068F-00 for simple-web-archive@ietf.org; Tue, 27 Jan 2004 07:40:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlSVj-00064c-00; Tue, 27 Jan 2004 07:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlSVd-0004cU-Ni; Tue, 27 Jan 2004 07:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlSVJ-0004ba-Cv for simple@optimus.ietf.org; Tue, 27 Jan 2004 07:39:41 -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 HAA02699 for ; Tue, 27 Jan 2004 07:39:39 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlSVI-000624-00 for simple@ietf.org; Tue, 27 Jan 2004 07:39:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlSUN-0005zX-00 for simple@ietf.org; Tue, 27 Jan 2004 07:38:44 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AlSTa-0005xR-00 for simple@ietf.org; Tue, 27 Jan 2004 07:37:54 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0RCbqV26531 for ; Tue, 27 Jan 2004 14:37:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 27 Jan 2004 14:37:49 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 27 Jan 2004 14:37:49 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on xcap-list-usage Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797653@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on xcap-list-usage Thread-Index: AcOpxt4tRSAqrTVoR7WMfU48P58s1Q7CxAvA To: Cc: X-OriginalArrivalTime: 27 Jan 2004 12:37:49.0286 (UTC) FILETIME=[5F7DF060:01C3E4D2] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Jan 2004 14:37:48 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I would like to follow up on this issue since I faced the same problem = while updating the XCAP usage for CPCP. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 13.November.2003 11:14 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on xcap-list-usage >=20 > hisham.khartabil@nokia.com wrote: > >=20 > > - If the "uri" attribute is absent in a document, but the > > "subscribeable" flag is set to true. the XCAP server must allocate > > a URI. But what if the URI is present but conflicts with an already > > existing URI? How does the server react? Does it reject the request > > or does it just rewrite the URI? >=20 > Great question. >=20 > I think it should return an error. The reason is that the document=20 > would be in violation of one of the non-schema data constraints. >=20 > The real question is, how does the client know that it should retry=20 > with a different URI? >=20 > I see no obvious answer. There are a few possibilities: >=20 > * disallow clients from setting the URI > * invent a new error resposne code > * add a body to the 409 that describes the condition >=20 I think the easiest and fastest thing to do is disallow the client from = setting the URI. Any other opinions? Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Jan 27 22:13:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13457 for ; Tue, 27 Jan 2004 22:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alg8a-0007Fc-00 for simple-archive@ietf.org; Tue, 27 Jan 2004 22:13:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alg7b-0007Ar-00 for simple-archive@ietf.org; Tue, 27 Jan 2004 22:12:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alg6i-00076N-00; Tue, 27 Jan 2004 22:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alg6Y-0007o8-N0; Tue, 27 Jan 2004 22:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alg5p-0007nR-SY for simple@optimus.ietf.org; Tue, 27 Jan 2004 22:10:17 -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 WAA13364 for ; Tue, 27 Jan 2004 22:10:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alg5m-00071l-00 for simple@ietf.org; Tue, 27 Jan 2004 22:10:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alg4q-0006xx-00 for simple@ietf.org; Tue, 27 Jan 2004 22:09:17 -0500 Received: from c-67-164-133-175.client.comcast.net ([67.164.133.175] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 1Alg4d-0006uB-00 for simple@ietf.org; Tue, 27 Jan 2004 22:09:03 -0500 Received: from dynamicsoft.com (verite [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i0RIJtNs012285 for ; Tue, 27 Jan 2004 12:21:15 -0600 Message-ID: <4016ABCB.1080502@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Updated Draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Jan 2004 12:19:55 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I just submitted an updated MSRP draft. Until it shows up in the repository, you can find it at: http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-03.txt ...or... http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-03.html The big changes to this version include the removal of the relay specification, and all MSRP features that were specific to relays. It also includes new verbiage on SDP exchanges that affect an existing stream. I added a "count" parameter to the direction attribute, as was discussed in the recent thread on how an endpoint signals the desire to reconnect. There are still 3 to do items that I am aware of: 1) We need to get closure on whether and how we supress duplicate messages when a connection fails, the endpoints signal a reconnect, and the stream is resumed on the new connection. 2) I still need to do the work on allowing all standard MIME header fields. I don't think this is controversial; I just don't have it done yet and wanted to get a checkpoint draft out asap. 3) Fluffy's text on certificate handling for the security considerations section. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Jan 27 22:13:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13487 for ; Tue, 27 Jan 2004 22:13:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alg8e-00087a-Q4 for simple-archive@odin.ietf.org; Tue, 27 Jan 2004 22:13:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S3DCoB031214 for simple-archive@odin.ietf.org; Tue, 27 Jan 2004 22:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alg8e-00087N-KE for simple-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 22:13:12 -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 WAA13474 for ; Tue, 27 Jan 2004 22:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alg8b-0007Fh-00 for simple-web-archive@ietf.org; Tue, 27 Jan 2004 22:13:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alg7c-0007Ay-00 for simple-web-archive@ietf.org; Tue, 27 Jan 2004 22:12:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alg6i-00076N-00; Tue, 27 Jan 2004 22:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alg6Y-0007o8-N0; Tue, 27 Jan 2004 22:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alg5p-0007nR-SY for simple@optimus.ietf.org; Tue, 27 Jan 2004 22:10:17 -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 WAA13364 for ; Tue, 27 Jan 2004 22:10:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alg5m-00071l-00 for simple@ietf.org; Tue, 27 Jan 2004 22:10:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alg4q-0006xx-00 for simple@ietf.org; Tue, 27 Jan 2004 22:09:17 -0500 Received: from c-67-164-133-175.client.comcast.net ([67.164.133.175] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 1Alg4d-0006uB-00 for simple@ietf.org; Tue, 27 Jan 2004 22:09:03 -0500 Received: from dynamicsoft.com (verite [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i0RIJtNs012285 for ; Tue, 27 Jan 2004 12:21:15 -0600 Message-ID: <4016ABCB.1080502@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Updated Draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Jan 2004 12:19:55 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I just submitted an updated MSRP draft. Until it shows up in the repository, you can find it at: http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-03.txt ...or... http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-03.html The big changes to this version include the removal of the relay specification, and all MSRP features that were specific to relays. It also includes new verbiage on SDP exchanges that affect an existing stream. I added a "count" parameter to the direction attribute, as was discussed in the recent thread on how an endpoint signals the desire to reconnect. There are still 3 to do items that I am aware of: 1) We need to get closure on whether and how we supress duplicate messages when a connection fails, the endpoints signal a reconnect, and the stream is resumed on the new connection. 2) I still need to do the work on allowing all standard MIME header fields. I don't think this is controversial; I just don't have it done yet and wanted to get a checkpoint draft out asap. 3) Fluffy's text on certificate handling for the security considerations section. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 28 07:48:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28623 for ; Wed, 28 Jan 2004 07:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alp7k-0005Gg-00 for simple-archive@ietf.org; Wed, 28 Jan 2004 07:48:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alp6o-00056t-00 for simple-archive@ietf.org; Wed, 28 Jan 2004 07:47:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Alp5l-0004yM-03; Wed, 28 Jan 2004 07:46:50 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Alof7-000415-W9; Wed, 28 Jan 2004 07:19:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aloer-0001Up-QP; Wed, 28 Jan 2004 07:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloeJ-0001RR-UD for simple@optimus.ietf.org; Wed, 28 Jan 2004 07:18:27 -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 HAA27981 for ; Wed, 28 Jan 2004 07:18:26 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AloeJ-00032J-00 for simple@ietf.org; Wed, 28 Jan 2004 07:18:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlodO-0002td-00 for simple@ietf.org; Wed, 28 Jan 2004 07:17:31 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aloca-0002pS-00 for simple@ietf.org; Wed, 28 Jan 2004 07:16:40 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SCGcY28065 for ; Wed, 28 Jan 2004 14:16:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 28 Jan 2004 13:59:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 13:59:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E596.2A531080" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17291@esebe004.ntc.nokia.com> Thread-Topic: New version of partial notifications draft Thread-Index: AcPlliqeWcGpxsR6Qo6F+K35rd6E4Q== To: X-OriginalArrivalTime: 28 Jan 2004 11:59:23.0083 (UTC) FILETIME=[2B4D09B0:01C3E596] Subject: [Simple] New version of partial notifications draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 13:59:21 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E596.2A531080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In case you haven't noticed partial notifications draft has now been split into two. Format is now described in: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-forma t-00.txt And the mechanism in: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-01. txt No other major changes have been done. - Mikko ------_=_NextPart_001_01C3E596.2A531080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of partial notifications draft

Hi,

In case you haven't noticed partial = notifications draft has now been split into two.
Format is now described in:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-f= ormat-00.txt

And the mechanism in:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify= -01.txt

No other major changes have been = done.

- Mikko

------_=_NextPart_001_01C3E596.2A531080-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jan 28 07:49:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28718 for ; Wed, 28 Jan 2004 07:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alp7m-00032i-2d for simple-archive@odin.ietf.org; Wed, 28 Jan 2004 07:48:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SCmsO3011692 for simple-archive@odin.ietf.org; Wed, 28 Jan 2004 07:48:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alp7l-00032V-Vu for simple-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 07:48:54 -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 HAA28643 for ; Wed, 28 Jan 2004 07:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alp7l-0005Gl-00 for simple-web-archive@ietf.org; Wed, 28 Jan 2004 07:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alp6p-000570-00 for simple-web-archive@ietf.org; Wed, 28 Jan 2004 07:47:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Alp5l-0004yM-03; Wed, 28 Jan 2004 07:46:50 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Alof7-000415-W9; Wed, 28 Jan 2004 07:19:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aloer-0001Up-QP; Wed, 28 Jan 2004 07:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloeJ-0001RR-UD for simple@optimus.ietf.org; Wed, 28 Jan 2004 07:18:27 -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 HAA27981 for ; Wed, 28 Jan 2004 07:18:26 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AloeJ-00032J-00 for simple@ietf.org; Wed, 28 Jan 2004 07:18:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlodO-0002td-00 for simple@ietf.org; Wed, 28 Jan 2004 07:17:31 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aloca-0002pS-00 for simple@ietf.org; Wed, 28 Jan 2004 07:16:40 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SCGcY28065 for ; Wed, 28 Jan 2004 14:16:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 28 Jan 2004 13:59:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 13:59:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E596.2A531080" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17291@esebe004.ntc.nokia.com> Thread-Topic: New version of partial notifications draft Thread-Index: AcPlliqeWcGpxsR6Qo6F+K35rd6E4Q== To: X-OriginalArrivalTime: 28 Jan 2004 11:59:23.0083 (UTC) FILETIME=[2B4D09B0:01C3E596] Subject: [Simple] New version of partial notifications draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 13:59:21 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E596.2A531080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In case you haven't noticed partial notifications draft has now been split into two. Format is now described in: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-forma t-00.txt And the mechanism in: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-01. txt No other major changes have been done. - Mikko ------_=_NextPart_001_01C3E596.2A531080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of partial notifications draft

Hi,

In case you haven't noticed partial = notifications draft has now been split into two.
Format is now described in:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-f= ormat-00.txt

And the mechanism in:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify= -01.txt

No other major changes have been = done.

- Mikko

------_=_NextPart_001_01C3E596.2A531080-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Jan 28 17:34:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04279 for ; Wed, 28 Jan 2004 17:34:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlyGn-0006Bm-00 for simple-archive@ietf.org; Wed, 28 Jan 2004 17:34:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlyFw-00064k-00 for simple-archive@ietf.org; Wed, 28 Jan 2004 17:33:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlyF7-0005ux-00; Wed, 28 Jan 2004 17:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyF3-0007mi-25; Wed, 28 Jan 2004 17:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyEp-0007mM-8Z for simple@optimus.ietf.org; Wed, 28 Jan 2004 17:32:47 -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 RAA03929 for ; Wed, 28 Jan 2004 17:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlyEm-0005o1-00 for simple@ietf.org; Wed, 28 Jan 2004 17:32:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlyDR-0005Xy-00 for simple@ietf.org; Wed, 28 Jan 2004 17:31:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AlyC9-00059q-00 for simple@ietf.org; Wed, 28 Jan 2004 17:30:01 -0500 Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0SMTX9W011342; Wed, 28 Jan 2004 17:29:36 -0500 (EST) Message-ID: <401837C1.6060003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-list-usage References: <2038BCC78B1AD641891A0D1AE133DBB701797653@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797653@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 17:29:21 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Certainly that tactic is simpler. However, it makes it hard to have "vanity URIs" for specific lists, for example - jonathans-friends@example.com. Do we think that this function is needed? -Jonathan R. hisham.khartabil@nokia.com wrote: > I would like to follow up on this issue since I faced the same problem while updating the XCAP usage for CPCP. > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Jonathan Rosenberg >>Sent: 13.November.2003 11:14 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on xcap-list-usage >> >>hisham.khartabil@nokia.com wrote: >> >>>- If the "uri" attribute is absent in a document, but the >>>"subscribeable" flag is set to true. the XCAP server must allocate >>>a URI. But what if the URI is present but conflicts with an already >>>existing URI? How does the server react? Does it reject the request >>>or does it just rewrite the URI? >> >>Great question. >> >>I think it should return an error. The reason is that the document >>would be in violation of one of the non-schema data constraints. >> >>The real question is, how does the client know that it should retry >>with a different URI? >> >>I see no obvious answer. There are a few possibilities: >> >> * disallow clients from setting the URI >> * invent a new error resposne code >> * add a body to the 409 that describes the condition >> > > > I think the easiest and fastest thing to do is disallow the client from setting the URI. Any other opinions? > > Regards, > Hisham > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Jan 28 17:35:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04316 for ; Wed, 28 Jan 2004 17:35:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyGr-0008IB-7z for simple-archive@odin.ietf.org; Wed, 28 Jan 2004 17:34:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SMYrHM031875 for simple-archive@odin.ietf.org; Wed, 28 Jan 2004 17:34:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyGr-0008I2-59 for simple-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 17:34:53 -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 RAA04294 for ; Wed, 28 Jan 2004 17:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlyGo-0006Bt-00 for simple-web-archive@ietf.org; Wed, 28 Jan 2004 17:34:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlyFx-00064r-00 for simple-web-archive@ietf.org; Wed, 28 Jan 2004 17:33:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlyF7-0005ux-00; Wed, 28 Jan 2004 17:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyF3-0007mi-25; Wed, 28 Jan 2004 17:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyEp-0007mM-8Z for simple@optimus.ietf.org; Wed, 28 Jan 2004 17:32:47 -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 RAA03929 for ; Wed, 28 Jan 2004 17:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlyEm-0005o1-00 for simple@ietf.org; Wed, 28 Jan 2004 17:32:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlyDR-0005Xy-00 for simple@ietf.org; Wed, 28 Jan 2004 17:31:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AlyC9-00059q-00 for simple@ietf.org; Wed, 28 Jan 2004 17:30:01 -0500 Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0SMTX9W011342; Wed, 28 Jan 2004 17:29:36 -0500 (EST) Message-ID: <401837C1.6060003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-list-usage References: <2038BCC78B1AD641891A0D1AE133DBB701797653@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797653@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 17:29:21 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Certainly that tactic is simpler. However, it makes it hard to have "vanity URIs" for specific lists, for example - jonathans-friends@example.com. Do we think that this function is needed? -Jonathan R. hisham.khartabil@nokia.com wrote: > I would like to follow up on this issue since I faced the same problem while updating the XCAP usage for CPCP. > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Jonathan Rosenberg >>Sent: 13.November.2003 11:14 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on xcap-list-usage >> >>hisham.khartabil@nokia.com wrote: >> >>>- If the "uri" attribute is absent in a document, but the >>>"subscribeable" flag is set to true. the XCAP server must allocate >>>a URI. But what if the URI is present but conflicts with an already >>>existing URI? How does the server react? Does it reject the request >>>or does it just rewrite the URI? >> >>Great question. >> >>I think it should return an error. The reason is that the document >>would be in violation of one of the non-schema data constraints. >> >>The real question is, how does the client know that it should retry >>with a different URI? >> >>I see no obvious answer. There are a few possibilities: >> >> * disallow clients from setting the URI >> * invent a new error resposne code >> * add a body to the 409 that describes the condition >> > > > I think the easiest and fastest thing to do is disallow the client from setting the URI. Any other opinions? > > Regards, > Hisham > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 29 04:01:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08821 for ; Thu, 29 Jan 2004 04:01:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am82s-00077m-00 for simple-archive@ietf.org; Thu, 29 Jan 2004 04:01:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am81x-00070v-00 for simple-archive@ietf.org; Thu, 29 Jan 2004 04:00:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Am80y-0006s0-00; Thu, 29 Jan 2004 03:59:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am80s-0002jp-6i; Thu, 29 Jan 2004 03:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am801-0002ht-I8 for simple@optimus.ietf.org; Thu, 29 Jan 2004 03:58:11 -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 DAA08599 for ; Thu, 29 Jan 2004 03:58:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am7zz-0006jM-00 for simple@ietf.org; Thu, 29 Jan 2004 03:58:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am7z6-0006ch-00 for simple@ietf.org; Thu, 29 Jan 2004 03:57:13 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Am7yS-0006X9-00 for simple@ietf.org; Thu, 29 Jan 2004 03:56:32 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0T8uV229852 for ; Thu, 29 Jan 2004 10:56:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 10:52:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 10:52:04 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on xcap-list-usage Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797679@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on xcap-list-usage Thread-Index: AcPl7lBKdklGP4sJSqyV787rVDhxLgAVqLrw To: Cc: X-OriginalArrivalTime: 29 Jan 2004 08:52:04.0982 (UTC) FILETIME=[2B48A960:01C3E645] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 10:52:07 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Well, you can always have a display name that the user can set. If the = list usage, you have the name attribute. In CPCP usage, we defined the Display-name element. I think that should = do it. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 29.January.2004 00:29 > To: Khartabil Hisham (Nokia-TP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on xcap-list-usage >=20 >=20 > Certainly that tactic is simpler. However, it makes it hard to have=20 > "vanity URIs" for specific lists, for example -=20 > jonathans-friends@example.com. Do we think that this function=20 > is needed? >=20 > -Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I would like to follow up on this issue since I faced the=20 > same problem while updating the XCAP usage for CPCP. > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Jonathan Rosenberg > >>Sent: 13.November.2003 11:14 > >>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>Cc: simple@ietf.org > >>Subject: Re: [Simple] Comments on xcap-list-usage > >> > >>hisham.khartabil@nokia.com wrote: > >> > >>>- If the "uri" attribute is absent in a document, but the > >>>"subscribeable" flag is set to true. the XCAP server must allocate > >>>a URI. But what if the URI is present but conflicts with an already > >>>existing URI? How does the server react? Does it reject the request > >>>or does it just rewrite the URI? > >> > >>Great question. > >> > >>I think it should return an error. The reason is that the document=20 > >>would be in violation of one of the non-schema data constraints. > >> > >>The real question is, how does the client know that it should retry=20 > >>with a different URI? > >> > >>I see no obvious answer. There are a few possibilities: > >> > >> * disallow clients from setting the URI > >> * invent a new error resposne code > >> * add a body to the 409 that describes the condition > >> > >=20 > >=20 > > I think the easiest and fastest thing to do is disallow the=20 > client from setting the URI. Any other opinions? > >=20 > > Regards, > > Hisham > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 29 04:01:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08855 for ; Thu, 29 Jan 2004 04:01:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am82w-0002ui-5J for simple-archive@odin.ietf.org; Thu, 29 Jan 2004 04:01:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T91AL5011199 for simple-archive@odin.ietf.org; Thu, 29 Jan 2004 04:01:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am82v-0002uY-U5 for simple-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 04:01:09 -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 EAA08839 for ; Thu, 29 Jan 2004 04:01:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am82t-00077r-00 for simple-web-archive@ietf.org; Thu, 29 Jan 2004 04:01:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am81y-000712-00 for simple-web-archive@ietf.org; Thu, 29 Jan 2004 04:00:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Am80y-0006s0-00; Thu, 29 Jan 2004 03:59:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am80s-0002jp-6i; Thu, 29 Jan 2004 03:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am801-0002ht-I8 for simple@optimus.ietf.org; Thu, 29 Jan 2004 03:58:11 -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 DAA08599 for ; Thu, 29 Jan 2004 03:58:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am7zz-0006jM-00 for simple@ietf.org; Thu, 29 Jan 2004 03:58:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am7z6-0006ch-00 for simple@ietf.org; Thu, 29 Jan 2004 03:57:13 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Am7yS-0006X9-00 for simple@ietf.org; Thu, 29 Jan 2004 03:56:32 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0T8uV229852 for ; Thu, 29 Jan 2004 10:56:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Jan 2004 10:52:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 10:52:04 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on xcap-list-usage Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797679@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on xcap-list-usage Thread-Index: AcPl7lBKdklGP4sJSqyV787rVDhxLgAVqLrw To: Cc: X-OriginalArrivalTime: 29 Jan 2004 08:52:04.0982 (UTC) FILETIME=[2B48A960:01C3E645] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 10:52:07 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Well, you can always have a display name that the user can set. If the = list usage, you have the name attribute. In CPCP usage, we defined the Display-name element. I think that should = do it. /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 29.January.2004 00:29 > To: Khartabil Hisham (Nokia-TP/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on xcap-list-usage >=20 >=20 > Certainly that tactic is simpler. However, it makes it hard to have=20 > "vanity URIs" for specific lists, for example -=20 > jonathans-friends@example.com. Do we think that this function=20 > is needed? >=20 > -Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I would like to follow up on this issue since I faced the=20 > same problem while updating the XCAP usage for CPCP. > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Jonathan Rosenberg > >>Sent: 13.November.2003 11:14 > >>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>Cc: simple@ietf.org > >>Subject: Re: [Simple] Comments on xcap-list-usage > >> > >>hisham.khartabil@nokia.com wrote: > >> > >>>- If the "uri" attribute is absent in a document, but the > >>>"subscribeable" flag is set to true. the XCAP server must allocate > >>>a URI. But what if the URI is present but conflicts with an already > >>>existing URI? How does the server react? Does it reject the request > >>>or does it just rewrite the URI? > >> > >>Great question. > >> > >>I think it should return an error. The reason is that the document=20 > >>would be in violation of one of the non-schema data constraints. > >> > >>The real question is, how does the client know that it should retry=20 > >>with a different URI? > >> > >>I see no obvious answer. There are a few possibilities: > >> > >> * disallow clients from setting the URI > >> * invent a new error resposne code > >> * add a body to the 409 that describes the condition > >> > >=20 > >=20 > > I think the easiest and fastest thing to do is disallow the=20 > client from setting the URI. Any other opinions? > >=20 > > Regards, > > Hisham > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 29 10:24:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24042 for ; Thu, 29 Jan 2004 10:24:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmE1v-0002VO-00 for simple-archive@ietf.org; Thu, 29 Jan 2004 10:24:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmE18-0002Ob-00 for simple-archive@ietf.org; Thu, 29 Jan 2004 10:23:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmE0b-0002HB-00; Thu, 29 Jan 2004 10:23:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE0T-0006bi-It; Thu, 29 Jan 2004 10:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDzm-0006W1-Jm for simple@optimus.ietf.org; Thu, 29 Jan 2004 10:22:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23808; Thu, 29 Jan 2004 10:22:14 -0500 (EST) Message-Id: <200401291522.KAA23808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-filter-reqs-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 10:22:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Filtering of Watcher Information Author(s) : K. Kiss Filename : draft-ietf-simple-winfo-filter-reqs-01.txt Pages : 10 Date : 2004-1-28 This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcher infomation notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-winfo-filter-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-29104427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-filter-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104427.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Jan 29 10:24:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24067 for ; Thu, 29 Jan 2004 10:24:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmE1x-0002Va-00 for simple-archive@ietf.org; Thu, 29 Jan 2004 10:24:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmE1A-0002Ot-00 for simple-archive@ietf.org; Thu, 29 Jan 2004 10:23:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmE0b-0002HC-00; Thu, 29 Jan 2004 10:23:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE0U-0006bw-9T; Thu, 29 Jan 2004 10:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE05-0006ao-Im for simple@optimus.ietf.org; Thu, 29 Jan 2004 10:22:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23869; Thu, 29 Jan 2004 10:22:33 -0500 (EST) Message-Id: <200401291522.KAA23869@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-pres-filter-reqs-03.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 10:22:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Presence Specific Event Notification Filtering Author(s) : H. Khartabil, E. Leppanen, T. Moran Filename : draft-ietf-simple-pres-filter-reqs-03.txt Pages : 13 Date : 2004-1-28 This document defines a set of structured requirements whereby a presence information subscriber may select specific information to be received in the presence infomation notification sent by the notifier. The purpose is to limit the content and frequency of notifications so that only essential information on a need basis is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-pres-filter-reqs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-29104438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104438.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 29 10:25:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24089 for ; Thu, 29 Jan 2004 10:25:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE1z-0006s6-BV for simple-archive@odin.ietf.org; Thu, 29 Jan 2004 10:24:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFOZX8026408 for simple-archive@odin.ietf.org; Thu, 29 Jan 2004 10:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE1z-0006rr-59 for simple-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:24:35 -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 KAA24061 for ; Thu, 29 Jan 2004 10:24:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmE1w-0002VU-00 for simple-web-archive@ietf.org; Thu, 29 Jan 2004 10:24:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmE19-0002Oj-00 for simple-web-archive@ietf.org; Thu, 29 Jan 2004 10:23:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmE0b-0002HB-00; Thu, 29 Jan 2004 10:23:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE0T-0006bi-It; Thu, 29 Jan 2004 10:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDzm-0006W1-Jm for simple@optimus.ietf.org; Thu, 29 Jan 2004 10:22:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23808; Thu, 29 Jan 2004 10:22:14 -0500 (EST) Message-Id: <200401291522.KAA23808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-filter-reqs-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 10:22:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Filtering of Watcher Information Author(s) : K. Kiss Filename : draft-ietf-simple-winfo-filter-reqs-01.txt Pages : 10 Date : 2004-1-28 This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcher infomation notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-winfo-filter-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-29104427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-filter-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104427.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Jan 29 10:25:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24106 for ; Thu, 29 Jan 2004 10:25:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE20-0006sO-Nm for simple-archive@odin.ietf.org; Thu, 29 Jan 2004 10:24:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFOaiK026426 for simple-archive@odin.ietf.org; Thu, 29 Jan 2004 10:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE20-0006s9-Jp for simple-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 10:24:36 -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 KAA24080 for ; Thu, 29 Jan 2004 10:24:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmE1y-0002Vf-00 for simple-web-archive@ietf.org; Thu, 29 Jan 2004 10:24:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmE1A-0002P0-00 for simple-web-archive@ietf.org; Thu, 29 Jan 2004 10:23:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmE0b-0002HC-00; Thu, 29 Jan 2004 10:23:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE0U-0006bw-9T; Thu, 29 Jan 2004 10:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmE05-0006ao-Im for simple@optimus.ietf.org; Thu, 29 Jan 2004 10:22:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23869; Thu, 29 Jan 2004 10:22:33 -0500 (EST) Message-Id: <200401291522.KAA23869@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-pres-filter-reqs-03.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 10:22:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Presence Specific Event Notification Filtering Author(s) : H. Khartabil, E. Leppanen, T. Moran Filename : draft-ietf-simple-pres-filter-reqs-03.txt Pages : 13 Date : 2004-1-28 This document defines a set of structured requirements whereby a presence information subscriber may select specific information to be received in the presence infomation notification sent by the notifier. The purpose is to limit the content and frequency of notifications so that only essential information on a need basis is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-pres-filter-reqs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-29104438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-filter-reqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-filter-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104438.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 30 11:54:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27433 for ; Fri, 30 Jan 2004 11:54:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbuS-0006h5-00 for simple-archive@ietf.org; Fri, 30 Jan 2004 11:54:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbtR-0006Vs-00 for simple-archive@ietf.org; Fri, 30 Jan 2004 11:53:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmbsX-0006LU-00; Fri, 30 Jan 2004 11:52:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbsB-0000xW-So; Fri, 30 Jan 2004 11:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ambrk-0000m8-QQ for simple@optimus.ietf.org; Fri, 30 Jan 2004 11:51:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27076; Fri, 30 Jan 2004 11:51:33 -0500 (EST) Message-Id: <200401301651.LAA27076@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-03.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Jan 2004 11:51:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Instant Message Sessions in SIMPLE Author(s) : B. Campbell Filename : draft-ietf-simple-message-sessions-03.txt Pages : 39 Date : 2004-1-29 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-30121205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121205.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 30 11:54:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27535 for ; Fri, 30 Jan 2004 11:54:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbuV-0001Ve-BP for simple-archive@odin.ietf.org; Fri, 30 Jan 2004 11:54:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGsRaP005798 for simple-archive@odin.ietf.org; Fri, 30 Jan 2004 11:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbuV-0001VR-7W for simple-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 11:54:27 -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 LAA27453 for ; Fri, 30 Jan 2004 11:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbuT-0006hI-00 for simple-web-archive@ietf.org; Fri, 30 Jan 2004 11:54:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbtS-0006W2-00 for simple-web-archive@ietf.org; Fri, 30 Jan 2004 11:53:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmbsX-0006LU-00; Fri, 30 Jan 2004 11:52:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbsB-0000xW-So; Fri, 30 Jan 2004 11:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ambrk-0000m8-QQ for simple@optimus.ietf.org; Fri, 30 Jan 2004 11:51:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27076; Fri, 30 Jan 2004 11:51:33 -0500 (EST) Message-Id: <200401301651.LAA27076@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-03.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Jan 2004 11:51:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Instant Message Sessions in SIMPLE Author(s) : B. Campbell Filename : draft-ietf-simple-message-sessions-03.txt Pages : 39 Date : 2004-1-29 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-30121205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121205.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Jan 30 17:27:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11192 for ; Fri, 30 Jan 2004 17:27:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amh6x-0003Gr-00 for simple-archive@ietf.org; Fri, 30 Jan 2004 17:27:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amh5z-000394-00 for simple-archive@ietf.org; Fri, 30 Jan 2004 17:26:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amh5R-00031H-00; Fri, 30 Jan 2004 17:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amh5P-0007kx-3r; Fri, 30 Jan 2004 17:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am9LH-0001Gf-IQ for simple@optimus.ietf.org; Thu, 29 Jan 2004 05:24:11 -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 FAA11694 for ; Thu, 29 Jan 2004 05:24:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am9LE-0000S0-00 for simple@ietf.org; Thu, 29 Jan 2004 05:24:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am9KF-0000Lx-00 for simple@ietf.org; Thu, 29 Jan 2004 05:23:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Am9JI-0000FD-00 for simple@ietf.org; Thu, 29 Jan 2004 05:22:09 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0TAM9205423 for ; Thu, 29 Jan 2004 12:22:09 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 29 Jan 2004 12:22:09 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 12:22:08 +0200 Received: from nokia.com (xitami.research.nokia.com [172.21.40.110]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA15848 for ; Thu, 29 Jan 2004 12:22:18 +0200 (EET) X-Authentication-Warning: mgw.research.nokia.com: Host xitami.research.nokia.com [172.21.40.110] claimed to be nokia.com Message-ID: <4018DECF.7040108@nokia.com> From: Jari Urpalainen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2004 10:22:08.0702 (UTC) FILETIME=[C026E5E0:01C3E651] Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP questions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 12:22:07 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi ! I have been developing a reference implementation for XCAP server (standalone and an Apache module). There are some open/unclear issues (to me at least), so here's the list of questions. 1. XCAP directory list In XCAP presence auth draft chapter 4.4, there's a requirement to get all documents from the server. However, in the base XCAP draft it is unspecified how the server should send this directory list. While http-servers can/will provide this information in many ways, IMO the base XCAP draft should specify this format (xml?). Furhermore, it would be nice if ETags were included in the response in order to help to synchonize documents between the client and the server. 2. XCAP ETags In order to ease the synchronizing within resources between client and server the base XCAP draft could specify the secure hash method e.g. SHA-1 or whatever that is used to calculate the ETag. This is already proposed in xcap-package but IMHO could be in the base spec. 3. XCAP attributes When updating/querying attributes is it necessary to include attribute name in payload as attribute name is already provided in XPATH-query ? e.g. you could get /resource-lists/list[@name="friends"]/@uri so you already know that you receive response for attribute uri. IMHO when putting/getting attributes, payload could include only attribute value. 4. XCAP namespace declarations As namespace handling resemble "standard" XML attributes is it also allowed to change namespace declarations with similar semantics ? BR, Jari Urpalainen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Jan 30 17:28:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11862 for ; Fri, 30 Jan 2004 17:28:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amh70-0007r6-HM for simple-archive@odin.ietf.org; Fri, 30 Jan 2004 17:27:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UMRgPE030196 for simple-archive@odin.ietf.org; Fri, 30 Jan 2004 17:27:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amh70-0007qx-CF for simple-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 17:27:42 -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 RAA11205 for ; Fri, 30 Jan 2004 17:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amh6x-0003Gw-00 for simple-web-archive@ietf.org; Fri, 30 Jan 2004 17:27:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amh60-00039B-00 for simple-web-archive@ietf.org; Fri, 30 Jan 2004 17:26:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amh5R-00031H-00; Fri, 30 Jan 2004 17:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amh5P-0007kx-3r; Fri, 30 Jan 2004 17:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am9LH-0001Gf-IQ for simple@optimus.ietf.org; Thu, 29 Jan 2004 05:24:11 -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 FAA11694 for ; Thu, 29 Jan 2004 05:24:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am9LE-0000S0-00 for simple@ietf.org; Thu, 29 Jan 2004 05:24:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am9KF-0000Lx-00 for simple@ietf.org; Thu, 29 Jan 2004 05:23:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Am9JI-0000FD-00 for simple@ietf.org; Thu, 29 Jan 2004 05:22:09 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0TAM9205423 for ; Thu, 29 Jan 2004 12:22:09 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 29 Jan 2004 12:22:09 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 12:22:08 +0200 Received: from nokia.com (xitami.research.nokia.com [172.21.40.110]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA15848 for ; Thu, 29 Jan 2004 12:22:18 +0200 (EET) X-Authentication-Warning: mgw.research.nokia.com: Host xitami.research.nokia.com [172.21.40.110] claimed to be nokia.com Message-ID: <4018DECF.7040108@nokia.com> From: Jari Urpalainen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2004 10:22:08.0702 (UTC) FILETIME=[C026E5E0:01C3E651] Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP questions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Jan 2004 12:22:07 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi ! I have been developing a reference implementation for XCAP server (standalone and an Apache module). There are some open/unclear issues (to me at least), so here's the list of questions. 1. XCAP directory list In XCAP presence auth draft chapter 4.4, there's a requirement to get all documents from the server. However, in the base XCAP draft it is unspecified how the server should send this directory list. While http-servers can/will provide this information in many ways, IMO the base XCAP draft should specify this format (xml?). Furhermore, it would be nice if ETags were included in the response in order to help to synchonize documents between the client and the server. 2. XCAP ETags In order to ease the synchronizing within resources between client and server the base XCAP draft could specify the secure hash method e.g. SHA-1 or whatever that is used to calculate the ETag. This is already proposed in xcap-package but IMHO could be in the base spec. 3. XCAP attributes When updating/querying attributes is it necessary to include attribute name in payload as attribute name is already provided in XPATH-query ? e.g. you could get /resource-lists/list[@name="friends"]/@uri so you already know that you receive response for attribute uri. IMHO when putting/getting attributes, payload could include only attribute value. 4. XCAP namespace declarations As namespace handling resemble "standard" XML attributes is it also allowed to change namespace declarations with similar semantics ? BR, Jari Urpalainen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple