From simple-admin@mailman.dynamicsoft.com Mon Jul 1 05:03:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11914 for ; Mon, 1 Jul 2002 05:03:28 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6193bCB001568 for ; Mon, 1 Jul 2002 05:03:37 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02099 for ; Mon, 1 Jul 2002 05:03:44 -0400 (EDT) Date: Mon, 1 Jul 2002 05:03:44 -0400 (EDT) Message-Id: <200207010903.FAA02099@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk This is a reminder, sent out once a month, about your mailman.dynamicsoft.com 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@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Mon Jul 1 06:40:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22764 for ; Mon, 1 Jul 2002 06:40:31 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g61Ae0CB002917; Mon, 1 Jul 2002 06:40:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04083; Mon, 1 Jul 2002 06:40:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04063 for ; Mon, 1 Jul 2002 06:39:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22433; Mon, 1 Jul 2002 06:38:52 -0400 (EDT) Message-Id: <200207011038.GAA22433@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presencelist-package-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 01 Jul 2002 06:38:52 -0400 --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 : A SIP Event Package for List Presence Author(s) : J. Rosenberg, B. Campbell Filename : draft-ietf-simple-presencelist-package-00.txt Pages : 17 Date : 28-Jun-02 This document presents a SIP event package for subscribing to a list of presentities. Instead of the subscriber sending a SUBSCRIBE to each presentity individually, the subscriber can subscribe to their presence list as a whole, and then receive notifications when the state of any of the presentities on the list changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presencelist-package-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-presencelist-package-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-presencelist-package-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: <20020628142820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presencelist-package-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presencelist-package-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 1 06:40:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22791 for ; Mon, 1 Jul 2002 06:40:38 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g61AeOCB002935; Mon, 1 Jul 2002 06:40:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04099; Mon, 1 Jul 2002 06:40:31 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04062 for ; Mon, 1 Jul 2002 06:39:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22480; Mon, 1 Jul 2002 06:39:03 -0400 (EDT) Message-Id: <200207011039.GAA22480@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-sip-message-05.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 01 Jul 2002 06:39:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-sip-message-05.txt Pages : 22 Date : 28-Jun-02 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-05.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-sip-message-05.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-sip-message-05.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: <20020628142840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 1 06:40:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22803 for ; Mon, 1 Jul 2002 06:40:49 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g61AeTCB002951; Mon, 1 Jul 2002 06:40:30 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04115; Mon, 1 Jul 2002 06:40:37 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04064 for ; Mon, 1 Jul 2002 06:39:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22463; Mon, 1 Jul 2002 06:38:58 -0400 (EDT) Message-Id: <200207011038.GAA22463@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cpim-mapping-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 01 Jul 2002 06:38:57 -0400 --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 : CPIM Mapping of SIMPLE Presence and Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-simple-cpim-mapping-01.txt Pages : 13 Date : 28-Jun-02 The SIMPLE work group has defined a SIP events package for distribution of presence information. It has also proposed a MESSAGE extension for the transport of instant messages. This document describes how those mechanisms map to the abstract CPIM service, in order to interoperate with other CPIM compliant presence and instant messaging services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cpim-mapping-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-cpim-mapping-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-cpim-mapping-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: <20020628142830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cpim-mapping-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cpim-mapping-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142830.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 1 09:55:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05993 for ; Mon, 1 Jul 2002 09:55:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g61Dt0CB004132; Mon, 1 Jul 2002 09:55:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04753; Mon, 1 Jul 2002 09:55:03 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04740 for ; Mon, 1 Jul 2002 09:54:31 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA14899; Mon, 1 Jul 2002 15:54:28 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA06977; Mon, 1 Jul 2002 15:54:29 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 15:54:29 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E35@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Ben Campbell'" Cc: "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Simple] RE: [SIP] Provisional response for MESSAGE Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 1 Jul 2002 15:54:23 +0200 Hi, I refer to the last paragraph of Section 9 of draft-ietf-sip-message-05.txt : It has been suggested that provisional responses should not be allowed for pager-model MESSAGE requests. However, it is not possible to require special treatment for MESSAGE, since many proxy servers will not be aware of the MESSAGE method. Therefore MESSAGE requests will receive the same provisional response treatment as any other non-INVITE method, as described in the SIP specification. The paragraph seems to imply that provisional responses are normally generated for MESSAGE requests, which is not the case, as the SIP specification states that provisional response SHOULD NOT be issued for a non-INVITE request. I was actually hoping that the draft would relax the non-method-specific guideline by allowing the generation of the 100 (Trying) provisional response for MESSAGE by UAS and stateful proxies. The reason being that some UAS may not respond with a final respond immediately even though they SHOULD. For example, if a message relay receives a MESSAGE with Expires:0, instead of sending a 202 immediately, it may (incorrectly?) decide to check if the final user is available in order to forward the message immediately (and even awaits the 200 OK from the final user). This can result in a lot of retransmissions on hops where the MESSAGE has been forwarded over UDP, causing unnecessary congestions. Regards, Ya-Ching | -----Original Message----- | From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] | Sent: 29 May 2002 15:46 | To: Tan Ya-Ching ICM N PG U ID A 1 | Subject: Re: [SIP] Provisional response for MESSAGE | | | Thanks! The first part of the paragraph was geared towards | 2543 proxies, | but I was not explicit about it. Also, a "SHOULD NOT" does not | effectively prohibit anything. It means you shouldn't do it | unless you | have a good, clear reason to do so. In some networks, it _might_ be | reasonable to violate the should not if you have a problem | with lots of | retransmissions. | | I will re-word the paragraph to make it clearer in terms of 3261. | | Thanks! | | Ben. | | Tan Ya-Ching ICM N PG U ID A 1 wrote: | > Hi, | > | > The last paragraph of draft-ietf-sip-message-04 section 9 | states that : | > | > "It has been suggested that provisional responses should not be used | > for pager-model MESSAGE requests. However, this is not possible, as | > many proxy servers will not be aware of the MESSAGE method, and will | > treat MESSAGE requests using the standard non-invite transaction. | > Additionally, prohibiting provisional responses may in some cases | > increase the number of retries, and actually make | congestion problems | > worse. Therefore MESSAGE requests SHOULD receive the same | > provisional response treatment as any other non-INVITE method, as | > described in the SIP specification." | > | > But RFC 3261 (8.2.6.1 for UAS, 16.2 for stateful proxy, | 16.11 stateless | > proxy) states that provisional response SHOULD NOT be issued for a | > non-INVITE request. So this is effectively 'prohibiting provisional | > responses' and 'may in some cases increase the number of retries'. | > | > | > Regards, | > Ya-Ching | > | > | | | _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 2 06:33:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01505 for ; Tue, 2 Jul 2002 06:33:31 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g62AW7CB010944; Tue, 2 Jul 2002 06:32:08 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08150; Tue, 2 Jul 2002 06:32:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08139 for ; Tue, 2 Jul 2002 06:31:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01055; Tue, 2 Jul 2002 06:31:12 -0400 (EDT) Message-Id: <200207021031.GAA01055@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-allen-simple-msg-3gpp-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 02 Jul 2002 06:31:12 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : 3GPP work related to SIP based messaging Author(s) : A. Allen Filename : draft-allen-simple-msg-3gpp-01.txt Pages : 7 Date : 01-Jul-02 The 3rd Generation Partnership Project (3GPP) is using SIP RFC 3261 [1] as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IM CN Subsystem, IMS). 3GPP has recently started working on messaging over the IM CN Subsystem. It is intended that this will utilize the IM CN Subsystem for delivery and may be based on IETF protocols including the work being performed in the SIMPLE working group. In this document is provided an outline and areas of interest of the 3GPP work on IMS messaging for the information of the SIMPLE working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allen-simple-msg-3gpp-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-allen-simple-msg-3gpp-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-allen-simple-msg-3gpp-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: <20020701152003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allen-simple-msg-3gpp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-allen-simple-msg-3gpp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152003.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 2 09:26:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08566 for ; Tue, 2 Jul 2002 09:26:29 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g62DPxCB011884; Tue, 2 Jul 2002 09:25:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08724; Tue, 2 Jul 2002 09:26:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08713 for ; Tue, 2 Jul 2002 09:25:19 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62DPitf014803; Tue, 2 Jul 2002 09:25:44 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM76438; Tue, 2 Jul 2002 09:29:51 -0400 (EDT) Message-ID: <3D21A9B7.D719EEF4@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] updated buddy list package draft References: <3D18E1EF.7050700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 02 Jul 2002 09:25:11 -0400 Content-Transfer-Encoding: 7bit Jonathan, Here are some comments about the new spin on this package. Paul - You have the PLS subscribe using the From of its own subscriber. This sounds good, but it limits a significant optimization: If the PLS has many users that subscribe to the same presence list, and/or if some presentities appear in many lists, the PLS can realize a significant savings by subscribing only once to a particular presentity. Clearly there are tradeoffs here. Generally I prefer to get things right first and worry about optimizations later. But this may be too big an optimization to forego. - One solution to the above may be to use the identity of the owner of the list to subscribe to its elements. The owner then gets to decide who can access the gathered information. Perhaps we can specify that the definition of a presence list SHOULD (MAY?) specify the expected type of each element. - It seems ugly to use trial and error to decide whether to subscribe to presencelist or presence. Perhaps the definition of a presence list should be assumed to specify which is which, with trial and error as a fallback. - typo: 3.7 still mentions a BLSS. - typo: 4.1 - reference to watcherinfo seems to be cut/paste error. - That same sentence in 4.1, which suggests triggering a full state refresh, ought to be conditional on the received document containing partial state. (If you get one out of order but with full state, then you don't need to refresh.) - question: what should a PLS do if a presence list is revised while there are subscriptions outstanding? Presumably it should do a full refresh. - If a presence list contains references to other presence lists, the resulting presence-list document is flattened - only the top level presence list is named as an entity. I think it would be better if a contained a mixture of and elements, reflecting the structure of the actual presence list. - Somebody objected to the creation of a new document format because it prevents turning this into a package that can be applied to other event types. I have mixed feelings about the tradeoffs involved, but *if* that is a goal then I have a suggestion. How about defining a document type that does nothing but describe the hierarchical structure of the list, together with the version, and possibly a version of each element. Then transmit the values of each revised element, or each element, as separate elements in multipart/mixed. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 2 14:34:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06953 for ; Tue, 2 Jul 2002 14:34:23 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g62IXFCB014260; Tue, 2 Jul 2002 14:33:17 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09691; Tue, 2 Jul 2002 14:33:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09680 for ; Tue, 2 Jul 2002 14:32:53 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62IWqlt011355; Tue, 2 Jul 2002 14:32:53 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM79107; Tue, 2 Jul 2002 14:36:59 -0400 (EDT) Message-ID: <3D21F1B3.8F2D72B0@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: seancolson@yahoo.com CC: "'Ben Campbell'" , "'Rosen, Brian'" , "'Jonathan Rosenberg'" , bateman@acm.org, "'Li Hua Tang'" , "'DAO TRUNG Tin FTRD/DAC/ISS'" , simple@mailman.dynamicsoft.com Subject: Re: Status discussion again RE: [Simple] Test message References: <000001c21c12$cb7ab1c0$6601a8c0@BOB> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 02 Jul 2002 14:32:19 -0400 Content-Transfer-Encoding: 7bit Sorry - I'm way behind in my mail. It still seems to me we are talking past one another. Maybe this comes down to differences about the purpose of presence. My assumption is that the purpose of presence is to convey willingness to participate in interactive communication. An important subcase of this is when the communication will be realitime communication initiated via sip - perhaps IM, perhaps voice, perhaps something else. An important aspect of presence in this regard is determining in advance whether successful communication will be possible. I don't want to call you unless there is a likelihood that you will answer. Similarly, I don't want to call with voice if all you are willing to do is IM. If I do send you an invite, we negotiate the kind of communication we are willing to do in common using an exchange of SDP. The media types carried in the SDP don't explicitly say what applications should be used, but they imply it, because if the invitation is successful, the two ends will be exchanging data in those mime types and doing something with it. There is nothing else in the invitation to say what will be done. This is true whether the mime type is audio/g711, text/html, image/jpeg or application/wb. In the case of audio or image, it is pretty clear what sort of application will be required regardless of the subtype. This is also true to a lesser extent for text. For application, it is pretty much impossible to figure out what kind of application might be needed, or whether it is available. So, I think it makes pretty good sense to advertise the mimetype/subtype as part of presence. How much of it is presented to a presence subscriber could be a function of the UI at the subscriber end. Frankly, I am not at all convinced that mime types are the best way to describe media in sip, but that is water over the dam. Paul Sean Olson wrote: > > What I mean is that while application/wb may give you a clue as to the > application, > text/html, image/jpeg, or even message/sip do not. MIME types are not > usually > a good indication of the application that will process that media. > "voice" is interesting, but as a MIME type would more likely be > represented as > the less useful audio/g711, etc. > > If what you want to convey is a list of MIME types, that's fine. I just > don't want to confuse that with a list of applications. (Of course, MIME > types > are best represented with a suitable subtype as you mention) > > By mode, I meant a token that succintly defines an application -- like > "voice" perhaps. > But I definitely don't want to get into the game of defining a list of > codecs ... this > is much better handled by SIP itself than by a presence document format. > > /sean > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Paul Kyzivat > Sent: Monday, June 24, 2002 10:23 PM > To: Sean Olson > Cc: Ben Campbell; Rosen, Brian; 'Jonathan Rosenberg'; bateman@acm.org; > 'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS'; > simple@mailman.dynamicsoft.com > Subject: Re: Status discussion again RE: [Simple] Test message > > Sean Olson wrote: > > > > Mode seems to make sense. I like the idea > > of announcing supported MIME types, BUT I think > > it is very dangerous to infer applications from > > MIME types (as you hint at for the > > application/wb case). I see this leading to a > > rathole. Could we set the bar at just > > announcing "modes" for now? > > You have to tell me what you mean by "mode" then. > > I don't think of application/wb as an "application" in any specific > sense. As far as I am concerned, "application" and "voice" are simply > different subdivisions of the overall mimetype namespace. But "voice" in > its own right is much more specific than "application" is. I have a > reasonable chance of deciding if I can support "voice" without more > detail. (If I can't support the offered codecs then I can probably find > a transcoder that can convert to something I do understand.) > > But by itself "application" tells me nothing about what I will be > expected to do. And in general there are no transcoders that can convert > between application/wb that I support and application/foo that I don't - > there is no least common denominator between subtypes of application. > > If the bar is set so low that mime subtypes can never be used, then > presence will not be at all useful for any media that happen to be > described by subtypes of application. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 2 19:51:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23289 for ; Tue, 2 Jul 2002 19:51:55 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g62NoxCB016223; Tue, 2 Jul 2002 19:50:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10631; Tue, 2 Jul 2002 19:51:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10620 for ; Tue, 2 Jul 2002 19:50:59 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62NpM4i001942; Tue, 2 Jul 2002 19:51:23 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM81013; Tue, 2 Jul 2002 19:55:30 -0400 (EDT) Message-ID: <3D223C5A.5E908CF@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: "'Ben Campbell'" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] RE: [SIP] Provisional response for MESSAGE References: <5B4D0C5BA65ECA46969C1419122317E6E74E35@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 02 Jul 2002 19:50:50 -0400 Content-Transfer-Encoding: 7bit I would like to continue this train of thought. I can see cases when a proxy might want to return a 182 Queued response to a message. For instance, a specialized proxy that selects among alternative destinations for the message based upon presence. If none of the alternatives is Open to accept the message, it may wish to return Queued until it can pick a destination and deliver the message. This could be done using a B2BUA that stores the message persistently, returns 202, and then waits to deliver the message. But if it doesn't want to be stateful, the Queud tactic is interesting, even though it requires another interim status to be returned fairly often. Paul Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Hi, > > I refer to the last paragraph of Section 9 of draft-ietf-sip-message-05.txt > : > > It has been suggested that provisional responses should > not be allowed for pager-model MESSAGE requests. > However, it is not possible to require special treatment for > MESSAGE, since many proxy servers will not be aware > of the MESSAGE method. Therefore MESSAGE requests > will receive the same provisional response treatment as > any other non-INVITE method, as described in the SIP > specification. > > The paragraph seems to imply that provisional responses are normally > generated for MESSAGE requests, which is not the case, as the SIP > specification states that provisional response SHOULD NOT be issued for a > non-INVITE request. I was actually hoping that the draft would relax the > non-method-specific guideline by allowing the generation of the 100 (Trying) > provisional response for MESSAGE by UAS and stateful proxies. The reason > being that some UAS may not respond with a final respond immediately even > though they SHOULD. For example, if a message relay receives a MESSAGE with > Expires:0, instead of sending a 202 immediately, it may (incorrectly?) > decide to check if the final user is available in order to forward the > message immediately (and even awaits the 200 OK from the final user). This > can result in a lot of retransmissions on hops where the MESSAGE has been > forwarded over UDP, causing unnecessary congestions. > > Regards, > Ya-Ching _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 4 06:19:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13176 for ; Thu, 4 Jul 2002 06:19:59 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g64AJBCB023659; Thu, 4 Jul 2002 06:19:11 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16237; Thu, 4 Jul 2002 06:19:07 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16226 for ; Thu, 4 Jul 2002 06:18:21 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g64AGpd17024 for ; Thu, 4 Jul 2002 13:16:51 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 13:18:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 13:18:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] revised SIMPLE charter - comments? Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBB68@esebe004.NOE.Nokia.com> Thread-Topic: [Simple] revised SIMPLE charter - comments? Thread-Index: AcIBb7PgikI5u2D7THmwUQML4+62RwhxgQpA To: , X-OriginalArrivalTime: 04 Jul 2002 10:18:19.0694 (UTC) FILETIME=[1E8A8CE0:01C22344] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA16226 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 4 Jul 2002 13:18:18 +0300 Content-Transfer-Encoding: 8bit Hi folks, New charter looks like a step to right direction. Some comments inline: > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 22 May, 2002 11:53 > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] revised SIMPLE charter - comments? > > Description of Working Group: > > This working group focuses on the application of the Session > Initiation > Protocol (SIP, RFC 3261) to the suite of services > collectively known as > instant messaging and presence (IMP). The IETF has committed > to producing an > interoperable standard for these services compliant to the > requirements for > IM > outlined in RFC 2779 (including the security and privacy > requirements there) > and in the Common Presence and Instant Messaging (CPIM) specification, > developed > within the IMPP working group. As the most common services > for which SIP is > used > share quite a bit in common with IMP, the adaptation of SIP > to IMP seems a > natural choice given the widespread support for (and relative > maturity of) > the > SIP standard. > > The primary work of this group will be to generate: > > 1. A proposed standard SIP extension documenting the > transport of Instant > Messages in SIP, compliant to the requirements for IM > outlined in RFC 2779, > CPIM and in BCP 41 (so that the transport implications of the > extension > with respect to network congestion are considered in the design). > > 2. A proposed standard SIP event package and any related protocol > mechanisms used to support presence, compliant to the > requirements for > presence outlined in RFC 2779 and CPIM. > > 3. An architecture for the implementation of a traditional buddylist- > based instant messaging and presence application with SIP, > including for > example new mechanisms for message confirmation delivery, > indications for > when > a party is in the process of typing a message, secure > buddylist manipulation > > operations, and the extension of the CPIM presence format to describe > typical > IM states. > > All SIMPLE proposals fulfilling these goals must document the > mappings of > their operation to CPIM. Any SIP extensions proposed in the > course of this > development will, after a last call process, be transferred > to the SIP WG > for consideration as formal SIP extensions. > > The working group will work within the framework for presence and IM > described in RFC 2778. The extensions it defines must also be > compliant with > the SIP processes for extensions. The group cannot modify baseline SIP > behavior or define a new version of SIP for IM and presence. > If the group > determines that any capabilities requiring an extension to > SIP are needed, > the group will seek to define such extensions within the SIP > working group, > and then use them here. > > The working group will operate in close cooperation with the > IMPP working > group, which will be completing CPIM in parallel. The working > group will > also cooperate with any other groups defined to standardize > other presence > and IM systems, to ensure maximum sharing of information and avoid > reinvention of the wheel. The working group will cooperate > with the SIP > working group, soliciting reviews to ensure its extensions meet SIPs > requirements. The working group will also collaborate with > the SIP WG to > ensure consistent operation of the SUBSCRIBE and NOTIFY methods across > the other applications being defined for its use. > > Goals and Milestones: > Apr 02 Submission of event package for presence to IESG > for publication > as Proposed Standard > May 02 Submission of watcher information drafts to IESG > for publication > as Proposed Standards > Jun 02 Submission of CPIM mapping draft to IESG for publication as > Informational > Jun 02 Submission of instant messaging session drafts to IESG for > publication as Proposed Standards > Jul 02 Submission of buddylist package set to IESG for > publication as > Proposed Standards > Jul 02 Submission of buddylist auth/modify requirements > draft to IESG > for publication as Informational There are also some other 'management' requirements for presence service, for example presence authorization and presence uploading. Could this work item be extended to include also those. Also the actual solution spec. seems to be missing. Could that be added to charter as well? > Aug 02 Submission of SIMPLE PIDF profile to IESG for > publication as > Proposed Standard To my understanding this item is mainly targeted to specify SIMPLE specific status values. I was just wondering if the scope of this working item could be extended to contain items like support for partial notifications? > Aug 02 Submission of advanced messaging requirements draft > to IESG for > publication as Informational Could the actual solution specification also be added to charter? > Sep 02 Submission of Presence/IM System Architecture draft > to IESG for > publication as Informational This item seems a bit unclear to me. If the purpose of this item is to provide information how all different SIMPLE specifications fit together then this sounds reasonable but otherwise I don't see much value in this. Here is a list of missing WG items that in my mind would benefit SIMPLE group: - Filtering solutions for presence and winfo: Solution could be either generic or event package specific. There has already been some discussions on the SIPPING list about this topic and I would like to ask whether this should be handled in SIPPING or in SIMPLE wg? -Partial notifications: Partial notifications means that instead of PS always sending complete presence state it could only send data that has actually changed. For example winfo already allows this kind of functionality. I understand that this is not CPIM compliant feature but it is still very important (at least for wireless environments) and would be good if SIMPLE and IMPP WGs could consider adopting this as wg work item. regards - Mikko _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 4 08:58:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16531 for ; Thu, 4 Jul 2002 08:58:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g64CvxCB024059; Thu, 4 Jul 2002 08:57:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16752; Thu, 4 Jul 2002 08:58:03 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16741 for ; Thu, 4 Jul 2002 08:57:44 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g64CwEi22260 for ; Thu, 4 Jul 2002 15:58:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 15:57:43 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 15:57:43 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 15:57:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Choosing a mechanism for presence publication. Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203B9@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Choosing a mechanism for presence publication. Thread-Index: AcIYoy06tDhnFwkWTx2futm/PDkRxwKtp8mA To: , Cc: , , , X-OriginalArrivalTime: 04 Jul 2002 12:57:43.0225 (UTC) FILETIME=[62D99290:01C2235A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA16741 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 4 Jul 2002 15:57:42 +0300 Content-Transfer-Encoding: 8bit My main concern is that if the PUBLISH gets big enough contents, the PUA has to POST the presence info to some HTTP server and send a PUBLISH to the Presence Server with content-indirection. The Presence Serve then has to GET using HTTP. This is like going around in a circle. Why not just use HTTP in the first place and avoid all this. BIND to the presence server can help you discover where to publish your presence info using HTTP. Regards, Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, June 21, 2002 12:29 AM > To: Simple > Cc: Ben Campbell; Jonathan Rosenberg; Brian Stucker; Sean Olson; Jon > Peterson > Subject: [Simple] Choosing a mechanism for presence publication. > > > Several of us have engaged in an offline discussion on how to > handle the > publication of presence imformation from a PUA to a remote > PA. We think > we have reached a preliminary conclusion on the mechanism > choice. This > email reflects (what I believe to be) the consensus of that group so > far. The bottom line is, there is significant advantage in > using a SIP > based mechanism. > > There has been some controversy over the choice of mechanism by which > SIMPLE presence user agents publish information to remote presence > agents. The two most favored approaches so far have been the > creation of > a new SIP method for the purpose, and the use of HTTP. > > Nature of Presence Publication: > > We propose a model for presence composition where more than > one PUA may > publish on behalf of a single presentity. Those PUAs may exist in > separate administrative domains. The publications eventually > make it to > a logical network element that composes the views of presence sent by > the various PUAs into a composite presence document. For the > moment, at > least, we are calling this logical element a "compositor". This model > implies a few assumptions for publication: > > 1) A PUA must be capable of remotely publishing a presence > document to a > compositor. There is no requirement so far for the PUA to > query a PA to > determine what document it had published previously. We > assume the PUA > can subscribe to the final composed document via SIMPLE. > > 2) A presence document can be expressed by a MIME body part. > > 3) The document published by a PUA to a particular input is not > dependent upon previous publications to that input. The only > transaction > semantic for a given input is "replace". (Note that this does not > prevent the compositor from applying complex application semantics to > compose the input, along with all other inputs, into a composite > presence document.) Any versioning is handled by payload itself. > > 4) The composition semantics belong to the local policy of the > compositor. The PUA does not need to understand these semantics, and > cannot expect to make composition policy choices as part of the > publication action. If a principle needs to make composition policy > decisions, that is through some other mechanism. > > 5) There may be multiple PUAs publishing on behalf of the same > presentity. There is no assumption that these PUAs all connect through > the same network, or even belong to the same administrative > or security > domain. > > Differences between HTTP and SIP publication: > > HTTP is well suited for moving data around in the form of MIME body > parts. An HTTP client-to-server publication solution would not require > much work to specify. A SOAP over HTTP solution would > additionally allow > complex transaction semantics with little additional work. > > HTTP, however, does not have a well-defined routing model at the > application level. It works fine if the publication point is > well known > and fairly static, but it will require additional work to deal with > situations where the publication point changes dynamically. > > SIP, on the otherhand, is built around the concept of mobility of > endpoints. The SIP proxy, registrar, and location service concepts > provide a rich mechanism of finding a dynamically changing > endpoint from > and address of record. > > SIP, however, does not have an existing method suited for presence > publication. REGISTER gets us part of the way, but has well-known > limitations when used for this purpose. SIP is, by nature, > also adept at > moving around MIME payloads, so the creation of such a method is not a > particularly difficult task. > > Motivation for a SIP based mechanism: > > The application-level routing capabilities of SIP can be very > useful for > presence publication. If all PUAs for a given presentity exist in the > same administrative domain, then they can most likely publish directly > to a compositor. But if PUAs exist outside the administrative > domain, it > is likely they will not be able to do so. > > For example, suppose that Alice uses a presence service that allows > multiple PUAs to publish to a compositor inside the service provider > network. Further suppose that Alice wishes to incorporate presence > information from an external provider, that has no business > relationship > with her primary provider. For this example, Alice wishes to use a > shared browsing service that tracks the "location" she is currently > browsing in the web. That service acts as a PUA on Alice's behalf, and > publishes the information to her primary presence provider. > Other users > of the shared browsing service can subscribe to her presence > information, and determine when they are browsing the same site. > > The presence provider is highly unlikely to allow the external PUA to > send data directly to the compositor. But if Alice registers a contact > with a methods parameter value of "PUBLISH", that PUA can > send a publish > request to an edge proxy in the presence providers network, and use > Alice's address of record as the requestURI. This AoR could be her > normal SIP URI, or it could be a special AoR for the purposes of > presence publication. The proxy forwards the request to the > compositor, > without the external PUA having to talk directly to the compositor, or > even know its IP address. > > Now consider that Alice's primary providor is actually an enterprise. > That enterprise has different compositors for different > departments. The > external provider has no way of knowing this internal > organization, nor > does it know what department Alice works in. Still, Alice > register's her > publication contact at an enterprise registrar, the external > provider sends the publish request to Alice's address of > record, and the > companies internal SIP network handles things from there, eventually > getting the request to the correct compositor. > > The composition model does not at first appear to require > publishing to > dynamically changing PAs. But a very powerful, but often forgotten, > aspect of SIMPLE is it allows a PA to exist on an end-user device. > Indeed, some early implentations of SIMPLE rely on exactly that model. > It is reasonable to expect the composition model above to > co-exist with > end-user device PAs, where the PA location changes dynamically. > > For example, imagine Alice hosts a PA on her PC, which aquires its IP > address via DHCP. This address changes relatively frequently, and > registers a publish contact with an enterprise registrar. Now, > imagine she also has a mobile phone which contains a PUA. She > wants her > presence document to show a combined view of her PCs concept of her > presence and her mobile phone service's concept of her precence. She > cannot simply tell the mobile service her PC address since it changes > often. Instead, she tells the service an AoR to publish presence to. > The mobile service publishes presence state to that AoR, > which resolves > to a SIP proxy or redirect server. Normal SIP proxy or > redirect behavior > is invoked to get the publication to Alice's PC based on her publish > contact registration. > > It is our opinion that SIP style routing is very useful for presence > publication. Without the application level routing > capabilities of SIP, > it would be difficult to build these sort of services. It is more > appropriate to add a publication mechanism to SIP than to standardize > SIP-style routing features for HTTP proxies. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 4 11:33:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19698 for ; Thu, 4 Jul 2002 11:33:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g64FS1CB024455; Thu, 4 Jul 2002 11:28:01 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17252; Thu, 4 Jul 2002 11:28:03 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA17241 for ; Thu, 4 Jul 2002 11:27:26 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 4 Jul 2002 15:27:52 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Choosing a mechanism for presence publication. Message-ID: <45730E094814E44488F789C1CDED27AE018C23B1@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Simple] Choosing a mechanism for presence publication. Thread-Index: AcIYoy06tDhnFwkWTx2futm/PDkRxwKtp8mAAAUXBhA= From: "James Undery" To: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA17241 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 4 Jul 2002 16:29:16 +0100 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > My main concern is that if the PUBLISH gets big enough > contents, the PUA has to POST the presence info to some HTTP > server and send a PUBLISH to the Presence Server with > content-indirection. The Presence Serve then has to GET using > HTTP. This is like going around in a circle. Why not just use > HTTP in the first place and avoid all this. > > BIND to the presence server can help you discover where to > publish your presence info using HTTP. I sortof agree with Hisham here, how I envisaged this working was The presentity using BIND to provide the "compositor" with the locations of PUAs. Depending on the URL the compositor would then fetch and aggregate the information from the PUAs using a sutable mechanism (e.g. SIP scheme use SUB/NOT, HTTP use GET). The "compositor" itself would just look like a regular PUA to subscribers (i.e. use SUB/NOT). _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 4 15:12:15 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23108 for ; Thu, 4 Jul 2002 15:12:15 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g64JBxCB024895; Thu, 4 Jul 2002 15:11:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17906; Thu, 4 Jul 2002 15:12:03 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17895 for ; Thu, 4 Jul 2002 15:11:18 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g64JBV125622 for ; Thu, 4 Jul 2002 14:11:31 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 14:11:16 -0500 Message-ID: From: "Sriram Parameswar" To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2238E.924F8B90" Subject: [Simple] Questions/comments on draft-olson-simple-publish-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 4 Jul 2002 14:11:16 -0500 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_01C2238E.924F8B90 Content-Type: text/plain; charset="iso-8859-1" Hi: Overall I liked the document and agree with its purpose. Just have a few questions and comments: 1. The draft seems to take it for granted that the Compositor/Presence Agent supports the PUBLISH method. Given that we already have presence deployed - I would like to see some mechanism to (a) establish that the compositor/presence agent supports the PUBLISH method (b) a fallback mechanism in case it doesn't: example back to using REGISTER or other mechanisms. 2. I understand the motivation to limit PUBLISH to event state publishing. However since we are taking the trouble to add a whole new method to SIP, I would like to see you establish some extensibility mechanisms within the method so it may be extended to publish other things like CPL, etc. I do not buy the argument in the Abstract that there are better mechanisms to publish things like CPL. 3. In section 1.1.1 it says "Each PUA publishes a full view of presence from its perspective--each publication carries full state, and does not depend on previous states for the particular PUA." Why can't each PUA publish incremental/differential presence state - after all the compositor should have the logic to handle this. 4. The whole motivation for slots (and future standardization of slot names) and the use of the PTYPE header, may be solved if cpim-pidf simply adds the RFC2778 mandated "Contact Means". I have contacted the pidf authors on this. Is there any other need for the PTYPE header - the Contact Means tag would carry the same meaning. 5. PStream tracking - the document reiterates that PUBLISH does not establish a dialog, as dialogs create state to keep track of. Then the discussion on REGISTER says "However, this does not guarantee that clients will follow the rules, and thus, sequencing may be lost as a result". If the Compositor/PA has to keep track of PStream to keep temporal ordering - how have we reduced the state that has to be maintained. Also if clients do not 'follow the rules' and uses different Pstream values for PUBLISH, again sequencing is lost. I am not sure that PStream buys us anything more than simply requiring clients to PUBLISH using the same Call-ID. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C2238E.924F8B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Questions/comments on draft-olson-simple-publish-00.txt

Hi:

Overall I liked the document and agree with its = purpose. Just have a few questions and comments:

1. The draft seems to take it for granted that the = Compositor/Presence Agent supports the PUBLISH method. Given that we = already have presence deployed - I would like to see some mechanism to = (a) establish that the compositor/presence agent supports the PUBLISH = method (b) a fallback mechanism in case it doesn't: example back to = using REGISTER or other mechanisms.

2. I understand the motivation to limit PUBLISH to = event state publishing. However since we are taking the trouble to add = a whole new method to SIP, I would like to see you establish some = extensibility mechanisms within the method so it may be extended to = publish other things like CPL, etc. I do not buy the argument in the = Abstract that there are better mechanisms to publish things like = CPL.

3. In section 1.1.1 it says "Each PUA publishes = a full view of presence from its perspective--each publication carries = full state, and does not depend on previous states for the particular = PUA." Why can't each PUA publish incremental/differential presence = state - after all the compositor should have the logic to handle = this.

4. The whole motivation for slots (and future = standardization of slot names) and the use of the PTYPE header, may be = solved if cpim-pidf simply adds the RFC2778 mandated "Contact = Means". I have contacted the pidf authors on this. Is there any = other need for the PTYPE header - the Contact Means tag would carry the = same meaning.

5. PStream tracking - the document reiterates that = PUBLISH does not establish a dialog, as dialogs create state to keep = track of. Then the discussion on REGISTER says "However, this does not = guarantee that clients will follow the rules, and thus, sequencing may = be lost as a result". If the Compositor/PA has to keep track of PStream = to keep temporal ordering - how have we reduced the state that has to = be maintained. Also if clients do not 'follow the rules' and uses = different Pstream values for PUBLISH, again sequencing is lost. I am = not sure that PStream buys us anything more than simply requiring = clients to PUBLISH using the same Call-ID.

Regards,


Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C2238E.924F8B90-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 4 16:53:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24669 for ; Thu, 4 Jul 2002 16:53:09 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g64KqvCB025122; Thu, 4 Jul 2002 16:52:57 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18272; Thu, 4 Jul 2002 16:53:04 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18253 for ; Thu, 4 Jul 2002 16:52:44 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g64Kqv102315; Thu, 4 Jul 2002 15:52:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 15:52:42 -0500 Message-ID: From: "Sriram Parameswar" To: "'simple@mailman.dynamicsoft.com'" Cc: "'aallen@dynamicsoft.com'" , "'aki.niemi@nokia.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2239C.BD72E890" Subject: [Simple] Comment: draft-allen-simple-msg-3gpp-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 4 Jul 2002 15:52:42 -0500 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_01C2239C.BD72E890 Content-Type: text/plain; charset="iso-8859-1" Hi: Minor comment on the draft - I did not see explicit mention of Instant Messaging sessions. As you are aware - this is one area that is being worked on in the SIMPLE WG. I think this merits mention as it is explicitly called out in TR 22.940 in Section 5 "Session based messaging: The sender(s) and the receiver(s) have to join to a messaging session". The draft does mention a chat room, however session based IMs need not occur only in the context of a chat room. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C2239C.BD72E890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comment: draft-allen-simple-msg-3gpp-01.txt

Hi:

Minor comment on the draft - I did not = see explicit mention of Instant Messaging sessions. As you are aware - = this is one area that is being worked on in the SIMPLE WG. I think this = merits mention as it is explicitly called out in TR 22.940 in Section 5 = "Session based = messaging: The = sender(s) and the receiver(s) have to join to a messaging = session". The draft does mention a = chat room, however session based IMs need not occur only in the context = of a chat room.

Thanks,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: = 972-685-8540
Interactive Multimedia Server (IMS) = Fax: 972-684-3986
Nortel Networks, Richardson = USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C2239C.BD72E890-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 5 14:40:15 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09705 for ; Fri, 5 Jul 2002 14:40:15 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g65Id3CB027756; Fri, 5 Jul 2002 14:39:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21788; Fri, 5 Jul 2002 14:39:05 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21777 for ; Fri, 5 Jul 2002 14:38:21 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65IcAYH028425; Fri, 5 Jul 2002 14:38:11 -0400 (EDT) Message-ID: <3D25E790.6090104@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, simple@mailman.dynamicsoft.com, bstucker@nortelnetworks.com, seanol@windows.microsoft.com, jon.peterson@neustar.biz Subject: Re: [Simple] Choosing a mechanism for presence publication. References: <2038BCC78B1AD641891A0D1AE133DBB7C203B9@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 05 Jul 2002 14:38:08 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > My main concern is that if the PUBLISH gets big enough contents, the PUA > has to POST the presence info to some HTTP server and send a PUBLISH to > the Presence Server with content-indirection. The Presence Serve then > has to GET using HTTP. This is like going around in a circle. Why not > just use HTTP in the first place and avoid all this. Well, the indirection is needed only if you don't have e2e congestion control. We're working on that. > > BIND to the presence server can help you discover where to publish your > presence info using HTTP. The problem is that the server that you need to publish to may not be accessible directly by HTTP. COnsider the example in the draft about the PA deep within a multi-level enterprise, or the case where the PA is a registered PC. I can understand the desire for HTTP - I've been on both sides of this fence! My current leaning is for sip publish because, practically speaking, there were a number of cases where http didn't work. I also think that the presence publication problem is sufficiently different from a number of other "data publication" things we're looking at (see http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt), where i do believe HTTP/SOAP is better. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 5 15:04:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11487 for ; Fri, 5 Jul 2002 15:04:36 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g65J3qCB027887; Fri, 5 Jul 2002 15:03:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21908; Fri, 5 Jul 2002 15:04:02 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21897 for ; Fri, 5 Jul 2002 15:03:39 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65J3cYH028438; Fri, 5 Jul 2002 15:03:39 -0400 (EDT) Message-ID: <3D25ED87.1080203@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: jon.peterson@neustar.biz, simple@mailman.dynamicsoft.com Subject: Re: [Simple] revised SIMPLE charter - comments? References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBB68@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 05 Jul 2002 15:03:35 -0400 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > Hi folks, > > New charter looks like a step to right direction. > Some comments inline: > >>Jul 02 Submission of buddylist auth/modify requirements >>draft to IESG >>for publication as Informational > > > There are also some other 'management' requirements for presence service, > for example presence authorization and presence uploading. Could this work item > be extended to include also those. Presence uploading is being considered separately; see the publish draft just recently submitted. Other general management issues are in scope, IMHO. In fact: http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt looks at the problem more generally. > Also the actual solution spec. seems to be > missing. Could that be added to charter as well? I think the idea was to get the requirements doc done and then move onto the solution do as a result of another recharter. >>Aug 02 Submission of advanced messaging requirements draft >>to IESG for >>publication as Informational > > > Could the actual solution specification also be added to charter? Same as above. > > >>Sep 02 Submission of Presence/IM System Architecture draft >>to IESG for >>publication as Informational > > > This item seems a bit unclear to me. If the purpose of this item > is to provide information how all different SIMPLE specifications fit > together then this sounds reasonable but otherwise I don't see much value in this. Its the "overall architecture" document that shows how all this various stuff fits together to build complete systems. > > Here is a list of missing WG items that in my mind would benefit SIMPLE group: > - Filtering solutions for presence and winfo: > Solution could be either generic or event package specific. There has already > been some discussions on the SIPPING list about this topic and I would like to ask > whether this should be handled in SIPPING or in SIMPLE wg? Good question. It could be either. Its not a SIP extension, in fact. If its for sip-events generally, probably sipping is better, but simple has more cycles... > > -Partial notifications: > Partial notifications means that instead of PS always sending complete presence state > it could only send data that has actually changed. For example winfo already allows this > kind of functionality. I understand that this is not CPIM compliant feature but it is > still very important (at least for wireless environments) and would be good > if SIMPLE and IMPP WGs could consider adopting this as wg work item. The presence list package provides partial notifications, on the level of granularity of individual presentity. Do you feel there is really a need for partial notifications at a finer granularity? I am not convinced. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 5 18:05:17 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21209 for ; Fri, 5 Jul 2002 18:05:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g65M4vCB028360; Fri, 5 Jul 2002 18:04:57 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22490; Fri, 5 Jul 2002 18:05:04 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22477 for ; Fri, 5 Jul 2002 18:04:58 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-eth-s4p2c0.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g65M4M505578; Fri, 5 Jul 2002 17:04:37 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 17:04:07 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA810A02E5@STNTEXCH2> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Cc: "'rsparks@dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] SIMPLE draft agenda Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 5 Jul 2002 17:04:05 -0500 Below find the proposed agenda for the SIMPLE WG meeting in Yokohama. Please let us know if you have any suggestions or corrections. Jon Peterson NeuStar, Inc. ---- SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) Wednesday, July 17 at 0900-1130 =================================== Chairs: Robert Sparks (rsparks@dynamicsoft.com) Jon Peterson (jon.peterson@neustar.biz) Agenda: 0900 - Agenda Bashing/Charter Review (Chairs) 0910 - MESSAGE update (draft-ietf-sip-message-05) CPIM draft update (draft-ietf-simple-cpim-mapping-01) 0920 - Presence List Event Package draft-ietf-simple-presencelist-package-00 0940 - SIMPLE Data Manipulation Requirements draft-ietf-rosenberg-simple-data-req-00 1000 - Presence Publication draft-olson-simple-publish-00 1025 - 3GPP drafts draft-allen-simple-msg-3gpp-01 draft-kiss-simple-presence-wireless-reqs 1050 - Message sessions IMSX analysis (draft-barnes-simple-imsx-prot-eval-00) _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Jul 6 14:30:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28282 for ; Sat, 6 Jul 2002 14:30:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g66IO3CB029807; Sat, 6 Jul 2002 14:24:03 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25721; Sat, 6 Jul 2002 14:24:03 -0400 (EDT) Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25710 for ; Sat, 6 Jul 2002 14:23:55 -0400 (EDT) Received: from tele.tct.hut.fi (tele.tct.hut.fi [130.233.154.160]) by keskus.tct.hut.fi (8.10.0/8.10.0) with ESMTP id g66INjr10971; Sat, 6 Jul 2002 21:23:45 +0300 (EET DST) From: Costa Requena To: cc: , , , , , Subject: RE: [Simple] Choosing a mechanism for presence publication. In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C203B9@esebe019.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 6 Jul 2002 21:23:45 +0300 (EET DST) Hi Hisham, I completely agree! If PUBLISH suffer from Content Indirection we are going around the same problem once more. Would it be much cleaner approach to use HTTP as publishing mechanism? BR Jose On Thu, 4 Jul 2002 hisham.khartabil@nokia.com wrote: > My main concern is that if the PUBLISH gets big enough contents, the PUA has to POST the presence info to some HTTP server and send a PUBLISH to the Presence Server with content-indirection. The Presence Serve then has to GET using HTTP. This is like going around in a circle. Why not just use HTTP in the first place and avoid all this. > > BIND to the presence server can help you discover where to publish your presence info using HTTP. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Friday, June 21, 2002 12:29 AM > > To: Simple > > Cc: Ben Campbell; Jonathan Rosenberg; Brian Stucker; Sean Olson; Jon > > Peterson > > Subject: [Simple] Choosing a mechanism for presence publication. > > > > > > Several of us have engaged in an offline discussion on how to > > handle the > > publication of presence imformation from a PUA to a remote > > PA. We think > > we have reached a preliminary conclusion on the mechanism > > choice. This > > email reflects (what I believe to be) the consensus of that group so > > far. The bottom line is, there is significant advantage in > > using a SIP > > based mechanism. > > > > There has been some controversy over the choice of mechanism by which > > SIMPLE presence user agents publish information to remote presence > > agents. The two most favored approaches so far have been the > > creation of > > a new SIP method for the purpose, and the use of HTTP. > > > > Nature of Presence Publication: > > > > We propose a model for presence composition where more than > > one PUA may > > publish on behalf of a single presentity. Those PUAs may exist in > > separate administrative domains. The publications eventually > > make it to > > a logical network element that composes the views of presence sent by > > the various PUAs into a composite presence document. For the > > moment, at > > least, we are calling this logical element a "compositor". This model > > implies a few assumptions for publication: > > > > 1) A PUA must be capable of remotely publishing a presence > > document to a > > compositor. There is no requirement so far for the PUA to > > query a PA to > > determine what document it had published previously. We > > assume the PUA > > can subscribe to the final composed document via SIMPLE. > > > > 2) A presence document can be expressed by a MIME body part. > > > > 3) The document published by a PUA to a particular input is not > > dependent upon previous publications to that input. The only > > transaction > > semantic for a given input is "replace". (Note that this does not > > prevent the compositor from applying complex application semantics to > > compose the input, along with all other inputs, into a composite > > presence document.) Any versioning is handled by payload itself. > > > > 4) The composition semantics belong to the local policy of the > > compositor. The PUA does not need to understand these semantics, and > > cannot expect to make composition policy choices as part of the > > publication action. If a principle needs to make composition policy > > decisions, that is through some other mechanism. > > > > 5) There may be multiple PUAs publishing on behalf of the same > > presentity. There is no assumption that these PUAs all connect through > > the same network, or even belong to the same administrative > > or security > > domain. > > > > Differences between HTTP and SIP publication: > > > > HTTP is well suited for moving data around in the form of MIME body > > parts. An HTTP client-to-server publication solution would not require > > much work to specify. A SOAP over HTTP solution would > > additionally allow > > complex transaction semantics with little additional work. > > > > HTTP, however, does not have a well-defined routing model at the > > application level. It works fine if the publication point is > > well known > > and fairly static, but it will require additional work to deal with > > situations where the publication point changes dynamically. > > > > SIP, on the otherhand, is built around the concept of mobility of > > endpoints. The SIP proxy, registrar, and location service concepts > > provide a rich mechanism of finding a dynamically changing > > endpoint from > > and address of record. > > > > SIP, however, does not have an existing method suited for presence > > publication. REGISTER gets us part of the way, but has well-known > > limitations when used for this purpose. SIP is, by nature, > > also adept at > > moving around MIME payloads, so the creation of such a method is not a > > particularly difficult task. > > > > Motivation for a SIP based mechanism: > > > > The application-level routing capabilities of SIP can be very > > useful for > > presence publication. If all PUAs for a given presentity exist in the > > same administrative domain, then they can most likely publish directly > > to a compositor. But if PUAs exist outside the administrative > > domain, it > > is likely they will not be able to do so. > > > > For example, suppose that Alice uses a presence service that allows > > multiple PUAs to publish to a compositor inside the service provider > > network. Further suppose that Alice wishes to incorporate presence > > information from an external provider, that has no business > > relationship > > with her primary provider. For this example, Alice wishes to use a > > shared browsing service that tracks the "location" she is currently > > browsing in the web. That service acts as a PUA on Alice's behalf, and > > publishes the information to her primary presence provider. > > Other users > > of the shared browsing service can subscribe to her presence > > information, and determine when they are browsing the same site. > > > > The presence provider is highly unlikely to allow the external PUA to > > send data directly to the compositor. But if Alice registers a contact > > with a methods parameter value of "PUBLISH", that PUA can > > send a publish > > request to an edge proxy in the presence providers network, and use > > Alice's address of record as the requestURI. This AoR could be her > > normal SIP URI, or it could be a special AoR for the purposes of > > presence publication. The proxy forwards the request to the > > compositor, > > without the external PUA having to talk directly to the compositor, or > > even know its IP address. > > > > Now consider that Alice's primary providor is actually an enterprise. > > That enterprise has different compositors for different > > departments. The > > external provider has no way of knowing this internal > > organization, nor > > does it know what department Alice works in. Still, Alice > > register's her > > publication contact at an enterprise registrar, the external > > provider sends the publish request to Alice's address of > > record, and the > > companies internal SIP network handles things from there, eventually > > getting the request to the correct compositor. > > > > The composition model does not at first appear to require > > publishing to > > dynamically changing PAs. But a very powerful, but often forgotten, > > aspect of SIMPLE is it allows a PA to exist on an end-user device. > > Indeed, some early implentations of SIMPLE rely on exactly that model. > > It is reasonable to expect the composition model above to > > co-exist with > > end-user device PAs, where the PA location changes dynamically. > > > > For example, imagine Alice hosts a PA on her PC, which aquires its IP > > address via DHCP. This address changes relatively frequently, and > > registers a publish contact with an enterprise registrar. Now, > > imagine she also has a mobile phone which contains a PUA. She > > wants her > > presence document to show a combined view of her PCs concept of her > > presence and her mobile phone service's concept of her precence. She > > cannot simply tell the mobile service her PC address since it changes > > often. Instead, she tells the service an AoR to publish presence to. > > The mobile service publishes presence state to that AoR, > > which resolves > > to a SIP proxy or redirect server. Normal SIP proxy or > > redirect behavior > > is invoked to get the publication to Alice's PC based on her publish > > contact registration. > > > > It is our opinion that SIP style routing is very useful for presence > > publication. Without the application level routing > > capabilities of SIP, > > it would be difficult to build these sort of services. It is more > > appropriate to add a publication mechanism to SIP than to standardize > > SIP-style routing features for HTTP proxies. > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Jul 6 14:38:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28406 for ; Sat, 6 Jul 2002 14:38:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g66IUrCB029881; Sat, 6 Jul 2002 14:30:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25788; Sat, 6 Jul 2002 14:31:03 -0400 (EDT) Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25777 for ; Sat, 6 Jul 2002 14:30:54 -0400 (EDT) Received: from tele.tct.hut.fi (tele.tct.hut.fi [130.233.154.160]) by keskus.tct.hut.fi (8.10.0/8.10.0) with ESMTP id g66IUpr11170; Sat, 6 Jul 2002 21:30:51 +0300 (EET DST) From: Costa Requena To: Jonathan Rosenberg cc: , , , , , Subject: Re: [Simple] Choosing a mechanism for presence publication. In-Reply-To: <3D25E790.6090104@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 6 Jul 2002 21:30:51 +0300 (EET DST) Hi, The problem with PUBLISH is e2e congestion control and that's one of the drawbacks. Could it be listed what are the scenarios where HTTP cannot be used. I see that "draft-rosenberg-simple-data-req-00.txt" clearly set the requirements for data management and presence publishing is one clear example. Therefore, it would be wise to list pros and cons of using HTTP versus PUBLISH. BR Jose On Fri, 5 Jul 2002, Jonathan Rosenberg wrote: > > > hisham.khartabil@nokia.com wrote: > > My main concern is that if the PUBLISH gets big enough contents, the PUA > > has to POST the presence info to some HTTP server and send a PUBLISH to > > the Presence Server with content-indirection. The Presence Serve then > > has to GET using HTTP. This is like going around in a circle. Why not > > just use HTTP in the first place and avoid all this. > > Well, the indirection is needed only if you don't have e2e congestion > control. We're working on that. > > > > > BIND to the presence server can help you discover where to publish your > > presence info using HTTP. > > The problem is that the server that you need to publish to may not be > accessible directly by HTTP. COnsider the example in the draft about the > PA deep within a multi-level enterprise, or the case where the PA is a > registered PC. > > I can understand the desire for HTTP - I've been on both sides of this > fence! My current leaning is for sip publish because, practically > speaking, there were a number of cases where http didn't work. I also > think that the presence publication problem is sufficiently different > from a number of other "data publication" things we're looking at (see > http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt), > where i do believe HTTP/SOAP is better. > > -Jonathan R. > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Jul 7 19:43:46 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11994 for ; Sun, 7 Jul 2002 19:43:46 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g67Nh1CB001944; Sun, 7 Jul 2002 19:43:03 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00518; Sun, 7 Jul 2002 19:43:04 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00507 for ; Sun, 7 Jul 2002 19:42:03 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g67Ng8N16891; Sun, 7 Jul 2002 18:42:09 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Jul 2002 18:41:55 -0500 Message-ID: From: "Sriram Parameswar" To: Jonathan Rosenberg , bcampbell@dynamicsoft.com, simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2260F.DC91E8F0" Subject: [Simple] Question: draft-ietf-simple-presencelist-package-00. Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 7 Jul 2002 18:41:48 -0500 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_01C2260F.DC91E8F0 Content-Type: text/plain; charset="iso-8859-1" Jonathan/Ben: Question on the 'presencelist' draft. Section 3.5 NOTIFY bodies : "The PIDF format only supports information for a single presentity. Therefore, its usage is limited to notifications that report a change in state for a single presentity. It is mandated in order to facilitate operation of the PLS. The PLS can simply pass on any presence documents it receives from the presentities in a notification, without modification." Does this mean in a presencelist of A, B and C. If the Notify from B comes back to the PLS with a PIDF body, it is passed on unmodified? The reason I ask is that in section 4.2 (Constructing Coherent Presence State)there is extensive discussion on the use of version and state - which is available only in PLIDF. My guess is that the PLS (which sends out individual SUBSCRIBEs) has to convert from PIDF to PLIDF when receiving individual NOTIFYs spaced out in time. Section 3.5 may need some changes to clarify this. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C2260F.DC91E8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question: draft-ietf-simple-presencelist-package-00.

Jonathan/Ben:

Question on the 'presencelist' draft.

Section 3.5 NOTIFY bodies :
"The PIDF format only supports information for = a single presentity. Therefore, its usage is limited to notifications = that report a change in state for a single presentity. It is mandated = in order to facilitate operation of the PLS. The PLS can simply pass on = any presence documents it receives from the presentities in a = notification, without modification."

Does this mean in a presencelist of A, B and C. If = the Notify from B comes back to the PLS with a PIDF body, it is passed = on unmodified? The reason I ask is that in section 4.2 (Constructing = Coherent Presence State)there is extensive discussion on the use of = version and state - which is available only in PLIDF.

My guess is that the PLS (which sends out individual = SUBSCRIBEs) has to convert from PIDF to PLIDF when receiving individual = NOTIFYs spaced out in time. Section 3.5 may need some changes to = clarify this.

Thanks,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C2260F.DC91E8F0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 8 02:13:12 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04563 for ; Mon, 8 Jul 2002 02:13:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g686CuCB002669; Mon, 8 Jul 2002 02:12:56 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01618; Mon, 8 Jul 2002 02:13:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01607 for ; Mon, 8 Jul 2002 02:12:01 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g686BvYH028983; Mon, 8 Jul 2002 02:11:58 -0400 (EDT) Message-ID: <3D292D2B.6060607@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sriram Parameswar CC: bcampbell@dynamicsoft.com, simple@mailman.dynamicsoft.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Question: draft-ietf-simple-presencelist-package-00. Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 08 Jul 2002 02:11:55 -0400 Content-Transfer-Encoding: 7bit inline. Sriram Parameswar wrote: > Jonathan/Ben: > > Question on the 'presencelist' draft. > > Section 3.5 NOTIFY bodies : > "The PIDF format only supports information for a single presentity. > Therefore, its usage is limited to notifications that report a change in > state for a single presentity. It is mandated in order to facilitate > operation of the PLS. The PLS can simply pass on any presence documents > it receives from the presentities in a notification, without > modification." > > Does this mean in a presencelist of A, B and C. If the Notify from B > comes back to the PLS with a PIDF body, it is passed on unmodified? The idea was that this should be allowed, yes. > The > reason I ask is that in section 4.2 (Constructing Coherent Presence > State)there is extensive discussion on the use of version and state - > which is available only in PLIDF. True. However, the spec also talks about handlign the case of PIDF and multipart/mixed, in which case the version is "faked" to be one higher than the previous, and the state is assumed to be partial. > > My guess is that the PLS (which sends out individual SUBSCRIBEs) has to > convert from PIDF to PLIDF when receiving individual NOTIFYs spaced out > in time. Section 3.5 may need some changes to clarify this. It was my hope to avoid needless conversions of formats. Amongst other things, they will break any e2e signatures. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 8 08:43:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12312 for ; Mon, 8 Jul 2002 08:43:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g68CguO7000888; Mon, 8 Jul 2002 08:42:56 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00914; Mon, 8 Jul 2002 08:43:03 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00903 for ; Mon, 8 Jul 2002 08:42:41 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68ChBi14324 for ; Mon, 8 Jul 2002 15:43:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Jul 2002 15:42:41 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 15:42:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 15:42:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203C9@esebe019.NOE.Nokia.com> Thread-Topic: Comments on PUBLISH Thread-Index: AcImfPJ/lruOYk7DRBCJMuWKjjwJXQ== To: X-OriginalArrivalTime: 08 Jul 2002 12:42:41.0097 (UTC) FILETIME=[F2CAC390:01C2267C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA00903 Subject: [Simple] Comments on PUBLISH Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 8 Jul 2002 15:42:40 +0300 Content-Transfer-Encoding: 8bit 1. The concept of Input slots seems a bit vague. Does a slot represent entities that publish presence info of the same type, eg: geographic location? i.e. All devices that publish geographic location information fit into that slot? If so, why is a use device not a GeoLoc entity? A User device can publish geographic location information as well as the user's availability for voice and IM, for example. How do slots work in that scenario? Also, how does a Presence Compositor know which publication belongs to which slot? Perhaps I miss understood this concept completely. 2. Document assumes that all presence publication is achieved using PUBLISH. That is not true. A example, as a matter of fact, is the GeoLoc. 3. PType header: If is described as useful for 2 things: - the document that is being published is part of a larger composite document. How does PType here help? If PType is defined to be "mobile", how does that tell the compositor that it belongs to a larger composite document? I would have thought the presentity URI would be used for that purpose. - The document that is being published will be applied to many components of the composed document. Please give me an example of this. I fail to understand how this could be done. This is something for the PUBLISH body, not a SIP header. 4. PStream header: How does a header that looks like call-id guarantees correct sequencing of messages? Header like Date, and information in the message body seem like a much better way of sequencing. 5. PState Header: why is it defined that way? why not PExpires or just Expires? 6. I don't think its the PA who should decide how long a PUBLISH is valid for. How is that possible? I publish from my PC that's I'm available for IM for one hour, why would a PA override that? Regards, Hisham _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 9 15:01:54 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09939 for ; Tue, 9 Jul 2002 15:01:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g69J1NO7011568; Tue, 9 Jul 2002 15:01:23 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05896; Tue, 9 Jul 2002 15:01:12 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05885 for ; Tue, 9 Jul 2002 15:00:13 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g69Ixnr38181; Tue, 9 Jul 2002 13:59:50 -0500 (CDT) Message-ID: <3D2B3309.7050304@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sriram Parameswar CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Questions/comments on draft-olson-simple-publish-00.txt References: X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 09 Jul 2002 14:01:29 -0500 Content-Transfer-Encoding: 7bit Sriram Parameswar wrote: > Hi: > > Overall I liked the document and agree with its purpose. Just have a few > questions and comments: > > 1. The draft seems to take it for granted that the Compositor/Presence > Agent supports the PUBLISH method. Given that we already have presence > deployed - I would like to see some mechanism to (a) establish that the > compositor/presence agent supports the PUBLISH method (b) a fallback > mechanism in case it doesn't: example back to using REGISTER or other > mechanisms. The draft is only proposing a mechanism. It does not in anyway assume that other mechanisms do not exist. If the compositor supports other SIP methods, but not PUBLISH, I would think 504 responses and OPTIONS provide a sufficient mechanism to discover this. If you are asking that we mandate that all compositors support REGISTER as a fallback for backwards compatibility, then I do not agree. > > 2. I understand the motivation to limit PUBLISH to event state > publishing. However since we are taking the trouble to add a whole new > method to SIP, I would like to see you establish some extensibility > mechanisms within the method so it may be extended to publish other > things like CPL, etc. I do not buy the argument in the Abstract that > there are better mechanisms to publish things like CPL. By limiting the scope, we were not trying to say it was not possible to use it for other things. We were trying to say that we did not worry about requirements beyond those for event publishing. > > 3. In section 1.1.1 it says "Each PUA publishes a full view of presence > from its perspective--each publication carries full state, and does not > depend on previous states for the particular PUA." Why can't each PUA > publish incremental/differential presence state - after all the > compositor should have the logic to handle this. If you by incremental state, you mean a situation where the compositor cannot intepret a publication P(n) without also having received P(0) through P(n-1), then that is a much bigger problem than we were attempting to solve. > > 4. The whole motivation for slots (and future standardization of slot > names) and the use of the PTYPE header, may be solved if cpim-pidf > simply adds the RFC2778 mandated "Contact Means". I have contacted the > pidf authors on this. Is there any other need for the PTYPE header - the > Contact Means tag would carry the same meaning. We still may need the ptype to deal with situations where the compositor/PA might not otherwise interpret the payload. Even if all the info we need is in the cpim-pidf payload, other event type payloads may not have this information. > > 5. PStream tracking - the document reiterates that PUBLISH does not > establish a dialog, as dialogs create state to keep track of. Then the > discussion on REGISTER says "However, this does not guarantee that > clients will follow the rules, and thus, sequencing may be lost as a > result". If the Compositor/PA has to keep track of PStream to keep > temporal ordering - how have we reduced the state that has to be > maintained. Also if clients do not 'follow the rules' and uses different > Pstream values for PUBLISH, again sequencing is lost. I am not sure that > PStream buys us anything more than simply requiring clients to PUBLISH > using the same Call-ID. > > Regards, > > > Sriram > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 9 17:28:30 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18429 for ; Tue, 9 Jul 2002 17:28:28 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g69LRxO7012718; Tue, 9 Jul 2002 17:28:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06413; Tue, 9 Jul 2002 17:28:03 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06402 for ; Tue, 9 Jul 2002 17:27:23 -0400 (EDT) From: bindignavile.srinivas@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g69LV5j20568 for ; Tue, 9 Jul 2002 16:31:05 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 9 Jul 2002 16:27:21 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 16:27:05 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: Query about Group Creation in SIP Thread-Index: AcInjQCQYZpxd/G6QcqpWjvSd1zcgQAAkTrw To: X-OriginalArrivalTime: 09 Jul 2002 21:27:05.0982 (UTC) FILETIME=[5FBCF1E0:01C2278F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA06402 Subject: [Simple] Query about Group Creation in SIP Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 9 Jul 2002 17:27:04 -0400 Content-Transfer-Encoding: 8bit > Hi, > I was interested in finding out if there has been any work done on SIP extensions for group creation in the SIMPLE WG. I have not been able to find any drafts regarding this issue in the other SIP related WGs too! > > B. Srinivas > Senior Research Engineer > NRC Boston > Tel: (781) 993-3786 > FAX: (781) 993-1907 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 10 08:41:14 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29899 for ; Wed, 10 Jul 2002 08:41:14 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6ACf0O7015813; Wed, 10 Jul 2002 08:41:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09028; Wed, 10 Jul 2002 08:41:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09017 for ; Wed, 10 Jul 2002 08:40:35 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6ACeaYH001931; Wed, 10 Jul 2002 08:40:37 -0400 (EDT) Message-ID: <3D2C2B3F.40509@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bindignavile.srinivas@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Query about Group Creation in SIP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 10 Jul 2002 08:40:31 -0400 Content-Transfer-Encoding: 7bit We are chartered to develop requirements for such manipulation, and then develop (or more likely, choose amongst existing) a protocol to meet the requirements. A stab at such requirements document can be found at: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt -Jonathan R. bindignavile.srinivas@nokia.com wrote: >>Hi, >>I was interested in finding out if there has been any work done on SIP > > extensions for group creation in the SIMPLE WG. I have not been able to > find any drafts regarding this issue in the other SIP related WGs too! > >>B. Srinivas >>Senior Research Engineer >>NRC Boston >>Tel: (781) 993-3786 >>FAX: (781) 993-1907 >> > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 11 09:55:09 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18491 for ; Thu, 11 Jul 2002 09:55:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6BDs5O7023744; Thu, 11 Jul 2002 09:54:05 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13105; Thu, 11 Jul 2002 09:54:07 -0400 (EDT) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12115 for ; Thu, 11 Jul 2002 03:44:00 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g6B7iS924142 for ; Thu, 11 Jul 2002 09:44:28 +0200 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g6B7iRQD019210 for ; Thu, 11 Jul 2002 09:44:27 +0200 (MET DST) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <34N5YYGB>; Thu, 11 Jul 2002 09:44:25 +0200 Message-ID: From: Brazier Lachlan To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228AE.C67174E0" Subject: [Simple] SIP-specific event notification draft? Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 11 Jul 2002 09:44:23 +0200 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_01C228AE.C67174E0 Content-Type: text/plain Hello, I lost track with all the drafts and RFC's concerning SIP. I was looking for the "SIP-specific event notification" draft as mentioned in draft-ietf-simple-presence-07.txt but I couldn't find it. Is it a RFC? Which number? Sorry if I missed an anouncement somewhere. Lachlan ------_=_NextPart_001_01C228AE.C67174E0 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPlNJUC1zcGVj aWZpYyBldmVudCBub3RpZmljYXRpb24gZHJhZnQ/PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0K DQo8UD48Rk9OVCBTSVpFPTI+SGVsbG8sPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ SSBsb3N0IHRyYWNrIHdpdGggYWxsIHRoZSBkcmFmdHMgYW5kIFJGQydzIGNvbmNlcm5pbmcgU0lQ LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgd2FzIGxvb2tpbmcgZm9yIHRoZTwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZxdW90O1NJUC1zcGVjaWZpYyBldmVudCBu b3RpZmljYXRpb24mcXVvdDsgZHJhZnQgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ YXMgbWVudGlvbmVkIGluPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ZHJhZnQtaWV0 Zi1zaW1wbGUtcHJlc2VuY2UtMDcudHh0PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ YnV0Jm5ic3A7IEkgY291bGRuJ3QgZmluZCBpdC4gSXMgaXQgYSBSRkM/IFdoaWNoIG51bWJlcj88 L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Tb3JyeSBpZiBJIG1pc3NlZCBhbiBhbm91 bmNlbWVudCBzb21ld2hlcmUuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+TGFjaGxh bjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C228AE.C67174E0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 11 10:00:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18586 for ; Thu, 11 Jul 2002 10:00:28 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6BDxqO7023803; Thu, 11 Jul 2002 09:59:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13154; Thu, 11 Jul 2002 10:00:03 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13139 for ; Thu, 11 Jul 2002 09:59:18 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BDxSs05882; Thu, 11 Jul 2002 08:59:28 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 08:59:14 -0500 Message-ID: From: "Sriram Parameswar" To: "'Brazier Lachlan'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIP-specific event notification draft? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228E3.23605C00" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 11 Jul 2002 08:59:13 -0500 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_01C228E3.23605C00 Content-Type: text/plain; charset="iso-8859-1" RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification Enjoy Sriram -----Original Message----- From: Brazier Lachlan [mailto:lachlan.brazier@siemens.com] Sent: Thursday, July 11, 2002 2:44 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] SIP-specific event notification draft? Hello, I lost track with all the drafts and RFC's concerning SIP. I was looking for the "SIP-specific event notification" draft as mentioned in draft-ietf-simple-presence-07.txt but I couldn't find it. Is it a RFC? Which number? Sorry if I missed an anouncement somewhere. Lachlan ------_=_NextPart_001_01C228E3.23605C00 Content-Type: text/html; charset="iso-8859-1" SIP-specific event notification draft?

RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification

 

Enjoy

 

Sriram

-----Original Message-----
From: Brazier Lachlan [mailto:lachlan.brazier@siemens.com]
Sent: Thursday, July 11, 2002 2:44 AM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] SIP-specific event notification draft?

Hello,

I lost track with all the drafts and RFC's concerning SIP.

I was looking for the

"SIP-specific event notification" draft

as mentioned in

draft-ietf-simple-presence-07.txt

but  I couldn't find it. Is it a RFC? Which number?

Sorry if I missed an anouncement somewhere.

Lachlan

------_=_NextPart_001_01C228E3.23605C00-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 12 05:16:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12995 for ; Fri, 12 Jul 2002 05:16:01 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6C9CvO7027897; Fri, 12 Jul 2002 05:13:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16409; Fri, 12 Jul 2002 05:13:03 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16398 for ; Fri, 12 Jul 2002 05:12:47 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA28531 for ; Fri, 12 Jul 2002 11:12:30 +0200 (MET DST) Received: from icn.siemens.de ([139.21.148.41]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA09000 for ; Fri, 12 Jul 2002 11:12:45 +0200 (MET DST) Message-ID: <3D2E9D8D.6040509@icn.siemens.de> From: Peter =?ISO-8859-1?Q?P=E4ppinghaus?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Simple] Message session & associated dialog Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 12 Jul 2002 11:12:45 +0200 Content-Transfer-Encoding: 8bit Hi, so far I have not been following the discussions about message sessions, so maybe I am cooking up something that was discussed already. Message sessions are somewhat hybrid in nature: on the one hand they are not part of the dialog that initiated the message session, on the other hand they are associated with this dialog. I think it would be helpful if this association relation is reflected somehow in the MESSAGE requests sent in a message session. draft-rosenberg-simple-message-session-00 is silent about construction of Call-ID and From and To header tags in the MESSAGE requests sent within a message session. Following RFC 3261 the MESSAGE requests should receive Call-IDs different from the Call-ID of the associated dialog. This is necessary in order not to mess up the CSeq numbering. But it seems reasonable to me that they would share the From and To tag values with the From and To tag values of the associated dialog. If one would introduce a new informational header, say "Assoc-Call-ID" carrying the value of the Call-ID of the associated dialog, then it would be possible to reconstruct the dialog ID of the associated dialog from the MESSAGE requests in the message session. I think this would be very useful. -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1702 / Room 530 D - 81359 München | Email: peter.paeppinghaus@icn.siemens.de _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Jul 13 09:23:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23298 for ; Sat, 13 Jul 2002 09:23:29 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6DDN4O7002163; Sat, 13 Jul 2002 09:23:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21033; Sat, 13 Jul 2002 09:23:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21022 for ; Sat, 13 Jul 2002 09:22:43 -0400 (EDT) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6DDMeYH005420; Sat, 13 Jul 2002 09:22:41 -0400 (EDT) Message-ID: <3D302998.3050004@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Peter_P=E4ppinghaus?= CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 13 Jul 2002 09:22:32 -0400 Content-Transfer-Encoding: 8bit inline. Peter Päppinghaus wrote: > Hi, > > so far I have not been following the discussions about message sessions, > > so maybe I am cooking up something that was discussed already. > > Message sessions are somewhat hybrid in nature: on the one hand they are > > not part of the dialog that initiated the message session, on the other > hand they are associated with this dialog. I think it would be helpful > if this association relation is reflected somehow in the MESSAGE > requests sent in a message session. Well, they are associated just like an RTP stream is associated with the dialog that sets it up. In the case of RTP, the association occurs through the port numbers handed out in the SDP. For MESSAGE, the idea is that its the request URI. So, in an INVITE, the sdp would be like: c=IN IP4 host.example.com t=0 0 m=message 54344 SIP a=user:ahss7aa9 which would result in receiving IMs that look like, in part: MESSAGE sip:ahss7aa9@host.example.com SIP/2.0 the request URI is used for the demux, as a result. > > draft-rosenberg-simple-message-session-00 is silent about construction > of Call-ID and From and To header tags in the MESSAGE requests sent > within a message session. Well, the draft was just a proposal. I guess the messages would all use the same dialog ID, with increasing CSeq within the dialog. Different dialog ID than the INVITE one, of course. > > Following RFC 3261 the MESSAGE requests should receive Call-IDs > different from the Call-ID of the associated dialog. This is necessary > in order not to mess up the CSeq numbering. Right. > But it seems reasonable to me that they would share the From and To tag > values with the From and To tag values of the associated dialog. I don't see any need for that; see above. > > If one would introduce a new informational header, say "Assoc-Call-ID" > carrying the value of the Call-ID of the associated dialog, then it > would be possible to reconstruct the dialog ID of the associated dialog > from the MESSAGE requests in the message session. I think this would be > very useful. > Why? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 15 09:30:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03877 for ; Mon, 15 Jul 2002 09:30:49 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6FDS2wa000907; Mon, 15 Jul 2002 09:28:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01078; Mon, 15 Jul 2002 09:28:09 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01067 for ; Mon, 15 Jul 2002 09:27:17 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6FDRgDQ017744; Mon, 15 Jul 2002 09:27:42 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN27112; Mon, 15 Jul 2002 09:31:49 -0400 (EDT) Message-ID: <3D32CDAB.51210C4E@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Peter =?iso-8859-1?Q?P=E4ppinghaus?= , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 15 Jul 2002 09:27:07 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > draft-rosenberg-simple-message-session-00 is silent about construction > > of Call-ID and From and To header tags in the MESSAGE requests sent > > within a message session. > > Well, the draft was just a proposal. > > I guess the messages would all use the same dialog ID, with increasing > CSeq within the dialog. Different dialog ID than the INVITE one, of course. It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established? There are currently two ways of establishing a dialog: - the 2xx reply to an INVITE can establish one - the 2xx reply to a SUBSCRIBE can establish one In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request to establish a dialog. Some possibilities: - send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog. - permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control constraints haven't been met.) Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the distinction between page and session mode messaging. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 15 20:38:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21367 for ; Mon, 15 Jul 2002 20:38:56 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6G0brwa003613; Mon, 15 Jul 2002 20:37:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02958; Mon, 15 Jul 2002 20:38:03 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02947 for ; Mon, 15 Jul 2002 20:37:09 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6G0athZ010017; Mon, 15 Jul 2002 19:36:56 -0500 (CDT) Message-ID: <3D336AA6.6050202@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , =?ISO-8859-1?Q?Peter_?= =?ISO-8859-1?Q?P=E4ppinghaus?= , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 15 Jul 2002 19:36:54 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Jonathan Rosenberg wrote: > >>>draft-rosenberg-simple-message-session-00 is silent about construction >>>of Call-ID and From and To header tags in the MESSAGE requests sent >>>within a message session. >> >>Well, the draft was just a proposal. >> >>I guess the messages would all use the same dialog ID, with increasing >>CSeq within the dialog. Different dialog ID than the INVITE one, of course. > > > It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established? > > There are currently two ways of establishing a dialog: > > - the 2xx reply to an INVITE can establish one > > - the 2xx reply to a SUBSCRIBE can establish one > > In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request > to establish a dialog. Some possibilities: > > - send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog. > > - permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control > constraints haven't been met.) > > Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the > distinction between page and session mode messaging. > That blurring concerns me a lot. A method where a successful request sometimes creates a dialog, and sometimes does not, is problematic. In particular, letting the recipient select whether a session is created may ignore the wishes of the sender. In particular, I can imagine a client might exist that supports page mode, but not session mode. If I send you a MESSAGE request with such a client, and you add a contact header to your response with the assumption that it will create a dialog, what happens? You think we are in a dialog, but I think we are not. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 15 21:22:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22812 for ; Mon, 15 Jul 2002 21:22:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6G1Lrwa003780; Mon, 15 Jul 2002 21:21:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03144; Mon, 15 Jul 2002 21:22:02 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03133 for ; Mon, 15 Jul 2002 21:21:22 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6G1Lm72002707; Mon, 15 Jul 2002 21:21:48 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN32098; Mon, 15 Jul 2002 21:25:55 -0400 (EDT) Message-ID: <3D33750A.85F8BFD2@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Jonathan Rosenberg , "Peter =?iso-8859-1?Q?P=E4ppinghaus?=" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 15 Jul 2002 21:21:14 -0400 Content-Transfer-Encoding: 7bit Ben - I agree with you. But I can't tell if you: - believe jonathan's proposal already implies use of invite to establish the dialog - think invite ought to be used - have some other way in mind to set up the dialog Paul Ben Campbell wrote: > > Paul Kyzivat wrote: > > Jonathan Rosenberg wrote: > > > >>>draft-rosenberg-simple-message-session-00 is silent about construction > >>>of Call-ID and From and To header tags in the MESSAGE requests sent > >>>within a message session. > >> > >>Well, the draft was just a proposal. > >> > >>I guess the messages would all use the same dialog ID, with increasing > >>CSeq within the dialog. Different dialog ID than the INVITE one, of course. > > > > > > It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established? > > > > There are currently two ways of establishing a dialog: > > > > - the 2xx reply to an INVITE can establish one > > > > - the 2xx reply to a SUBSCRIBE can establish one > > > > In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request > > to establish a dialog. Some possibilities: > > > > - send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog. > > > > - permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control > > constraints haven't been met.) > > > > Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the > > distinction between page and session mode messaging. > > > > That blurring concerns me a lot. A method where a successful request > sometimes creates a dialog, and sometimes does not, is problematic. In > particular, letting the recipient select whether a session is created > may ignore the wishes of the sender. > > In particular, I can imagine a client might exist that supports page > mode, but not session mode. If I send you a MESSAGE request with such a > client, and you add a contact header to your response with the > assumption that it will create a dialog, what happens? You think we are > in a dialog, but I think we are not. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 15 21:57:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24117 for ; Mon, 15 Jul 2002 21:57:21 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6G1uswa003922; Mon, 15 Jul 2002 21:56:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03326; Mon, 15 Jul 2002 21:57:03 -0400 (EDT) Received: from nt1 ([207.224.78.58]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id VAA03315 for ; Mon, 15 Jul 2002 21:56:24 -0400 (EDT) Received: from growler (207.224.78.57) by NT1 (MailMax 4. 7. 0. 9) with ESMTP id 39060332 for simple@mailman.dynamicsoft.com; Mon, 15 Jul 2002 21:45:06 -0400 EDT Reply-To: From: "Andrew" To: Message-ID: <005801c22c6c$49f35890$d402a8c0@hq.tti.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Simple] Working message dumps for MS Messenger ... Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 15 Jul 2002 21:58:31 -0400 Content-Transfer-Encoding: 7bit Presently trying to get my presence/proxy server running with MS Messenger. Sort of a pain without any docs from MS but progress is being made. I've seen the dumps from Columbia and have gone over them with them, but am still a little confused. Can someone supply some message dumps between two end users on different machines with a proxy/presence server on yet another machine? Specifically I'd love to see: END USER A --------- SUB TO END USER B------- > Proxy/Presence END USER A <-------- SUB 200 OK ---------------------- Proxy/Presence END USER A <--------- NOTIFY ----------------------------- Proxy/Presence Any help and suggestions would be great. Thanks, Andrew _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 00:49:02 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28753 for ; Tue, 16 Jul 2002 00:49:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6G4lrwa004281; Tue, 16 Jul 2002 00:47:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03835; Tue, 16 Jul 2002 00:48:03 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03824 for ; Tue, 16 Jul 2002 00:47:09 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6G4lei01185 for ; Tue, 16 Jul 2002 07:47:40 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Jul 2002 07:47:08 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 16 Jul 2002 07:47:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message session & associated dialog Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED7A@esebe013.NOE.Nokia.com> Thread-Topic: [Simple] Message session & associated dialog Thread-Index: AcIsA9wmDgQFIBJYRy+HsoQlHy+nuwAfcS+w To: , Cc: , X-OriginalArrivalTime: 16 Jul 2002 04:47:08.0048 (UTC) FILETIME=[D7130100:01C22C83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id AAA03824 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 07:47:33 +0300 Content-Transfer-Encoding: 8bit Hi All, I don't understand why you would need to have a dialog for the one-shot message. I think it has been already explained in both sip-message and message-session why such a thing is not a good idea. However, if something more concrete than the "imaginary" dialog is needed, then MESSAGE as media in an INVITEd session is the way to do it. This is what I thought Jonathan was also referring to in his mail, i.e., what Call-ID is used in MESSAGEs within the session media and so on. Having MESSAGE set up a dialog (for example) may sound reasonable, but when would such a dialog end? Would I have to remember this dialog indefinitely, just in case someone replies to it? Using a "dummy" INVITE is also problematic. Not only does it blur the paging mode and the session mode, but also, what happens if the other end rejects? How would a user determine whether to accept or reject a "medialess" INVITE? Cheers, Aki > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, July 15, 2002 4:27 PM > To: Jonathan Rosenberg > Cc: Peter Päppinghaus; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Message session & associated dialog > > > Jonathan Rosenberg wrote: > > > > > draft-rosenberg-simple-message-session-00 is silent about > construction > > > of Call-ID and From and To header tags in the MESSAGE > requests sent > > > within a message session. > > > > Well, the draft was just a proposal. > > > > I guess the messages would all use the same dialog ID, with > increasing > > CSeq within the dialog. Different dialog ID than the INVITE > one, of course. > > It makes sense that all the messages share a dialog. The > question is: what causes this dialog to be established? > > There are currently two ways of establishing a dialog: > > - the 2xx reply to an INVITE can establish one > > - the 2xx reply to a SUBSCRIBE can establish one > > In the case we are discussing, MESSAGE requests are the only > thing being sent along the path where we want a dialog. But > we don't want the response to every MESSAGE request > to establish a dialog. Some possibilities: > > - send a medialess INVITE to establish a dialog, and then > send the MESSAGEs within that dialog. > > - permit the recipient of a MESSAGE to decide contextually > whether to establish a dialog. (Would require some rules to > prevent doing so when all the flow control > constraints haven't been met.) > > Sending another INVITE is straightforward, but seems a bit > circuitous and wasteful of round trips. But using the MESSAGE > to do this may lead to a blurring of the > distinction between page and session mode messaging. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 02:00:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01842 for ; Tue, 16 Jul 2002 02:00:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6G60Cwa004504; Tue, 16 Jul 2002 02:00:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04083; Tue, 16 Jul 2002 01:59:04 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04072 for ; Tue, 16 Jul 2002 01:58:13 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6G5vohZ032772; Tue, 16 Jul 2002 00:57:51 -0500 (CDT) Message-ID: <3D33B5D9.8010907@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , =?ISO-8859-1?Q?Peter_?= =?ISO-8859-1?Q?P=E4ppinghaus?= , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 00:57:45 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Ben - I agree with you. But I can't tell if you: > > - believe jonathan's proposal already implies > use of invite to establish the dialog > > - think invite ought to be used > > - have some other way in mind to set up the dialog > > Paul > If by Jonathan's proposal you mean draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE. > Ben Campbell wrote: > >>Paul Kyzivat wrote: >> >>>Jonathan Rosenberg wrote: >>> >>> >>>>>draft-rosenberg-simple-message-session-00 is silent about construction >>>>>of Call-ID and From and To header tags in the MESSAGE requests sent >>>>>within a message session. >>>> >>>>Well, the draft was just a proposal. >>>> >>>>I guess the messages would all use the same dialog ID, with increasing >>>>CSeq within the dialog. Different dialog ID than the INVITE one, of course. >>> >>> >>>It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established? >>> >>>There are currently two ways of establishing a dialog: >>> >>>- the 2xx reply to an INVITE can establish one >>> >>>- the 2xx reply to a SUBSCRIBE can establish one >>> >>>In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request >>>to establish a dialog. Some possibilities: >>> >>>- send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog. >>> >>>- permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control >>>constraints haven't been met.) >>> >>>Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the >>>distinction between page and session mode messaging. >>> >> >>That blurring concerns me a lot. A method where a successful request >>sometimes creates a dialog, and sometimes does not, is problematic. In >>particular, letting the recipient select whether a session is created >>may ignore the wishes of the sender. >> >>In particular, I can imagine a client might exist that supports page >>mode, but not session mode. If I send you a MESSAGE request with such a >>client, and you add a contact header to your response with the >>assumption that it will create a dialog, what happens? You think we are >>in a dialog, but I think we are not. > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 03:36:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12671 for ; Tue, 16 Jul 2002 03:36:36 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6G7aDwa004803; Tue, 16 Jul 2002 03:36:13 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04413; Tue, 16 Jul 2002 03:35:04 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04400 for ; Tue, 16 Jul 2002 03:34:43 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6G7ZGi00602 for ; Tue, 16 Jul 2002 10:35:16 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Jul 2002 10:34:40 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 16 Jul 2002 10:34:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Questions/comments on draft-olson-simple-publish-00.txt Message-ID: Thread-Topic: [Simple] Questions/comments on draft-olson-simple-publish-00.txt Thread-Index: AcIne4mSbBl6E1U2TzCtI5xdDFZ4JgFFELHA To: , Cc: X-OriginalArrivalTime: 16 Jul 2002 07:34:39.0834 (UTC) FILETIME=[3E67D3A0:01C22C9B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA04400 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 10:34:39 +0300 Content-Transfer-Encoding: 8bit Hi, Ben Campbell wrote: > > 3. In section 1.1.1 it says "Each PUA publishes a full view > of presence > > from its perspective--each publication carries full state, > and does not > > depend on previous states for the particular PUA." Why > can't each PUA > > publish incremental/differential presence state - after all the > > compositor should have the logic to handle this. > > If you by incremental state, you mean a situation where the > compositor > cannot intepret a publication P(n) without also having received P(0) > through P(n-1), then that is a much bigger problem than we were > attempting to solve. I think there should be a way to publish only limited changes to the composite presence state. If a user has a single device from which he publishes the presence state, it does not make sense to allways send the full document/state when some small bit changes. Talking about CPIM, I think it should be possible to publish changes in each tuple separately, without the need to always send all of them. I don't think "diff" type of deltas are needed, but there should be some kind of granularity. (Actually, the same should apply to SUB/NOT too.) From the PUBLISH draft I understood that the "slot" model and PType header could somehow accomplish this. However, it is assumed that this happens between multiple physical devices. In my opinion a single device should be able to partition the presence state as well, which seems to require multiple PUAs per device? Markus > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 09 July, 2002 22:01 > To: Sriram Parameswar > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Questions/comments on > draft-olson-simple-publish-00.txt > > > Sriram Parameswar wrote: > > Hi: > > > > Overall I liked the document and agree with its purpose. > Just have a few > > questions and comments: > > > > 1. The draft seems to take it for granted that the > Compositor/Presence > > Agent supports the PUBLISH method. Given that we already > have presence > > deployed - I would like to see some mechanism to (a) > establish that the > > compositor/presence agent supports the PUBLISH method (b) a > fallback > > mechanism in case it doesn't: example back to using > REGISTER or other > > mechanisms. > > The draft is only proposing a mechanism. It does not in anyway assume > that other mechanisms do not exist. If the compositor > supports other SIP > methods, but not PUBLISH, I would think 504 responses and OPTIONS > provide a sufficient mechanism to discover this. > > If you are asking that we mandate that all compositors > support REGISTER > as a fallback for backwards compatibility, then I do not agree. > > > > > 2. I understand the motivation to limit PUBLISH to event state > > publishing. However since we are taking the trouble to add > a whole new > > method to SIP, I would like to see you establish some extensibility > > mechanisms within the method so it may be extended to publish other > > things like CPL, etc. I do not buy the argument in the > Abstract that > > there are better mechanisms to publish things like CPL. > > By limiting the scope, we were not trying to say it was not > possible to > use it for other things. We were trying to say that we did not worry > about requirements beyond those for event publishing. > > > > > 3. In section 1.1.1 it says "Each PUA publishes a full view > of presence > > from its perspective--each publication carries full state, > and does not > > depend on previous states for the particular PUA." Why > can't each PUA > > publish incremental/differential presence state - after all the > > compositor should have the logic to handle this. > > If you by incremental state, you mean a situation where the > compositor > cannot intepret a publication P(n) without also having received P(0) > through P(n-1), then that is a much bigger problem than we were > attempting to solve. > > > > > 4. The whole motivation for slots (and future > standardization of slot > > names) and the use of the PTYPE header, may be solved if cpim-pidf > > simply adds the RFC2778 mandated "Contact Means". I have > contacted the > > pidf authors on this. Is there any other need for the PTYPE > header - the > > Contact Means tag would carry the same meaning. > > We still may need the ptype to deal with situations where the > compositor/PA might not otherwise interpret the payload. Even > if all the > info we need is in the cpim-pidf payload, other event type > payloads may > not have this information. > > > > > 5. PStream tracking - the document reiterates that PUBLISH does not > > establish a dialog, as dialogs create state to keep track > of. Then the > > discussion on REGISTER says "However, this does not guarantee that > > clients will follow the rules, and thus, sequencing may be > lost as a > > result". If the Compositor/PA has to keep track of PStream to keep > > temporal ordering - how have we reduced the state that has to be > > maintained. Also if clients do not 'follow the rules' and > uses different > > Pstream values for PUBLISH, again sequencing is lost. I am > not sure that > > PStream buys us anything more than simply requiring clients > to PUBLISH > > using the same Call-ID. > > > > Regards, > > > > > > Sriram > > __________________________________________ > > Sriram Parameswar Phone: 972-685-8540 > > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 04:03:19 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13232 for ; Tue, 16 Jul 2002 04:03:19 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6G83Awa004912; Tue, 16 Jul 2002 04:03:10 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04552; Tue, 16 Jul 2002 04:02:04 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04541 for ; Tue, 16 Jul 2002 04:01:37 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6G81ZhZ040653; Tue, 16 Jul 2002 03:01:36 -0500 (CDT) Message-ID: <3D33D2D8.9080508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: sriramp@nortelnetworks.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Questions/comments on draft-olson-simple-publish-00.txt References: X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 03:01:28 -0500 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > Ben Campbell wrote: > >>>3. In section 1.1.1 it says "Each PUA publishes a full view >> >>of presence >> >>>from its perspective--each publication carries full state, >> >>and does not >> >>>depend on previous states for the particular PUA." Why >> >>can't each PUA >> >>>publish incremental/differential presence state - after all the >>>compositor should have the logic to handle this. >> >>If you by incremental state, you mean a situation where the >>compositor >>cannot intepret a publication P(n) without also having received P(0) >>through P(n-1), then that is a much bigger problem than we were >>attempting to solve. > > > I think there should be a way to publish only limited changes to the composite presence state. If a user has a single device from which he publishes the presence state, it does not make sense to allways send the full document/state when some small bit changes. Talking about CPIM, I think it should be possible to publish changes in each tuple separately, without the need to always send all of them. I don't think "diff" type of deltas are needed, but there should be some kind of granularity. (Actually, the same should apply to SUB/NOT too.) > > From the PUBLISH draft I understood that the "slot" model and PType header could somehow accomplish this. However, it is assumed that this happens between multiple physical devices. In my opinion a single device should be able to partition the presence state as well, which seems to require multiple PUAs per device? The model in the publish draft is entirely a logical model. There is no reason at all why a single physical device could not publish to multiple slots. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 08:40:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18506 for ; Tue, 16 Jul 2002 08:40:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GCdqwa005625; Tue, 16 Jul 2002 08:39:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05395; Tue, 16 Jul 2002 08:40:04 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05382 for ; Tue, 16 Jul 2002 08:39:17 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6GCdGY12629; Tue, 16 Jul 2002 08:39:16 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id HAA21248; Tue, 16 Jul 2002 07:39:14 -0500 (CDT) Message-ID: <3D3413F0.8000804@lucent.com> From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bcampbell@dynamicsoft.com CC: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] -05 MESSAGE and Expires header Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 07:39:12 -0500 Content-Transfer-Encoding: 7bit Ben: Any reasons why -05 MESSAGE I-D overloads "Expires: 0" to mean immediate attention. Maybe we can use "Priority: Urgent" instead; since the Priority header is defined in 3261 and "may be factored into decisions about call routing and acceptance". I think that overloading the Expires header here is confusing; 3261's use of "Expires: 0" in conjunction with REGISTER means something entirely different -- that this registration is invalid. From a semantic point of view, "Expires: 0" with REGISTER to mean deregistration appears to make sense; but "Expires: 0" with MESSAGE to mean immediate delivery appears incongrous. If it is not too late, maybe you can consider using the Priority header. I won't be able to make it to simple WG meeting tomorrow, so I just wanted to bring this to you attention. Thanks, - vijay _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 08:55:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18777 for ; Tue, 16 Jul 2002 08:55:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GCspwa005753; Tue, 16 Jul 2002 08:54:51 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05502; Tue, 16 Jul 2002 08:55:04 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05489 for ; Tue, 16 Jul 2002 08:54:09 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA27261; Tue, 16 Jul 2002 14:54:07 +0200 (MET DST) Received: from mchh169e.mch4.siemens.de ([139.21.130.176]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA02166; Tue, 16 Jul 2002 14:54:08 +0200 (MET DST) Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Jul 2002 14:54:09 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Vijay K. Gurbani'" , bcampbell@dynamicsoft.com Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] -05 MESSAGE and Expires header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 14:54:02 +0200 Vijay, It is stated in RFC 3261 section 20.19 Expires that : "The precise meaning of this (header) is method dependant". The use of the Expires header in MESSAGE is as it is defined in -05. It has only one meaning, so there is no overloading. Regards, Ya-Ching _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 09:05:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18940 for ; Tue, 16 Jul 2002 09:05:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GD4rwa005864; Tue, 16 Jul 2002 09:04:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05584; Tue, 16 Jul 2002 09:05:04 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05571 for ; Tue, 16 Jul 2002 09:04:34 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6GD4XY28571; Tue, 16 Jul 2002 09:04:33 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA29151; Tue, 16 Jul 2002 08:04:31 -0500 (CDT) Message-ID: <3D3419CF.4010905@lucent.com> From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: bcampbell@dynamicsoft.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 08:04:15 -0500 Content-Transfer-Encoding: 7bit Tan Ya-Ching ICM N PG U ID A 1 wrote: > Vijay, > > It is stated in RFC 3261 section 20.19 Expires that : > "The precise meaning of this (header) is method dependant". Agreed. > The use of the Expires header in MESSAGE is as it is defined in -05. It has > only one meaning, so there is no overloading. That is debatable; good thing about ASCII protocols is that they are self describing. Thus, having a "Priority: Urgent" is far more preferable to overloading "Expires: 0" to mean immediate handling. "Priority: Urgent" in this case makes it far more easy to figure out what is going on. - vijay _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 09:27:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19237 for ; Tue, 16 Jul 2002 09:27:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GDQnwa006053; Tue, 16 Jul 2002 09:26:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05748; Tue, 16 Jul 2002 09:27:03 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05737 for ; Tue, 16 Jul 2002 09:26:17 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6GDQ8hZ062203; Tue, 16 Jul 2002 08:26:09 -0500 (CDT) Message-ID: <3D341EE8.2050800@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 08:26:00 -0500 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> Vijay, >> >> It is stated in RFC 3261 section 20.19 Expires that : >> "The precise meaning of this (header) is method dependant". > > > Agreed. > >> The use of the Expires header in MESSAGE is as it is defined in -05. >> It has >> only one meaning, so there is no overloading. > > > That is debatable; good thing about ASCII protocols is that they are > self describing. Thus, having a "Priority: Urgent" is far more > preferable to overloading "Expires: 0" to mean immediate handling. > "Priority: Urgent" in this case makes it far more easy to figure > out what is going on. > > - vijay > > > > I do not have strong feelings on this one way or another--either approach works for me. I will bow to the will of the majority. Anyone else have comments? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 10:19:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20205 for ; Tue, 16 Jul 2002 10:19:21 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GEJ5wa006338; Tue, 16 Jul 2002 10:19:05 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05962; Tue, 16 Jul 2002 10:19:07 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05951 for ; Tue, 16 Jul 2002 10:18:47 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GEJ9Na014298; Tue, 16 Jul 2002 10:19:10 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN34690; Tue, 16 Jul 2002 10:23:16 -0400 (EDT) Message-ID: <3D342B3B.E093356C@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Jonathan Rosenberg , "Peter =?iso-8859-1?Q?P=E4ppinghaus?=" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 10:18:35 -0400 Content-Transfer-Encoding: 8bit below... Ben Campbell wrote: > > Paul Kyzivat wrote: > > Ben - I agree with you. But I can't tell if you: > > > > - believe jonathan's proposal already implies > > use of invite to establish the dialog > > > > - think invite ought to be used > > > > - have some other way in mind to set up the dialog > > > > Paul > > > > If by Jonathan's proposal you mean > draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE. Yes, that is the one. I guess I wasn't clear about my concern. Here is the call flow from draft-rosenberg-simple-message-session-00: Caller Proxy Relay Callee |(1) INVITE | | | |m=54344 | | | |c=1.2.3.4 | | | |------------------>|(2) INVITE | | | |m=54344 | | | |c=1.2.3.4 | | | |hop=sip:relay | | | |-------------------------------------->| | |(3) 200 OK | | | |m=44345 | | | |c=4.3.2.1 | | |(4) 200 OK |<--------------------------------------| |m=44345 | | | |c=4.3.2.1 | | | |hop=sip:relay | | | |<------------------| | | |(5) ACK | | | |---------------------------------------------------------->| | | |(6) MESSAGE | | | |ruri=1.2.3.4:54344 | | | |Route=sip:relay | | | |<------------------| |(7) MESSAGE | | | |ruri=1.2.3.4:54344 | | | |<--------------------------------------| | |(8) 200 OK | | | |-------------------------------------->| | | | |(9) 200 OK | | | |------------------>| |(10) MESSAGE | | | |ruri=4.3.2.1:44345 | | | |Route=sip:relay | | | |-------------------------------------->| | | | |(11) MESSAGE | | | |ruri=4.3.2.1:44345 | | | |------------------>| | | |(12) 200 OK | | | |<------------------| |(13) 200 OK | | | |<--------------------------------------| | |(14) BYE | | | |---------------------------------------------------------->| |(15) 200 OK | | | |<----------------------------------------------------------| This shows the MESSAGEs that are not part of any dialog. Then, earlier in this thread: Jonathan Rosenberg wrote: > > Peter Päppinghaus wrote: > > draft-rosenberg-simple-message-session-00 is silent about construction > > of Call-ID and From and To header tags in the MESSAGE requests sent > > within a message session. > > Well, the draft was just a proposal. > > I guess the messages would all use the same dialog ID, with increasing > CSeq within the dialog. Different dialog ID than the INVITE one, of course. This last sentence is what started this discussion. If the messages are to use the same dialog ID, and it is a different dialog ID than the INVITE, then where does this other dialog come from? In the above flow, it would have to be implicit in the first MESSAGE (6), which seems wrong. Another possibility (but also dubious) would be to generate a new INVITE between (5) and (6), from caller to callee, using the route header that involves the relay. This would be a media-less invite with the sole purpose of establishing a dialog. Then, the messages could be sent within the context of this dialog. The simplest answer here is just to say that the messages don't share a dialog. Or, it could be considered like REGISTER, where register refreshes SHOULD be sent using the same callid yet there is no dialog. Session oriented messages could also be sent using the same callid without any implication that this is a dialog. (But I don't like this much either.) Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 11:07:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21316 for ; Tue, 16 Jul 2002 11:07:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GF6nwa006591; Tue, 16 Jul 2002 11:06:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06177; Tue, 16 Jul 2002 11:07:03 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06166 for ; Tue, 16 Jul 2002 11:06:38 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA18337; Tue, 16 Jul 2002 17:06:20 +0200 (MET DST) Received: from icn.siemens.de ([139.21.148.41]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06924; Tue, 16 Jul 2002 17:06:37 +0200 (MET DST) Message-ID: <3D34367D.4070008@icn.siemens.de> From: Peter =?ISO-8859-1?Q?P=E4ppinghaus?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: Paul Kyzivat CC: Ben Campbell , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 17:06:37 +0200 Content-Transfer-Encoding: 8bit Comments inline. Paul Kyzivat wrote: > below... > > Ben Campbell wrote: > >>Paul Kyzivat wrote: >> >>>Ben - I agree with you. But I can't tell if you: >>> >>>- believe jonathan's proposal already implies >>> use of invite to establish the dialog >>> >>>- think invite ought to be used >>> >>>- have some other way in mind to set up the dialog >>> >>> Paul >>> >>> >>If by Jonathan's proposal you mean >>draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE. >> > > Yes, that is the one. I guess I wasn't clear about my concern. Here is the call flow from draft-rosenberg-simple-message-session-00: > > Caller Proxy Relay Callee > |(1) INVITE | | | > |m=54344 | | | > |c=1.2.3.4 | | | > |------------------>|(2) INVITE | | > | |m=54344 | | > | |c=1.2.3.4 | | > | |hop=sip:relay | | > | |-------------------------------------->| > | |(3) 200 OK | | > | |m=44345 | | > | |c=4.3.2.1 | | > |(4) 200 OK |<--------------------------------------| > |m=44345 | | | > |c=4.3.2.1 | | | > |hop=sip:relay | | | > |<------------------| | | > |(5) ACK | | | > |---------------------------------------------------------->| > | | |(6) MESSAGE | > | | |ruri=1.2.3.4:54344 | > | | |Route=sip:relay | > | | |<------------------| > |(7) MESSAGE | | | > |ruri=1.2.3.4:54344 | | | > |<--------------------------------------| | > |(8) 200 OK | | | > |-------------------------------------->| | > | | |(9) 200 OK | > | | |------------------>| > |(10) MESSAGE | | | > |ruri=4.3.2.1:44345 | | | > |Route=sip:relay | | | > |-------------------------------------->| | > | | |(11) MESSAGE | > | | |ruri=4.3.2.1:44345 | > | | |------------------>| > | | |(12) 200 OK | > | | |<------------------| > |(13) 200 OK | | | > |<--------------------------------------| | > |(14) BYE | | | > |---------------------------------------------------------->| > |(15) 200 OK | | | > |<----------------------------------------------------------| > > This shows the MESSAGEs that are not part of any dialog. > > Then, earlier in this thread: > > Jonathan Rosenberg wrote: > >>Peter Päppinghaus wrote: >> >>>draft-rosenberg-simple-message-session-00 is silent about construction >>>of Call-ID and From and To header tags in the MESSAGE requests sent >>>within a message session. >>> >>Well, the draft was just a proposal. >> >>I guess the messages would all use the same dialog ID, with increasing >>CSeq within the dialog. Different dialog ID than the INVITE one, of course. >> > > This last sentence is what started this discussion. If the messages are to use the same dialog ID, and it is a different dialog ID than the INVITE, then where does this > other dialog come from? What starts the topic - in my opinion - is simply the observation that the messages within a message session are intended to be threaded together, and this should be reflected SOMEHOW. For example, there should be a means to guarantee correct sequencing. Unless one thinks about a completely different approach to this - like e.g. the one in draft-olson-simple-publish-00 - the most natural approach seems to be to let the messages of a message session be threaded together by sharing their From tag, To tag and Call-ID values, und use CSeq numbering for sequencing. Since RFC 3261 leaves room for SIP extensions to "define other means for creating dialogs", why not stipulate the following: when a response to an INVITE creates a message session, it creates at the same time (beyond the signaling dialog) a second dialog, namely a media-dialog? The route of this media-dialog is based on information contained in the SDP of the signaling dialog. In the same manner a dialog ID for this media-dialog could also be negotiated in the SDP of the signaling dialog. Termination of the signaling dialog should imply termination of its associated media-dialog. (As far as I understand, RFC 3261 also leaves room for that.) > In the above flow, it would have to be implicit in the first MESSAGE (6), which seems wrong. > > Another possibility (but also dubious) would be to generate a new INVITE between (5) and (6), from caller to callee, using the route header that involves the relay. This > would be a media-less invite with the sole purpose of establishing a dialog. Then, the messages could be sent within the context of this dialog. > > The simplest answer here is just to say that the messages don't share a dialog. > > Or, it could be considered like REGISTER, where register refreshes SHOULD be sent using the same callid yet there is no dialog. Session oriented messages could also be sent > using the same callid without any implication that this is a dialog. (But I don't like this much either.) > > Paul -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1702 / Room 530 D - 81359 München | Email: peter.paeppinghaus@icn.siemens.de _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 11:34:20 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21956 for ; Tue, 16 Jul 2002 11:34:20 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GFWrwa006804; Tue, 16 Jul 2002 11:32:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06347; Tue, 16 Jul 2002 11:33:04 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06336 for ; Tue, 16 Jul 2002 11:32:48 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6GFWqi11944; Tue, 16 Jul 2002 10:32:52 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Jul 2002 10:32:38 -0500 Message-ID: From: "Sriram Parameswar" To: "'Ben Campbell'" , "Vijay K. Gurbani" Cc: Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com Subject: RE: [Simple] -05 MESSAGE and Expires header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22CDD.FE55DDF0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 10:32:28 -0500 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_01C22CDD.FE55DDF0 Content-Type: text/plain; charset="iso-8859-1" Personally I would not like to use Priority and leave the Expires semantic as is. As justification take this example: if you have several IM sessions in progress, and the window which logs your session with your significant-other is buried below a ton of other windows. When a message arrives with a Priority "Urgent" - 'House on Fire' the application (please note - I said application nothing to do with protocol) could decide to pop the window to the top. This would not be possible if we overload Priority. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Tuesday, July 16, 2002 8:26 AM To: Vijay K. Gurbani Cc: Tan Ya-Ching ICM N PG U ID A 1; simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header Vijay K. Gurbani wrote: > Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> Vijay, >> >> It is stated in RFC 3261 section 20.19 Expires that : >> "The precise meaning of this (header) is method dependant". > > > Agreed. > >> The use of the Expires header in MESSAGE is as it is defined in -05. >> It has >> only one meaning, so there is no overloading. > > > That is debatable; good thing about ASCII protocols is that they are > self describing. Thus, having a "Priority: Urgent" is far more > preferable to overloading "Expires: 0" to mean immediate handling. > "Priority: Urgent" in this case makes it far more easy to figure > out what is going on. > > - vijay > > > > I do not have strong feelings on this one way or another--either approach works for me. I will bow to the will of the majority. Anyone else have comments? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C22CDD.FE55DDF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] -05 MESSAGE and Expires header

Personally I would not like to use Priority and leave = the Expires semantic as is.

As justification take this example: if you have = several IM sessions in progress, and the window which logs your session = with your significant-other is buried below a ton of other windows. = When a message arrives with a Priority "Urgent" - 'House on = Fire' the application (please note - I said application nothing to do = with protocol) could decide to pop the window to the top. This would = not be possible if we overload Priority.

Regards,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.c= om]
Sent: Tuesday, July 16, 2002 8:26 AM
To: Vijay K. Gurbani
Cc: Tan Ya-Ching ICM N PG U ID A 1; = simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires = header


Vijay K. Gurbani wrote:
> Tan Ya-Ching ICM N PG U ID A 1 wrote:
>
>> Vijay,
>>
>> It is stated in RFC 3261 section 20.19 = Expires that :
>> "The precise meaning of this (header) = is method dependant".
>
>
> Agreed.
>
>> The use of the Expires header in MESSAGE is = as it is defined in -05.
>> It has
>> only one meaning, so there is no = overloading.
>
>
> That is debatable; good thing about ASCII = protocols is that they are
> self describing.  Thus, having a = "Priority: Urgent" is far more
> preferable to overloading "Expires: = 0" to mean immediate handling.
> "Priority: Urgent" in this case makes = it far more easy to figure
> out what is going on.
>
> - vijay
>
>
>
>

I do not have strong feelings on this one way or = another--either
approach works for me. I will bow to the will of the = majority. Anyone
else have comments?


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple=

------_=_NextPart_001_01C22CDD.FE55DDF0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 12:10:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22831 for ; Tue, 16 Jul 2002 12:10:13 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GG9swa007176; Tue, 16 Jul 2002 12:09:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06595; Tue, 16 Jul 2002 12:10:06 -0400 (EDT) Received: from mailserver.sylantro.com ([65.200.90.207]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA06568 for ; Tue, 16 Jul 2002 12:09:54 -0400 (EDT) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 16 Jul 2002 09:03:28 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1Y4A7M06>; Tue, 16 Jul 2002 09:03:28 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD018F11C8@mailserver.sylantro.com> From: "Fred O'Leary" To: "Ben Campbell" , "Vijay K. Gurbani" cc: "Tan Ya-Ching ICM N PG U ID A 1" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] -05 MESSAGE and Expires header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 112A9C5A1239878-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 09:03:23 -0700 Content-Transfer-Encoding: 7bit I vote for the 'priority' header. Mixing headers/semantics is a sure-fire path the iter-op problems. The urgent message doesn't 'expire immediately' and "Expires: 0" implies something like that. -Fred -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Tuesday, July 16, 2002 6:26 AM To: Vijay K. Gurbani Cc: Tan Ya-Ching ICM N PG U ID A 1; simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header Vijay K. Gurbani wrote: > Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> Vijay, >> >> It is stated in RFC 3261 section 20.19 Expires that : >> "The precise meaning of this (header) is method dependant". > > > Agreed. > >> The use of the Expires header in MESSAGE is as it is defined in -05. >> It has >> only one meaning, so there is no overloading. > > > That is debatable; good thing about ASCII protocols is that they are > self describing. Thus, having a "Priority: Urgent" is far more > preferable to overloading "Expires: 0" to mean immediate handling. > "Priority: Urgent" in this case makes it far more easy to figure > out what is going on. > > - vijay > > > > I do not have strong feelings on this one way or another--either approach works for me. I will bow to the will of the majority. Anyone else have comments? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 13:01:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24313 for ; Tue, 16 Jul 2002 13:01:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GGxvwa007508; Tue, 16 Jul 2002 12:59:57 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06857; Tue, 16 Jul 2002 13:00:04 -0400 (EDT) Received: from rwc-ex0.corp.seven.com ([209.19.68.212]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06844 for ; Tue, 16 Jul 2002 12:59:02 -0400 (EDT) Received: from seven.com ([10.0.10.123]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 16 Jul 2002 10:01:18 -0700 Message-ID: <3D3450A9.D47B0910@seven.com> From: Bobby Sardana Organization: Seven Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> <3D341EE8.2050800@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------8251D6713A71D2D5B286E601" X-OriginalArrivalTime: 16 Jul 2002 17:01:18.0320 (UTC) FILETIME=[67151700:01C22CEA] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 09:58:17 -0700 --------------8251D6713A71D2D5B286E601 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'll cast my vote for the Priority header. Expires: 0 somehow implies that the message needs to be dropped. regards, Bobby Sardana. dsardana@seven.com Ben Campbell wrote: > Vijay K. Gurbani wrote: > > Tan Ya-Ching ICM N PG U ID A 1 wrote: > > > >> Vijay, > >> > >> It is stated in RFC 3261 section 20.19 Expires that : > >> "The precise meaning of this (header) is method dependant". > > > > > > Agreed. > > > >> The use of the Expires header in MESSAGE is as it is defined in -05. > >> It has > >> only one meaning, so there is no overloading. > > > > > > That is debatable; good thing about ASCII protocols is that they are > > self describing. Thus, having a "Priority: Urgent" is far more > > preferable to overloading "Expires: 0" to mean immediate handling. > > "Priority: Urgent" in this case makes it far more easy to figure > > out what is going on. > > > > - vijay > > > > > > > > > > I do not have strong feelings on this one way or another--either > approach works for me. I will bow to the will of the majority. Anyone > else have comments? > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- ___________________________ Bobby Sardana | SEVEN Software Engineer, Engineering ___________________________ 901 Marshall St. Redwood City, CA 94063 650.381.2535 (v) 650.216.6455 (f) dsardana@seven.com www.seven.com --------------8251D6713A71D2D5B286E601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I'll cast my vote for the Priority header. Expires: 0 somehow implies that the message needs to be dropped.

regards,

Bobby Sardana.
dsardana@seven.com

Ben Campbell wrote:

Vijay K. Gurbani wrote:
> Tan Ya-Ching ICM N PG U ID A 1 wrote:
>
>> Vijay,
>>
>> It is stated in RFC 3261 section 20.19 Expires that :
>> "The precise meaning of this (header) is method dependant".
>
>
> Agreed.
>
>> The use of the Expires header in MESSAGE is as it is defined in -05.
>> It has
>> only one meaning, so there is no overloading.
>
>
> That is debatable; good thing about ASCII protocols is that they are
> self describing.  Thus, having a "Priority: Urgent" is far more
> preferable to overloading "Expires: 0" to mean immediate handling.
> "Priority: Urgent" in this case makes it far more easy to figure
> out what is going on.
>
> - vijay
>
>
>
>

I do not have strong feelings on this one way or another--either
approach works for me. I will bow to the will of the majority. Anyone
else have comments?

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
___________________________ 

Bobby Sardana |  SEVEN 
Software Engineer, Engineering  
___________________________ 

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com
  --------------8251D6713A71D2D5B286E601-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 13:41:19 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25184 for ; Tue, 16 Jul 2002 13:41:19 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GHfCwa007806; Tue, 16 Jul 2002 13:41:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07031; Tue, 16 Jul 2002 13:40:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07018 for ; Tue, 16 Jul 2002 13:39:56 -0400 (EDT) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GHeKr1010786; Tue, 16 Jul 2002 13:40:20 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAZ91183; Tue, 16 Jul 2002 13:34:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20020716133802.00b40db8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Bobby Sardana From: Michael Hammer Subject: Re: [Simple] -05 MESSAGE and Expires header Cc: Ben Campbell , "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com In-Reply-To: <3D3450A9.D47B0910@seven.com> References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> <3D341EE8.2050800@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 13:39:44 -0400 Is it possible to deliver a message with an indication that it is expired/stale? Mike At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote: >I'll cast my vote for the Priority header. Expires: 0 somehow implies that >the message needs to be dropped. > >regards, > >Bobby Sardana. >dsardana@seven.com > >Ben Campbell wrote: >>Vijay K. Gurbani wrote: >> > Tan Ya-Ching ICM N PG U ID A 1 wrote: >> > >> >> Vijay, >> >> >> >> It is stated in RFC 3261 section 20.19 Expires that : >> >> "The precise meaning of this (header) is method dependant". >> > >> > >> > Agreed. >> > >> >> The use of the Expires header in MESSAGE is as it is defined in -05. >> >> It has >> >> only one meaning, so there is no overloading. >> > >> > >> > That is debatable; good thing about ASCII protocols is that they are >> > self describing. Thus, having a "Priority: Urgent" is far more >> > preferable to overloading "Expires: 0" to mean immediate handling. >> > "Priority: Urgent" in this case makes it far more easy to figure >> > out what is going on. >> > >> > - vijay >> > >> > >> > >> > >> >>I do not have strong feelings on this one way or another--either >>approach works for me. I will bow to the will of the majority. Anyone >>else have comments? >> >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple > >-- >___________________________ > >Bobby Sardana | SEVEN >Software Engineer, Engineering >___________________________ > >901 Marshall St. >Redwood City, CA 94063 >650.381.2535 (v) >650.216.6455 (f) >dsardana@seven.com >www.seven.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 13:47:32 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25281 for ; Tue, 16 Jul 2002 13:47:32 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GHkDwa007894; Tue, 16 Jul 2002 13:46:13 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07083; Tue, 16 Jul 2002 13:45:05 -0400 (EDT) Received: from rwc-ex0.corp.seven.com ([209.19.68.212]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07070 for ; Tue, 16 Jul 2002 13:44:19 -0400 (EDT) Received: from seven.com ([10.0.10.123]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 16 Jul 2002 10:46:35 -0700 Message-ID: <3D345B45.5300EC60@seven.com> From: Bobby Sardana Organization: Seven Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Hammer CC: Ben Campbell , "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> <3D341EE8.2050800@dynamicsoft.com> <4.3.2.7.2.20020716133802.00b40db8@cia.cisco.com> Content-Type: multipart/alternative; boundary="------------BC3F45C54E0C30CBDE88BE03" X-OriginalArrivalTime: 16 Jul 2002 17:46:35.0009 (UTC) FILETIME=[BA5AEF10:01C22CF0] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 10:43:33 -0700 --------------BC3F45C54E0C30CBDE88BE03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Expires:0 appears to provide the following semantics: a. The message needs to be dropped (stale?) b. The message does not have an explicit expiration (infinite) Michael Hammer wrote: > Is it possible to deliver a message with an indication that it is > expired/stale? An erroneous implementation might. Why introduce the ambiguity. regards, Bobby Sardana. dsardana@seven.com > > > Mike > > At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote: > >I'll cast my vote for the Priority header. Expires: 0 somehow implies that > >the message needs to be dropped. > > > >regards, > > > >Bobby Sardana. > >dsardana@seven.com > > > >Ben Campbell wrote: > >>Vijay K. Gurbani wrote: > >> > Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> > > >> >> Vijay, > >> >> > >> >> It is stated in RFC 3261 section 20.19 Expires that : > >> >> "The precise meaning of this (header) is method dependant". > >> > > >> > > >> > Agreed. > >> > > >> >> The use of the Expires header in MESSAGE is as it is defined in -05. > >> >> It has > >> >> only one meaning, so there is no overloading. > >> > > >> > > >> > That is debatable; good thing about ASCII protocols is that they are > >> > self describing. Thus, having a "Priority: Urgent" is far more > >> > preferable to overloading "Expires: 0" to mean immediate handling. > >> > "Priority: Urgent" in this case makes it far more easy to figure > >> > out what is going on. > >> > > >> > - vijay > >> > > >> > > >> > > >> > > >> > >>I do not have strong feelings on this one way or another--either > >>approach works for me. I will bow to the will of the majority. Anyone > >>else have comments? > >> > >>_______________________________________________ > >>simple mailing list > >>simple@mailman.dynamicsoft.com > >>http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > >-- > >___________________________ > > > >Bobby Sardana | SEVEN > >Software Engineer, Engineering > >___________________________ > > > >901 Marshall St. > >Redwood City, CA 94063 > >650.381.2535 (v) > >650.216.6455 (f) > >dsardana@seven.com > >www.seven.com > > -- ___________________________ Bobby Sardana | SEVEN Software Engineer, Engineering ___________________________ 901 Marshall St. Redwood City, CA 94063 650.381.2535 (v) 650.216.6455 (f) dsardana@seven.com www.seven.com --------------BC3F45C54E0C30CBDE88BE03 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Expires:0 appears to provide the following semantics:

a. The message needs to be dropped (stale?)
b. The message does not have an explicit expiration (infinite)

Michael Hammer wrote:

Is it possible to deliver a message with an indication that it is
expired/stale?
An erroneous implementation might. Why introduce the ambiguity.

regards,

Bobby Sardana.
dsardana@seven.com

 

Mike

At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote:
>I'll cast my vote for the Priority header. Expires: 0 somehow implies that
>the message needs to be dropped.
>
>regards,
>
>Bobby Sardana.
>dsardana@seven.com
>
>Ben Campbell wrote:
>>Vijay K. Gurbani wrote:
>> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
>> >
>> >> Vijay,
>> >>
>> >> It is stated in RFC 3261 section 20.19 Expires that :
>> >> "The precise meaning of this (header) is method dependant".
>> >
>> >
>> > Agreed.
>> >
>> >> The use of the Expires header in MESSAGE is as it is defined in -05.
>> >> It has
>> >> only one meaning, so there is no overloading.
>> >
>> >
>> > That is debatable; good thing about ASCII protocols is that they are
>> > self describing.  Thus, having a "Priority: Urgent" is far more
>> > preferable to overloading "Expires: 0" to mean immediate handling.
>> > "Priority: Urgent" in this case makes it far more easy to figure
>> > out what is going on.
>> >
>> > - vijay
>> >
>> >
>> >
>> >
>>
>>I do not have strong feelings on this one way or another--either
>>approach works for me. I will bow to the will of the majority. Anyone
>>else have comments?
>>
>>_______________________________________________
>>simple mailing list
>>simple@mailman.dynamicsoft.com
>><http://mailman.dynamicsoft.com/mailman/listinfo/simple>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>--
>___________________________
>
>Bobby Sardana |  SEVEN
>Software Engineer, Engineering
>___________________________
>
>901 Marshall St.
>Redwood City, CA 94063
>650.381.2535 (v)
>650.216.6455 (f)
>dsardana@seven.com
>www.seven.com
>

-- 
___________________________ 

Bobby Sardana |  SEVEN 
Software Engineer, Engineering  
___________________________ 

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com
  --------------BC3F45C54E0C30CBDE88BE03-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 14:29:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26330 for ; Tue, 16 Jul 2002 14:29:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GIQrwa008556; Tue, 16 Jul 2002 14:26:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07290; Tue, 16 Jul 2002 14:27:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07279 for ; Tue, 16 Jul 2002 14:26:37 -0400 (EDT) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GIR1a9017353; Tue, 16 Jul 2002 14:27:02 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAZ91668; Tue, 16 Jul 2002 14:21:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20020716142439.00b8a820@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Bobby Sardana From: Michael Hammer Subject: Re: [Simple] -05 MESSAGE and Expires header Cc: Ben Campbell , "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com In-Reply-To: <3D345B45.5300EC60@seven.com> References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> <3D341EE8.2050800@dynamicsoft.com> <4.3.2.7.2.20020716133802.00b40db8@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 14:26:25 -0400 Bobby, I vaguely recall a prior discussion on the possibility of stale messages. Not trying to propose anything, just wanted to be sure Expires: 0 does not have more than one semantic associated. Mike At 10:43 AM 7/16/2002 -0700, Bobby Sardana wrote: >Expires:0 appears to provide the following semantics: > >a. The message needs to be dropped (stale?) >b. The message does not have an explicit expiration (infinite) > >Michael Hammer wrote: >>Is it possible to deliver a message with an indication that it is >>expired/stale? >An erroneous implementation might. Why introduce the ambiguity. > >regards, > >Bobby Sardana. >dsardana@seven.com >> >> >>Mike >> >>At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote: >> >I'll cast my vote for the Priority header. Expires: 0 somehow implies that >> >the message needs to be dropped. >> > >> >regards, >> > >> >Bobby Sardana. >> >dsardana@seven.com >> > >> >Ben Campbell wrote: >> >>Vijay K. Gurbani wrote: >> >> > Tan Ya-Ching ICM N PG U ID A 1 wrote: >> >> > >> >> >> Vijay, >> >> >> >> >> >> It is stated in RFC 3261 section 20.19 Expires that : >> >> >> "The precise meaning of this (header) is method dependant". >> >> > >> >> > >> >> > Agreed. >> >> > >> >> >> The use of the Expires header in MESSAGE is as it is defined in -05. >> >> >> It has >> >> >> only one meaning, so there is no overloading. >> >> > >> >> > >> >> > That is debatable; good thing about ASCII protocols is that they are >> >> > self describing. Thus, having a "Priority: Urgent" is far more >> >> > preferable to overloading "Expires: 0" to mean immediate handling. >> >> > "Priority: Urgent" in this case makes it far more easy to figure >> >> > out what is going on. >> >> > >> >> > - vijay >> >> > >> >> > >> >> > >> >> > >> >> >> >>I do not have strong feelings on this one way or another--either >> >>approach works for me. I will bow to the will of the majority. Anyone >> >>else have comments? >> >> >> >>_______________________________________________ >> >>simple mailing list >> >>simple@mailman.dynamicsoft.com >> >><http://mailman >> .dynamicsoft.com/mailman/listinfo/simple>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> >> > >> >-- >> >___________________________ >> > >> >Bobby Sardana | SEVEN >> >Software Engineer, Engineering >> >___________________________ >> > >> >901 Marshall St. >> >Redwood City, CA 94063 >> >650.381.2535 (v) >> >650.216.6455 (f) >> >dsardana@seven.com >> >www.seven.com >> > > >-- >___________________________ > >Bobby Sardana | SEVEN >Software Engineer, Engineering >___________________________ > >901 Marshall St. >Redwood City, CA 94063 >650.381.2535 (v) >650.216.6455 (f) >dsardana@seven.com >www.seven.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 15:25:17 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27672 for ; Tue, 16 Jul 2002 15:25:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GJNrwa008878; Tue, 16 Jul 2002 15:23:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07503; Tue, 16 Jul 2002 15:24:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07492 for ; Tue, 16 Jul 2002 15:23:25 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GJNqZM027649; Tue, 16 Jul 2002 15:23:52 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN36979; Tue, 16 Jul 2002 15:27:59 -0400 (EDT) Message-ID: <3D3472A5.307D922D@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: jdrosen@dynamicsoft.com, peter.paeppinghaus@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED7A@esebe013.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 15:23:17 -0400 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > > Hi All, > > I don't understand why you would need to have a dialog for the one-shot message. As far as I am concerned, none of this discussion has anything to do with one-shot (page mode) messages. It would indeed be a bad idea to require a dialog for page-mode messages. > Having MESSAGE set up a dialog (for example) may sound reasonable, but when would such a dialog end? Would I have to remember this dialog indefinitely, just in case someone replies to it? Agree there are a multitude of problems with this. > Using a "dummy" INVITE is also problematic. Not only does it blur the paging mode and the session mode, but also, what happens if the other end rejects? How would a user determine whether to accept or reject a "medialess" INVITE? It does raise some issues. I think they are resolvable, but it isn't clear that they are worth resolving. I am becoming convinced that the best solution is to say that the message "session" consists of page-mode messages over the negotiated route, without any common dialog, common callid, etc. Any message ordering that is required can be handled in the message body using CPIM. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 18:21:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01328 for ; Tue, 16 Jul 2002 18:21:01 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GMJP4t009853; Tue, 16 Jul 2002 18:19:26 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08062; Tue, 16 Jul 2002 18:19:10 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08051 for ; Tue, 16 Jul 2002 18:18:37 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6GMI3hZ002845; Tue, 16 Jul 2002 17:18:04 -0500 (CDT) Message-ID: <3D349B91.3090802@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , =?ISO-8859-1?Q?Peter_?= =?ISO-8859-1?Q?P=E4ppinghaus?= , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 17:17:53 -0500 Content-Transfer-Encoding: 8bit Paul Kyzivat wrote: > below... > > Ben Campbell wrote: > >>Paul Kyzivat wrote: >> >>>Ben - I agree with you. But I can't tell if you: >>> >>>- believe jonathan's proposal already implies >>> use of invite to establish the dialog >>> >>>- think invite ought to be used >>> >>>- have some other way in mind to set up the dialog >>> >>> Paul >>> >> >>If by Jonathan's proposal you mean >>draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE. > > > Yes, that is the one. I guess I wasn't clear about my concern. Here is the call flow from draft-rosenberg-simple-message-session-00: > > Caller Proxy Relay Callee > |(1) INVITE | | | > |m=54344 | | | > |c=1.2.3.4 | | | > |------------------>|(2) INVITE | | > | |m=54344 | | > | |c=1.2.3.4 | | > | |hop=sip:relay | | > | |-------------------------------------->| > | |(3) 200 OK | | > | |m=44345 | | > | |c=4.3.2.1 | | > |(4) 200 OK |<--------------------------------------| > |m=44345 | | | > |c=4.3.2.1 | | | > |hop=sip:relay | | | > |<------------------| | | > |(5) ACK | | | > |---------------------------------------------------------->| > | | |(6) MESSAGE | > | | |ruri=1.2.3.4:54344 | > | | |Route=sip:relay | > | | |<------------------| > |(7) MESSAGE | | | > |ruri=1.2.3.4:54344 | | | > |<--------------------------------------| | > |(8) 200 OK | | | > |-------------------------------------->| | > | | |(9) 200 OK | > | | |------------------>| > |(10) MESSAGE | | | > |ruri=4.3.2.1:44345 | | | > |Route=sip:relay | | | > |-------------------------------------->| | > | | |(11) MESSAGE | > | | |ruri=4.3.2.1:44345 | > | | |------------------>| > | | |(12) 200 OK | > | | |<------------------| > |(13) 200 OK | | | > |<--------------------------------------| | > |(14) BYE | | | > |---------------------------------------------------------->| > |(15) 200 OK | | | > |<----------------------------------------------------------| > > This shows the MESSAGEs that are not part of any dialog. > > Then, earlier in this thread: > > Jonathan Rosenberg wrote: > >>Peter Päppinghaus wrote: >> >>>draft-rosenberg-simple-message-session-00 is silent about construction >>>of Call-ID and From and To header tags in the MESSAGE requests sent >>>within a message session. >> >>Well, the draft was just a proposal. >> >>I guess the messages would all use the same dialog ID, with increasing >>CSeq within the dialog. Different dialog ID than the INVITE one, of course. > > > This last sentence is what started this discussion. If the messages are to use the same dialog ID, and it is a different dialog ID than the INVITE, then where does this > other dialog come from? > > In the above flow, it would have to be implicit in the first MESSAGE (6), which seems wrong. > > Another possibility (but also dubious) would be to generate a new INVITE between (5) and (6), from caller to callee, using the route header that involves the relay. This > would be a media-less invite with the sole purpose of establishing a dialog. Then, the messages could be sent within the context of this dialog. > > The simplest answer here is just to say that the messages don't share a dialog. > > Or, it could be considered like REGISTER, where register refreshes SHOULD be sent using the same callid yet there is no dialog. Session oriented messages could also be sent > using the same callid without any implication that this is a dialog. (But I don't like this much either.) > OK, I see. My initial reaction is to just say the messages don't share a dialog. I don't think we want to deal with the implications of saying they do share a dialog (i.e. record-route, contact headers, etc.) _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 19:27:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02559 for ; Tue, 16 Jul 2002 19:27:25 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GNPG4t010144; Tue, 16 Jul 2002 19:25:17 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08371; Tue, 16 Jul 2002 19:25:09 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08358 for ; Tue, 16 Jul 2002 19:24:15 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6GNO5hZ007095; Tue, 16 Jul 2002 18:24:06 -0500 (CDT) Message-ID: <3D34AB0B.1060401@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bobby Sardana CC: "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> <3D341EE8.2050800@dynamicsoft.com> <3D3450A9.D47B0910@seven.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 18:23:55 -0500 Content-Transfer-Encoding: 7bit So, for all that have commented on this thread, is the description of Expires in RFC 3261 sufficient? If so, we can fix this by simply dropping the sentence about "Expires:0". Or do you think the MESSAGE draft needs to contain additional language concerning "Priority"? Bobby Sardana wrote: > I'll cast my vote for the Priority header. Expires: 0 somehow implies > that the message needs to be dropped. > > regards, > > Bobby Sardana. > dsardana@seven.com > > Ben Campbell wrote: > >> Vijay K. Gurbani wrote: >> > Tan Ya-Ching ICM N PG U ID A 1 wrote: >> > >> >> Vijay, >> >> >> >> It is stated in RFC 3261 section 20.19 Expires that : >> >> "The precise meaning of this (header) is method dependant". >> > >> > >> > Agreed. >> > >> >> The use of the Expires header in MESSAGE is as it is defined in -05. >> >> It has >> >> only one meaning, so there is no overloading. >> > >> > >> > That is debatable; good thing about ASCII protocols is that they are >> > self describing. Thus, having a "Priority: Urgent" is far more >> > preferable to overloading "Expires: 0" to mean immediate handling. >> > "Priority: Urgent" in this case makes it far more easy to figure >> > out what is going on. >> > >> > - vijay >> > >> > >> > >> > >> >> I do not have strong feelings on this one way or another--either >> approach works for me. I will bow to the will of the majority. Anyone >> else have comments? >> >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.com >> http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > -- > ___________________________ > > Bobby Sardana | SEVEN > Software Engineer, Engineering > ___________________________ > > 901 Marshall St. > Redwood City, CA 94063 > 650.381.2535 (v) > 650.216.6455 (f) > dsardana@seven.com > www.seven.com > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 19:56:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03310 for ; Tue, 16 Jul 2002 19:56:25 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6GNsw4t010303; Tue, 16 Jul 2002 19:54:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08524; Tue, 16 Jul 2002 19:55:05 -0400 (EDT) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA08511 for ; Tue, 16 Jul 2002 19:54:20 -0400 (EDT) Message-ID: <20020716235415.24341.qmail@web11604.mail.yahoo.com> Received: from [133.93.76.168] by web11604.mail.yahoo.com via HTTP; Tue, 16 Jul 2002 16:54:15 PDT From: Sean Olson Subject: Re: [Simple] -05 MESSAGE and Expires header To: Ben Campbell , Bobby Sardana Cc: "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com In-Reply-To: <3D34AB0B.1060401@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 16:54:15 -0700 (PDT) Which are we trying to convey: 1) The message expires on reception 2) This is an urgent message (1) seems to be solved by Expires: (2) seems to be solved by Priority /sean --- Ben Campbell wrote: > So, for all that have commented on this thread, is > the description of > Expires in RFC 3261 sufficient? If so, we can fix > this by simply > dropping the sentence about "Expires:0". > > Or do you think the MESSAGE draft needs to contain > additional language > concerning "Priority"? > > Bobby Sardana wrote: > > I'll cast my vote for the Priority header. > Expires: 0 somehow implies > > that the message needs to be dropped. > > > > regards, > > > > Bobby Sardana. > > dsardana@seven.com > > > > Ben Campbell wrote: > > > >> Vijay K. Gurbani wrote: > >> > Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> > > >> >> Vijay, > >> >> > >> >> It is stated in RFC 3261 section 20.19 Expires > that : > >> >> "The precise meaning of this (header) is > method dependant". > >> > > >> > > >> > Agreed. > >> > > >> >> The use of the Expires header in MESSAGE is as > it is defined in -05. > >> >> It has > >> >> only one meaning, so there is no overloading. > >> > > >> > > >> > That is debatable; good thing about ASCII > protocols is that they are > >> > self describing. Thus, having a "Priority: > Urgent" is far more > >> > preferable to overloading "Expires: 0" to mean > immediate handling. > >> > "Priority: Urgent" in this case makes it far > more easy to figure > >> > out what is going on. > >> > > >> > - vijay > >> > > >> > > >> > > >> > > >> > >> I do not have strong feelings on this one way or > another--either > >> approach works for me. I will bow to the will of > the majority. Anyone > >> else have comments? > >> > >> _______________________________________________ > >> simple mailing list > >> simple@mailman.dynamicsoft.com > >> > http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > -- > > ___________________________ > > > > Bobby Sardana | SEVEN > > Software Engineer, Engineering > > ___________________________ > > > > 901 Marshall St. > > Redwood City, CA 94063 > > 650.381.2535 (v) > > 650.216.6455 (f) > > dsardana@seven.com > > www.seven.com > > > > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 20:18:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04435 for ; Tue, 16 Jul 2002 20:18:09 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6H0Gu4t010414; Tue, 16 Jul 2002 20:16:57 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08654; Tue, 16 Jul 2002 20:17:03 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08643 for ; Tue, 16 Jul 2002 20:16:09 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6H0Fk4l000976; Tue, 16 Jul 2002 17:15:46 -0700 (PDT) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADL64995; Tue, 16 Jul 2002 17:16:06 -0700 (PDT) From: "Cullen Jennings" To: Cc: , "Vijay K. Gurbani" Subject: RE: [Simple] -05 MESSAGE and Expires header Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D3413F0.8000804@lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 17:15:50 -0700 Content-Transfer-Encoding: 7bit To quote the honorable Mr. Sparks "leave it alone" I don't think that it is fundamentally broken (other than of course the lame name). Priority is definitely not the right thing to use. I would vote for just going with it as it is. Cullen > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Vijay K. > Gurbani > Sent: Tuesday, July 16, 2002 5:39 AM > To: bcampbell@dynamicsoft.com > Cc: simple@mailman.dynamicsoft.com > Subject: [Simple] -05 MESSAGE and Expires header > > > Ben: > > Any reasons why -05 MESSAGE I-D overloads "Expires: 0" to mean > immediate attention. Maybe we can use "Priority: Urgent" instead; since > the Priority header is defined in 3261 and "may be factored into > decisions about call routing and acceptance". > > I think that overloading the Expires header here is confusing; 3261's > use of "Expires: 0" in conjunction with REGISTER means something > entirely different -- that this registration is invalid. From a > semantic point of view, "Expires: 0" with REGISTER to mean > deregistration appears to make sense; but "Expires: 0" with MESSAGE to > mean immediate delivery appears incongrous. > > If it is not too late, maybe you can consider using the Priority header. > I won't be able to make it to simple WG meeting tomorrow, so I just > wanted to bring this to you attention. > > Thanks, > > - vijay > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 20:31:54 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04929 for ; Tue, 16 Jul 2002 20:31:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6H0U24t010509; Tue, 16 Jul 2002 20:30:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08755; Tue, 16 Jul 2002 20:30:07 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08742 for ; Tue, 16 Jul 2002 20:29:44 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6H0TXhZ011468; Tue, 16 Jul 2002 19:29:34 -0500 (CDT) Message-ID: <3D34BA62.5090908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@mailman.dynamicsoft.com, "Vijay K. Gurbani" , "Sip@Ietf. Org" Subject: Re: [Simple] -05 MESSAGE and Expires header References: X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 19:29:22 -0500 Content-Transfer-Encoding: 7bit Yes--this was pretty much the mood of the room in the SIMPLE wg meeting. It was also mentioned that this is a SIP draft, and any decisions must be made on the SIP list. (I am copying this message to SIP). So, my current plan is to leave it alone. If others disagree, please express that on the SIP list. Thanks! Ben. Cullen Jennings wrote: > To quote the honorable Mr. Sparks "leave it alone" > > I don't think that it is fundamentally broken (other than of course the lame > name). Priority is definitely not the right thing to use. I would vote for > just going with it as it is. > > Cullen > > > >>-----Original Message----- >>From: simple-admin@mailman.dynamicsoft.com >>[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Vijay K. >>Gurbani >>Sent: Tuesday, July 16, 2002 5:39 AM >>To: bcampbell@dynamicsoft.com >>Cc: simple@mailman.dynamicsoft.com >>Subject: [Simple] -05 MESSAGE and Expires header >> >> >>Ben: >> >>Any reasons why -05 MESSAGE I-D overloads "Expires: 0" to mean >>immediate attention. Maybe we can use "Priority: Urgent" instead; since >>the Priority header is defined in 3261 and "may be factored into >>decisions about call routing and acceptance". >> >>I think that overloading the Expires header here is confusing; 3261's >>use of "Expires: 0" in conjunction with REGISTER means something >>entirely different -- that this registration is invalid. From a >>semantic point of view, "Expires: 0" with REGISTER to mean >>deregistration appears to make sense; but "Expires: 0" with MESSAGE to >>mean immediate delivery appears incongrous. >> >>If it is not too late, maybe you can consider using the Priority header. >>I won't be able to make it to simple WG meeting tomorrow, so I just >>wanted to bring this to you attention. >> >>Thanks, >> >>- vijay >> >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 20:43:14 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05279 for ; Tue, 16 Jul 2002 20:43:13 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6H0fu4t010610; Tue, 16 Jul 2002 20:41:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08856; Tue, 16 Jul 2002 20:42:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08845 for ; Tue, 16 Jul 2002 20:41:46 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com ([63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6H0fOEU012464; Tue, 16 Jul 2002 20:41:26 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APYXX>; Tue, 16 Jul 2002 19:41:41 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F46A@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Bobby Sardana Cc: "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com Subject: RE: [Simple] -05 MESSAGE and Expires header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 19:41:40 -0500 Personally, I think the "Expires" handling is sufficient and unambiguious. The use of "Priority" would be inappropriate. High priority items don't necessarily have a high urgency -- and what you're trying to communicate here is urgency, not priority. However, I'd take a different tact: this is really a disposition for the message. In the final equasion, though, I think it's all a moot point, since "Expires: 0" works just fine. /a > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, July 16, 2002 18:24 > To: Bobby Sardana > Cc: Vijay K. Gurbani; Tan Ya-Ching ICM N PG U ID A 1; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] -05 MESSAGE and Expires header > > > So, for all that have commented on this thread, is the description of > Expires in RFC 3261 sufficient? If so, we can fix this by simply > dropping the sentence about "Expires:0". > > Or do you think the MESSAGE draft needs to contain additional > language > concerning "Priority"? > > Bobby Sardana wrote: > > I'll cast my vote for the Priority header. Expires: 0 > somehow implies > > that the message needs to be dropped. > > > > regards, > > > > Bobby Sardana. > > dsardana@seven.com > > > > Ben Campbell wrote: > > > >> Vijay K. Gurbani wrote: > >> > Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> > > >> >> Vijay, > >> >> > >> >> It is stated in RFC 3261 section 20.19 Expires that : > >> >> "The precise meaning of this (header) is method dependant". > >> > > >> > > >> > Agreed. > >> > > >> >> The use of the Expires header in MESSAGE is as it is > defined in -05. > >> >> It has > >> >> only one meaning, so there is no overloading. > >> > > >> > > >> > That is debatable; good thing about ASCII protocols is > that they are > >> > self describing. Thus, having a "Priority: Urgent" is far more > >> > preferable to overloading "Expires: 0" to mean immediate > handling. > >> > "Priority: Urgent" in this case makes it far more easy to figure > >> > out what is going on. > >> > > >> > - vijay > >> > > >> > > >> > > >> > > >> > >> I do not have strong feelings on this one way or another--either > >> approach works for me. I will bow to the will of the > majority. Anyone > >> else have comments? > >> > >> _______________________________________________ > >> simple mailing list > >> simple@mailman.dynamicsoft.com > >> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > -- > > ___________________________ > > > > Bobby Sardana | SEVEN > > Software Engineer, Engineering > > ___________________________ > > > > 901 Marshall St. > > Redwood City, CA 94063 > > 650.381.2535 (v) > > 650.216.6455 (f) > > dsardana@seven.com > > www.seven.com > > > > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 16 22:18:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08610 for ; Tue, 16 Jul 2002 22:18:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6H2Hq4t010911; Tue, 16 Jul 2002 22:17:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09213; Tue, 16 Jul 2002 22:18:04 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09202 for ; Tue, 16 Jul 2002 22:17:11 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6H2HE332144 for ; Tue, 16 Jul 2002 21:17:14 -0500 From: "Dean Willis" To: Message-ID: <002901c22d38$0b3fe330$7e4d5d85@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Simple] Rough notes on SIMPLE session Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 21:17:03 -0500 Content-Transfer-Encoding: 7bit My rough notes are attached. Please send amendments to the chairs. --- Dean Notes SIMPLE Working Group, IETF 54 0900-1130 17Jul02 Agenda presented, accepted MESSAGE Update, Ben Campbell MESSAGE method in UETF last call, waiting IESG feedback. There have been several small changes. This draft has added an option for large messages if congestion-safe transport os used. Also clarified Expires header, although new discussion of this topic has occurred on list in the last 24 hours. Use of 0-value Expires as "immediate" request label is an open question vs "Priority". Audience poll favored current usage with 0-value. There has been discussion of a stronger requirement for REGISTER with method-message. Current discussion is to leave it as currently documented. Motion made from floor to leave well enough alone -- barring major issues, just go with the current form. CPIM Mapping, Ben Campbell Recent draft has minor changes to sync with 3261, but has CPIM dependencies. IMPP chair Mark Day reports that CPIM has experienced a resurgence of interest and may be the last deliverable from IMPP, with a due date on the order of "a couple of months". SIMPLE Data Manipluation Requirements, Jonathan Rosenberg Presence List Changes: Terminology change from "buddy list" to "presence list" in latest draft. More data than PIDF needed due to requirement for partial update, including full/partial update flags to allow differential updates. Lists may include lists, so the list server subscribes to list package for each entry rather than the basic presence package, thereby providing nesting. Open Issue #1: Should PL be a Template package? Discussion presented in slides. Open question -- is a new body type required? Current draft proposes a multipart body with a madatory base class and an optional seperate "collection" body with references to other elements. This preserves the original bodies in an unmodified fashion and allows package-indpendent collection servers. Example bodies presented in slides. Comment from floor: this has some similarity to SynchML and may justify examination thereof. Comment from floor: This multi-level approach is interesting, but the given approach has a lot of overhead. Also the proposal doesn't seem to have any way to distinguish multiple elements. 2nd comment adddressed, spec requires that templateable packages specify a URI to reference elements. Application/versioninfo should be an XML document with full referencing. Comment from Patrik: Mixing MIME dividers and XML dividers can be problematic, especially if signatures are used. Response: Reason author likes multipart/mixed rather than pidf is that this appproach preserves signatures and seems to work. Open Issue #2: Too Many Choices Current draft allows PIDF, PLIDF, Multipart Mixed, all of which have assorted issues discussed in slides. The Collection Template approach discussed above seems to allow mixing of these types while clearing all of the noted issues. Open Issue #3: State of Suscriptions The Presence List Server is a "fan-out" server. There's currently no way to know the state of the fanned-out subscriptions on a transitive basis. Proposal is to aggregate this information in listinfo format as proposed in collection template class, then support partial updates. Discussion: What would the event header look like? Proposed alternative: multipart/mixed with message/sip inside. This would reduce maintenance of collection formats. Response is tha t this would keep all of the overhead of SIP routing information -- cseqs, etc. and would create a great deal of overhead problematic for wireless applications. Open Issue #4: Sharing Of Versions Issues discussed in slides, all cleared by proposed collection model. Open Issue #5: Which Package does PLS use? Several options proposed: 1) presence.collection, fallback to presence, 2) add labels to lists so they can be parsed as lists 3) user has to KNOW that a subscribed list is a list, not an individual, 4) Server OPTION The URI to discover that it is a list, then uses appropriate package, which works as long as role of URI is fixed. 5) disallow recursion. Comments requested: Question: How are 1, 3 ,and 4 not complementary? Ans: Original proposal was "All but 2". This results in notifications that exceed the scope of the subscription, which could be confusing to sort out. Question: How do you identify these? The event header was "buddy list", what now? Ans: It was always a request URI, the only thing that changes is the event name. Question: Could the AOR be a bddy list? Ans: Yes, but not in an overloaded condition where the URI presents both an indivdual and a list. This would seem to be a reasonable interpretation of URI usage. Question: What about multipart recursion? Extended discussion followed . . . discussion deferred to offline. Question: If something has presence but not presence collection, would it be reasonable to serve up presence instead of a prsence collection? Ans: yes. This will be clarified in draft. Audience polled: Is going in the direction of a template class generally reasonable? Answer favorable, none opposed. Data Requirements, Jonathan Rosenberg Presence and IM ssytems use multiple data elements to drive the application. We need to manipulate these data items, interact with, change, etc. them. This is disjoint from the subscription and notification mechanism, and includes read and write mechanisms with caching (offline access, and modification) and security requirements (listed in draft). Question: Does this create additional requirements around concurrent offline changes and reconciliation? Ans: Not a requirements issue but an implementation issue. Comment: This topic could use its own working group, we should perhaps not solve it here. Ans: We're just talking about requirements and really expect to reuse an existing solution like SyncML. Comment: Should study data model in ACAP very carefully. Ans: Authors are already working with ACAP author to analyze. Extended discssion on tradeoff of authorization, inheritance, and cacheing issues followed. Open issues include 1) Do enough of the data manipulation type thihngs we do fit under this model to justify further work, 2) Should we generalize or do something specific for presence lists? 3) How do we align with SIP conf work? 4) Should we adopt as a WG item? Comment: This is a large problem space, and includes things like WebDAV, XPath, XML database, and probably becomes at least a New York sized rathole. It probably would be a bad idea to choose to do something limited to the presence list problem. Comment: There's a lot of overlap with W3C and other work, we should collaborate. Comment: This is similar to the UA configuration task, can we combine them? Comment: Is this really a semantic manipulation problem, or a remove text editing problem? Comment: What is start with a pure XML framework, then we can use stuff like XPath and see if it works. Comments: We should at least work on this here, starting from specific topics in charter. Poll: Should this work be adopted as a wokring group item toward existing charter goal? Response favorable, none opposed. The PUBLISH Method, Sean Olson The critical issues here depend on the composition model in the preceeding discussion. The basic model is discussed in the slides. The contentious component of the draft is the "slot" model of presence composition. Open issues include: 1) Should we includeCPL problem in scope, Proposal, No. 2) Is "slot" idea right way to go? 3) Do we need to standardize PType tokens? 40 Should PType require IANA registration? 5) Should PState be replaced with Expires header? Comments: This seems to be the micro-version of WebDAV, but scope-limited for just the PL problem. This may argue that the very general "PUBLISH" name is too broad. Also, do we really want to differentiate between hard-state and soft-state data? Ans: Name can be changed. Authors have deliberately restricted to soft-state because this data has direct correlation or "binding" with SIP routing and cannot be well addressed by other mechanisms like WebDAV. Hard-state information does not seem to have this characteristic. This is particularly crucial for third-party manipulation of soft-state information given only a SIP URI as a key to that information. SIMPLE isn't deployable without this and it has to be fixed NOW. The requirement here is scoped explicitly by SIP Events. Comment: Can we identify a reasonable stopping point? The model of having to find a "stopping point" based on a SIP URI seems reasonably common. Proposal: Could we do PUBLISH via a reversed subscribe/notify model? Discussion of this approach not favorable. Question: How does one manage policy of slot composition? Ans: The composition policy of a compositor is locally determined. 3GPP Presence Requirements, Krizstian Kiss Slides summarize requirements. from draft. Discussion of requirememt "Keep all PUAs aware of each other's publishing": Comment that this seems to be contradictory, it would be better to make publishing transparent across devices. Ans: This is because we have "network attributes" that have to work this way. Further discussion deferred. Comment: there are requirements for filtering in a lot of our discussions, we should add to charter. Comment: partial notification is messy. We need to clarify this. For example, CPIM and partial notification are conflicting requirements. Comments on requirment for anonymous subscription: This means the subscriber is anoynmous, not that the subscription is invisible to the prsentity, right? Ans: yes. Comment: If geoloc is part of presence document, how does it get composited? Ans: simply -- just reference the geoloc document. There are lots of authorization issues around WHO can update and/or see geoloc. Discussion: Is it reasonable to accept requirement from 3GPP? Discussion: Rather than having "3GPP requriements" on our charter, shouldn't we simply integrate these requirements into our chartered requiremeents documents? This proposal seems to be generally favorable to the audience. 3GPP Instant Messaging Requirements, Aki Niemi This document is intended as a "heads up" to IETF. The work is at a very early stage in 3GPP. Formal requirements are expected by IETF55. IMSX Protocol Evaluation for Session-Based IM, Mary Barnes Analysis presented. Comment: Although it doesn't currently support threading, BEEP could so so easily. Aomment: Although there may be objections to implememnting yet another protocol in a node, SIP does shine at multiprotocol stories and really does work well with a mix of transports and codecs. Comment: The status of IMXP does not seem clear, as there have been apparent strategic shifts by the author (Jabber). Comment: Rohan said something about IMTP and strategic subsets and Fred Baker, but this reporter didn't parse it. Comment: messages are somewhat like media, and somewhat not like media, and we probably don't need a divergence between session and pager model. Comment: We seem to have only one proposal -- use SIP. The idea of defining IMTP as a seperate protocol subset seems pointless. Defining the session model as a stream of MESSAGES bounded by a dialog seems like the right thing to do. Comment: Using SIP without changing the name clearly violates the spirit and letter of our own SIP guidelines and has potential interop problems. Comment: If somebody is going to define a new proposal, they need to do it really soon. We really DO have only one draft under current consideration. Proposal: Let's just move forward with Jonathan's draft, in a non-exclusive sense. Discussion seems to favor this as the baseline default, and we can do additional stuff later if needed. We should immediately discuss on list and conclude whetehr we go forward immediately with SIP or a renamed SIP-subset (IMTP). _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 17 11:01:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18553 for ; Wed, 17 Jul 2002 11:01:51 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6HF144t013122; Wed, 17 Jul 2002 11:01:04 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11481; Wed, 17 Jul 2002 11:01:08 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11470 for ; Wed, 17 Jul 2002 11:00:17 -0400 (EDT) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6HF0e1W017059; Wed, 17 Jul 2002 11:00:40 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAZ98843; Wed, 17 Jul 2002 10:55:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20020717105028.00b5cda0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ben Campbell From: Michael Hammer Subject: Re: [Simple] Message session & associated dialog Cc: Paul Kyzivat , Jonathan Rosenberg , Peter =?iso-8859-1?Q?P=E4ppinghaus?= , simple@mailman.dynamicsoft.com In-Reply-To: <3D349B91.3090802@dynamicsoft.com> References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA11470 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 17 Jul 2002 11:00:04 -0400 Content-Transfer-Encoding: 8bit Ben, If you substitute RTP stream for MESSAGE stream in this discussion are there any differences? That is, is the correlation between the RTP stream and the SIP signaling stream any different? Can we conclude that the operational requirements of both these media streams would be parallel? Mike At 05:17 PM 7/16/2002 -0500, Ben Campbell wrote: >Paul Kyzivat wrote: >>below... >>Ben Campbell wrote: >> >>>Paul Kyzivat wrote: >>> >>>>Ben - I agree with you. But I can't tell if you: >>>> >>>>- believe jonathan's proposal already implies >>>> use of invite to establish the dialog >>>> >>>>- think invite ought to be used >>>> >>>>- have some other way in mind to set up the dialog >>>> >>>> Paul >>> >>>If by Jonathan's proposal you mean >>>draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE. >> >>Yes, that is the one. I guess I wasn't clear about my concern. Here is >>the call flow from draft-rosenberg-simple-message-session-00: >> Caller Proxy Relay Callee >> |(1) INVITE | | | >> |m=54344 | | | >> |c=1.2.3.4 | | | >> |------------------>|(2) INVITE | | >> | |m=54344 | | >> | |c=1.2.3.4 | | >> | |hop=sip:relay | | >> | |-------------------------------------->| >> | |(3) 200 OK | | >> | |m=44345 | | >> | |c=4.3.2.1 | | >> |(4) 200 OK |<--------------------------------------| >> |m=44345 | | | >> |c=4.3.2.1 | | | >> |hop=sip:relay | | | >> |<------------------| | | >> |(5) ACK | | | >> |---------------------------------------------------------->| >> | | |(6) MESSAGE | >> | | |ruri=1.2.3.4:54344 | >> | | |Route=sip:relay | >> | | |<------------------| >> |(7) MESSAGE | | | >> |ruri=1.2.3.4:54344 | | | >> |<--------------------------------------| | >> |(8) 200 OK | | | >> |-------------------------------------->| | >> | | |(9) 200 OK | >> | | |------------------>| >> |(10) MESSAGE | | | >> |ruri=4.3.2.1:44345 | | | >> |Route=sip:relay | | | >> |-------------------------------------->| | >> | | |(11) MESSAGE | >> | | |ruri=4.3.2.1:44345 | >> | | |------------------>| >> | | |(12) 200 OK | >> | | |<------------------| >> |(13) 200 OK | | | >> |<--------------------------------------| | >> |(14) BYE | | | >> |---------------------------------------------------------->| >> |(15) 200 OK | | | >> |<----------------------------------------------------------| >>This shows the MESSAGEs that are not part of any dialog. >>Then, earlier in this thread: >>Jonathan Rosenberg wrote: >> >>>Peter Päppinghaus wrote: >>> >>>>draft-rosenberg-simple-message-session-00 is silent about construction >>>>of Call-ID and From and To header tags in the MESSAGE requests sent >>>>within a message session. >>> >>>Well, the draft was just a proposal. >>> >>>I guess the messages would all use the same dialog ID, with increasing >>>CSeq within the dialog. Different dialog ID than the INVITE one, of course. >> >>This last sentence is what started this discussion. If the messages are >>to use the same dialog ID, and it is a different dialog ID than the >>INVITE, then where does this >>other dialog come from? >>In the above flow, it would have to be implicit in the first MESSAGE (6), >>which seems wrong. >>Another possibility (but also dubious) would be to generate a new INVITE >>between (5) and (6), from caller to callee, using the route header that >>involves the relay. This >>would be a media-less invite with the sole purpose of establishing a >>dialog. Then, the messages could be sent within the context of this dialog. >>The simplest answer here is just to say that the messages don't share a >>dialog. >>Or, it could be considered like REGISTER, where register refreshes SHOULD >>be sent using the same callid yet there is no dialog. Session oriented >>messages could also be sent >>using the same callid without any implication that this is a dialog. (But >>I don't like this much either.) > >OK, I see. My initial reaction is to just say the messages don't share a >dialog. I don't think we want to deal with the implications of saying they >do share a dialog (i.e. record-route, contact headers, etc.) > > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 17 20:16:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03313 for ; Wed, 17 Jul 2002 20:16:13 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6I0Fs4t016702; Wed, 17 Jul 2002 20:15:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13111; Wed, 17 Jul 2002 20:16:05 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13100 for ; Wed, 17 Jul 2002 20:15:41 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6I0FPhZ013365; Wed, 17 Jul 2002 19:15:26 -0500 (CDT) Message-ID: <3D360892.3070204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Paul Kyzivat , Jonathan Rosenberg , =?ISO-8859-1?Q?Peter_P=E4ppinghaus?= , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com> <4.3.2.7.2.20020717105028.00b5cda0@cia.cisco.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 17 Jul 2002 19:15:14 -0500 Content-Transfer-Encoding: 8bit It seems it would make sense for it to be the same. The MESSAGE stream should be just another media stream from the perspective of the associated dialog. Michael Hammer wrote: > Ben, > > If you substitute RTP stream for MESSAGE stream in this discussion are > there any differences? That is, is the correlation between the RTP > stream and the SIP signaling stream any different? Can we conclude that > the operational requirements of both these media streams would be parallel? > > Mike > > > At 05:17 PM 7/16/2002 -0500, Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >>> below... >>> Ben Campbell wrote: >>> >>>> Paul Kyzivat wrote: >>>> >>>>> Ben - I agree with you. But I can't tell if you: >>>>> >>>>> - believe jonathan's proposal already implies >>>>> use of invite to establish the dialog >>>>> >>>>> - think invite ought to be used >>>>> >>>>> - have some other way in mind to set up the dialog >>>>> >>>>> Paul >>>> >>>> >>>> If by Jonathan's proposal you mean >>>> draft-rosenberg-simple-message-session-00, it fairly explicitly uses >>>> INVITE. >>> >>> >>> Yes, that is the one. I guess I wasn't clear about my concern. Here >>> is the call flow from draft-rosenberg-simple-message-session-00: >>> Caller Proxy Relay >>> Callee >>> |(1) INVITE | | | >>> |m=54344 | | | >>> |c=1.2.3.4 | | | >>> |------------------>|(2) INVITE | | >>> | |m=54344 | | >>> | |c=1.2.3.4 | | >>> | |hop=sip:relay | | >>> | |-------------------------------------->| >>> | |(3) 200 OK | | >>> | |m=44345 | | >>> | |c=4.3.2.1 | | >>> |(4) 200 OK |<--------------------------------------| >>> |m=44345 | | | >>> |c=4.3.2.1 | | | >>> |hop=sip:relay | | | >>> |<------------------| | | >>> |(5) ACK | | | >>> |---------------------------------------------------------->| >>> | | |(6) MESSAGE | >>> | | |ruri=1.2.3.4:54344 | >>> | | |Route=sip:relay | >>> | | |<------------------| >>> |(7) MESSAGE | | | >>> |ruri=1.2.3.4:54344 | | | >>> |<--------------------------------------| | >>> |(8) 200 OK | | | >>> |-------------------------------------->| | >>> | | |(9) 200 OK | >>> | | |------------------>| >>> |(10) MESSAGE | | | >>> |ruri=4.3.2.1:44345 | | | >>> |Route=sip:relay | | | >>> |-------------------------------------->| | >>> | | |(11) MESSAGE | >>> | | |ruri=4.3.2.1:44345 | >>> | | |------------------>| >>> | | |(12) 200 OK | >>> | | |<------------------| >>> |(13) 200 OK | | | >>> |<--------------------------------------| | >>> |(14) BYE | | | >>> |---------------------------------------------------------->| >>> |(15) 200 OK | | | >>> |<----------------------------------------------------------| >>> This shows the MESSAGEs that are not part of any dialog. >>> Then, earlier in this thread: >>> Jonathan Rosenberg wrote: >>> >>>> Peter Päppinghaus wrote: >>>> >>>>> draft-rosenberg-simple-message-session-00 is silent about construction >>>>> of Call-ID and From and To header tags in the MESSAGE requests sent >>>>> within a message session. >>>> >>>> >>>> Well, the draft was just a proposal. >>>> >>>> I guess the messages would all use the same dialog ID, with increasing >>>> CSeq within the dialog. Different dialog ID than the INVITE one, of >>>> course. >>> >>> >>> This last sentence is what started this discussion. If the messages >>> are to use the same dialog ID, and it is a different dialog ID than >>> the INVITE, then where does this >>> other dialog come from? >>> In the above flow, it would have to be implicit in the first MESSAGE >>> (6), which seems wrong. >>> Another possibility (but also dubious) would be to generate a new >>> INVITE between (5) and (6), from caller to callee, using the route >>> header that involves the relay. This >>> would be a media-less invite with the sole purpose of establishing a >>> dialog. Then, the messages could be sent within the context of this >>> dialog. >>> The simplest answer here is just to say that the messages don't share >>> a dialog. >>> Or, it could be considered like REGISTER, where register refreshes >>> SHOULD be sent using the same callid yet there is no dialog. Session >>> oriented messages could also be sent >>> using the same callid without any implication that this is a dialog. >>> (But I don't like this much either.) >> >> >> OK, I see. My initial reaction is to just say the messages don't share >> a dialog. I don't think we want to deal with the implications of >> saying they do share a dialog (i.e. record-route, contact headers, etc.) >> >> >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.com >> http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 17 22:25:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07511 for ; Wed, 17 Jul 2002 22:25:24 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6I2Ot4t017089; Wed, 17 Jul 2002 22:24:56 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13505; Wed, 17 Jul 2002 22:25:05 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13492 for ; Wed, 17 Jul 2002 22:25:00 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6I2OsYH010758; Wed, 17 Jul 2002 22:24:55 -0400 (EDT) Message-ID: <3D3626F3.3080106@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Ben Campbell , Bobby Sardana , "Vijay K. Gurbani" , Tan Ya-Ching ICM N PG U ID A 1 , simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <9BF66EBF6BEFD942915B4D4D45C051F325F46A@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 18 Jul 2002 11:24:51 +0900 Content-Transfer-Encoding: 7bit Expires is method specific, since its precise interpretation is method specific. The general notion is that it indicates a lifetime of something; a point after which the thing is no longer valid. I think that this more genearl definition is an exact match to our need here, and the current Expires text is an appropriate instantiation of it for MESSAGE. I believe that priority is quite different. A message can be for immediate delivery, and be either urgent ("my house is on fire") or not ("leaving now for lunch"). A message can be OK for storage (some non-zero expires) and be urgent ("I need that business presentation by 10pm!") or non-urgent ("Did you see that movie"). The fact that two things can be used orthogonally is a sign that they are, in fact, two different things. I strongly support keeping Expires as currently defined. -Jonathan R. Adam Roach wrote: > Personally, I think the "Expires" handling is sufficient > and unambiguious. > > The use of "Priority" would be inappropriate. High priority > items don't necessarily have a high urgency -- and what you're > trying to communicate here is urgency, not priority. > > However, I'd take a different tact: this is really a disposition > for the message. > > In the final equasion, though, I think it's all a moot point, > since "Expires: 0" works just fine. > > /a > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Tuesday, July 16, 2002 18:24 >>To: Bobby Sardana >>Cc: Vijay K. Gurbani; Tan Ya-Ching ICM N PG U ID A 1; >>simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] -05 MESSAGE and Expires header >> >> >>So, for all that have commented on this thread, is the description of >>Expires in RFC 3261 sufficient? If so, we can fix this by simply >>dropping the sentence about "Expires:0". >> >>Or do you think the MESSAGE draft needs to contain additional >>language >>concerning "Priority"? >> >>Bobby Sardana wrote: >> >>>I'll cast my vote for the Priority header. Expires: 0 >> >>somehow implies >> >>>that the message needs to be dropped. >>> >>>regards, >>> >>>Bobby Sardana. >>>dsardana@seven.com >>> >>>Ben Campbell wrote: >>> >>> >>>>Vijay K. Gurbani wrote: >>>> >>>>>Tan Ya-Ching ICM N PG U ID A 1 wrote: >>>>> >>>>> >>>>>>Vijay, >>>>>> >>>>>>It is stated in RFC 3261 section 20.19 Expires that : >>>>>>"The precise meaning of this (header) is method dependant". >>>>> >>>>> >>>>>Agreed. >>>>> >>>>> >>>>>>The use of the Expires header in MESSAGE is as it is >>>>> >>defined in -05. >> >>>>>>It has >>>>>>only one meaning, so there is no overloading. >>>>> >>>>> >>>>>That is debatable; good thing about ASCII protocols is >>>> >>that they are >> >>>>>self describing. Thus, having a "Priority: Urgent" is far more >>>>>preferable to overloading "Expires: 0" to mean immediate >>>> >>handling. >> >>>>>"Priority: Urgent" in this case makes it far more easy to figure >>>>>out what is going on. >>>>> >>>>>- vijay >>>>> >>>>> >>>>> >>>>> >>>> >>>>I do not have strong feelings on this one way or another--either >>>>approach works for me. I will bow to the will of the >>> >>majority. Anyone >> >>>>else have comments? >>>> >>>>_______________________________________________ >>>>simple mailing list >>>>simple@mailman.dynamicsoft.com >>>>http://mailman.dynamicsoft.com/mailman/listinfo/simple >>>> >>> >>>-- >>>___________________________ >>> >>>Bobby Sardana | SEVEN >>>Software Engineer, Engineering >>>___________________________ >>> >>>901 Marshall St. >>>Redwood City, CA 94063 >>>650.381.2535 (v) >>>650.216.6455 (f) >>>dsardana@seven.com >>>www.seven.com >>> >>> >> >> >> >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 18 06:10:15 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27478 for ; Thu, 18 Jul 2002 06:10:14 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6IA9r4t018167; Thu, 18 Jul 2002 06:09:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14788; Thu, 18 Jul 2002 06:10:05 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14775 for ; Thu, 18 Jul 2002 06:09:23 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA17851; Thu, 18 Jul 2002 12:09:20 +0200 (MET DST) Received: from icn.siemens.de ([139.21.148.41]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA08119; Thu, 18 Jul 2002 12:09:21 +0200 (MET DST) Message-ID: <3D3693D0.2030901@icn.siemens.de> From: Peter =?ISO-8859-1?Q?P=E4ppinghaus?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: Ben Campbell CC: Michael Hammer , Paul Kyzivat , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com> <4.3.2.7.2.20020717105028.00b5cda0@cia.cisco.com> <3D360892.3070204@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 18 Jul 2002 12:09:20 +0200 Content-Transfer-Encoding: 8bit I am certainly not an expert on RTP, but elaborating on the RTP stream / MESSAGE stream comparison: RTP services certainly include sequence numbering. How would sequence numbering be obtained, if the MESSAGE requests of a message session stream all have different Call-IDs? Could not a shared Call-ID play a similar role that an SSRC (synchronization source identifier) plays in RTP, and the CSeq header field play the role that the sequence number field plays in RTP headers? Peter Ben Campbell wrote: > It seems it would make sense for it to be the same. The MESSAGE stream > should be just another media stream from the perspective of the > associated dialog. > > Michael Hammer wrote: > >> Ben, >> >> If you substitute RTP stream for MESSAGE stream in this discussion are >> there any differences? That is, is the correlation between the RTP >> stream and the SIP signaling stream any different? Can we conclude >> that the operational requirements of both these media streams would be >> parallel? >> >> Mike >> >> >> At 05:17 PM 7/16/2002 -0500, Ben Campbell wrote: >> >>> Paul Kyzivat wrote: >>> >>>> below... >>>> Ben Campbell wrote: >>>> >>>>> Paul Kyzivat wrote: >>>>> >>>>>> Ben - I agree with you. But I can't tell if you: >>>>>> >>>>>> - believe jonathan's proposal already implies >>>>>> use of invite to establish the dialog >>>>>> >>>>>> - think invite ought to be used >>>>>> >>>>>> - have some other way in mind to set up the dialog >>>>>> >>>>>> Paul >>>>> >>>>> >>>>> >>>>> If by Jonathan's proposal you mean >>>>> draft-rosenberg-simple-message-session-00, it fairly explicitly >>>>> uses INVITE. >>>> >>>> >>>> >>>> Yes, that is the one. I guess I wasn't clear about my concern. Here >>>> is the call flow from draft-rosenberg-simple-message-session-00: >>>> Caller Proxy Relay >>>> Callee >>>> |(1) INVITE | | | >>>> |m=54344 | | | >>>> |c=1.2.3.4 | | | >>>> |------------------>|(2) INVITE | | >>>> | |m=54344 | | >>>> | |c=1.2.3.4 | | >>>> | |hop=sip:relay | | >>>> | |-------------------------------------->| >>>> | |(3) 200 OK | | >>>> | |m=44345 | | >>>> | |c=4.3.2.1 | | >>>> |(4) 200 OK |<--------------------------------------| >>>> |m=44345 | | | >>>> |c=4.3.2.1 | | | >>>> |hop=sip:relay | | | >>>> |<------------------| | | >>>> |(5) ACK | | | >>>> |---------------------------------------------------------->| >>>> | | |(6) MESSAGE | >>>> | | |ruri=1.2.3.4:54344 | >>>> | | |Route=sip:relay | >>>> | | |<------------------| >>>> |(7) MESSAGE | | | >>>> |ruri=1.2.3.4:54344 | | | >>>> |<--------------------------------------| | >>>> |(8) 200 OK | | | >>>> |-------------------------------------->| | >>>> | | |(9) 200 OK | >>>> | | |------------------>| >>>> |(10) MESSAGE | | | >>>> |ruri=4.3.2.1:44345 | | | >>>> |Route=sip:relay | | | >>>> |-------------------------------------->| | >>>> | | |(11) MESSAGE | >>>> | | |ruri=4.3.2.1:44345 | >>>> | | |------------------>| >>>> | | |(12) 200 OK | >>>> | | |<------------------| >>>> |(13) 200 OK | | | >>>> |<--------------------------------------| | >>>> |(14) BYE | | | >>>> |---------------------------------------------------------->| >>>> |(15) 200 OK | | | >>>> |<----------------------------------------------------------| >>>> This shows the MESSAGEs that are not part of any dialog. >>>> Then, earlier in this thread: >>>> Jonathan Rosenberg wrote: >>>> >>>>> Peter Päppinghaus wrote: >>>>> >>>>>> draft-rosenberg-simple-message-session-00 is silent about >>>>>> construction >>>>>> of Call-ID and From and To header tags in the MESSAGE requests sent >>>>>> within a message session. >>>>> >>>>> >>>>> >>>>> Well, the draft was just a proposal. >>>>> >>>>> I guess the messages would all use the same dialog ID, with increasing >>>>> CSeq within the dialog. Different dialog ID than the INVITE one, of >>>>> course. >>>> >>>> >>>> >>>> This last sentence is what started this discussion. If the messages >>>> are to use the same dialog ID, and it is a different dialog ID than >>>> the INVITE, then where does this >>>> other dialog come from? >>>> In the above flow, it would have to be implicit in the first MESSAGE >>>> (6), which seems wrong. >>>> Another possibility (but also dubious) would be to generate a new >>>> INVITE between (5) and (6), from caller to callee, using the route >>>> header that involves the relay. This >>>> would be a media-less invite with the sole purpose of establishing a >>>> dialog. Then, the messages could be sent within the context of this >>>> dialog. >>>> The simplest answer here is just to say that the messages don't >>>> share a dialog. >>>> Or, it could be considered like REGISTER, where register refreshes >>>> SHOULD be sent using the same callid yet there is no dialog. Session >>>> oriented messages could also be sent >>>> using the same callid without any implication that this is a dialog. >>>> (But I don't like this much either.) >>> >>> >>> >>> OK, I see. My initial reaction is to just say the messages don't >>> share a dialog. I don't think we want to deal with the implications >>> of saying they do share a dialog (i.e. record-route, contact headers, >>> etc.) >>> >>> >>> _______________________________________________ >>> simple mailing list >>> simple@mailman.dynamicsoft.com >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >> >> >> > > > -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1702 / Room 530 D - 81359 München | Email: peter.paeppinghaus@icn.siemens.de _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 18 08:27:02 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00137 for ; Thu, 18 Jul 2002 08:27:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6ICNq4t018522; Thu, 18 Jul 2002 08:24:01 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15217; Thu, 18 Jul 2002 08:24:04 -0400 (EDT) Received: from smtp5.cluster.oleane.net (smtp5.cluster.oleane.net [195.25.12.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15206 for ; Thu, 18 Jul 2002 08:23:05 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id g6ICN1U82512 for ; Thu, 18 Jul 2002 14:23:05 +0200 (CEST) Message-ID: <007a01c22e57$14bda300$0701a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C22E67.D5C100A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Simple] International SIP conference, Paris, third edition Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 18 Jul 2002 14:31:42 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C22E67.D5C100A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable International SIP conference, Paris, third edition. The principal worldwide SIP event will take place in Paris from 14 to 17 = January 2003. The call for proposals dead line has been postponed to August 21st. Please get all details at: http://www.upperside.fr/intersip03/sip03intro.htm ------=_NextPart_000_0077_01C22E67.D5C100A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
International SIP conference, Paris, third=20 edition.
The principal worldwide SIP event will take place in = Paris=20 from 14 to 17 January 2003.
The call for proposals dead line has been postponed = to August=20 21st.
Please get all details at:
http://www.upp= erside.fr/intersip03/sip03intro.htm
 
 
 
------=_NextPart_000_0077_01C22E67.D5C100A0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 18 10:33:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03478 for ; Thu, 18 Jul 2002 10:33:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6IEUD4t019314; Thu, 18 Jul 2002 10:30:13 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15657; Thu, 18 Jul 2002 10:29:04 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15646 for ; Thu, 18 Jul 2002 10:28:04 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6IESai26759 for ; Thu, 18 Jul 2002 17:28:36 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 17:28:04 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 17:28:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message session & associated dialog Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED85@esebe013.NOE.Nokia.com> Thread-Topic: [Simple] Message session & associated dialog Thread-Index: AcIuRYk1kaX8Dsf7SjGbZ0i7jYYhwQAIIeWQ To: , Cc: , , , X-OriginalArrivalTime: 18 Jul 2002 14:28:04.0071 (UTC) FILETIME=[53B58770:01C22E67] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA15646 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 18 Jul 2002 17:28:03 +0300 Content-Transfer-Encoding: 8bit > I am certainly not an expert on RTP, but elaborating on the > RTP stream / MESSAGE stream comparison: > RTP services certainly include sequence numbering. Much of the reason RTP would have sequence numbering probably lies in the fact that the underlying transport protocol (UDP) provides no guarantees on sequential delivery of packets. However, TCP does, so the message-session would only need the CSeq in MESSAGE to sequence overlapping requests. As far as I know, this is currently not allowed. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 18 14:11:48 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09515 for ; Thu, 18 Jul 2002 14:11:48 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6IIBM4t020566; Thu, 18 Jul 2002 14:11:22 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16343; Thu, 18 Jul 2002 14:10:09 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16330 for ; Thu, 18 Jul 2002 14:09:53 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IIA4Q13674; Thu, 18 Jul 2002 13:10:04 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 13:09:49 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04B470AE@zrc2c012.us.nortel.com> From: "Brian Stucker" To: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Comments on PUBLISH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E86.4DFCBE60" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 18 Jul 2002 13:09:48 -0500 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_01C22E86.4DFCBE60 Content-Type: text/plain; charset="iso-8859-1" Comments embedded within... > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, July 08, 2002 7:43 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Comments on PUBLISH > > > 1. The concept of Input slots seems a bit vague. Does a slot > represent entities that publish presence info of the same > type, eg: geographic location? i.e. All devices that publish > geographic location information fit into that slot? If so, > why is a use device not a GeoLoc entity? > > A User device can publish geographic location information as > well as the user's availability for voice and IM, for > example. How do slots work in that scenario? > > Also, how does a Presence Compositor know which publication > belongs to which slot? > > Perhaps I miss understood this concept completely. I'll let Jonathan answer that one.. > > > 2. Document assumes that all presence publication is achieved > using PUBLISH. That is not true. A example, as a matter of > fact, is the GeoLoc. The idea here is that GeoLoc, if it so wished, could use the PUBLISH method to update a presence server. I do not believe that the intent was to provide EVERY way of publishing presence information via this draft, but a single, standardizable approach that covers off as much ground as possible without becoming overly complex. For instance, the compositor can still use registration information to build the presence document. PUBLISH is simply one tentacle feeding the octopus. > > 3. PType header: If is described as useful for 2 things: > > - the document that is being published is part of a larger > composite document. How does PType here help? If PType is > defined to be "mobile", how does that tell the compositor > that it belongs to a larger composite document? I would have > thought the presentity URI would be used for that purpose. > > - The document that is being published will be applied to > many components of the composed document. Please give me an > example of this. I fail to understand how this could be done. > > This is something for the PUBLISH body, not a SIP header. The header is optional. Some compositor functions may want more information about what to do with the message body, where the contents of the message body can't easily convey what is intended. You could put the CPIM-PIDF tuple id here if you liked, or leave it totally off. > > 4. PStream header: How does a header that looks like call-id > guarantees correct sequencing of messages? Header like Date, > and information in the message body seem like a much better > way of sequencing. Let's say I have two devices, and they faithfully put the date header in, as you suggest, but there's no easy way to figure out from the message content that the PUBLISH messages from these two sources are, in fact, from two sources. So, the result of that is to either require the clients to use the same callid/tags and keep bumping up the CSeq (ala the weak/brittle solution for REGISTER), or we give them an additional way to provide a token that the compositor can track against to correlate that this set of PUBLISH messages came from the same place, without getting into tag/callid mayhem. > > 5. PState Header: why is it defined that way? why not > PExpires or just Expires? A'la subscription-state. Expires is confusing. Does it mean when the message itself expires, or the content of the message? > > 6. I don't think its the PA who should decide how long a > PUBLISH is valid for. How is that possible? I publish from my > PC that's I'm available for IM for one hour, why would a PA > override that? The PA is the repository of this information, and as such needs to control how long it is responsible for such. You could apply the same logic to say that a registrar shouldn't limit the amount of time that a contact is registered for. If the client wants to stay registered for 137 years, then so be it. Same goes for event subscriptions. A PUBLISH uses finite resources at the compositor, therefore, the compositor should have final word in how long it's willing to allow those resource to be used at one shot. > > Regards, > Hisham > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C22E86.4DFCBE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Comments on PUBLISH

Comments embedded within...

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia= .com]
> Sent: Monday, July 08, 2002 7:43 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Comments on PUBLISH
>
>
> 1. The concept of Input slots seems a bit = vague. Does a slot
> represent entities that publish presence info = of the same
> type, eg: geographic location? i.e. All devices = that publish
> geographic location information fit into that = slot? If so,
> why is a use device not a GeoLoc entity?
>
> A User device can publish geographic location = information as
> well as the user's availability for voice and = IM, for
> example. How do slots work in that = scenario?
>
> Also, how does a Presence Compositor know which = publication
> belongs to which slot?
>
> Perhaps I miss understood this concept = completely.

I'll let Jonathan answer that one..

>
>
> 2. Document assumes that all presence = publication is achieved
> using PUBLISH. That is not true. A example, as = a matter of
> fact, is the GeoLoc.

The idea here is that GeoLoc, if it so wished, could = use the PUBLISH method to update a presence server. I do not believe = that the intent was to provide EVERY way of publishing presence = information via this draft, but a single, standardizable approach that = covers off as much ground as possible without becoming overly complex. = For instance, the compositor can still use registration information to = build the presence document. PUBLISH is simply one tentacle feeding the = octopus.

>
> 3. PType header: If is described as useful for = 2 things:
>
> - the document that is being published is part = of a larger
> composite document. How does PType here help? = If PType is
> defined to be "mobile", how does that = tell the compositor
> that it belongs to a larger composite document? = I would have
> thought the presentity URI would be used for = that purpose.
>
> - The document that is being published will be = applied to
> many components of the composed document. = Please give me an
> example of this. I fail to understand how this = could be done.
>
> This is something for the PUBLISH body, not a = SIP header.

The header is optional. Some compositor functions may = want more information about what to do with the message body,  = where the contents of the message body can't easily convey what is = intended. You could put the CPIM-PIDF tuple id here if you liked, or = leave it totally off.

>
> 4. PStream header: How does a header that looks = like call-id
> guarantees correct sequencing of messages? = Header like Date,
> and information in the message body seem like a = much better
> way of sequencing.

Let's say I have two devices, and they faithfully put = the date header in, as you suggest, but there's no easy way to figure = out from the message content that the PUBLISH messages from these two = sources are, in fact, from two sources. So, the result of that is to = either require the clients to use the same callid/tags and keep bumping = up the CSeq (ala the weak/brittle solution for REGISTER), or we give = them an additional way to provide a token that the compositor can track = against to correlate that this set of PUBLISH messages came from the = same place, without getting into tag/callid mayhem.

>
> 5. PState Header: why is it defined that way? = why not
> PExpires or just Expires?

A'la subscription-state. Expires is confusing. Does = it mean when the message itself expires, or the content of the = message?

>
> 6. I don't think its the PA who should decide = how long a
> PUBLISH is valid for. How is that possible? I = publish from my
> PC that's I'm available for IM for one hour, = why would a PA
> override that?

The PA is the repository of this information, and as = such needs to control how long it is responsible for such. You could = apply the same logic to say that a registrar shouldn't limit the amount = of time that a contact is registered for. If the client wants to stay = registered for 137 years, then so be it. Same goes for event = subscriptions. A PUBLISH uses finite resources at the compositor, = therefore, the compositor should have final word in how long it's = willing to allow those resource to be used at one shot.

>
> Regards,
> Hisham
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C22E86.4DFCBE60-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Jul 21 01:31:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22506 for ; Sun, 21 Jul 2002 01:31:42 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6L5V04t000119; Sun, 21 Jul 2002 01:31:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26022; Sun, 21 Jul 2002 01:31:06 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26011 for ; Sun, 21 Jul 2002 01:30:14 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6L5UCYH014701; Sun, 21 Jul 2002 01:30:12 -0400 (EDT) Message-ID: <3D3A46E3.8020900@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, pkyzivat@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED85@esebe013.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 21 Jul 2002 14:30:11 +0900 Content-Transfer-Encoding: 7bit Before I comment on this point below, let me state outright that I do NOT believe that the MESSAGE requests exist in any dialog. THe only dialog in existence is the one through INVITE. It was my belief that the "media stream" in this case was a sequence of what effectively look like page mode requests. However, I would like to provide sequencing for them, and so CSeq is natural for that. In order to use CSeq, you must have a well defined scope in which they exist. I had merely indicated that this was a "dialog ID" - meaning the To-tag, From-tag, and call-id, which does not imply the existence of a dialog. More below: aki.niemi@nokia.com wrote: >>I am certainly not an expert on RTP, but elaborating on the >>RTP stream / MESSAGE stream comparison: >>RTP services certainly include sequence numbering. > > > Much of the reason RTP would have sequence numbering probably lies in > the fact that the underlying transport protocol (UDP) provides no > guarantees on sequential delivery of packets. > > However, TCP does, so the message-session would only need the CSeq in > MESSAGE to sequence overlapping requests. As far as I know, this is > currently not allowed. With the existence of intermediary relays, you cannot guarantee end-to-end sequencing any longer. However, it occurs to me that if the URI is the point of demux at the UAS, then the scope of the sequence numbers can be within that URI. In other words, each MESSAGE in the message media stream could (and probably should, thinking about this more) have a unique call-id. The cseq increment by one for each message sent by the originating UA. The UAS will provide a URI of sufficient uniqueness that it won't receive any messages at the URI except for ones sent by the originator. Thus, the cseq can provide ordering within the scope of the r-uri as seen by the UAS. I think, however, we should focus on the bigger issue of whether this is really SIP, or whether we should go back to the older IMTP proposal. There was some debate on that during the meeting. I am still collecting thoughts on that, and welcome comments from others. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Jul 21 18:07:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11110 for ; Sun, 21 Jul 2002 18:07:13 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6LM704t001357; Sun, 21 Jul 2002 18:07:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28779; Sun, 21 Jul 2002 18:07:10 -0400 (EDT) Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.190.223.73]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28768 for ; Sun, 21 Jul 2002 18:06:55 -0400 (EDT) Received: from vas (81-86-154-229.dsl.pipex.com [81.86.154.229]) by colossus.systems.pipex.net (Postfix) with ESMTP id D04C916000340 for ; Sun, 21 Jul 2002 23:06:53 +0100 (BST) From: "Mr Vasilis Papageorgiou" To: Message-ID: <000001c23102$e9349c30$0300a8c0@vas> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C2310B.4AF90430" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Simple] SIMPLE / DynamicSoft Question Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 21 Jul 2002 23:06:42 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2310B.4AF90430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Everybody. I have couple of questions if you have couple of minutes to spare. 1. Do the DymanicSoft products include/support the presence and location extensions the SIMPLE group is working on? 2. Are there any Open Source implementations that support the SIMPLE draft extensions? Thanks in advance for your time and help. Regards Mr Vasilis Papageorgiou ------=_NextPart_000_0001_01C2310B.4AF90430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Everybody…

 

I have couple of = questions if you have couple of minutes to spare.

 

  1. Do the DymanicSoft products include/support the presence and location extensions the = SIMPLE group is working on?
  2. Are there any Open Source = implementations that support the SIMPLE draft = extensions?

 

 

Thanks in advance for = your time and help.

 

Regards

Mr Vasilis = Papageorgiou

------=_NextPart_000_0001_01C2310B.4AF90430-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 05:45:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29541 for ; Mon, 22 Jul 2002 05:45:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6M9idBc000404; Mon, 22 Jul 2002 05:44:40 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00447; Mon, 22 Jul 2002 05:43:05 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00436 for ; Mon, 22 Jul 2002 05:42:46 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M9hIi16094 for ; Mon, 22 Jul 2002 12:43:19 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 12:42:45 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 12:42:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] -05 MESSAGE and Expires header Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EA@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] -05 MESSAGE and Expires header Thread-Index: AcIuBY6OLe/FTntMQLS13f5W+xX2owDWtAdg To: , Cc: , , , , X-OriginalArrivalTime: 22 Jul 2002 09:42:45.0589 (UTC) FILETIME=[21F37850:01C23164] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA00436 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 12:42:44 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, July 18, 2002 5:25 AM > To: Adam Roach > Cc: Ben Campbell; Bobby Sardana; Vijay K. Gurbani; Tan > Ya-Ching ICMN PG > U ID A 1; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] -05 MESSAGE and Expires header > > > Expires is method specific, since its precise interpretation > is method > specific. The general notion is that it indicates a lifetime of > something; a point after which the thing is no longer valid. I think > that this more genearl definition is an exact match to our need here, > and the current Expires text is an appropriate instantiation > of it for > MESSAGE. How do you interpret "the thing is no longer valid" to mean immediate delivery? In 3261, it says about Priority header "For example, it may be factored into decisions about call routing and acceptance". So, if you want your message to be delivered immediately, you are playing with the routing, hence Priority header. Message saying "Leaving for lunch now" with Expires 0 to me says that this message expires immediately (just like a SUBSCRIBE with expires 0 means this subscription expires immediately), not that it requires immediate delivery. It also means "don't bother replying, I've left already". I think using expires for routing decisions is a hack. The questions are: - Is Priority header used for user interface purposes only, or for routing decisions as well? - When is a message urgent but does not require immediate delivery? If I need the business presentation by 10pm and its 7am, then the message does not require immediate delivery nor is it urgent, but if its 9:55pm, then its urgent and certainly needs immediate delivery. Regards, Hisham > > I believe that priority is quite different. A message can be for > immediate delivery, and be either urgent ("my house is on > fire") or not > ("leaving now for lunch"). A message can be OK for storage (some > non-zero expires) and be urgent ("I need that business > presentation by > 10pm!") or non-urgent ("Did you see that movie"). The fact that two > things can be used orthogonally is a sign that they are, in fact, two > different things. > > I strongly support keeping Expires as currently defined. > > -Jonathan R. > > Adam Roach wrote: > > Personally, I think the "Expires" handling is sufficient > > and unambiguious. > > > > The use of "Priority" would be inappropriate. High priority > > items don't necessarily have a high urgency -- and what you're > > trying to communicate here is urgency, not priority. > > > > However, I'd take a different tact: this is really a disposition > > for the message. > > > > In the final equasion, though, I think it's all a moot point, > > since "Expires: 0" works just fine. > > > > /a > > > > > >>-----Original Message----- > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>Sent: Tuesday, July 16, 2002 18:24 > >>To: Bobby Sardana > >>Cc: Vijay K. Gurbani; Tan Ya-Ching ICM N PG U ID A 1; > >>simple@mailman.dynamicsoft.com > >>Subject: Re: [Simple] -05 MESSAGE and Expires header > >> > >> > >>So, for all that have commented on this thread, is the > description of > >>Expires in RFC 3261 sufficient? If so, we can fix this by simply > >>dropping the sentence about "Expires:0". > >> > >>Or do you think the MESSAGE draft needs to contain additional > >>language > >>concerning "Priority"? > >> > >>Bobby Sardana wrote: > >> > >>>I'll cast my vote for the Priority header. Expires: 0 > >> > >>somehow implies > >> > >>>that the message needs to be dropped. > >>> > >>>regards, > >>> > >>>Bobby Sardana. > >>>dsardana@seven.com > >>> > >>>Ben Campbell wrote: > >>> > >>> > >>>>Vijay K. Gurbani wrote: > >>>> > >>>>>Tan Ya-Ching ICM N PG U ID A 1 wrote: > >>>>> > >>>>> > >>>>>>Vijay, > >>>>>> > >>>>>>It is stated in RFC 3261 section 20.19 Expires that : > >>>>>>"The precise meaning of this (header) is method dependant". > >>>>> > >>>>> > >>>>>Agreed. > >>>>> > >>>>> > >>>>>>The use of the Expires header in MESSAGE is as it is > >>>>> > >>defined in -05. > >> > >>>>>>It has > >>>>>>only one meaning, so there is no overloading. > >>>>> > >>>>> > >>>>>That is debatable; good thing about ASCII protocols is > >>>> > >>that they are > >> > >>>>>self describing. Thus, having a "Priority: Urgent" is far more > >>>>>preferable to overloading "Expires: 0" to mean immediate > >>>> > >>handling. > >> > >>>>>"Priority: Urgent" in this case makes it far more easy to figure > >>>>>out what is going on. > >>>>> > >>>>>- vijay > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>>I do not have strong feelings on this one way or another--either > >>>>approach works for me. I will bow to the will of the > >>> > >>majority. Anyone > >> > >>>>else have comments? > >>>> > >>>>_______________________________________________ > >>>>simple mailing list > >>>>simple@mailman.dynamicsoft.com > >>>>http://mailman.dynamicsoft.com/mailman/listinfo/simple > >>>> > >>> > >>>-- > >>>___________________________ > >>> > >>>Bobby Sardana | SEVEN > >>>Software Engineer, Engineering > >>>___________________________ > >>> > >>>901 Marshall St. > >>>Redwood City, CA 94063 > >>>650.381.2535 (v) > >>>650.216.6455 (f) > >>>dsardana@seven.com > >>>www.seven.com > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>simple mailing list > >>simple@mailman.dynamicsoft.com > >>http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > -- > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 06:09:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29874 for ; Mon, 22 Jul 2002 06:09:56 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MA9mBc000522; Mon, 22 Jul 2002 06:09:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00578; Mon, 22 Jul 2002 06:10:05 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00565 for ; Mon, 22 Jul 2002 06:09:46 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MAAJi03436 for ; Mon, 22 Jul 2002 13:10:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 13:09:46 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 13:09:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Comments on PUBLISH Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EB@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Comments on PUBLISH Thread-Index: AcIuhuB9iLdv0batQyayM6X6fL+tCwC3f99A To: , X-OriginalArrivalTime: 22 Jul 2002 10:09:46.0054 (UTC) FILETIME=[E7D2CE60:01C23167] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA00565 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 13:09:45 +0300 Content-Transfer-Encoding: 8bit -----Original Message----- From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, July 18, 2002 9:10 PM To: Khartabil Hisham (NMP/Helsinki); simple@mailman.dynamicsoft.com Subject: RE: [Simple] Comments on PUBLISH Comments embedded within... > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, July 08, 2002 7:43 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Comments on PUBLISH > > > >> 4. PStream header: How does a header that looks like call-id >> guarantees correct sequencing of messages? Header like Date, >> and information in the message body seem like a much better >> way of sequencing. >Let's say I have two devices, and they faithfully put the date header in, as you suggest, but there's no easy way to figure out from the message content that the PUBLISH messages from these two >sources are, in fact, from two sources. So, the result of that is to either require the clients to use the same callid/tags and keep bumping up the CSeq (ala the weak/brittle solution for >REGISTER), or we give them an additional way to provide a token that the compositor can track against to correlate that this set of PUBLISH messages came from the same place, without getting into >tag/callid mayhem. > if a publisher has to remember the value of the PSteam header and still use CSeq for sequencing, then its the same weak/brittle solution. You might as well use the call-id header and save yourself the bandwidth. If the PSteam header carried a sequence number of its own, then I can understand its purpose, but I still think that this information is better carried in the body. >> 5. PState Header: why is it defined that way? why not >> PExpires or just Expires? >A'la subscription-state. Expires is confusing. Does it mean when the message itself expires, or the content of the message? This is what the PUBLISH draft has to document. Expires is method dependent as we all know. > >> 6. I don't think its the PA who should decide how long a >> PUBLISH is valid for. How is that possible? I publish from my >> PC that's I'm available for IM for one hour, why would a PA >> override that? >The PA is the repository of this information, and as such needs to control how long it is responsible for such. You could apply the same logic to say that a registrar shouldn't limit the amount of >time that a contact is registered for. If the client wants to stay registered for 137 years, then so be it. Same goes for event subscriptions. A PUBLISH uses finite resources at the compositor, >therefore, the compositor should have final word in how long it's willing to allow those resource to be used at one shot. Ok, why is it a MUST then? How does the compositor tell the publisher that this publication is valid until you update it if the compositor doesn't care about how long the PUBLISH is valid for. Is Expires-header mandatory in PUBLISH request? If so, why? Regards, Hisham > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 06:36:19 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00219 for ; Mon, 22 Jul 2002 06:36:19 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MAa8Bc000657; Mon, 22 Jul 2002 06:36:09 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00702; Mon, 22 Jul 2002 06:35:05 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00683 for ; Mon, 22 Jul 2002 06:34:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MAZ4i20559 for ; Mon, 22 Jul 2002 13:35:05 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 13:34:31 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 13:34:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message session & associated dialog Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EC@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Message session & associated dialog Thread-Index: AcIsBC+bxZCahR/nQzK182k523SIOAFZg3hw To: , Cc: , X-OriginalArrivalTime: 22 Jul 2002 10:34:31.0657 (UTC) FILETIME=[5D4FD590:01C2316B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA00683 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 13:34:30 +0300 Content-Transfer-Encoding: 8bit Forget for a second that instant message inside a session use sip. To instantiate a session for any type of media, it being voice, video, white board, etc, we use INVITE. Now think of IM as another media, INVITE would be used for that too. It just happens that the protocol used to carry the instant messages in this case is SIP, just like RTP is used to carry audio. They are not related to signalling. Continuing to compare RTP and SIP as the media carrying protocol. The port identified in SDP is the one that is used to group the packets, so it being RTP or SIP is irrelevant. If, during signalling in the INVITE, you indicate that audio packets are received on port 45123 and IM packets are received on port 45130, then there is no need to create a dialog to group the packets. You can just use the port. To sequencing, CSeq is enough in this case since IMs are grouped together because they are received on the same port (you can replace 'port' with 'socket' if you wish. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, July 15, 2002 4:27 PM > To: Jonathan Rosenberg > Cc: Peter Päppinghaus; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Message session & associated dialog > > > Jonathan Rosenberg wrote: > > > > > draft-rosenberg-simple-message-session-00 is silent about > construction > > > of Call-ID and From and To header tags in the MESSAGE > requests sent > > > within a message session. > > > > Well, the draft was just a proposal. > > > > I guess the messages would all use the same dialog ID, with > increasing > > CSeq within the dialog. Different dialog ID than the INVITE > one, of course. > > It makes sense that all the messages share a dialog. The > question is: what causes this dialog to be established? > > There are currently two ways of establishing a dialog: > > - the 2xx reply to an INVITE can establish one > > - the 2xx reply to a SUBSCRIBE can establish one > > In the case we are discussing, MESSAGE requests are the only > thing being sent along the path where we want a dialog. But > we don't want the response to every MESSAGE request > to establish a dialog. Some possibilities: > > - send a medialess INVITE to establish a dialog, and then > send the MESSAGEs within that dialog. > > - permit the recipient of a MESSAGE to decide contextually > whether to establish a dialog. (Would require some rules to > prevent doing so when all the flow control > constraints haven't been met.) > > Sending another INVITE is straightforward, but seems a bit > circuitous and wasteful of round trips. But using the MESSAGE > to do this may lead to a blurring of the > distinction between page and session mode messaging. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 09:51:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04250 for ; Mon, 22 Jul 2002 09:51:31 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MDonBc001307; Mon, 22 Jul 2002 09:50:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01329; Mon, 22 Jul 2002 09:51:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01318 for ; Mon, 22 Jul 2002 09:50:50 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MDoSCU001960; Mon, 22 Jul 2002 09:50:28 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APZSW>; Mon, 22 Jul 2002 08:50:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2EC@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Jonathan Rosenberg , Adam Roach Cc: Ben Campbell , dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: RE: [Simple] -05 MESSAGE and Expires header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 08:50:37 -0500 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > - When is a message urgent but does not require immediate delivery? Are you proposing an "Urgency" header, or confusing priority with urgency? I'll see if I can accurately demonstrate their orthangonality. High Priority, Low Urgency: Note to new residents: failure to file income taxes by April 15th can lead to substantial penalties. Low Priority, High Urgency: You have 5 minutes to come by and pick up the rest of your lunch or I'm going to throw it away. High Priority, High Urgency: There's a tornado coming your way! Low Priority, Low Urgency: Llamas can make four distinct noises: humming, clucking, orgling, and a high pitched, rhythmic alarm sound. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 09:53:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04275 for ; Mon, 22 Jul 2002 09:52:59 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MDqlBc001343; Mon, 22 Jul 2002 09:52:47 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01361; Mon, 22 Jul 2002 09:53:04 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01344 for ; Mon, 22 Jul 2002 09:52:07 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6MDqW4V027038; Mon, 22 Jul 2002 09:52:33 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN62727; Mon, 22 Jul 2002 09:56:39 -0400 (EDT) Message-ID: <3D3C0DFD.CC504B1@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED85@esebe013.NOE.Nokia.com> <3D3A46E3.8020900@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 09:51:57 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Before I comment on this point below, let me state outright that I do > NOT believe that the MESSAGE requests exist in any dialog. THe only > dialog in existence is the one through INVITE. It was my belief that the > "media stream" in this case was a sequence of what effectively look like > page mode requests. Good! It was my (mis)interpretation that you were suggesting otherwise that set off this thread. > However, I would like to provide sequencing for > them, and so CSeq is natural for that. In order to use CSeq, you must > have a well defined scope in which they exist. I had merely indicated > that this was a "dialog ID" - meaning the To-tag, From-tag, and call-id, > which does not imply the existence of a dialog. I'm unconfortable with using "dialog ID" without there being a dialog. I can't at the moment give a solid reason why this is wrong, but it feels like an abuse. > However, it occurs to me that if the URI is the point of demux at the > UAS, then the scope of the sequence numbers can be within that URI. In > other words, each MESSAGE in the message media stream could (and > probably should, thinking about this more) have a unique call-id. The > cseq increment by one for each message sent by the originating UA. The > UAS will provide a URI of sufficient uniqueness that it won't receive > any messages at the URI except for ones sent by the originator. Thus, > the cseq can provide ordering within the scope of the r-uri as seen by > the UAS. If we continue the analogy with RTP streams, then this seems like a bad assumption. In the case of RTP, we never assume that all the packets arrive from the same source. This can be violated in many cases, such as when transferring a call, where one sender is replaced by another, but the receiver remains invariant. Why can't we rely on the message content to provide ordering, and the reliablility of the transport to guarantee delivery? Of course text content won't provide ordering, but that will provide more encouragement to use CPIM. > > I think, however, we should focus on the bigger issue of whether this is > really SIP, or whether we should go back to the older IMTP proposal. > There was some debate on that during the meeting. I am still collecting > thoughts on that, and welcome comments from others. Given a choice between SIP and something that is "almost-SIP" or an "extended-subset-of-SIP", I would choose SIP. If its not going to be SIP, then lets have something that does exactly what it needs to do in the simplest possible way. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 09:56:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04367 for ; Mon, 22 Jul 2002 09:56:35 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MDtmBc001466; Mon, 22 Jul 2002 09:55:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01409; Mon, 22 Jul 2002 09:56:05 -0400 (EDT) Received: from stamail.telecom.sna.samsung.com (mail1.sta.samsung.com [63.166.115.3]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13066 for ; Wed, 17 Jul 2002 20:09:45 -0400 (EDT) Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19) id <37042X1A>; Wed, 17 Jul 2002 19:14:18 -0500 Message-ID: <4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com> From: Kedar Patil To: "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DF0.0B573220" Subject: [Simple] Presence : Content-Length header field value Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 17 Jul 2002 19:14:12 -0500 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_01C22DF0.0B573220 Content-Type: text/plain; charset="iso-8859-1" Hi, I need some clarification about what Content-Length header field value can be. Documnet : draft-ietf-simple-presence-07.txt Section : 8. Example message flow Page : 18 ======================================================= When the value of the Content-Length header is "..." this means that the value should be whatever the computed length of the body is. ======================================================= In the first reading, this statement indicates that the string "..." (thre dots) is a valid Content-Length header field value. Co-incidentally, the examples that follow in that section also seems to be supporting this interpretation :) Please let me know, if this interpretation is correct. thanks, = Kedar = ------_=_NextPart_001_01C22DF0.0B573220 Content-Type: text/html; charset="iso-8859-1" Presence : Content-Length header field value

Hi,

I need some clarification about what Content-Length header
field value can be.

Documnet : draft-ietf-simple-presence-07.txt
Section : 8. Example message flow
Page : 18

=======================================================
When the value of the Content-Length header is "..." this means that
the value should be whatever the computed length of the body is.
=======================================================

In the first reading, this statement indicates that the string
"..." (thre dots) is a valid Content-Length header field value.
Co-incidentally, the examples that follow in that section also
seems to be supporting this interpretation :)

Please let me know, if this interpretation is correct.

thanks,
= Kedar =

------_=_NextPart_001_01C22DF0.0B573220-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 10:16:47 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04860 for ; Mon, 22 Jul 2002 10:16:47 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6ME8mBc001643; Mon, 22 Jul 2002 10:08:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01564; Mon, 22 Jul 2002 10:09:04 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01553 for ; Mon, 22 Jul 2002 10:08:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6ME8si00879 for ; Mon, 22 Jul 2002 17:08:54 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 17:08:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 17:08:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] -05 MESSAGE and Expires header Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EF@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] -05 MESSAGE and Expires header Thread-Index: AcIxhs9NeUFT/gDIQDWcRgiqq6iZqAAALEkw To: , Cc: , , , , X-OriginalArrivalTime: 22 Jul 2002 14:08:21.0129 (UTC) FILETIME=[3C45E790:01C23189] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA01553 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 17:08:20 +0300 Content-Transfer-Encoding: 8bit Well, you read my mind. I wanted to get consensus that Priority header is for user interface purposes only before I do so. Should we do something like that or are these issues part of the ieprep work? Regards, Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Monday, July 22, 2002 4:51 PM > To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach > Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; > Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] -05 MESSAGE and Expires header > > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > - When is a message urgent but does not require immediate delivery? > > Are you proposing an "Urgency" header, or confusing priority with > urgency? I'll see if I can accurately demonstrate their > orthangonality. > > High Priority, Low Urgency: > Note to new residents: failure to file income taxes by April > 15th can lead to substantial penalties. > > Low Priority, High Urgency: > You have 5 minutes to come by and pick up the rest of your lunch > or I'm going to throw it away. > > High Priority, High Urgency: > There's a tornado coming your way! > > Low Priority, Low Urgency: > Llamas can make four distinct noises: humming, clucking, > orgling, and > a high pitched, rhythmic alarm sound. > > /a > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 10:21:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04946 for ; Mon, 22 Jul 2002 10:21:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MEFlBc001735; Mon, 22 Jul 2002 10:15:47 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01631; Mon, 22 Jul 2002 10:16:04 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01620 for ; Mon, 22 Jul 2002 10:15:33 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MEG7i04587 for ; Mon, 22 Jul 2002 17:16:07 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 17:15:34 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 17:15:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Presence : Content-Length header field value Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203F0@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Presence : Content-Length header field value Thread-Index: AcIxiNvU9MBpBGm0S0K8cLRG97ba5gAALefA To: , X-OriginalArrivalTime: 22 Jul 2002 14:15:34.0206 (UTC) FILETIME=[3E6835E0:01C2318A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA01620 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 17:15:33 +0300 Content-Transfer-Encoding: 8bit "..." means the author had better things to do that count the number of bytes in the body. So to answer your question: No, its not allowed. Regards, Hisham -----Original Message----- From: ext Kedar Patil [mailto:kpatil@sta.samsung.com] Sent: Thursday, July 18, 2002 3:14 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Presence : Content-Length header field value Hi, I need some clarification about what Content-Length header field value can be. Documnet : draft-ietf-simple-presence-07.txt Section : 8. Example message flow Page : 18 ======================================================= When the value of the Content-Length header is "..." this means that the value should be whatever the computed length of the body is. ======================================================= In the first reading, this statement indicates that the string "..." (thre dots) is a valid Content-Length header field value. Co-incidentally, the examples that follow in that section also seems to be supporting this interpretation :) Please let me know, if this interpretation is correct. thanks, = Kedar = _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 10:31:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05224 for ; Mon, 22 Jul 2002 10:31:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MEVmBc001890; Mon, 22 Jul 2002 10:31:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01786; Mon, 22 Jul 2002 10:32:04 -0400 (EDT) Received: from auemail1.firewall.lucent.com ([192.11.223.161]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01775 for ; Mon, 22 Jul 2002 10:31:39 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6MEUxH09409; Mon, 22 Jul 2002 10:30:59 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA04158; Mon, 22 Jul 2002 09:29:37 -0500 (CDT) Message-ID: <3D3C16A8.6060900@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, jdrosen@dynamicsoft.com, bcampbell@dynamicsoft.com, dsardana@seven.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <2038BCC78B1AD641891A0D1AE133DBB7C203EF@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 09:28:56 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Well, you read my mind. I wanted to get consensus that Priority header > is for user interface purposes only before I do so. RFC 2076 says this about Priority: 3.9 Quality information Can be "normal", "urgent" or "non- Priority: RFC 1327, not for urgent" and can influence general usage. transmission speed and delivery. Which leads me to believe that it may *not* be for UI purposes only. > Should we do something like that or are these issues part of the ieprep > work? Good question; especially in view of the IEPREP discussion at the SIPPING WG meeting in Yokohama... Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 12:15:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10137 for ; Mon, 22 Jul 2002 12:15:06 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MGEpBc002631; Mon, 22 Jul 2002 12:14:51 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02230; Mon, 22 Jul 2002 12:15:05 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02217 for ; Mon, 22 Jul 2002 12:14:29 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGEJhZ059224; Mon, 22 Jul 2002 11:14:20 -0500 (CDT) Message-ID: <3D3C2F4E.5010300@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, adam@dynamicsoft.com, dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <2038BCC78B1AD641891A0D1AE133DBB7C203EA@esebe019.NOE.Nokia.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 11:14:06 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Thursday, July 18, 2002 5:25 AM >>To: Adam Roach >>Cc: Ben Campbell; Bobby Sardana; Vijay K. Gurbani; Tan >>Ya-Ching ICMN PG >>U ID A 1; simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] -05 MESSAGE and Expires header >> >> >>Expires is method specific, since its precise interpretation >>is method >>specific. The general notion is that it indicates a lifetime of >>something; a point after which the thing is no longer valid. I think >>that this more genearl definition is an exact match to our need here, >>and the current Expires text is an appropriate instantiation >>of it for >>MESSAGE. > > > > How do you interpret "the thing is no longer valid" to mean immediate delivery? It is a bit of a stretch, but not a _big_ stretch. I interpret to mean that the message is highly perishable. > > In 3261, it says about Priority header "For example, it may be factored into decisions about call routing and acceptance". So, if you want your message to be delivered immediately, you are playing with the routing, hence Priority header. > > Message saying "Leaving for lunch now" with Expires 0 to me says that this message expires immediately (just like a SUBSCRIBE with expires 0 means this subscription expires immediately), not that it requires immediate delivery. It also means "don't bother replying, I've left already". > > I think using expires for routing decisions is a hack. > > The questions are: > > - Is Priority header used for user interface purposes only, or for routing decisions as well? Priority can be used for routing decisions. But, as mentioned in the meeting, it should be interpreted as how high a priority the message has compared to _other_ messages. In the trivial case, where only one message is being processed, priority is meaningless. > - When is a message urgent but does not require immediate delivery? Let me step back and paint a broader picture: A store and forward device receives a message with Expires:0. It obviously wants to deliver the message immediately, but what if it can't? It should then treat the message as stale. What does it do with stale messages? That is a matter of local policy. But one perfectly reasonable option is to simply drop it on the floor. Now, that behavior makes no sense at all for a high priority message. The server wants to deliver that one quickly, but if it can't do so, it still needs to ensure the message gets delivered. That is _not_ the behavior we are looking for. For example, my boss might send me a message containing important information for a presentation I am to give tomorrow. It is not important that I get the message immediately, since the presentation is not until tomorrow. It is, however, important that I actuall _get_ the message, and that when I look at my queue of a thousand messages, I realize that this one is important for me to read. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 12:18:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10749 for ; Mon, 22 Jul 2002 12:18:51 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MGImBc002709; Mon, 22 Jul 2002 12:18:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02259; Mon, 22 Jul 2002 12:19:05 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02238 for ; Mon, 22 Jul 2002 12:16:17 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGG9hZ059311; Mon, 22 Jul 2002 11:16:09 -0500 (CDT) Message-ID: <3D3C2FBC.1090205@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, jdrosen@dynamicsoft.com, dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <2038BCC78B1AD641891A0D1AE133DBB7C203EF@esebe019.NOE.Nokia.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 11:15:56 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Well, you read my mind. I wanted to get consensus that Priority header is for user interface purposes only before I do so. As I mentioned in a separate mail, priority _can_ be used for routing purposes. But it means something different than urgency. > > Should we do something like that or are these issues part of the ieprep work? > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: Monday, July 22, 2002 4:51 PM >>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach >>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; >>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com >>Subject: RE: [Simple] -05 MESSAGE and Expires header >> >> >> >>>-----Original Message----- >>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>- When is a message urgent but does not require immediate delivery? >> >>Are you proposing an "Urgency" header, or confusing priority with >>urgency? I'll see if I can accurately demonstrate their >>orthangonality. >> >>High Priority, Low Urgency: >> Note to new residents: failure to file income taxes by April >> 15th can lead to substantial penalties. >> >>Low Priority, High Urgency: >> You have 5 minutes to come by and pick up the rest of your lunch >> or I'm going to throw it away. >> >>High Priority, High Urgency: >> There's a tornado coming your way! >> >>Low Priority, Low Urgency: >> Llamas can make four distinct noises: humming, clucking, >>orgling, and >> a high pitched, rhythmic alarm sound. >> >>/a >> > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 12:23:54 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11434 for ; Mon, 22 Jul 2002 12:23:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MGNmBc002853; Mon, 22 Jul 2002 12:23:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02329; Mon, 22 Jul 2002 12:24:05 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02318 for ; Mon, 22 Jul 2002 12:23:31 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGNVhZ059899; Mon, 22 Jul 2002 11:23:32 -0500 (CDT) Message-ID: <3D3C3174.7050507@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kedar Patil CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Presence : Content-Length header field value References: <4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 11:23:16 -0500 Content-Transfer-Encoding: 7bit Kedar Patil wrote: > Hi, > > I need some clarification about what Content-Length header > field value can be. > > Documnet : draft-ietf-simple-presence-07.txt > Section : 8. Example message flow > Page : 18 > > ======================================================= > When the value of the Content-Length header is "..." this means that > the value should be whatever the computed length of the body is. > ======================================================= > > In the first reading, this statement indicates that the string > "..." (thre dots) is a valid Content-Length header field value. > Co-incidentally, the examples that follow in that section also > seems to be supporting this interpretation :) > > Please let me know, if this interpretation is correct. > > thanks, > = Kedar = > No, it is not. I believe the "..." is simply a documentation convention that means, "in a real message, there would be a real value here." That is, it is a rather tedious task to make sure the content-length headers are correct in example flows, and the editor chose not to do it. A real message would be generated by a machine, which generally do not find counting octets to be quite so tedious :-) _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 12:31:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12455 for ; Mon, 22 Jul 2002 12:30:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MGUmBc002962; Mon, 22 Jul 2002 12:30:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02404; Mon, 22 Jul 2002 12:31:05 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02393 for ; Mon, 22 Jul 2002 12:30:12 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGUChZ060419; Mon, 22 Jul 2002 11:30:13 -0500 (CDT) Message-ID: <3D3C3307.9040605@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker CC: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Comments on PUBLISH References: <933FADF5E673D411B8A30002A5608A0E04B470AE@zrc2c012.us.nortel.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Jul 2002 11:29:59 -0500 Content-Transfer-Encoding: 7bit Brian Stucker wrote: > Comments embedded within... > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, July 08, 2002 7:43 AM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] Comments on PUBLISH > > > > > > 1. The concept of Input slots seems a bit vague. Does a slot > > represent entities that publish presence info of the same > > type, eg: geographic location? i.e. All devices that publish > > geographic location information fit into that slot? If so, > > why is a use device not a GeoLoc entity? > > > > A User device can publish geographic location information as > > well as the user's availability for voice and IM, for > > example. How do slots work in that scenario? > > > > Also, how does a Presence Compositor know which publication > > belongs to which slot? > > > > Perhaps I miss understood this concept completely. > > I'll let Jonathan answer that one.. I'm not Jonathan, nor do I play him on TV--but I will jump in anyway: Isn't that what the proposed ptype header is for? > > > > > > > 2. Document assumes that all presence publication is achieved > > using PUBLISH. That is not true. A example, as a matter of > > fact, is the GeoLoc. > > The idea here is that GeoLoc, if it so wished, could use the PUBLISH > method to update a presence server. I do not believe that the intent was > to provide EVERY way of publishing presence information via this draft, > but a single, standardizable approach that covers off as much ground as > possible without becoming overly complex. For instance, the compositor > can still use registration information to build the presence document. > PUBLISH is simply one tentacle feeding the octopus. Certainly, the compositor is not limited to using PUBLISH. We are just not in the business of standardizing all methods a compositor can choose to use. The compositor might periodically query a geoloc server. Or maybe someone builds a geoloc server to PUBLISH adapter. As long as the compositor has enough information to make policy decisions on how to compose the input, it could be anything. > > > > > 3. PType header: If is described as useful for 2 things: > > > > - the document that is being published is part of a larger > > composite document. How does PType here help? If PType is > > defined to be "mobile", how does that tell the compositor > > that it belongs to a larger composite document? I would have > > thought the presentity URI would be used for that purpose. The compositor decides whether the input should be composed or not, based on it's local policy for the "mobile" slot. > > > > - The document that is being published will be applied to > > many components of the composed document. Please give me an > > example of this. I fail to understand how this could be done. > > > > This is something for the PUBLISH body, not a SIP header. > > The header is optional. Some compositor functions may want more > information about what to do with the message body, where the contents > of the message body can't easily convey what is intended. You could put > the CPIM-PIDF tuple id here if you liked, or leave it totally off. > > > > > 4. PStream header: How does a header that looks like call-id > > guarantees correct sequencing of messages? Header like Date, > > and information in the message body seem like a much better > > way of sequencing. > > Let's say I have two devices, and they faithfully put the date header > in, as you suggest, but there's no easy way to figure out from the > message content that the PUBLISH messages from these two sources are, in > fact, from two sources. So, the result of that is to either require the > clients to use the same callid/tags and keep bumping up the CSeq (ala > the weak/brittle solution for REGISTER), or we give them an additional > way to provide a token that the compositor can track against to > correlate that this set of PUBLISH messages came from the same place, > without getting into tag/callid mayhem. > > > > > 5. PState Header: why is it defined that way? why not > > PExpires or just Expires? > > A'la subscription-state. Expires is confusing. Does it mean when the > message itself expires, or the content of the message? > > > > > 6. I don't think its the PA who should decide how long a > > PUBLISH is valid for. How is that possible? I publish from my > > PC that's I'm available for IM for one hour, why would a PA > > override that? > > The PA is the repository of this information, and as such needs to > control how long it is responsible for such. You could apply the same > logic to say that a registrar shouldn't limit the amount of time that a > contact is registered for. If the client wants to stay registered for > 137 years, then so be it. Same goes for event subscriptions. A PUBLISH > uses finite resources at the compositor, therefore, the compositor > should have final word in how long it's willing to allow those resource > to be used at one shot. > > > > > Regards, > > Hisham > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 22 18:17:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15394 for ; Mon, 22 Jul 2002 18:17:09 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MMGxBc004899; Mon, 22 Jul 2002 18:16:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03463; Mon, 22 Jul 2002 18:17:06 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03452 for ; Mon, 22 Jul 2002 18:16:38 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6MGQO123602; Mon, 22 Jul 2002 11:26:26 -0500 Subject: Re: [Simple] Presence : Content-Length header field value From: Robert Sparks To: Kedar Patil Cc: "'simple@mailman.dynamicsoft.com'" In-Reply-To: <4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com> References: <4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Message-Id: <1027375815.10985.26.camel@dhcp26.dfw.dynamicsoft.com> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 23 Jul 2002 07:10:12 +0900 Content-Transfer-Encoding: 7bit No. "..." is only an editorial convention used in the document. A message on the wire must have an integer value equal to the number of octets in the body. The body starts after the null line at the end of the headers. See rfc3261 if you need more detail. RjS On Thu, 2002-07-18 at 09:14, Kedar Patil wrote: > Hi, > > I need some clarification about what Content-Length header > field value can be. > > Documnet : draft-ietf-simple-presence-07.txt > Section : 8. Example message flow > Page : 18 > > ======================================================= > When the value of the Content-Length header is "..." this means that > the value should be whatever the computed length of the body is. > ======================================================= > > In the first reading, this statement indicates that the string > "..." (thre dots) is a valid Content-Length header field value. > Co-incidentally, the examples that follow in that section also > seems to be supporting this interpretation :) > > Please let me know, if this interpretation is correct. > > thanks, > = Kedar = > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 03:52:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02682 for ; Tue, 23 Jul 2002 03:52:55 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6N7qnBc006482; Tue, 23 Jul 2002 03:52:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05021; Tue, 23 Jul 2002 03:53:05 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA05010 for ; Tue, 23 Jul 2002 03:52:11 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 07:52:33 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45730E094814E44488F789C1CDED27AE018C23D4@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: Message Transport Protocol (SIP vs IMTP) Thread-Index: AcIyHfPFtloBi+BNRIOOsdn4jKRWpA== From: "James Undery" To: "SIMPLE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA05010 Subject: [Simple] Message Transport Protocol (SIP vs IMTP) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 08:52:54 +0100 Content-Transfer-Encoding: 8bit Hi, At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft. James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 04:46:40 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03756 for ; Tue, 23 Jul 2002 04:46:40 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6N8hoBc006689; Tue, 23 Jul 2002 04:43:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05246; Tue, 23 Jul 2002 04:44:04 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05235 for ; Tue, 23 Jul 2002 04:43:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6N8i2i13195 for ; Tue, 23 Jul 2002 11:44:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 11:43:29 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 11:43:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203F7@esebe019.NOE.Nokia.com> Thread-Topic: Message Transport Protocol (SIP vs IMTP) Thread-Index: AcIyHfPFtloBi+BNRIOOsdn4jKRWpAABvFsA To: , X-OriginalArrivalTime: 23 Jul 2002 08:43:28.0935 (UTC) FILETIME=[046EE370:01C23225] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA05235 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 11:43:27 +0300 Content-Transfer-Encoding: 8bit And how many of those RFC2543 complaint proxies will you see deployed in a year's time? /Hisham > -----Original Message----- > From: ext James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, July 23, 2002 10:53 AM > To: SIMPLE (E-mail) > Subject: [Simple] Message Transport Protocol (SIP vs IMTP) > > > Hi, > > At the SIMPLE meeting I believe the consensus was to go with > a SIP based message transport, however, it was unclear if > this should be SIP or IMTP. The argument for SIP is because > of rfc3261 we can now use SIP as is, IMTP was complicated due > to all the requirements of messaging that couldn't be > addressed easily; I'd definitely agree with that, however, I > believe that won't work, rfc2543 proxies may still do all the > bad things IMTP was designed to avoid. The suggestion made by > Rohan (that I strongly agree with) was to take rfc3261 and > just swap SIP/2.0 for IMTP/1.0 every time the protocol is > mentioned in the spec. This has the advantage that you know > older proxies aren't going to misbehave and the draft > specifying it should be trivial modification to Jonathan's > latest draft. > > James > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 05:30:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04398 for ; Tue, 23 Jul 2002 05:30:57 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6N9UnBc006871; Tue, 23 Jul 2002 05:30:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05443; Tue, 23 Jul 2002 05:31:05 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA05432 for ; Tue, 23 Jul 2002 05:30:14 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 09:30:36 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Message-ID: <45730E094814E44488F789C1CDED27AE018C23D6@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: Message Transport Protocol (SIP vs IMTP) Thread-Index: AcIyHfPFtloBi+BNRIOOsdn4jKRWpAABvFsAAAE/+xA= From: "James Undery" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA05432 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 10:30:58 +0100 Content-Transfer-Encoding: 8bit There are also other advantages. If it is clear that IMTP is different from SIP this allows more targeted filtering just like SOAP RPC calls over HTTP don't ;-) (Note the much touted firewall avoidance power of SOAP over HTTP is considered a bad thing by the security community, IM is less of a concern but helping administrative policies to be enforced surely is good) James P.S. More than one which is all that matters. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: 23 July 2002 09:43 > To: James Undery; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) > > > And how many of those RFC2543 complaint proxies will you see > deployed in a year's time? > > /Hisham > > > -----Original Message----- > > From: ext James Undery [mailto:jundery@ubiquity.net] > > Sent: Tuesday, July 23, 2002 10:53 AM > > To: SIMPLE (E-mail) > > Subject: [Simple] Message Transport Protocol (SIP vs IMTP) > > > > > > Hi, > > > > At the SIMPLE meeting I believe the consensus was to go with > > a SIP based message transport, however, it was unclear if > > this should be SIP or IMTP. The argument for SIP is because > > of rfc3261 we can now use SIP as is, IMTP was complicated due > > to all the requirements of messaging that couldn't be > > addressed easily; I'd definitely agree with that, however, I > > believe that won't work, rfc2543 proxies may still do all the > > bad things IMTP was designed to avoid. The suggestion made by > > Rohan (that I strongly agree with) was to take rfc3261 and > > just swap SIP/2.0 for IMTP/1.0 every time the protocol is > > mentioned in the spec. This has the advantage that you know > > older proxies aren't going to misbehave and the draft > > specifying it should be trivial modification to Jonathan's > > latest draft. > > > > James > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 09:10:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10287 for ; Tue, 23 Jul 2002 09:10:06 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6ND9oBc007606; Tue, 23 Jul 2002 09:09:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06185; Tue, 23 Jul 2002 09:10:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06172 for ; Tue, 23 Jul 2002 09:09:11 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6ND9jA9004560; Tue, 23 Jul 2002 09:09:46 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN69924; Tue, 23 Jul 2002 09:13:52 -0400 (EDT) Message-ID: <3D3D5576.B3229C5D@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: "SIMPLE (E-mail)" Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) References: <45730E094814E44488F789C1CDED27AE018C23D4@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 09:09:10 -0400 Content-Transfer-Encoding: 7bit James Undery wrote: > > Hi, > > At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft. To avoid misbehaving proxies, shouldn't it be sufficient to do something like Proxy-Require: message_session or something to that effect? Changing the version requires much more mucking in the stack. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 09:36:25 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11430 for ; Tue, 23 Jul 2002 09:36:25 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NDSmBc007784; Tue, 23 Jul 2002 09:28:48 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06278; Tue, 23 Jul 2002 09:29:05 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA06267 for ; Tue, 23 Jul 2002 09:28:02 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 13:28:26 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Message-ID: <45730E094814E44488F789C1CDED27AE018C23D9@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Simple] Message Transport Protocol (SIP vs IMTP) Thread-Index: AcIySj8sS3kZ06lIQaiAkXCKTJvFewAAXHtg From: "James Undery" To: "Paul Kyzivat" Cc: "SIMPLE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA06267 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 14:28:47 +0100 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > James Undery wrote: > > > > Hi, > > > > At the SIMPLE meeting I believe the consensus was to go > with a SIP based message transport, however, it was unclear > if this should be SIP or IMTP. The argument for SIP is > because of rfc3261 we can now use SIP as is, IMTP was > complicated due to all the requirements of messaging that > couldn't be addressed easily; I'd definitely agree with that, > however, I believe that won't work, rfc2543 proxies may still > do all the bad things IMTP was designed to avoid. The > suggestion made by Rohan (that I strongly agree with) was to > take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time > the protocol is mentioned in the spec. This has the advantage > that you know older proxies aren't going to misbehave and the > draft specifying it should be trivial modification to > Jonathan's latest draft. > > To avoid misbehaving proxies, shouldn't it be sufficient to > do something like > > Proxy-Require: message_session > > or something to that effect? Changing the version requires > much more mucking in the stack. This is really an implementation's flexibility issue. In soem implementations changing the Protocol can allow for greater efficiency in application servers where modules handle headers like Proxy-Requires. I wouldn't have a problem with Proxy-Require it'd just be nice to think it through. James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 11:03:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16007 for ; Tue, 23 Jul 2002 11:03:30 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NEtqBc008361; Tue, 23 Jul 2002 10:55:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06651; Tue, 23 Jul 2002 10:56:07 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06640 for ; Tue, 23 Jul 2002 10:55:07 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NEt0d01362; Tue, 23 Jul 2002 09:55:00 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 09:54:46 -0500 Message-ID: From: "Sriram Parameswar" To: "'Paul Kyzivat'" , James Undery Cc: "SIMPLE (E-mail)" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23258.DDCE2260" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 09:54:37 -0500 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_01C23258.DDCE2260 Content-Type: text/plain; charset="iso-8859-1" Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a 420 Bad Extension? Is this the behavior we want? After all we want the IM Session to succeed in most cases. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, July 23, 2002 8:09 AM To: James Undery Cc: SIMPLE (E-mail) Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) James Undery wrote: > > Hi, > > At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft. To avoid misbehaving proxies, shouldn't it be sufficient to do something like Proxy-Require: message_session or something to that effect? Changing the version requires much more mucking in the stack. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C23258.DDCE2260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Message Transport Protocol (SIP vs IMTP)

Wouldn't a 'Proxy-Require: message_session' cause the = proxy to send back a 420 Bad Extension? Is this the behavior we want? = After all we want the IM Session to succeed in most cases.

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=
Sent: Tuesday, July 23, 2002 8:09 AM
To: James Undery
Cc: SIMPLE (E-mail)
Subject: Re: [Simple] Message Transport Protocol = (SIP vs IMTP)




James Undery wrote:
>
> Hi,
>
> At the SIMPLE meeting I believe the consensus = was to go with a SIP based message transport, however, it was unclear = if this should be SIP or IMTP. The argument for SIP is because of = rfc3261 we can now use SIP as is, IMTP was complicated due to all the = requirements of messaging that couldn't be addressed easily; I'd = definitely agree with that, however, I believe that won't work, rfc2543 = proxies may still do all the bad things IMTP was designed to avoid. The = suggestion made by Rohan (that I strongly agree with) was to take  = rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is = mentioned in the spec. This has the advantage that you know older = proxies aren't going to misbehave and the draft specifying it should be = trivial modification to Jonathan's latest draft.

To avoid misbehaving proxies, shouldn't it be = sufficient to do something like

        Proxy-Require: message_session

or something to that effect? Changing the version = requires much more mucking in the stack.

        Paul
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple=

------_=_NextPart_001_01C23258.DDCE2260-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 11:26:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17519 for ; Tue, 23 Jul 2002 11:26:21 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NFInBc008567; Tue, 23 Jul 2002 11:18:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06754; Tue, 23 Jul 2002 11:19:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06743 for ; Tue, 23 Jul 2002 11:18:00 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6NFIX2T020434; Tue, 23 Jul 2002 11:18:33 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN71211; Tue, 23 Jul 2002 11:22:41 -0400 (EDT) Message-ID: <3D3D73A7.F250C48E@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sriram Parameswar CC: James Undery , "SIMPLE (E-mail)" Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 11:17:59 -0400 Content-Transfer-Encoding: 7bit This would require use of proxies that support my hypothetical "message_session" extension. That extension would require use of the rfc 3261 features, and could otherwise be empty. If you like, we could make it "Proxy-Require: rfc3261". Any proxy supporting 3261 should be able to comply, and the whole point is to exclude those that don't. If you get a 420 back, then the message stream path was incorrectly defined. Paul > Sriram Parameswar wrote: > > Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a 420 Bad Extension? Is this the behavior we want? After all we want the IM Session to succeed in > most cases. > > Regards, > > Sriram > > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, July 23, 2002 8:09 AM > To: James Undery > Cc: SIMPLE (E-mail) > Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) > > James Undery wrote: > > > > Hi, > > > > At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP > is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with > that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree > with) was to take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't > going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft. > > To avoid misbehaving proxies, shouldn't it be sufficient to do something like > > Proxy-Require: message_session > > or something to that effect? Changing the version requires much more mucking in the stack. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 11:40:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18938 for ; Tue, 23 Jul 2002 11:40:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NFWoBc008744; Tue, 23 Jul 2002 11:32:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06843; Tue, 23 Jul 2002 11:33:04 -0400 (EDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA06832 for ; Tue, 23 Jul 2002 11:32:44 -0400 (EDT) Received: from 12-235-154-217.client.attbi.com (HELO BOB) (seancolson@12.235.154.217 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jul 2002 15:32:44 -0000 Reply-To: From: "Sean Olson" To: "'Sriram Parameswar'" , "'Paul Kyzivat'" , "'James Undery'" Cc: "'SIMPLE \(E-mail\)'" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Message-ID: <003601c2325e$31fdb3a0$6401a8c0@BOB> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C23223.85A06240" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 08:32:45 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C23223.85A06240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't see the benefits of using IMTP as a protocol identifier in this case. In fact, I think it negates some of the benefits of using SIP as the underlying protocol altogether. What you really want in this case is MESSAGE-specific behavior. Or did people have the notion of sending something other than MESSAGE in this "IMTP" transport? I really dislike the notion of receiving a 420 in this situation. Because a session was explicitly established with a policy to route MESSAGEs through some set of intermediaries, it seems a bit odd that these intermediaries wouldn't be able to handle MESSAGE (or for that matter, loose routing if needed) /sean -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Sriram Parameswar Sent: Tuesday, July 23, 2002 7:55 AM To: 'Paul Kyzivat'; James Undery Cc: SIMPLE (E-mail) Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a 420 Bad Extension? Is this the behavior we want? After all we want the IM Session to succeed in most cases. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, July 23, 2002 8:09 AM To: James Undery Cc: SIMPLE (E-mail) Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) James Undery wrote: > > Hi, > > At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft. To avoid misbehaving proxies, shouldn't it be sufficient to do something like Proxy-Require: message_session or something to that effect? Changing the version requires much more mucking in the stack. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------=_NextPart_000_0037_01C23223.85A06240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I = don't see the=20 benefits of using IMTP as a protocol identifier in this case. In = fact, I=20 think it negates
some of the=20 benefits of using SIP as the underlying protocol altogether. What you = really=20 want in this case
is=20 MESSAGE-specific behavior. Or did people have the notion of sending = something=20 other than MESSAGE
in = this "IMTP"=20 transport? I really dislike the notion of receiving a 420 in this = situation.=20 Because a session
was = explicitly=20 established with a policy to route MESSAGEs through some set of = intermediaries,=20 it seems
a = bit odd that=20 these intermediaries wouldn't be able to handle MESSAGE (or for that = matter,=20 loose routing
if=20 needed)
 
/sean
-----Original Message-----
From:=20 simple-admin@mailman.dynamicsoft.com=20 [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of = Sriram=20 Parameswar
Sent: Tuesday, July 23, 2002 7:55 = AM
To: 'Paul=20 Kyzivat'; James Undery
Cc: SIMPLE = (E-mail)
Subject: RE:=20 [Simple] Message Transport Protocol (SIP vs IMTP)

Wouldn't a 'Proxy-Require: message_session' cause = the proxy to=20 send back a 420 Bad Extension? Is this the behavior we want? After all = we want=20 the IM Session to succeed in most cases.

Regards,

Sriram

__________________________________________ =
Sriram=20 = Parameswar          &nb= sp;  =20 Phone: 972-685-8540
Interactive Multimedia = Server=20 (IMS) Fax: 972-684-3986
Nortel Networks, = Richardson=20 USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Paul=20 Kyzivat [mailto:pkyzivat@cisco.com] =
Sent: Tuesday, July 23, 2002 8:09 AM =
To: James Undery
Cc: SIMPLE = (E-mail)=20
Subject: Re: [Simple] Message Transport Protocol = (SIP vs=20 IMTP)




James Undery wrote:
>=20
> Hi,
> =
> At the SIMPLE meeting I believe the consensus was to go = with a SIP=20 based message transport, however, it was unclear if this should be SIP = or=20 IMTP. The argument for SIP is because of rfc3261 we can now use SIP as = is,=20 IMTP was complicated due to all the requirements of messaging that = couldn't be=20 addressed easily; I'd definitely agree with that, however, I believe = that=20 won't work, rfc2543 proxies may still do all the bad things IMTP was = designed=20 to avoid. The suggestion made by Rohan (that I strongly agree with) = was to=20 take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the = protocol=20 is mentioned in the spec. This has the advantage that you know older = proxies=20 aren't going to misbehave and the draft specifying it should be = trivial=20 modification to Jonathan's latest draft.

To avoid misbehaving proxies, shouldn't it be = sufficient to do=20 something like

        Proxy-Require:=20 message_session

or something to that effect? Changing the version = requires=20 much more mucking in the stack.

        Paul=20
_______________________________________________=20
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple=20

------=_NextPart_000_0037_01C23223.85A06240-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 11:54:20 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19552 for ; Tue, 23 Jul 2002 11:54:19 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NFknBc008929; Tue, 23 Jul 2002 11:46:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06917; Tue, 23 Jul 2002 11:47:05 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA06906 for ; Tue, 23 Jul 2002 11:46:52 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 15:47:14 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Message-ID: <45730E094814E44488F789C1CDED27AE018C23DC@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Simple] Message Transport Protocol (SIP vs IMTP) Thread-Index: AcIyXkwY1rPdpyapSN2UFPJKA7luPwAAec3g From: "James Undery" To: Cc: "SIMPLE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA06906 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 16:47:36 +0100 Content-Transfer-Encoding: 8bit I think you may be missing the point of this. The reason for not using SIP originally was the worry IM would be used to transfer huge files such as mp3s. To counter this Jonathan created a cut down version of SIP called IMTP, once loose routing and TCP requirements were introduced into the bis spec this cut down version wasn't required. The crunch is it's obviously still required for non 3261 entities to prevent UDP and old Record Route nastiness occurring. Proxy-Require, new Protocol or some other solution something needs to be done. James P.S. If rfc2543 proxies are a non-issue can't we just deprecate UDP while we're at it ;-) -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: 23 July 2002 16:33 To: 'Sriram Parameswar'; 'Paul Kyzivat'; James Undery Cc: 'SIMPLE (E-mail)' Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) I don't see the benefits of using IMTP as a protocol identifier in this case. In fact, I think it negates some of the benefits of using SIP as the underlying protocol altogether. What you really want in this case is MESSAGE-specific behavior. Or did people have the notion of sending something other than MESSAGE in this "IMTP" transport? I really dislike the notion of receiving a 420 in this situation. Because a session was explicitly established with a policy to route MESSAGEs through some set of intermediaries, it seems a bit odd that these intermediaries wouldn't be able to handle MESSAGE (or for that matter, loose routing if needed) /sean -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Sriram Parameswar Sent: Tuesday, July 23, 2002 7:55 AM To: 'Paul Kyzivat'; James Undery Cc: SIMPLE (E-mail) Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a 420 Bad Extension? Is this the behavior we want? After all we want the IM Session to succeed in most cases. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, July 23, 2002 8:09 AM To: James Undery Cc: SIMPLE (E-mail) Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) James Undery wrote: > > Hi, > > At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft. To avoid misbehaving proxies, shouldn't it be sufficient to do something like Proxy-Require: message_session or something to that effect? Changing the version requires much more mucking in the stack. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 12:46:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22590 for ; Tue, 23 Jul 2002 12:46:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NGdtBc009270; Tue, 23 Jul 2002 12:39:55 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07164; Tue, 23 Jul 2002 12:40:06 -0400 (EDT) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA07149 for ; Tue, 23 Jul 2002 12:39:08 -0400 (EDT) Message-ID: <20020723163908.50599.qmail@web11607.mail.yahoo.com> Received: from [131.107.3.79] by web11607.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 09:39:08 PDT From: Sean Olson Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) To: James Undery Cc: "SIMPLE \(E-mail\)" In-Reply-To: <45730E094814E44488F789C1CDED27AE018C23DC@GBNEWP0758M.eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 09:39:08 -0700 (PDT) Actually, I completely understand the point of the original IMTP proposal :) And BTW, calling it IMTP does *NOTHING* to fix these problems. (By this, I mean changing the protocol identifier to IMTP) Sure, you can define a new profile for SIP, label it IMTP and assume everything goes well. But let's be honest. Calling it IMTP will NOT stop people from sending large files via IM. It will NOT solve the congestion control problem. It will NOT allow you to magically work with non-3261 entities. I'm not claiming that 2543 proxies are a non-issue. I am claiming that you can't take a 2543 proxy out of the box and run IMTP or any other new profile of SIP through it. If you want to support "IMTP" (or whatever we label it), you are going to have to do some work. I don't think it's unreasonable to make 3261 compliance part of that work. You can still route the INVITE for the message session through the older 2543 proxies, you will just need something new for the "media". /sean P.S. While I'm the last person to admit, I think UDP for SIP is on its deathbed ;-) --- James Undery wrote: > > I think you may be missing the point of this. The > reason for not using SIP originally was the worry IM > would be used to transfer huge files such as mp3s. > To counter this Jonathan created a cut down version > of SIP called IMTP, once loose routing and TCP > requirements were introduced into the bis spec this > cut down version wasn't required. The crunch is it's > obviously still required for non 3261 entities to > prevent UDP and old Record Route nastiness > occurring. Proxy-Require, new Protocol or some other > solution something needs to be done. > > James > > P.S. If rfc2543 proxies are a non-issue can't we > just deprecate UDP while we're at it ;-) > > > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: 23 July 2002 16:33 > To: 'Sriram Parameswar'; 'Paul Kyzivat'; James > Undery > Cc: 'SIMPLE (E-mail)' > Subject: RE: [Simple] Message Transport Protocol > (SIP vs IMTP) > > > I don't see the benefits of using IMTP as a protocol > identifier in this case. In fact, I think it negates > some of the benefits of using SIP as the underlying > protocol altogether. What you really want in this > case > is MESSAGE-specific behavior. Or did people have the > notion of sending something other than MESSAGE > in this "IMTP" transport? I really dislike the > notion of receiving a 420 in this situation. Because > a session > was explicitly established with a policy to route > MESSAGEs through some set of intermediaries, it > seems > a bit odd that these intermediaries wouldn't be able > to handle MESSAGE (or for that matter, loose routing > if needed) > > /sean > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On > Behalf Of Sriram Parameswar > Sent: Tuesday, July 23, 2002 7:55 AM > To: 'Paul Kyzivat'; James Undery > Cc: SIMPLE (E-mail) > Subject: RE: [Simple] Message Transport Protocol > (SIP vs IMTP) > > > Wouldn't a 'Proxy-Require: message_session' cause > the proxy to send back a 420 Bad Extension? Is this > the behavior we want? After all we want the IM > Session to succeed in most cases. > Regards, > Sriram > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: > 972-684-3986 > Nortel Networks, Richardson USA Email: > sriramp@nortelnetworks.com > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, July 23, 2002 8:09 AM > To: James Undery > Cc: SIMPLE (E-mail) > Subject: Re: [Simple] Message Transport Protocol > (SIP vs IMTP) > > > > > James Undery wrote: > > > > Hi, > > > > At the SIMPLE meeting I believe the consensus was > to go with a SIP based message transport, however, > it was unclear if this should be SIP or IMTP. The > argument for SIP is because of rfc3261 we can now > use SIP as is, IMTP was complicated due to all the > requirements of messaging that couldn't be addressed > easily; I'd definitely agree with that, however, I > believe that won't work, rfc2543 proxies may still > do all the bad things IMTP was designed to avoid. > The suggestion made by Rohan (that I strongly agree > with) was to take rfc3261 and just swap SIP/2.0 for > IMTP/1.0 every time the protocol is mentioned in the > spec. This has the advantage that you know older > proxies aren't going to misbehave and the draft > specifying it should be trivial modification to > Jonathan's latest draft. > To avoid misbehaving proxies, shouldn't it be > sufficient to do something like > Proxy-Require: message_session > or something to that effect? Changing the version > requires much more mucking in the stack. > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 13:21:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24820 for ; Tue, 23 Jul 2002 13:21:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NHKoBc009564; Tue, 23 Jul 2002 13:20:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07318; Tue, 23 Jul 2002 13:21:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07307 for ; Tue, 23 Jul 2002 13:20:34 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6NHL7qR010021; Tue, 23 Jul 2002 13:21:08 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN72351; Tue, 23 Jul 2002 13:25:14 -0400 (EDT) Message-ID: <3D3D9060.381B578D@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: James Undery , "SIMPLE (E-mail)" Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) References: <20020723163908.50599.qmail@web11607.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 13:20:32 -0400 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > I'm not claiming that 2543 proxies are a non-issue. > I am claiming that you can't take a 2543 proxy out > of the box and run IMTP or any other new profile of > SIP through it. If you want to support "IMTP" > (or whatever we label it), you are going to have to > do some work. I don't think it's unreasonable to > make 3261 compliance part of that work. You can > still route the INVITE for the message session through > the older 2543 proxies, you will just need something > new for the "media". I'm not sure I get your point - I suspect we are in violent agreement. Is anyone arguing that you don't need something new for message sessions? If all you currently have is 2543 based, then of course you do. But it would be nice if the only new thing you needed was a path through 3261 compatible proxies. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 13:36:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25561 for ; Tue, 23 Jul 2002 13:36:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NHZpBc009700; Tue, 23 Jul 2002 13:35:51 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07403; Tue, 23 Jul 2002 13:36:05 -0400 (EDT) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA07390 for ; Tue, 23 Jul 2002 13:35:01 -0400 (EDT) Message-ID: <20020723173500.65101.qmail@web11608.mail.yahoo.com> Received: from [207.46.225.252] by web11608.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 10:35:00 PDT From: Sean Olson Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) To: Paul Kyzivat Cc: James Undery , "SIMPLE \(E-mail\)" In-Reply-To: <3D3D9060.381B578D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 10:35:00 -0700 (PDT) I think we are saying the same thing then. The one (I believe small) difference of opinion I have with Rohan's proposal is that I don't think we should call this IMTP. I think it should be labelled "SIP/2.0" /sean --- Paul Kyzivat wrote: > Sean Olson wrote: > > > > I'm not claiming that 2543 proxies are a > non-issue. > > I am claiming that you can't take a 2543 proxy out > > of the box and run IMTP or any other new profile > of > > SIP through it. If you want to support "IMTP" > > (or whatever we label it), you are going to have > to > > do some work. I don't think it's unreasonable to > > make 3261 compliance part of that work. You can > > still route the INVITE for the message session > through > > the older 2543 proxies, you will just need > something > > new for the "media". > > I'm not sure I get your point - I suspect we are in > violent agreement. > > Is anyone arguing that you don't need something new > for message sessions? If all you currently have is > 2543 based, then of course you do. But it would be > nice if the only > new thing you needed was a path through 3261 > compatible proxies. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 13:59:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26679 for ; Tue, 23 Jul 2002 13:59:10 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NHwoBc009870; Tue, 23 Jul 2002 13:58:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07516; Tue, 23 Jul 2002 13:59:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07505 for ; Tue, 23 Jul 2002 13:58:35 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6NHx9ZP014319; Tue, 23 Jul 2002 13:59:09 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN72708; Tue, 23 Jul 2002 14:03:17 -0400 (EDT) Message-ID: <3D3D994B.17125D4F@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: James Undery , "SIMPLE (E-mail)" Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) References: <20020723173500.65101.qmail@web11608.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 13:58:35 -0400 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > I think we are saying the same thing then. > The one (I believe small) difference of opinion > I have with Rohan's proposal is that I don't > think we should call this IMTP. I think it should > be labelled "SIP/2.0" Well (sorry Rohan) I don't like that much either. To support it I have to hack every proxy to accept either "SIP/2.0" or "IMTP/1.0", remember it, and put it into responses. This is a pretty invasive change to the stack. If I have a 3261 compatible stack, it ought to be easier than that. Hence my suggestion for Proxy-Require - it has exactly the right semantics: proxies that don't support it are supposed to complain. And the hooks to handle it should be easy in most stacks. (Of course non-compliant stacks could ignore it. But they could ignore the version too. You can't protect against all forms of stupidity.) Paul > > /sean > > --- Paul Kyzivat wrote: > > Sean Olson wrote: > > > > > > I'm not claiming that 2543 proxies are a > > non-issue. > > > I am claiming that you can't take a 2543 proxy out > > > of the box and run IMTP or any other new profile > > of > > > SIP through it. If you want to support "IMTP" > > > (or whatever we label it), you are going to have > > to > > > do some work. I don't think it's unreasonable to > > > make 3261 compliance part of that work. You can > > > still route the INVITE for the message session > > through > > > the older 2543 proxies, you will just need > > something > > > new for the "media". > > > > I'm not sure I get your point - I suspect we are in > > violent agreement. > > > > Is anyone arguing that you don't need something new > > for message sessions? If all you currently have is > > 2543 based, then of course you do. But it would be > > nice if the only > > new thing you needed was a path through 3261 > > compatible proxies. > > > > Paul > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 15:48:09 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01751 for ; Tue, 23 Jul 2002 15:48:08 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NJlqBc010572; Tue, 23 Jul 2002 15:47:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07855; Tue, 23 Jul 2002 15:48:04 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07844 for ; Tue, 23 Jul 2002 15:47:32 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6NDvG123994; Tue, 23 Jul 2002 08:57:16 -0500 Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) From: Robert Sparks To: Paul Kyzivat Cc: Sean Olson , James Undery , "SIMPLE (E-mail)" In-Reply-To: <3D3D994B.17125D4F@cisco.com> References: <20020723173500.65101.qmail@web11608.mail.yahoo.com> <3D3D994B.17125D4F@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Message-Id: <1027453632.1314.42.camel@dhcp26.dfw.dynamicsoft.com> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 23 Jul 2002 14:47:11 -0500 Content-Transfer-Encoding: 7bit I'm a little confused about this whole discussion. The mechanism described in draft-rosenberg-simple-message-sessions-00.txt uses information collected in the INVITE to build a route set that is used as as preloaded route in each message in the session. This preloaded route is going to contain only elements that will process these MESSAGE requests in a congestion-safe fashion. (Otherwise, somebody violated the protocol). So, why is it we're wringing our hands over one of these hitting a 2543 proxy? IMHO, this is a non-issue and our time would be better spent inspecting and improving on the mechanism in the draft for collecting that preloaded route. RjS On Tue, 2002-07-23 at 12:58, Paul Kyzivat wrote: > Sean Olson wrote: > > > > I think we are saying the same thing then. > > The one (I believe small) difference of opinion > > I have with Rohan's proposal is that I don't > > think we should call this IMTP. I think it should > > be labelled "SIP/2.0" > > Well (sorry Rohan) I don't like that much either. To support it I have to hack every proxy to accept either "SIP/2.0" or "IMTP/1.0", remember it, and put it into responses. > This is a pretty invasive change to the stack. If I have a 3261 compatible stack, it ought to be easier than that. Hence my suggestion for Proxy-Require - it has exactly > the right semantics: proxies that don't support it are supposed to complain. And the hooks to handle it should be easy in most stacks. > > (Of course non-compliant stacks could ignore it. But they could ignore the version too. You can't protect against all forms of stupidity.) > > Paul > > > > > > /sean > > > > --- Paul Kyzivat wrote: > > > Sean Olson wrote: > > > > > > > > I'm not claiming that 2543 proxies are a > > > non-issue. > > > > I am claiming that you can't take a 2543 proxy out > > > > of the box and run IMTP or any other new profile > > > of > > > > SIP through it. If you want to support "IMTP" > > > > (or whatever we label it), you are going to have > > > to > > > > do some work. I don't think it's unreasonable to > > > > make 3261 compliance part of that work. You can > > > > still route the INVITE for the message session > > > through > > > > the older 2543 proxies, you will just need > > > something > > > > new for the "media". > > > > > > I'm not sure I get your point - I suspect we are in > > > violent agreement. > > > > > > Is anyone arguing that you don't need something new > > > for message sessions? If all you currently have is > > > 2543 based, then of course you do. But it would be > > > nice if the only > > > new thing you needed was a path through 3261 > > > compatible proxies. > > > > > > Paul > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - Feel better, live better > > http://health.yahoo.com > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 15:51:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01835 for ; Tue, 23 Jul 2002 15:51:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NJonBc010610; Tue, 23 Jul 2002 15:50:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07885; Tue, 23 Jul 2002 15:51:05 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07863 for ; Tue, 23 Jul 2002 15:49:44 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NJnHCU012901; Tue, 23 Jul 2002 15:49:25 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APZ72>; Tue, 23 Jul 2002 14:49:36 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A307@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , James Undery Cc: "SIMPLE (E-mail)" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 14:49:35 -0500 In the immortal words of Dave Oran: I'm confused. It seems to me that there have been a couple of proposals floated here that amount to: "RFC2543 proxies will break if you send message sessions through them. Therefore, we must come up with a mechanism to break RFC2543 proxies if you send message sessions through them." What? If they're broken, why take extra steps to break them? However, all of that seems like a completely moot point to me. Consider: how would a message session be routed through a proxy? If we use the mechanism in draft-rosenberg-simple-message-session-00.txt (which is the only proposal right now, to my knowledge), the *only* way a proxy can end up in the route of a message session is if it (a) knows about message sessions, and (b) explicitly inserts itself IN THE SDP. Can anyone point to a deployed RFC2543 proxy that does this? Then why are we spinning our wheels on this issue? It seems to me that a number of great minds are wasting a lot of time solving a non-problem here. /a > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, July 23, 2002 8:09 > To: James Undery > Cc: SIMPLE (E-mail) > Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) > > > > > James Undery wrote: > > > > Hi, > > > > At the SIMPLE meeting I believe the consensus was to go > with a SIP based message transport, however, it was unclear > if this should be SIP or IMTP. The argument for SIP is > because of rfc3261 we can now use SIP as is, IMTP was > complicated due to all the requirements of messaging that > couldn't be addressed easily; I'd definitely agree with that, > however, I believe that won't work, rfc2543 proxies may still > do all the bad things IMTP was designed to avoid. The > suggestion made by Rohan (that I strongly agree with) was to > take rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time > the protocol is mentioned in the spec. This has the advantage > that you know older proxies aren't going to misbehave and the > draft specifying it should be trivial modification to > Jonathan's latest draft. > > To avoid misbehaving proxies, shouldn't it be sufficient to > do something like > > Proxy-Require: message_session > > or something to that effect? Changing the version requires > much more mucking in the stack. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 16:41:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03473 for ; Tue, 23 Jul 2002 16:41:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NKewBc011024; Tue, 23 Jul 2002 16:40:58 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08067; Tue, 23 Jul 2002 16:41:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08056 for ; Tue, 23 Jul 2002 16:40:35 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.235]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6NKeXYH017330; Tue, 23 Jul 2002 16:40:33 -0400 (EDT) Message-ID: <3D3DBF40.1020605@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Paul Kyzivat , Sean Olson , James Undery , "SIMPLE (E-mail)" Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) References: <1027453632.1314.42.camel@dhcp26.dfw.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 16:40:32 -0400 Content-Transfer-Encoding: 7bit inline. Robert Sparks wrote: > > I'm a little confused about this whole discussion. > > The mechanism described in > draft-rosenberg-simple-message-sessions-00.txt > uses information collected in the INVITE to build > a route set that is used as as preloaded route in > each message in the session. > > This preloaded route is going to contain only > elements that will process these MESSAGE requests > in a congestion-safe fashion. (Otherwise, somebody > violated the protocol). > > So, why is it we're wringing our hands over one of > these hitting a 2543 proxy? I am collecting my thoughts on this issue; I think there is more here in this IMTP vs. SIP/2.0 debate than whether the proxies are 3261 compliant or not. > > IMHO, this is a non-issue and our time would be > better spent inspecting and improving on the mechanism > in the draft for collecting that preloaded route. Well, while we are on that subject, let me make a radical proposal. I would propose that, if we truly believe that IM sessions are NO different than voice sessions, we should have the same explicit support here for intermediaries as we do for RTP - which is NONE. That leaves several options for routing through intermediaries: 1. Proxies modify the SDP, as they do today for VoIP, replacing the URI in there with the URI that points to an intermediary which contains a mapping to the next hop. In this case, there is no preloaded route. What about congestion control? Well, we would mandate that message sessions MUST be sent over a congestion controlled transport, enforced with Proxy-Require: congestion-safe in the MESSAGE, used in all cases. Forking/redirection can still be avoided, but becomes an issue of proper implementation of the intermediaries. I suspect it would never happen in practice, since the URI inserted into the SDP would be some random string that is created for this mapping (i.e., sip:asd88d8as9dasd-asd9askk@intermediary33.foo.com). 2. If there is a mechanism for discovering loose routes for media, it be applicable for all media types, not just messaging, and not require proxies to muck with SDP. My session policy proposal: http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt provides one such mechanism. However, it would be a mistake to more or less invent that mechanism for each media type and hack it into the SDP for that type. If we believe in the concept of loose routing of media, and I do, we should solve the problem generally. Flame away.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 17:10:09 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04315 for ; Tue, 23 Jul 2002 17:10:08 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NL9qBc011264; Tue, 23 Jul 2002 17:09:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08180; Tue, 23 Jul 2002 17:10:06 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08167 for ; Tue, 23 Jul 2002 17:09:47 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NL9SCU013625; Tue, 23 Jul 2002 17:09:28 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APZ8F>; Tue, 23 Jul 2002 16:09:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A30C@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Robert Sparks Cc: Paul Kyzivat , Sean Olson , James Undery , "SIMPLE (E-mail)" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 16:09:45 -0500 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > I would propose that, if we truly believe that IM sessions are NO > different than voice sessions, we should have the same > explicit support > here for intermediaries as we do for RTP - which is NONE. Okay. I like consistency. Sounds good to me. >1. Proxies modify the SDP, as they do today for VoIP, > replacing the URI in there with the URI that points > to an intermediary which contains a mapping to the > next hop. And, as has been demonstrated by our experience in VoIP, people are going to do this. There's nothing we can do to stop them. I don't think it deserves any more endorsement than we've done for the same technique WRT voice. (That is, none). > 2. If there is a mechanism for discovering loose routes > for media, it be applicable for all media types, not > just messaging, and not require proxies to muck with SDP. And I think that solving this problem only once makes a whole lot more sense. Is there a *requirement* that message sessions can go through intermediaries? Basically, as you've pointed out, they're just media. We have SIP with voice and video media deployed just fine without such a mechanism, so I can't imagine that this would be a legitimate *requirement* of a messaging solution. That said, it's certainly a "nice to have", and the session-policy draft makes a good start at defining requirements and mechanisms for a solution. So, would it be possible to pull the routing attribute out of the message session draft altogether, get it out the door (it's extremely important!), and then work on a general media routing technique after we have it in the RFC editor's queue? /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 17:45:23 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05109 for ; Tue, 23 Jul 2002 17:45:23 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NLioBc011598; Tue, 23 Jul 2002 17:44:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08379; Tue, 23 Jul 2002 17:45:06 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08355 for ; Tue, 23 Jul 2002 17:44:28 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.235]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6NLiMYH017418; Tue, 23 Jul 2002 17:44:23 -0400 (EDT) Message-ID: <3D3DCE35.3000708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <3D3C0DFD.CC504B1@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 17:44:21 -0400 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > >>However, I would like to provide sequencing for >>them, and so CSeq is natural for that. In order to use CSeq, you must >>have a well defined scope in which they exist. I had merely indicated >>that this was a "dialog ID" - meaning the To-tag, From-tag, and >> call-id, >>which does not imply the existence of a dialog. > > > I'm unconfortable with using "dialog ID" without there being a dialog. I > can't at the moment give a solid reason why this is wrong, but it feels > like an abuse. OK, let me know be very explicit. Message sessions would be a sequence of pages. As per 3261, each of those will have a call-id, a from tag, and no to tag. The 200 OK response to each of those has a to tag filled in, different for each message. The CSeq refers to the sequencing within the URI seen by the UAS, as I have indicated in a previous mail, so I have fully backed off that notion. So, there is a dialog ID, but its different for each message, as it would be for page mode. > > >>However, it occurs to me that if the URI is the point of demux at the >>UAS, then the scope of the sequence numbers can be within that URI. In >>other words, each MESSAGE in the message media stream could (and >>probably should, thinking about this more) have a unique call-id. The >>cseq increment by one for each message sent by the originating UA. The >>UAS will provide a URI of sufficient uniqueness that it won't receive >>any messages at the URI except for ones sent by the originator. Thus, >>the cseq can provide ordering within the scope of the r-uri as seen by >>the UAS. > > > If we continue the analogy with RTP streams, then this seems like a bad > assumption. In the case of RTP, we never assume that all the packets > arrive from the same source. > This can be violated in many cases, such as when transferring a call, > where one sender is replaced by another, but the receiver remains > invariant. Yes, thats a good point. Its the combination of SSRC and port which define a sequence number space. In that case, we would need to do a similar thing. > > Why can't we rely on the message content to provide ordering, and the > reliablility of the transport to guarantee delivery? Of course text > content won't provide ordering, > but that will provide more encouragement to use CPIM. Sequencing is an existing sip functionality; it hardly seems worth it to use content provided ordering when the transport can already do it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 17:47:09 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05130 for ; Tue, 23 Jul 2002 17:47:08 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NLgpBc011525; Tue, 23 Jul 2002 17:42:51 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08314; Tue, 23 Jul 2002 17:43:04 -0400 (EDT) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA08303 for ; Tue, 23 Jul 2002 17:42:49 -0400 (EDT) Message-ID: <20020723214249.25359.qmail@web11604.mail.yahoo.com> Received: from [131.107.3.84] by web11604.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 14:42:49 PDT From: Sean Olson Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) To: Adam Roach , Jonathan Rosenberg , Robert Sparks Cc: Paul Kyzivat , Sean Olson , James Undery , "SIMPLE \(E-mail\)" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F377A30C@DYN-TX-EXCH-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 14:42:49 -0700 (PDT) > > 2. If there is a mechanism for discovering loose > routes > > for media, it be applicable for all media > types, not > > just messaging, and not require proxies to muck > with SDP. > > And I think that solving this problem only once > makes a whole > lot more sense. > > Is there a *requirement* that message sessions can > go through > intermediaries? Basically, as you've pointed out, > they're > just media. We have SIP with voice and video media > deployed > just fine without such a mechanism, so I can't > imagine that > this would be a legitimate *requirement* of a > messaging solution. > > That said, it's certainly a "nice to have", and the > session-policy > draft makes a good start at defining requirements > and mechanisms > for a solution. > > So, would it be possible to pull the routing > attribute out of > the message session draft altogether, get it out the > door > (it's extremely important!), and then work on a > general media > routing technique after we have it in the RFC > editor's queue? > > /a I'm all for having the message session work completed as quickly as possible. But I think the routing aspects need to be fleshed out before this can be a really useful mechanism. In particular, NAT/firewall traversal can be a bit thorny otherwise. /sean __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 17:55:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05392 for ; Tue, 23 Jul 2002 17:55:20 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NLssBc011722; Tue, 23 Jul 2002 17:54:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08444; Tue, 23 Jul 2002 17:55:06 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08431 for ; Tue, 23 Jul 2002 17:54:18 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.235]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6NLsGYH017425; Tue, 23 Jul 2002 17:54:16 -0400 (EDT) Message-ID: <3D3DD086.3070903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <3D3C2FBC.1090205@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 17:54:14 -0400 Content-Transfer-Encoding: 7bit I still believe that we should follow Robert's advice as offered in the SIMPLE session. We are now down to arguing the interpretation of the terms priority, urgency, and expiration. This is an argument for which there is no right answer. Since 3261 allows each method to define a method-specific meaning for Expires, we are well within the scope of the specifications. No one has found a technical flaw in this approach. At least several people (myself included) feel its reasonable if not perfect. Robert's advice was to leave it be unless people found it to be broken. I would rather finish this specification finally, rather than debating the relative interpretations of the terms in play here. -Jonathan R. Ben Campbell wrote: > hisham.khartabil@nokia.com wrote: > >>Well, you read my mind. I wanted to get consensus that Priority header > > is for user interface purposes only before I do so. > > As I mentioned in a separate mail, priority _can_ be used for routing > purposes. But it means something different than urgency. > > >>Should we do something like that or are these issues part of the > > ieprep work? > >>Regards, >>Hisham >> >> >> >>>-----Original Message----- >>>From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>>Sent: Monday, July 22, 2002 4:51 PM >>>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach >>>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; >>>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com >>>Subject: RE: [Simple] -05 MESSAGE and Expires header >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>- When is a message urgent but does not require immediate delivery? >>> >>>Are you proposing an "Urgency" header, or confusing priority with >>>urgency? I'll see if I can accurately demonstrate their >>>orthangonality. >>> >>>High Priority, Low Urgency: >>> Note to new residents: failure to file income taxes by April >>> 15th can lead to substantial penalties. >>> >>>Low Priority, High Urgency: >>> You have 5 minutes to come by and pick up the rest of your lunch >>> or I'm going to throw it away. >>> >>>High Priority, High Urgency: >>> There's a tornado coming your way! >>> >>>Low Priority, Low Urgency: >>> Llamas can make four distinct noises: humming, clucking, >>>orgling, and >>> a high pitched, rhythmic alarm sound. >>> >>>/a >>> >> >> > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 18:09:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05780 for ; Tue, 23 Jul 2002 18:09:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NM8qBc011851; Tue, 23 Jul 2002 18:08:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08500; Tue, 23 Jul 2002 18:09:06 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08487 for ; Tue, 23 Jul 2002 18:08:12 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6NM7shZ082134; Tue, 23 Jul 2002 17:07:55 -0500 (CDT) Message-ID: <3D3DD3A3.8070309@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , SIP LIST CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 17:07:31 -0500 Content-Transfer-Encoding: 7bit I concur. I have had many responses suggesting we leave it alone, and only a couple of people arguing for a change. The draft currently leaves most of the handling of Expires as a matter of local policy. I think that is the appropriate level of detail for the MESSAGE specification. Since the majority of the controversy concerns store and forward relays, I will echo Sean's statement that if we choose to standardize such relays, that specification if free to further constrain relay behavior. Also, as mentioned in the wg meeting, this discussion belongs on the SIP list, as it concerns a SIP work item. I have tried moving it there, but it doesn't seem to stick. Please direct any future discussion to the SIP list. Jonathan Rosenberg wrote: > I still believe that we should follow Robert's advice as offered in the > SIMPLE session. We are now down to arguing the interpretation of the > terms priority, urgency, and expiration. This is an argument for which > there is no right answer. Since 3261 allows each method to define a > method-specific meaning for Expires, we are well within the scope of the > specifications. No one has found a technical flaw in this approach. At > least several people (myself included) feel its reasonable if not > perfect. Robert's advice was to leave it be unless people found it to be > broken. I would rather finish this specification finally, rather than > debating the relative interpretations of the terms in play here. > > -Jonathan R. > > Ben Campbell wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> Well, you read my mind. I wanted to get consensus that Priority header >> >> >> is for user interface purposes only before I do so. >> >> As I mentioned in a separate mail, priority _can_ be used for routing >> purposes. But it means something different than urgency. >> >> >>> Should we do something like that or are these issues part of the >> >> >> ieprep work? >> >>> Regards, >>> Hisham >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>>> Sent: Monday, July 22, 2002 4:51 PM >>>> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach >>>> Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; >>>> Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com >>>> Subject: RE: [Simple] -05 MESSAGE and Expires header >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>> - When is a message urgent but does not require immediate delivery? >>>> >>>> >>>> Are you proposing an "Urgency" header, or confusing priority with >>>> urgency? I'll see if I can accurately demonstrate their orthangonality. >>>> >>>> High Priority, Low Urgency: >>>> Note to new residents: failure to file income taxes by April >>>> 15th can lead to substantial penalties. >>>> >>>> Low Priority, High Urgency: >>>> You have 5 minutes to come by and pick up the rest of your lunch >>>> or I'm going to throw it away. >>>> High Priority, High Urgency: >>>> There's a tornado coming your way! >>>> >>>> Low Priority, Low Urgency: >>>> Llamas can make four distinct noises: humming, clucking, orgling, and >>>> a high pitched, rhythmic alarm sound. >>>> >>>> /a >>>> >>> >>> >> >> >> > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 18:10:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05815 for ; Tue, 23 Jul 2002 18:10:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NM9qBc011882; Tue, 23 Jul 2002 18:09:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08523; Tue, 23 Jul 2002 18:10:07 -0400 (EDT) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08494 for ; Tue, 23 Jul 2002 18:09:03 -0400 (EDT) Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6NM8mhZ082208; Tue, 23 Jul 2002 17:08:49 -0500 (CDT) Message-ID: <3D3DD3D9.5020706@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , SIP LIST CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com> X-Enigmail-Version: 0.61.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 17:08:25 -0500 Content-Transfer-Encoding: 7bit I concur. I have had many responses suggesting we leave it alone, and only a couple of people arguing for a change. The draft currently leaves most of the handling of Expires as a matter of local policy. I think that is the appropriate level of detail for the MESSAGE specification. Since the majority of the controversy concerns store and forward relays, I will echo Sean's statement that if we choose to standardize such relays, that specification if free to further constrain relay behavior. Also, as mentioned in the wg meeting, this discussion belongs on the SIP list, as it concerns a SIP work item. I have tried moving it there, but it doesn't seem to stick. Please direct any future discussion to the SIP list. Jonathan Rosenberg wrote: > I still believe that we should follow Robert's advice as offered in the > SIMPLE session. We are now down to arguing the interpretation of the > terms priority, urgency, and expiration. This is an argument for which > there is no right answer. Since 3261 allows each method to define a > method-specific meaning for Expires, we are well within the scope of the > specifications. No one has found a technical flaw in this approach. At > least several people (myself included) feel its reasonable if not > perfect. Robert's advice was to leave it be unless people found it to be > broken. I would rather finish this specification finally, rather than > debating the relative interpretations of the terms in play here. > > -Jonathan R. > > Ben Campbell wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> Well, you read my mind. I wanted to get consensus that Priority header >> >> >> is for user interface purposes only before I do so. >> >> As I mentioned in a separate mail, priority _can_ be used for routing >> purposes. But it means something different than urgency. >> >> >>> Should we do something like that or are these issues part of the >> >> >> ieprep work? >> >>> Regards, >>> Hisham >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>>> Sent: Monday, July 22, 2002 4:51 PM >>>> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach >>>> Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; >>>> Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com >>>> Subject: RE: [Simple] -05 MESSAGE and Expires header >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>>> - When is a message urgent but does not require immediate delivery? >>>> >>>> >>>> Are you proposing an "Urgency" header, or confusing priority with >>>> urgency? I'll see if I can accurately demonstrate their orthangonality. >>>> >>>> High Priority, Low Urgency: >>>> Note to new residents: failure to file income taxes by April >>>> 15th can lead to substantial penalties. >>>> >>>> Low Priority, High Urgency: >>>> You have 5 minutes to come by and pick up the rest of your lunch >>>> or I'm going to throw it away. >>>> High Priority, High Urgency: >>>> There's a tornado coming your way! >>>> >>>> Low Priority, Low Urgency: >>>> Llamas can make four distinct noises: humming, clucking, orgling, and >>>> a high pitched, rhythmic alarm sound. >>>> >>>> /a >>>> >>> >>> >> >> >> > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 18:12:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05886 for ; Tue, 23 Jul 2002 18:12:00 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NMBoBc011921; Tue, 23 Jul 2002 18:11:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08550; Tue, 23 Jul 2002 18:12:05 -0400 (EDT) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA08539 for ; Tue, 23 Jul 2002 18:11:42 -0400 (EDT) Message-ID: <20020723221143.57917.qmail@web11606.mail.yahoo.com> Received: from [131.107.3.79] by web11606.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 15:11:43 PDT From: Sean Olson Subject: Re: [Simple] Message session & associated dialog To: Jonathan Rosenberg , Paul Kyzivat Cc: aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@mailman.dynamicsoft.com In-Reply-To: <3D3DCE35.3000708@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 15:11:43 -0700 (PDT) > OK, let me know be very explicit. > > Message sessions would be a sequence of pages. As > per 3261, each of > those will have a call-id, a from tag, and no to > tag. The 200 OK > response to each of those has a to tag filled in, > different for each > message. The CSeq refers to the sequencing within > the URI seen by the > UAS, as I have indicated in a previous mail, so I > have fully backed off > that notion. > > So, there is a dialog ID, but its different for each > message, as it > would be for page mode. If the dialog ID is different for each page, then how would the CSeq be used across these pages to do sequencing? Wouldn't there necessarily be a unique numbering space for each dialog ID? And if there is a possibility that these pages come from different sources, then we can't count on CSeq ordering. I think I may be misunderstanding your proposal. /sean __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 18:13:30 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05945 for ; Tue, 23 Jul 2002 18:13:30 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NMCpBc011973; Tue, 23 Jul 2002 18:12:51 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08573; Tue, 23 Jul 2002 18:13:06 -0400 (EDT) Received: from rwc-ex0.corp.seven.com ([209.19.68.212]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08562 for ; Tue, 23 Jul 2002 18:12:38 -0400 (EDT) Received: from seven.com ([10.0.36.36]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 15:14:57 -0700 Message-ID: <3D3DD4A7.81D1635B@seven.com> From: Bobby Sardana Organization: Seven Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Ben Campbell , hisham.khartabil@nokia.com, adam@dynamicsoft.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------39FC5F0FDFE35EA0217AF65C" X-OriginalArrivalTime: 23 Jul 2002 22:14:57.0021 (UTC) FILETIME=[60CB3AD0:01C23296] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 15:11:51 -0700 --------------39FC5F0FDFE35EA0217AF65C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Comments inline. Jonathan Rosenberg wrote: > I still believe that we should follow Robert's advice as offered in the > SIMPLE session. We are now down to arguing the interpretation of the > terms priority, urgency, and expiration. This is an argument for which > there is no right answer. Since 3261 allows each method to define a > method-specific meaning for Expires, we are well within the scope of the > specifications. No one has found a technical flaw in this approach. At > least several people (myself included) feel its reasonable if not > perfect. Robert's advice was to leave it be unless people found it to be > broken. I would rather finish this specification finally, rather than > debating the relative interpretations of the terms in play here. I agree that it is important to finish the specification than to debate about the merits of "Expire" and "Priority". The comment I want to make is that allowing "Expire" to be method specific allows it to be mis-used, maybe not in case of MESSAGE, but in still-to-be-articulated methods. We have the opportunity to fix it now by picking a header, like Priority, which is more verbose. Also, as an implementor, I would not have to pick the spec to figure out what specific meaning does "Expire" have and in what method context. If there are self-descriptive headers, then their use would be of help -- both from an implementation & understanding purposes. with regards, Bobby Sardana. dsardana@seven.com > > > -Jonathan R. > > Ben Campbell wrote: > > hisham.khartabil@nokia.com wrote: > > > >>Well, you read my mind. I wanted to get consensus that Priority header > > > > is for user interface purposes only before I do so. > > > > As I mentioned in a separate mail, priority _can_ be used for routing > > purposes. But it means something different than urgency. > > > > > >>Should we do something like that or are these issues part of the > > > > ieprep work? > > > >>Regards, > >>Hisham > >> > >> > >> > >>>-----Original Message----- > >>>From: ext Adam Roach [mailto:adam@dynamicsoft.com] > >>>Sent: Monday, July 22, 2002 4:51 PM > >>>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach > >>>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com; > >>>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com > >>>Subject: RE: [Simple] -05 MESSAGE and Expires header > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > >>>>- When is a message urgent but does not require immediate delivery? > >>> > >>>Are you proposing an "Urgency" header, or confusing priority with > >>>urgency? I'll see if I can accurately demonstrate their > >>>orthangonality. > >>> > >>>High Priority, Low Urgency: > >>> Note to new residents: failure to file income taxes by April > >>> 15th can lead to substantial penalties. > >>> > >>>Low Priority, High Urgency: > >>> You have 5 minutes to come by and pick up the rest of your lunch > >>> or I'm going to throw it away. > >>> > >>>High Priority, High Urgency: > >>> There's a tornado coming your way! > >>> > >>>Low Priority, Low Urgency: > >>> Llamas can make four distinct noises: humming, clucking, > >>>orgling, and > >>> a high pitched, rhythmic alarm sound. > >>> > >>>/a > >>> > >> > >> > > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com -- ___________________________ Bobby Sardana | SEVEN Software Engineer, Engineering ___________________________ 901 Marshall St. Redwood City, CA 94063 650.381.2535 (v) 650.216.6455 (f) dsardana@seven.com www.seven.com --------------39FC5F0FDFE35EA0217AF65C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Comments inline.

Jonathan Rosenberg wrote:

I still believe that we should follow Robert's advice as offered in the
SIMPLE session. We are now down to arguing the interpretation of the
terms priority, urgency, and expiration. This is an argument for which
there is no right answer. Since 3261 allows each method to define a
method-specific meaning for Expires, we are well within the scope of the
specifications. No one has found a technical flaw in this approach. At
least several people (myself included) feel its reasonable if not
perfect. Robert's advice was to leave it be unless people found it to be
broken. I would rather finish this specification finally, rather than
debating the relative interpretations of the terms in play here.
I agree that it is important to finish the specification than to debate about the merits of "Expire" and "Priority". The comment I want to make is that allowing "Expire" to be method specific allows it to be mis-used, maybe not in case of MESSAGE, but in still-to-be-articulated methods. We have the opportunity to fix it now by picking a header, like Priority, which is more verbose. Also, as an implementor, I would not have to pick the spec to figure out what specific meaning does "Expire" have and in what method context. If there are self-descriptive headers, then their use would be of help -- both from an implementation & understanding purposes.

with regards,

Bobby Sardana.
dsardana@seven.com

 

-Jonathan R.

Ben Campbell wrote:
> hisham.khartabil@nokia.com wrote:
>
>>Well, you read my mind. I wanted to get consensus that Priority header
>
> is for user interface purposes only before I do so.
>
> As I mentioned in a separate mail, priority _can_ be used for routing
> purposes. But it means something different than urgency.
>
>
>>Should we do something like that or are these issues part of the
>
> ieprep work?
>
>>Regards,
>>Hisham
>>
>>
>>
>>>-----Original Message-----
>>>From: ext Adam Roach [mailto:adam@dynamicsoft.com]
>>>Sent: Monday, July 22, 2002 4:51 PM
>>>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
>>>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;
>>>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com
>>>Subject: RE: [Simple] -05 MESSAGE and Expires header
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>>>>- When is a message urgent but does not require immediate delivery?
>>>
>>>Are you proposing an "Urgency" header, or confusing priority with
>>>urgency? I'll see if I can accurately demonstrate their
>>>orthangonality.
>>>
>>>High Priority, Low Urgency:
>>> Note to new residents: failure to file income taxes by April
>>> 15th can lead to substantial penalties.
>>>
>>>Low Priority, High Urgency:
>>> You have 5 minutes to come by and pick up the rest of your lunch
>>> or I'm going to throw it away.
>>>
>>>High Priority, High Urgency:
>>> There's a tornado coming your way!
>>>
>>>Low Priority, Low Urgency:
>>> Llamas can make four distinct noises: humming, clucking,
>>>orgling, and
>>> a high pitched, rhythmic alarm sound.
>>>
>>>/a
>>>
>>
>>
>
>
>

--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

-- 
___________________________ 

Bobby Sardana |  SEVEN 
Software Engineer, Engineering  
___________________________ 

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com
  --------------39FC5F0FDFE35EA0217AF65C-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 19:20:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07194 for ; Tue, 23 Jul 2002 19:20:27 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NNJuBc012331; Tue, 23 Jul 2002 19:19:58 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08818; Tue, 23 Jul 2002 19:20:08 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08805 for ; Tue, 23 Jul 2002 19:19:47 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NNJOCU014399; Tue, 23 Jul 2002 19:19:24 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APZ89>; Tue, 23 Jul 2002 18:19:39 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A30E@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Bobby Sardana'" , Jonathan Rosenberg Cc: Ben Campbell , hisham.khartabil@nokia.com, Adam Roach , vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: RE: [Simple] -05 MESSAGE and Expires header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 18:19:38 -0500 Please don't use HTML or Rich Text in your mail to the list. It makes your messages difficult to reply to. Comments below. -----Original Message----- From: Bobby Sardana [mailto:dsardana@seven.com] > ...as an implementor, I would not have to pick the spec > to figure out what specific meaning does "Expire" have > and in what method context. If there are self-descriptive > headers, then their use would be of help -- both from an > implementation & understanding purposes. I'm not sure that's possible. What does "Expire" *currently* mean? It might mean the duration of validity for an invitation. It might mean the duration of softstate for a registration or a subscription. In terms of handling, these are radically different things. So, to say that it could also be a user-interface indication for staleness of IMs that may or may not also be used in making store-and-forward decisions doesn't seem to be a stretch. Above all, I can't formulate a consistent handling that can be assigned to the existing methods (i.e. published in RFCs) to unify them. Or, perhaps I'm just missing something obvious. I would be interested in hearing you put forth a propasal that describes a handling for "Expires" that applies uniformly to all methods. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 20:10:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08124 for ; Tue, 23 Jul 2002 20:10:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6O07nBc012512; Tue, 23 Jul 2002 20:07:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08991; Tue, 23 Jul 2002 20:08:05 -0400 (EDT) Received: from rwc-ex0.corp.seven.com ([209.19.68.212]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08980 for ; Tue, 23 Jul 2002 20:07:46 -0400 (EDT) Received: from seven.com ([10.0.36.36]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 17:10:04 -0700 Message-ID: <3D3DEFA2.F1926D2B@seven.com> From: Bobby Sardana Organization: Seven Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , Ben Campbell , hisham.khartabil@nokia.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: Re: [Simple] -05 MESSAGE and Expires header References: <9BF66EBF6BEFD942915B4D4D45C051F377A30E@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2002 00:10:04.0237 (UTC) FILETIME=[75D0BFD0:01C232A6] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 17:06:58 -0700 Content-Transfer-Encoding: 7bit Comments towards the end. -----Original Message----- > From: Bobby Sardana [mailto:dsardana@seven.com] > > > ...as an implementor, I would not have to pick the spec > > to figure out what specific meaning does "Expire" have > > and in what method context. If there are self-descriptive > > headers, then their use would be of help -- both from an > > implementation & understanding purposes. > > I'm not sure that's possible. > > ... > > Or, perhaps I'm just missing something obvious. I would > be interested in hearing you put forth a propasal that > describes a handling for "Expires" that applies uniformly > to all methods. The proposal is simple: (not sure from a complete applicability point of view, but here it is) a. Expire signifies a unit of time b. For methods that have the Expire header, the unit of time determines the method validitity. The only exception here is 0, which can mean "expired" or "infinite". I know the above is not a formal proposal but it's the only one I am thinking. regards, Bobby Sardana. dsardana@seven.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jul 23 21:09:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09257 for ; Tue, 23 Jul 2002 21:09:28 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6O18oBc012756; Tue, 23 Jul 2002 21:08:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09186; Tue, 23 Jul 2002 21:09:05 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09175 for ; Tue, 23 Jul 2002 21:08:42 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6O18JCU014776; Tue, 23 Jul 2002 21:08:19 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306APZ9R>; Tue, 23 Jul 2002 20:08:38 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A315@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Bobby Sardana'" , Adam Roach Cc: Jonathan Rosenberg , Ben Campbell , hisham.khartabil@nokia.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com Subject: RE: [Simple] -05 MESSAGE and Expires header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Jul 2002 20:08:37 -0500 > -----Original Message----- > From: Bobby Sardana [mailto:dsardana@seven.com] > > The proposal is simple: (not sure from a complete > applicability point of > view, but here it is) > > a. Expire signifies a unit of time Agreed. > b. For methods that have the Expire header, the unit of time > determines > the method validitity. There's a problem with that approach. For SUBSCRIBE and REGISTER, the "Expires" header doesn't indicate the period of validity of the request (which is presumably what you mean by "method validity"); it indicates the period of validity for what is *created* by the request. The analog for INVITE would be "Session-Expires". > The only exception here is 0, which can mean > "expired" or "infinite". There are actually three problems here. 1. Historically, "0" has never been treated as a special case in SIP expirations. (More on this below). 2. "Expires: 0" does not mean "expired" (that would, in theory, be represented by a negative number -- but we don't do that); it means that expiration occurs in zero seconds (i.e. instantaneously). For the purposes of instant messages, that's exactly what we want to convey: "this mesage expires instantaneously -- so, send it on or consider it stale" (where handling of stale messages is a matter of local policy). 3. Zero has *never* meant infinity in a SIP "Expires" context. The convention for "infinity" is to use 4294967295 (2^32-1), which ends up being over 136 years -- long enough to mean "infinity" for the purposes of a computer protocol. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 24 08:14:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04223 for ; Wed, 24 Jul 2002 08:14:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6O8blBc013817; Wed, 24 Jul 2002 04:37:47 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10463; Wed, 24 Jul 2002 04:38:05 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10452 for ; Wed, 24 Jul 2002 04:37:26 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6O8Zmd01950 for ; Wed, 24 Jul 2002 11:35:49 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Jul 2002 11:37:20 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 11:37:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 11:37:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message session & associated dialog Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Message session & associated dialog Thread-Index: AcIyl2sE4n3mVllhQRu8N5qu4BHYJQAVW8BA To: , , Cc: , , , , X-OriginalArrivalTime: 24 Jul 2002 08:37:20.0147 (UTC) FILETIME=[53080E30:01C232ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA10452 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 11:37:19 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Wednesday, July 24, 2002 1:12 AM > To: Jonathan Rosenberg; Paul Kyzivat > Cc: Niemi Aki (NET/Espoo); peter.paeppinghaus@icn.siemens.de; > bcampbell@dynamicsoft.com; mhammer@cisco.com; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Message session & associated dialog > > > > > OK, let me know be very explicit. > > > > Message sessions would be a sequence of pages. As > > per 3261, each of > > those will have a call-id, a from tag, and no to > > tag. The 200 OK > > response to each of those has a to tag filled in, > > different for each > > message. The CSeq refers to the sequencing within > > the URI seen by the > > UAS, as I have indicated in a previous mail, so I > > have fully backed off > > that notion. > > > > So, there is a dialog ID, but its different for each > > message, as it > > would be for page mode. > > If the dialog ID is different for each page, then > how would the CSeq be used across these pages to > do sequencing? Wouldn't there necessarily be a > unique numbering space for each dialog ID? And if > there is a possibility that these pages come from > different sources, then we can't count on CSeq > ordering. I think I may be misunderstanding your > proposal. In an earlier I proposed using the local port and CSeq, but now there is the other dimension of receiving media from different sources. In this case, can we use local port, remote port and ip address, and CSeq (or whatever sequencing is supported by the media protocol) to identify groupings of media packets (MESSAGE)? Regards, Hisham > > /sean > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 24 08:58:46 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13955 for ; Wed, 24 Jul 2002 08:58:46 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6OCusBc014671; Wed, 24 Jul 2002 08:56:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11302; Wed, 24 Jul 2002 08:57:06 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11291 for ; Wed, 24 Jul 2002 08:56:08 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OCu7YH017749; Wed, 24 Jul 2002 08:56:07 -0400 (EDT) Message-ID: <3D3EA3E6.1040709@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: rsparks@dynamicsoft.com, pkyzivat@cisco.com, seancolson@yahoo.com, jundery@ubiquity.net, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) References: <2038BCC78B1AD641891A0D1AE133DBB7C20401@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 08:56:06 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I agree in removing the proxy modifying the SDP part in the spec. But we > need session-policy and message-session to complete in parallel. Not really. Message sessions will work without session policy, and you will be able to use intermediaries too. You will just need to muck with SDP, as we have always been doing (and will continue to be done, I suspect). > > There is a requirement for messages to do through intermediaries and > session-policy should fix that. Session-policy is one way to fix that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 24 09:01:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14147 for ; Wed, 24 Jul 2002 09:01:09 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6OCxoBc014695; Wed, 24 Jul 2002 08:59:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11331; Wed, 24 Jul 2002 09:00:06 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11310 for ; Wed, 24 Jul 2002 08:58:39 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OCweYH017752; Wed, 24 Jul 2002 08:58:40 -0400 (EDT) Message-ID: <3D3EA47F.2000406@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: seancolson@yahoo.com, pkyzivat@cisco.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 08:58:39 -0400 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Sean Olson [mailto:seancolson@yahoo.com] >>Sent: Wednesday, July 24, 2002 1:12 AM >>To: Jonathan Rosenberg; Paul Kyzivat >>Cc: Niemi Aki (NET/Espoo); peter.paeppinghaus@icn.siemens.de; >>bcampbell@dynamicsoft.com; mhammer@cisco.com; >>simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] Message session & associated dialog >> >> >> >> >>>OK, let me know be very explicit. >>> >>>Message sessions would be a sequence of pages. As >>>per 3261, each of >>>those will have a call-id, a from tag, and no to >>>tag. The 200 OK >>>response to each of those has a to tag filled in, >>>different for each >>>message. The CSeq refers to the sequencing within >>>the URI seen by the >>>UAS, as I have indicated in a previous mail, so I >>>have fully backed off >>>that notion. >>> >>>So, there is a dialog ID, but its different for each >>>message, as it >>>would be for page mode. >> >>If the dialog ID is different for each page, then >>how would the CSeq be used across these pages to >>do sequencing? Wouldn't there necessarily be a >>unique numbering space for each dialog ID? And if >>there is a possibility that these pages come from >>different sources, then we can't count on CSeq >>ordering. I think I may be misunderstanding your >>proposal. > > > > In an earlier I proposed using the local port and CSeq, but now there is > the other dimension of receiving media from different sources. In this > case, can we use local port, remote port and ip address, and CSeq (or > whatever sequencing is supported by the media protocol) to identify > groupings of media packets (MESSAGE)? Using a remote IP address or port is always a bad idea, for NAT reasons. I believe the CSeq numbering space is identified by the local request URI (i.e., the value in the r-uri seen by the UAS that receives the message) combined with the From field, which would then identify the sender. Since there is no dialog here, there is no requirement that the From field be the same for each message, and it can actually reflect the originator of that specific message. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 24 09:04:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04229 for ; Wed, 24 Jul 2002 08:14:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6O8UrBc013737; Wed, 24 Jul 2002 04:30:54 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10425; Wed, 24 Jul 2002 04:31:06 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10414 for ; Wed, 24 Jul 2002 04:30:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6O8Uoi29716 for ; Wed, 24 Jul 2002 11:30:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Jul 2002 11:30:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 11:30:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20401@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Message Transport Protocol (SIP vs IMTP) Thread-Index: AcIyirtcYQ3ZC3q0SGi0xLsqd4JiTAAYUqGg To: , Cc: , , , X-OriginalArrivalTime: 24 Jul 2002 08:30:17.0065 (UTC) FILETIME=[56DADD90:01C232EC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA10414 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 11:30:16 +0300 Content-Transfer-Encoding: 8bit I agree in removing the proxy modifying the SDP part in the spec. But we need session-policy and message-session to complete in parallel. There is a requirement for messages to do through intermediaries and session-policy should fix that. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 23, 2002 11:41 PM > To: Robert Sparks > Cc: Paul Kyzivat; Sean Olson; James Undery; SIMPLE (E-mail) > Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) > > > inline. > > Robert Sparks wrote: > > > > I'm a little confused about this whole discussion. > > > > The mechanism described in > > draft-rosenberg-simple-message-sessions-00.txt > > uses information collected in the INVITE to build > > a route set that is used as as preloaded route in > > each message in the session. > > > > This preloaded route is going to contain only > > elements that will process these MESSAGE requests > > in a congestion-safe fashion. (Otherwise, somebody > > violated the protocol). > > > > So, why is it we're wringing our hands over one of > > these hitting a 2543 proxy? > > I am collecting my thoughts on this issue; I think there is > more here in > this IMTP vs. SIP/2.0 debate than whether the proxies are > 3261 compliant > or not. > > > > > IMHO, this is a non-issue and our time would be > > better spent inspecting and improving on the mechanism > > in the draft for collecting that preloaded route. > > Well, while we are on that subject, let me make a radical proposal. > > I would propose that, if we truly believe that IM sessions are NO > different than voice sessions, we should have the same > explicit support > here for intermediaries as we do for RTP - which is NONE. > > That leaves several options for routing through intermediaries: > > 1. Proxies modify the SDP, as they do today for VoIP, > replacing the URI > in there with the URI that points to an intermediary which contains a > mapping to the next hop. In this case, there is no preloaded > route. What > about congestion control? Well, we would mandate that message > sessions > MUST be sent over a congestion controlled transport, enforced with > Proxy-Require: congestion-safe in the MESSAGE, used in all cases. > Forking/redirection can still be avoided, but becomes an > issue of proper > implementation of the intermediaries. I suspect it would > never happen in > practice, since the URI inserted into the SDP would be some random > string that is created for this mapping (i.e., > sip:asd88d8as9dasd-asd9askk@intermediary33.foo.com). > > 2. If there is a mechanism for discovering loose routes for > media, it be > applicable for all media types, not just messaging, and not require > proxies to muck with SDP. My session policy proposal: > http://search.ietf.org/internet-drafts/draft-rosenberg-sipping -session-policy-00.txt provides one such mechanism. However, it would be a mistake to more or less invent that mechanism for each media type and hack it into the SDP for that type. If we believe in the concept of loose routing of media, and I do, we should solve the problem generally. Flame away.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 24 11:31:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21428 for ; Wed, 24 Jul 2002 11:31:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6OFUtBc015619; Wed, 24 Jul 2002 11:30:55 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11768; Wed, 24 Jul 2002 11:31:07 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11757 for ; Wed, 24 Jul 2002 11:30:48 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OFUth08277; Wed, 24 Jul 2002 10:30:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 10:30:41 -0500 Message-ID: From: "Sriram Parameswar" To: "'Jonathan Rosenberg'" , hisham.khartabil@nokia.com Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23327.0F980F80" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 10:30:37 -0500 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_01C23327.0F980F80 Content-Type: text/plain; charset="iso-8859-1" I am a little confused by this talk of proxies messing around with the SDP *without* using session-policy. I distinctly remember that such proxies were labelled BBUA's and BBUA's were considered evil. Next question - this business of introducing intermediaries only for IM; we should re-visit it. As has been noted in preceding conversations - in the standards we do no such thing for other media like voice and video. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 24, 2002 7:56 AM To: hisham.khartabil@nokia.com Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com; seancolson@yahoo.com; jundery@ubiquity.net; simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) hisham.khartabil@nokia.com wrote: > I agree in removing the proxy modifying the SDP part in the spec. But we > need session-policy and message-session to complete in parallel. Not really. Message sessions will work without session policy, and you will be able to use intermediaries too. You will just need to muck with SDP, as we have always been doing (and will continue to be done, I suspect). > > There is a requirement for messages to do through intermediaries and > session-policy should fix that. Session-policy is one way to fix that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C23327.0F980F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Message Transport Protocol (SIP vs IMTP)

I am a little confused by this talk of proxies = messing around with the SDP *without* using session-policy. I = distinctly remember that such proxies were labelled BBUA's and BBUA's = were  considered evil.

Next question - this business of introducing = intermediaries only for IM; we should re-visit it. As has been noted in = preceding conversations - in the standards we do no such thing for = other media like voice and video.

Thanks,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, July 24, 2002 7:56 AM
To: hisham.khartabil@nokia.com
Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com; = seancolson@yahoo.com;
jundery@ubiquity.net; = simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message Transport Protocol = (SIP vs IMTP)




hisham.khartabil@nokia.com wrote:
> I agree in removing the proxy modifying the SDP = part in the spec. But we
> need session-policy and message-session to = complete in parallel.

Not really. Message sessions will work without = session policy, and you
will be able to use intermediaries too. You will = just need to muck with
SDP, as we have always been doing (and will continue = to be done, I
suspect).

>
> There is a requirement for messages to do = through intermediaries and
> session-policy should fix that.

Session-policy is one way to fix that.

-Jonathan R.


--
Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
dynamicsoft        &nbs= p;           &nbs= p;            = East Hanover, NJ 07936
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple=

------_=_NextPart_001_01C23327.0F980F80-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 24 13:19:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24865 for ; Wed, 24 Jul 2002 13:19:10 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6OHIoBc016201; Wed, 24 Jul 2002 13:18:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12121; Wed, 24 Jul 2002 13:19:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12110 for ; Wed, 24 Jul 2002 13:18:07 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHIWp8022807; Wed, 24 Jul 2002 13:18:32 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN79266; Wed, 24 Jul 2002 13:22:39 -0400 (EDT) Message-ID: <3D3EE145.55D5A373@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: seancolson@yahoo.com, jdrosen@dynamicsoft.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 13:17:57 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > In an earlier I proposed using the local port and CSeq, but now there is the other dimension of receiving media from different sources. In this case, can we use local port, remote port and ip address, and CSeq (or whatever sequencing is supported by the media protocol) to identify groupings of media packets (MESSAGE)? This only provides partial ordering - the recipient is still responsible for taking partially ordered sequences of messages and turning them into a total ordering for display. So the ordering is only approximately "correct" in any case. How much improvement in accuracy do we get from ordering one of those sequences using CSeq vs just using the order in which they are received? If ordering is done this way, what is the recipient to do if it receives a message with a CSeq value that is too large? Must it buffer it until the "missing" messages are received? Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 24 13:29:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25118 for ; Wed, 24 Jul 2002 13:29:58 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6OHTrBc016309; Wed, 24 Jul 2002 13:29:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12177; Wed, 24 Jul 2002 13:30:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12164 for ; Wed, 24 Jul 2002 13:29:20 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHTkC6024109; Wed, 24 Jul 2002 13:29:46 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN79382; Wed, 24 Jul 2002 13:33:53 -0400 (EDT) Message-ID: <3D3EE3E7.6192F83@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, seancolson@yahoo.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com> <3D3EA47F.2000406@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 13:29:11 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I believe the CSeq numbering space is identified by the local request > URI (i.e., the value in the r-uri seen by the UAS that receives the > message) combined with the From field, which would then identify the > sender. Since there is no dialog here, there is no requirement that the > From field be the same for each message, and it can actually reflect > the originator of that specific message. I don't think the From is necessarily unique here. Suppose I initially made a call to you from my desktop pc here, setting up a message session. Once we get chatting, I have to go to a meeting, so I transfer my end of the call to my laptop pc. Both pcs are registered as separate Contacts for my same address of record, and typically the AoR is what would be placed in the from address. During the reinvite transition, you may be getting messages from both pcs, using same From address. As an alternative, the address in the first Via header might be sufficiently unique. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 25 02:09:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24036 for ; Thu, 25 Jul 2002 02:09:05 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6P68tBc019073; Thu, 25 Jul 2002 02:08:56 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14320; Thu, 25 Jul 2002 02:09:09 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14309 for ; Thu, 25 Jul 2002 02:08:03 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6P67xYH018298; Thu, 25 Jul 2002 02:08:00 -0400 (EDT) Message-ID: <3D3F95BC.7010003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sriram Parameswar CC: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 02:07:56 -0400 Content-Transfer-Encoding: 7bit Sriram Parameswar wrote: > I am a little confused by this talk of proxies messing around with the > SDP *without* using session-policy. I distinctly remember that such > proxies were labelled BBUA's and BBUA's were considered evil. Sure, that hasn't changed. My point is only that we ought not special case messaging here. If people in deployments need intermediaries, they will do what they have already been doing for voice, mucking with sdp, despite the lack of blessing from ietf. > > Next question - this business of introducing intermediaries only for IM; > we should re-visit it. As has been noted in preceding conversations - in > the standards we do no such thing for other media like voice and video. I was proposing not to special case messaging. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 25 03:14:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25129 for ; Thu, 25 Jul 2002 03:14:58 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6P7EoBc019253; Thu, 25 Jul 2002 03:14:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14555; Thu, 25 Jul 2002 03:15:06 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14542 for ; Thu, 25 Jul 2002 03:14:40 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6P7FCi02166 for ; Thu, 25 Jul 2002 10:15:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Jul 2002 10:14:39 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Jul 2002 10:14:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message session & associated dialog Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2040C@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] Message session & associated dialog Thread-Index: AcIzN6dalLEkFPIgTyGm7fGXI8yfMwAcuIMQ To: , Cc: , , , , , X-OriginalArrivalTime: 25 Jul 2002 07:14:39.0619 (UTC) FILETIME=[F0BD4D30:01C233AA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA14542 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 10:14:38 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, July 24, 2002 8:29 PM > To: Jonathan Rosenberg > Cc: Khartabil Hisham (NMP/Helsinki); seancolson@yahoo.com; Niemi Aki > (NET/Espoo); peter.paeppinghaus@icn.siemens.de; > bcampbell@dynamicsoft.com; mhammer@cisco.com; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Message session & associated dialog > > > > > Jonathan Rosenberg wrote: > > > > I believe the CSeq numbering space is identified by the > local request > > URI (i.e., the value in the r-uri seen by the UAS that receives the > > message) combined with the From field, which would then identify the > > sender. Since there is no dialog here, there is no > requirement that the > > From field be the same for each message, and it can > actually reflect > > the originator of that specific message. > > I don't think the From is necessarily unique here. > > Suppose I initially made a call to you from my desktop pc > here, setting up a message session. Once we get chatting, I > have to go to a meeting, so I transfer my end of the > call to my laptop pc. > > Both pcs are registered as separate Contacts for my same > address of record, and typically the AoR is what would be > placed in the from address. > > During the reinvite transition, you may be getting messages > from both pcs, using same From address. > > As an alternative, the address in the first Via header might > be sufficiently unique. I think Jonathan was talking about the From-header in the media (MESSAGE) and not the signalling (INVITE). Hisham > > Paul > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jul 25 12:51:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12166 for ; Thu, 25 Jul 2002 12:51:11 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6PGoxBc021487; Thu, 25 Jul 2002 12:50:59 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16238; Thu, 25 Jul 2002 12:51:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16226 for ; Thu, 25 Jul 2002 12:50:23 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PGooGZ001305; Thu, 25 Jul 2002 12:50:50 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN86095; Thu, 25 Jul 2002 12:54:53 -0400 (EDT) Message-ID: <3D402C43.2B9F5A8D@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, seancolson@yahoo.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <2038BCC78B1AD641891A0D1AE133DBB7C2040C@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 12:50:11 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > > I don't think the From is necessarily unique here. > > > > Suppose I initially made a call to you from my desktop pc > > here, setting up a message session. Once we get chatting, I > > have to go to a meeting, so I transfer my end of the > > call to my laptop pc. > > > > Both pcs are registered as separate Contacts for my same > > address of record, and typically the AoR is what would be > > placed in the from address. > > > > During the reinvite transition, you may be getting messages > > from both pcs, using same From address. > > > > As an alternative, the address in the first Via header might > > be sufficiently unique. > > I think Jonathan was talking about the From-header in the media (MESSAGE) and not the signalling (INVITE). So was I. The scenario is moving both the call leg and the media termination from on pc to the other. I would expect (but this is subject to discussion) that the MESSAGEs sent in the media session would still list the Address of Record of the pc as the From address, rather than the pc-specific Contact address. To do otherwise could mess up the UI for the IM session. It may be using the From address to identify the sender of each message. (If the messages are text rather than CPIM format.) I don't think it is safe to assume that the From will be unique from source to source. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 26 08:14:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16172 for ; Fri, 26 Jul 2002 08:14:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QCDGBc025093; Fri, 26 Jul 2002 08:13:16 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19292; Fri, 26 Jul 2002 08:13:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19279 for ; Fri, 26 Jul 2002 08:11:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16056; Fri, 26 Jul 2002 08:10:50 -0400 (EDT) Message-Id: <200207261210.IAA16056@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-sip-message-06.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 08:10:50 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-sip-message-06.txt Pages : 22 Date : 25-Jul-02 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-06.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-sip-message-06.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-sip-message-06.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: <20020725151406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020725151406.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 26 14:35:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03526 for ; Fri, 26 Jul 2002 14:35:21 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QIZ7Bc026883; Fri, 26 Jul 2002 14:35:08 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20358; Fri, 26 Jul 2002 14:35:17 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20345 for ; Fri, 26 Jul 2002 14:34:30 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QIY8CU003732; Fri, 26 Jul 2002 14:34:09 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306AP5SM>; Fri, 26 Jul 2002 13:34:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A32C@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , hisham.khartabil@nokia.com Cc: Jonathan Rosenberg , seancolson@yahoo.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, Ben Campbell , mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Message session & associated dialog MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 13:34:19 -0500 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > I don't think it is safe to assume that the From will be > unique from source to source. Isn't this the exact reason the "tag" parameter was introduced? /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 26 15:17:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05059 for ; Fri, 26 Jul 2002 15:17:58 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QJHqBc027129; Fri, 26 Jul 2002 15:17:52 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20494; Fri, 26 Jul 2002 15:18:05 -0400 (EDT) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA20483 for ; Fri, 26 Jul 2002 15:17:01 -0400 (EDT) Message-ID: <20020726191701.90905.qmail@web11606.mail.yahoo.com> Received: from [131.107.3.75] by web11606.mail.yahoo.com via HTTP; Fri, 26 Jul 2002 12:17:01 PDT From: Sean Olson Subject: RE: [Simple] Message session & associated dialog To: Adam Roach , "'Paul Kyzivat'" , hisham.khartabil@nokia.com Cc: Jonathan Rosenberg , seancolson@yahoo.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, Ben Campbell , mhammer@cisco.com, simple@mailman.dynamicsoft.com In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F377A32C@DYN-TX-EXCH-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 12:17:01 -0700 (PDT) Hmmm. Tag will work in this case (within a dialog), but the tag doesn't really differentiate a source outside of a dialog. Kinda ugly unless we have a single dialog ID for this message session (at the MESSAGE level) Sean Olson Microsoft --- Adam Roach wrote: > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > I don't think it is safe to assume that the From > will be > > unique from source to source. > > Isn't this the exact reason the "tag" parameter was > introduced? > > /a __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 26 16:01:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06604 for ; Fri, 26 Jul 2002 16:01:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QK0oBc027352; Fri, 26 Jul 2002 16:00:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20657; Fri, 26 Jul 2002 16:01:06 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20646 for ; Fri, 26 Jul 2002 16:00:09 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QJxkCU004510; Fri, 26 Jul 2002 15:59:46 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306AP54Q>; Fri, 26 Jul 2002 15:00:06 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A32F@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Sean Olson'" , Adam Roach , "'Paul Kyzivat'" , hisham.khartabil@nokia.com Cc: Jonathan Rosenberg , aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, Ben Campbell , mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Message session & associated dialog MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 15:00:01 -0500 > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > > Hmmm. Tag will work in this case (within a dialog), > but the tag doesn't really differentiate a source > outside of a dialog. "When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness." [RFC3261] Working through the math, this gives about a 0.00000000069849% chance of collision between two sources, and 0.00000001280569% chance of any collision amongst 10 sources. Heck, even with 1000 contributors, your chances of collision are still around 0.0001%. I suspect these numbers are good enough for demultiplexing sources in an IM session -- especially when you consider that the consequences of failure are close to negligible. If anyone considers this unacceptable, perhaps we can suggest a syntax of "tag=32-bits-of-randomness!host.domain" for session-mode messages. /a P.S. Can you tell that I've been working with birthday-paradox problems recently? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 26 18:31:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10986 for ; Fri, 26 Jul 2002 18:31:01 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QMUnBc027959; Fri, 26 Jul 2002 18:30:50 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21121; Fri, 26 Jul 2002 18:31:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21110 for ; Fri, 26 Jul 2002 18:30:33 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6QMUqDN017392; Fri, 26 Jul 2002 18:30:53 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAN95331; Fri, 26 Jul 2002 18:35:00 -0400 (EDT) Message-ID: <3D41CD79.D094D694@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: hisham.khartabil@nokia.com, Jonathan Rosenberg , seancolson@yahoo.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, Ben Campbell , mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Message session & associated dialog References: <9BF66EBF6BEFD942915B4D4D45C051F377A32C@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 18:30:17 -0400 Content-Transfer-Encoding: 7bit Adam Roach wrote: > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > I don't think it is safe to assume that the From will be > > unique from source to source. > > Isn't this the exact reason the "tag" parameter was introduced? > > /a I don't think so. For purposes of sip signalling, the MESSAGEs in a message session aren't part of the dialog of the INVITE that established the session. They aren't part of any dialog. So either each MESSAGE gets a new tag in its From header, or else it gets no tag at all. It would definitely be wrong for them to get the tag from the dialog of the INVITE. (Do messages get a tag on the From if they don't establish a dialog and aren't part of a dialog?) So the from tag is useless for this purpose. Paul BTW - I'm going to be gone for a week or so, so you can finish this discussion without me. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jul 26 18:36:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11079 for ; Fri, 26 Jul 2002 18:36:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QMakBc028039; Fri, 26 Jul 2002 18:36:46 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21157; Fri, 26 Jul 2002 18:37:06 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21146 for ; Fri, 26 Jul 2002 18:36:32 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QMaBCU005483; Fri, 26 Jul 2002 18:36:12 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <306AP5V7>; Fri, 26 Jul 2002 17:36:27 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A331@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: hisham.khartabil@nokia.com, Jonathan Rosenberg , seancolson@yahoo.com, aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de, Ben Campbell , mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Message session & associated dialog MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 17:36:19 -0500 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Adam Roach wrote: > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > I don't think it is safe to assume that the From will be > > > unique from source to source. > > > > Isn't this the exact reason the "tag" parameter was introduced? > > > > /a > > I don't think so. For purposes of sip signalling, the > MESSAGEs in a message session aren't part of the dialog of > the INVITE that established the session. They aren't part > of any dialog. So either each MESSAGE gets a new tag in its > From header, or else it gets no tag at all. You're right. Since there is no dialog, they won't match. Mea culpa. So, I'd agree, then, that we need something equivalent to SSRC for session-mode messages. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Jul 27 16:23:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07120 for ; Sat, 27 Jul 2002 16:23:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6RKMuBc029947; Sat, 27 Jul 2002 16:22:56 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24891; Sat, 27 Jul 2002 16:23:10 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24880 for ; Sat, 27 Jul 2002 16:22:04 -0400 (EDT) From: bindignavile.srinivas@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6RKXlf24713 for ; Sat, 27 Jul 2002 23:33:47 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 27 Jul 2002 01:35:32 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 Jul 2002 01:35:32 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 17:35:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Question about SIP-CGI Thread-Index: AcI09LkBpAbJuy7MSUWOSPyLMJGO3w== To: X-OriginalArrivalTime: 26 Jul 2002 22:35:25.0675 (UTC) FILETIME=[BC5E33B0:01C234F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA24880 Subject: [Simple] Question about SIP-CGI Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 18:35:24 -0400 Content-Transfer-Encoding: 8bit Hi, I wasnt sure if this was the WG to which I should direct this question. But here goes! We have been creating a CGI script in PERL with the script called by a proxy server. We have been able to clarify the use of environment variables for inputting data to the script. However, for the data output from the script to the proxy server, that is where we were confused. The references we looked at state that CGI communicates output to the server through stdout. In the case of a web server where the output data has to be in the form of HTML code, we were clear about the issues. However, when the script communicates with a SIP server, how exactly does one convey the output (of the script) to the proxy server? Some clarification about this issue will be greatly appreciated. Thanks, -Srini _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 29 13:04:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07564 for ; Mon, 29 Jul 2002 13:04:51 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6TH4Cgb002033; Mon, 29 Jul 2002 13:04:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01625; Mon, 29 Jul 2002 13:04:21 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01614 for ; Mon, 29 Jul 2002 13:03:50 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6TH3ihI014035; Mon, 29 Jul 2002 10:03:44 -0700 (PDT) Received: from open-131-161-248-91.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAO89579; Mon, 29 Jul 2002 10:02:38 -0700 (PDT) Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Sriram Parameswar , hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3D3F95BC.7010003@dynamicsoft.com> Message-Id: <271534BD-A315-11D6-B41F-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 29 Jul 2002 10:03:49 -0700 Content-Transfer-Encoding: 7bit On Wednesday, July 24, 2002, at 11:07 PM, Jonathan Rosenberg wrote: > > > Sriram Parameswar wrote: >> I am a little confused by this talk of proxies messing around with the >> SDP *without* using session-policy. I distinctly remember that such >> proxies were labelled BBUA's and BBUA's were considered evil. > > Sure, that hasn't changed. My point is only that we ought not special > case messaging here. If people in deployments need intermediaries, they > will do what they have already been doing for voice, mucking with sdp, > despite the lack of blessing from ietf. Well, alternatively we could take a similar approach to the identity draft. intermediaries can reject offers and answers for a variety of reasons (can't see the SDP to open pinholes (firewall controller), or the SDP violates some local administrative policy (not authorized to use as much bandwidth), or the controller suggests a new SDP in the rejection (ex: a NAT-style middlebox controller). all of this is totally in the purview of a proxy. thx, -r >> Next question - this business of introducing intermediaries only for >> IM; >> we should re-visit it. As has been noted in preceding conversations - >> in >> the standards we do no such thing for other media like voice and video. > > I was proposing not to special case messaging. agreed! > -Jonathan R. > > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jul 29 16:26:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13846 for ; Mon, 29 Jul 2002 16:26:42 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6TKQ0gb003133; Mon, 29 Jul 2002 16:26:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02170; Mon, 29 Jul 2002 16:26:09 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02159 for ; Mon, 29 Jul 2002 16:25:07 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6TEZA129168 for ; Mon, 29 Jul 2002 09:35:10 -0500 From: Robert Sparks To: simple@mailman.dynamicsoft.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Message-Id: <1027974053.7113.2.camel@dhcp112.dfw.dynamicsoft.com> Mime-Version: 1.0 Subject: [Simple] Supplemental website Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 29 Jul 2002 15:20:53 -0500 Content-Transfer-Encoding: 7bit At the request of many, I've put together a supplemental weblet for SIMPLE similar to those for SIP and SIPPING. See http://www.softarmor.com/simple Send errors and omissions to rsparks@dynamicsoft.com. Many thanks to Dean Willis for maintaining the server this runs on. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jul 31 10:02:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27818 for ; Wed, 31 Jul 2002 10:02:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6VE1vgb010925; Wed, 31 Jul 2002 10:01:57 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09056; Wed, 31 Jul 2002 10:02:09 -0400 (EDT) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09045 for ; Wed, 31 Jul 2002 10:01:43 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6V8Bm129649 for ; Wed, 31 Jul 2002 03:11:48 -0500 From: Robert Sparks To: simple@mailman.dynamicsoft.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Message-Id: <1028124071.2826.2.camel@dhcp242.dfw.dynamicsoft.com> Mime-Version: 1.0 Subject: [Simple] comments on notes needed for minutes Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 31 Jul 2002 09:01:11 -0500 Content-Transfer-Encoding: 7bit If you participated in the SIMPLE meeting at IETF54, please take a few minutes to look through the rough notes at http://www.softarmor.com/simple/meets/ietf54/notes/notes.html and send corrections/amendments to me ASAP. Thanks! RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple