From mailman-bounces@ietf.org Sun Aug 1 06:46:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10872 for ; Sun, 1 Aug 2004 06:46:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrDu1-0001D6-U6 for simple-archive@ietf.org; Sun, 01 Aug 2004 06:49:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCU9-0006mH-FZ for simple-archive@ietf.org; Sun, 01 Aug 2004 05:18:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: simple-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:04:23 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From simple-bounces@ietf.org Sun Aug 1 10:57:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04798; Sun, 1 Aug 2004 10:57:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrHpM-0004GN-CC; Sun, 01 Aug 2004 11:00:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHb3-0003QS-CV; Sun, 01 Aug 2004 10:45:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHA3-0001Dq-LJ for simple@megatron.ietf.org; Sun, 01 Aug 2004 10:18:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00274 for ; Sun, 1 Aug 2004 10:18:01 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrHCj-0003Su-6H for simple@ietf.org; Sun, 01 Aug 2004 10:20:49 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i71EHoeE007685; Sun, 1 Aug 2004 10:17:51 -0400 (EDT) Message-ID: <410C53B4.8020809@dynamicsoft.com> Date: Sat, 31 Jul 2004 22:21:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] WG call for comment: Auth48 changes to winfo-package References: <1091061664.1984.12.camel@localhost.localdomain> <4108DA56.1060803@dynamicsoft.com> <222EC56B-E236-11D8-93B7-000D93B0AE1A@nostrum.com> In-Reply-To: <222EC56B-E236-11D8-93B7-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Robert Sparks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > I agree with all the changes, with one question below: > > On Jul 29, 2004, at 6:07 AM, Jonathan Rosenberg wrote: > > [...] > >> >> OLD: >> >> Watcherinfo notifications MAY be generated for watcher information on >> package foo, when the subscription state for a user on package foo >> changes. The watcher information package therefore needs a model of >> subscription state. >> >> NEW (add text and split into two paragraphs): >> >> Each watcherinfo subscription is associated with a set of "inner" >> subscriptions being watched. This set is defined by the URI in the >> Request URI of the watcherinfo SUBSCRIBE request, along with the >> parent event package of the watcherinfo subscription. The parent event >> package is obtained by removing the trailing ".winfo" from the value >> of the Event header field from the watcherinfo SUBSCRIBE request. If >> the Event header field in the watcherinfo subscription has a value of >> "presence.winfo", the parent event package is "presence". If the Event >> header field has a value of "presence.winfo.winfo", the parent event >> package is "presence.winfo". Normally, the URI in the Request URI of >> the watcherinfo SUBSCRIBE identifies an address-of-record within the >> domain. In that case, the set of subscriptions to be watched are all >> of the subscriptions for the parent event package that have been made >> to the resource in the Request URI of the watcherinfo SUBSCRIBE. >> However, the Request URI can contin a URI that defines a larger >> collection of resources. For example, sip:all-resources@example.com >> might be defined within example.com to refer to all resources. In that >> case, a watcherinfo subscription for "presence.winfo" to >> sip:all-resources@example.com is requesting notifications any time the >> state of any presence subscription for any resource within example.com >> changes. A watcherinfo notifier MAY generate a notification any time >> the state of any of the watched subscriptions changes. >> > > Do you mean to only allow winfo subscriptions to _larger_ scopes that > "all subscribers to a resource?" Is it possible to have something like > "sip:AoLUsersWatchingBen@example.com" that only tells me about watchers > in the AoL domain, but not watchers from some other domain? I'm not sure I follow. The problem which caused me to introduce this text is that winfo is based on a subscription to subscriptions, but it never actually explicitly says how you identify the "inner" subscriptions that your winfo subscription applies to! We *assumed* that, if the r-uri of the winfo subscribe was an AOR, this meant, "I'm interested in all subscriptions to this AOR". However, we explicitly designed winfo format to allow for more than one resource to be reported, so presumably, the request URI could identify a larger set of resources than just one user. The text above clarifies that, and gives an example of a URI that identifies all of the users in a domain. I'm not sure I see how your example differs from the one in the text I have suggested. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Aug 1 10:58:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04830; Sun, 1 Aug 2004 10:58:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrHqJ-0004Gy-7M; Sun, 01 Aug 2004 11:01:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHb6-0003W4-5r; Sun, 01 Aug 2004 10:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHAI-0001Qn-6V for simple@megatron.ietf.org; Sun, 01 Aug 2004 10:18:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00365 for ; Sun, 1 Aug 2004 10:18:16 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrHCw-0003T4-OZ for simple@ietf.org; Sun, 01 Aug 2004 10:21:04 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i71EI4eE007703; Sun, 1 Aug 2004 10:18:05 -0400 (EDT) Message-ID: <410C5B0A.3030603@dynamicsoft.com> Date: Sat, 31 Jul 2004 22:52:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] Comments on XCAP List Usage References: <1091010760.15943.43.camel@xitami.research.nokia.com> In-Reply-To: <1091010760.15943.43.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Jari Urpalainen wrote: > Hi! > > In chapter 3.4.6 there must be a typo, instead of If-None-Match If-Match > is needed. Right. THanks. I always seem to mix them up. > > I have some trouble understanding why the service document can contain > also the list data with entrys etc.. If the document split is being done > why not use this referencing always ? Thats a good question. Originally, I had it this way. However, it meant that there wasn't a simple case where all I want is a list for my buddy list; I don't care about sharing of resource lists. I thought it would be valuable to therefore allow the RLS services document to be self-contained. A related benefit is that a self-contained document can be modified and you never have referential integrity problems. That is, I never have the problem that the RLS services document refers to a resource list that doesn't exist. > > Furthermore, if indexing is meant only to find service element for a > particular uri, I would propose a simpler format, i.e. > > > joe/services.xml/~~/services[@uri=... > > jim/services.xml/~~/services[@uri=... The reference to the resource-list isnt' the only thing though. There is also the set of supported packages. I expect that in the future there could be lots of other things - the authorization policies to apply, whether or not filters get forwarded, usernames/passwords to use in back-end subscriptions, etc. Really, the RLS services document is meant to encompass all of the provisioned data that an RLS needs to get access to in order to process an event-list subscription. I think that set could potentially be quite large, and I think we need to design for extensibility. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Aug 1 11:55:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07698; Sun, 1 Aug 2004 11:55:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrIiu-00054I-4S; Sun, 01 Aug 2004 11:58:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrITd-00064p-I2; Sun, 01 Aug 2004 11:42:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrIDh-0007Rc-L1 for simple@megatron.ietf.org; Sun, 01 Aug 2004 11:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06284 for ; Sun, 1 Aug 2004 11:25:51 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrIGN-0004e4-Ou for simple@ietf.org; Sun, 01 Aug 2004 11:28:40 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i71FPeeE007764; Sun, 1 Aug 2004 11:25:40 -0400 (EDT) Message-ID: <410D0B5B.6060503@dynamicsoft.com> Date: Sun, 01 Aug 2004 11:25:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] WGLC: XCAP Base References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> In-Reply-To: <41076D39.9090508@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Thanks for your comments, Jari. Responses inline. Jari Urpalainen wrote: > A few comments/questions. > > 8.5 Managing Etags > > As Jonathan has interpreted (complying with rfc2616) that a node or even > an attribute of an xml-document can be regarded as a resource is it > allowable to send the document ETag after partial delete which is then > actually an ETag of a different resource ? I don't know. I fear that the answer is no; after a DELETE, the resource is deleted, so by definition THAT resource doesn't have an etag anymore. > I would certainly prefer that > it is still being sent as otherwise you introduce a second deficiency > into safe updates of the document (the first one being partial append). I'm not sure what ability we have to mandate this. Since we're using HTTP, its going to depend on what HTTP says. I looked around for any text which talks about etags in DELETE responses, and didnt see anything. > This would mean that only partial modifies are safe. I can think only > ugly solutions to this IMO annoying problem which is mostly due to the > fact that partial updates were (naturally) not thought when http was > created. Well, we have what we have. I do think we need to clarify the etag behavior in DELETE. If someone can confirm that a DELETE response would never contain an etag, that would be helpful. An alternative that I debated (but discarded) for this whole mess was to think of resources in a document as not getting deleted, but rather, becoming empty. That is, if element exists in a document, than any child of that element is said to exist, but be empty. Thus, if you did a GET against an element whose direct parent existed, you would not get a 404; you'd get a 204 (No Content). That would include an entity tag, since 204 explicitly permits meta-data. Thus, you would never actually DELETE. To remove an element, you would do a PUT against it, and the body of the PUT would be empty. This has the benefit that an insertion operations morphs into a modification. An element gets modified from empty to having the value in the PUT. As a result, entity tags would become meaningful for insertions, deletions and modifications as we know them today. The drawback to this approach is that its clearly a hack. It will require the server to be able to create and manage meta-data for an infinite number of resources. Clearly this would be done on-the-fly, but its ugly. It also adds some complexity, and produces behavior which is non-obvious. Furthermore, it might have ugly interactions with other mechanisms we might consider down the road, but I'm not sure. So, I discarded this approach. > > 6.3 Node selector > > Although I have already commented on the default namespace issue I'll > repeat it here: XPath 1.0 has the interpretation that namespace uri is > null if the location step prefix is empty. The upcoming XPath 2.0 seems > to use the element context which is the only sane way in XCAP, too. So > just clearly state that in the text (otherwise compliant with XPath 1.0). > This is flagged as "todo" in the document. I understand that the default namespace for xpath expressions is null (something I have never understood the rationale for). I agree this seemed horribly broken. In XPath 2.0, help me understand how this works. Lets say the namespace is defined as the one from the current element context in which the Xpath expression is being evaluated. I have a doc that is like this: Lets say I want to select the test:bar element, and I'm evaluating an expression within the foo context. I can't figure out how to construct an xpath expression to do that. The reason is that, if the evaluation context is foo, I can't name test:bar or other:bar because the namespaces test and other aren't defined in the foo context. I'm hoping that I've just misunderstood how to construct the namespace context for xpath expression evaluations.... > 7 Client Operations > > I am sorry to repeat but I still don't understand idempotent delete. > What should the server do during "a subsequent DELETE to the same URI > should FIND the resource deleted..." ? I don't understand find here. The server wouldn't do anything different. WHen the second DELETE arrives, it would look at the URI, and find that the resource doesn't exist, and thus reject the DELETE with a 404. I reworded the text thusly: look the same. Similarly, when a client performs a DELETE, if it succeeds, a subsequent DELETE to the same URI will generate a 404; the resource no longer exists on the server since it was deleted by the previous DELETE operation. To maintain this property, the client Is that better? > --------------- > I still miss non-default namespace examples. Once I figure out how this works, I will add them. The norm for us will include non-default namespaces, so, in fact, I will change all of them to use non-defaults. > Also in all examples where > location steps exist there should be more predicates to imply that each > step has to point to a single element. OK, I will do that. > > Also I havn't noticed any discussions in the mailing lists about caching > proxies as they will certainly try to cache responses unless > Cache-Control or Expires headers are used. So some recommendations are > needed in the text. Good point. Caching responses is OK, I think. If a client is GETing lots of different elements within the document, the caching won't be very effective. A cache won't know how to relate the URI for the document with the URIs for the elements and attributes within the document, but thats OK. The caching isn't broken; its just not taking advantage of xcap URI interdependencies to improve performance. Putting that aside, subsequent requests for the same URI/resource could fetch the content from a cache. That would be OK. The server probably wants to set the max-age such that the content expires relatively quickly, but this probably depends on the application usage. As long as all of that sounds fine, I will add text explaining this in a new section on caching. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Aug 1 12:46:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10155; Sun, 1 Aug 2004 12:46:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrJW4-0005jv-Bb; Sun, 01 Aug 2004 12:48:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrJDD-00060X-D5; Sun, 01 Aug 2004 12:29:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrJ74-0002cB-LN for simple@megatron.ietf.org; Sun, 01 Aug 2004 12:23:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09062 for ; Sun, 1 Aug 2004 12:23:04 -0400 (EDT) Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrJ9j-0005S4-CS for simple@ietf.org; Sun, 01 Aug 2004 12:25:53 -0400 Received: from dialup-4.241.217.150.dial1.sandiego1.level3.net ([4.241.217.150] helo=JLaptop.stevecrocker.com) by bittern.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BrJ6v-0000mM-00 for simple@ietf.org; Sun, 01 Aug 2004 09:22:58 -0700 Message-Id: <5.1.0.14.0.20040801121624.023dd520@localhost> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 01 Aug 2004 12:22:33 -0400 To: simple@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Simple] XCAP - Idempotent Delete X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a I noticed in reading the recent XCAP draft that in making everything Idempotent, certain restrictions were introduced. Given a document contenta contentb contentc one can replace the second bar with a path of the form /foo/bar[2]. However, one can not delete that second element with /foo/bar[2], because that delete, if applied a second time, would produce a different document (i.e. it is not idempotent.) I can live with this restriction. But it does awkward. Also, the server is require to check the condition, which makes for some interesting error checking code. Yours, Joel M. Halpern _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Aug 1 13:28:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12507; Sun, 1 Aug 2004 13:28:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrKB5-0006KB-Lz; Sun, 01 Aug 2004 13:31:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrK4j-00070s-Lq; Sun, 01 Aug 2004 13:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrJxz-0003EE-JD for simple@megatron.ietf.org; Sun, 01 Aug 2004 13:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11796 for ; Sun, 1 Aug 2004 13:17:44 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrK0f-00065n-Qd for simple@ietf.org; Sun, 01 Aug 2004 13:20:35 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i71HHXeE007778; Sun, 1 Aug 2004 13:17:34 -0400 (EDT) Message-ID: <410D2593.1040203@dynamicsoft.com> Date: Sun, 01 Aug 2004 13:17:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Simple] XCAP - Idempotent Delete References: <5.1.0.14.0.20040801121624.023dd520@localhost> In-Reply-To: <5.1.0.14.0.20040801121624.023dd520@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > I noticed in reading the recent XCAP draft that in making everything > Idempotent, certain restrictions were introduced. > > Given a document > > contenta > contentb > contentc > > one can replace the second bar with a path of the form /foo/bar[2]. > However, one can not delete that second element with /foo/bar[2], > because that delete, if applied a second time, would produce a different > document (i.e. it is not idempotent.) That's not the intent. The intent is that it is allowed. The definition of idempotent is that a series of N operations have the same effect as 1. If I do N DELETE operations to foo/bar[2], the first causes the delete, and the rest generate 404. The net result is that N of the operations have the same result as 1, and thus the operation is idempotent. > > I can live with this restriction. > But it does awkward. > Also, the server is require to check the condition, which makes for some > interesting error checking code. Jari had a similar impression, so clearly there is text in here that is conveying an intent that I am not seeing. Can you point to the specific text that is leading you to this conclusion? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Aug 1 17:00:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24137; Sun, 1 Aug 2004 17:00:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrNUD-0000ni-FV; Sun, 01 Aug 2004 17:03:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrNK6-0006H6-TZ; Sun, 01 Aug 2004 16:52:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrN6r-0007Ul-4C for simple@megatron.ietf.org; Sun, 01 Aug 2004 16:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23390 for ; Sun, 1 Aug 2004 16:39:07 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrN9W-0000XO-47 for simple@ietf.org; Sun, 01 Aug 2004 16:41:58 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i71KcpeE007806; Sun, 1 Aug 2004 16:38:52 -0400 (EDT) Message-ID: <410D54C1.1050104@dynamicsoft.com> Date: Sun, 01 Aug 2004 16:38:25 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Biot Olivier Subject: Re: [Simple] WGLC: XCAP Base References: <6B546A602AD2D211BFF00008C7A428890B1E28F7@hrtades2.atea.be> In-Reply-To: <6B546A602AD2D211BFF00008C7A428890B1E28F7@hrtades2.atea.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Thanks for the comments. Responses inline. Biot Olivier wrote: > First impression is that it reads well! Thanks! > > Some nits I found so far: > > General remark: > Some lines with HTTP examples and XML schema have not been line-wrapped. > This can probably be deferred till the very end. OK, I will fix them all. > > Page 18: > [Question] The 2nd last paragraph of 6.3 does not contain RFC2119 language. > Is this because RFC2616 (or to be more precise, sections 3 and 3.3 of > RFC2396 regarding abs_path) mandates the escaping of "[", "]" and <"> in > URIs and we don't want to duplicate requirements? Are you referring to this paragraph: Note that the left bracket, right bracket, and double quote characters, which are meaningful to XCAP, cannot be directly represented in the HTTP URI. As a result, they are escape coded when placed within the HTTP URI. Yes, you are right. I am merely stating a fact that is mandated in RFC 2396. > > Page 21: > Caption and caption text, on 2 separate lines. > Both should be removed. There is now a single line. > > Pages 48--51: > First sentence of 13.2.1 stops after one line. This introduction is missing > entirely in the 3 other registration sections, and they also lack a blank > line between section heading and section text. The first sentence in 13.2.1 shouldnt be there; its a copy paste leftover, and was removed. The lack of a blank line is just how xml2rfc is formatting the document. I played around with the options, and I think its fixed now. The trick was to set compact to yes, and subcompact to no. > > The 4 MIME media types are registered differently, > more precisely the "Published specification" section, where > once "RFCXXXX" is used, then "This specification." Fixed to all be consistent. > > Page 51: > File extension of application/xcap-caps+xml > is the same as application/xcap-error+xml (.xe). Although files with this > content will not be that common, I'd suggest .xer or .xml for the former and > .xca or .xml for the latter. Maybe we can get rid of the ".xe[r]" or > ".xc[a]" extension altogether as the documents written in those formats are > valid XML documents. I changed to .xer and .xca respectively. > > Page 54: > Reference [1]: "W3C FirstEdition" should read either "W3C REC" or "W3C > Recommendation". > > By the way, the current XML 1.0 specification is the 3rd edition: > Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau: "The > Extensible Markup Language version 1.0 (3rd edition)". W3C recommendation, > http://www.w3.org/TR/2004/REC-xml-20040204, February 2004. I've updated the reference to the third edition. > > Note that [4] is a W3C candidate recommendation. Right. This should actually be an informative reference. I've moved it to the informative references section. > > That's all I found so far. Thanks for your comments! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 06:38:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28546; Mon, 2 Aug 2004 06:38:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BraFf-0003DC-7p; Mon, 02 Aug 2004 06:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bra9m-0002vj-3X; Mon, 02 Aug 2004 06:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bra3A-0000hE-S4 for simple@megatron.ietf.org; Mon, 02 Aug 2004 06:28:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27995 for ; Mon, 2 Aug 2004 06:28:10 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bra61-00033u-3H for simple@ietf.org; Mon, 02 Aug 2004 06:31:09 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72AS2N24732; Mon, 2 Aug 2004 13:28:02 +0300 (EET DST) X-Scanned: Mon, 2 Aug 2004 13:27:55 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i72ARt3N004216; Mon, 2 Aug 2004 13:27:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00U1Q6cV; Mon, 02 Aug 2004 13:27:54 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72ARpn03229; Mon, 2 Aug 2004 13:27:52 +0300 (EET DST) Subject: Re: [Simple] WGLC: XCAP Base From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <410D0B5B.6060503@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> Content-Type: text/plain Message-Id: <1091442424.4525.270.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 02 Aug 2004 13:27:04 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit On Sun, 2004-08-01 at 18:25, ext Jonathan Rosenberg wrote: > Thanks for your comments, Jari. Responses inline. > > Jari Urpalainen wrote: > > > A few comments/questions. > > > > 8.5 Managing Etags > > > > As Jonathan has interpreted (complying with rfc2616) that a node or even > > an attribute of an xml-document can be regarded as a resource is it > > allowable to send the document ETag after partial delete which is then > > actually an ETag of a different resource ? > > I don't know. I fear that the answer is no; after a DELETE, the resource > is deleted, so by definition THAT resource doesn't have an etag anymore. > > > I would certainly prefer that > > it is still being sent as otherwise you introduce a second deficiency > > into safe updates of the document (the first one being partial append). > > I'm not sure what ability we have to mandate this. Since we're using > HTTP, its going to depend on what HTTP says. I looked around for any > text which talks about etags in DELETE responses, and didnt see anything. > > > This would mean that only partial modifies are safe. I can think only > > ugly solutions to this IMO annoying problem which is mostly due to the > > fact that partial updates were (naturally) not thought when http was > > created. > > Well, we have what we have. I do think we need to clarify the etag > behavior in DELETE. If someone can confirm that a DELETE response would > never contain an etag, that would be helpful. > > > An alternative that I debated (but discarded) for this whole mess was to > think of resources in a document as not getting deleted, but rather, > becoming empty. That is, if element exists in a document, than any > child of that element is said to exist, but be empty. Thus, if you did a > GET against an element whose direct parent existed, you would not get a > 404; you'd get a 204 (No Content). That would include an entity tag, > since 204 explicitly permits meta-data. > > Thus, you would never actually DELETE. To remove an element, you would > do a PUT against it, and the body of the PUT would be empty. > > This has the benefit that an insertion operations morphs into a > modification. An element gets modified from empty to having the value in > the PUT. > > As a result, entity tags would become meaningful for insertions, > deletions and modifications as we know them today. > > The drawback to this approach is that its clearly a hack. It will > require the server to be able to create and manage meta-data for an > infinite number of resources. Clearly this would be done on-the-fly, but > its ugly. It also adds some complexity, and produces behavior which is > non-obvious. Furthermore, it might have ugly interactions with other > mechanisms we might consider down the road, but I'm not sure. > > So, I discarded this approach. > > > > > > 6.3 Node selector > > > > Although I have already commented on the default namespace issue I'll > > repeat it here: XPath 1.0 has the interpretation that namespace uri is > > null if the location step prefix is empty. The upcoming XPath 2.0 seems > > to use the element context which is the only sane way in XCAP, too. So > > just clearly state that in the text (otherwise compliant with XPath 1.0). > > > > This is flagged as "todo" in the document. I understand that the default > namespace for xpath expressions is null (something I have never > understood the rationale for). I agree this seemed horribly broken. In > XPath 2.0, help me understand how this works. Lets say the namespace is > defined as the one from the current element context in which the Xpath > expression is being evaluated. I have a doc that is like this: > > > > > > > Lets say I want to select the test:bar element, and I'm evaluating an > expression within the foo context. I can't figure out how to construct > an xpath expression to do that. The reason is that, if the evaluation > context is foo, I can't name test:bar or other:bar because the > namespaces test and other aren't defined in the foo context. > > I'm hoping that I've just misunderstood how to construct the namespace > context for xpath expression evaluations.... > As you can't send namespace prefix and corresponding namespace uris with queries (unless you use namepace-uri() and local-name() functions) you have to use in-scope definitions that you find from the document. Given your example I don't see a problem: does not know test or other namespace definitions only 's have in-scope definitions. So you can do relative selections like "test:bar[condition xxx]" within context as (which is a child node of -> also a new location step) clearly belongs to test:.. namespace. So when doing implementations location step parsers have to be aware of all in-scope namespace definitions. (and if you use fully xpath 1.0 compatible libraries they'll most likely have some "hooks" where namepaces can be "registered" when evaluating xpath expressions). I'll also remind that with XCAP it was agreed that namespace definitions can not be added like attributes, so during insert you can not just insert (as it has namespace definition), instead you have to insert . > > > > 7 Client Operations > > > > I am sorry to repeat but I still don't understand idempotent delete. > > What should the server do during "a subsequent DELETE to the same URI > > should FIND the resource deleted..." ? I don't understand find here. > > The server wouldn't do anything different. WHen the second DELETE > arrives, it would look at the URI, and find that the resource doesn't > exist, and thus reject the DELETE with a 404. > > I reworded the text thusly: > > look the same. Similarly, when a client performs a DELETE, if it > succeeds, a subsequent DELETE to the same URI will generate a 404; > the resource no longer exists on the server since it was deleted by > the previous DELETE operation. To maintain this property, the client > > Is that better? > definitely, though idempotency issue still remains, btw. has anybody contacts to the http authors ? > > > --------------- > > I still miss non-default namespace examples. > > Once I figure out how this works, I will add them. The norm for us will > include non-default namespaces, so, in fact, I will change all of them > to use non-defaults. > as both models are allowed it would imo be best to have also both examples. > > Also in all examples where > > location steps exist there should be more predicates to imply that each > > step has to point to a single element. > > OK, I will do that. > > > > > Also I havn't noticed any discussions in the mailing lists about caching > > proxies as they will certainly try to cache responses unless > > Cache-Control or Expires headers are used. So some recommendations are > > needed in the text. > > Good point. Caching responses is OK, I think. If a client is GETing lots > of different elements within the document, the caching won't be very > effective. A cache won't know how to relate the URI for the document > with the URIs for the elements and attributes within the document, but > thats OK. The caching isn't broken; its just not taking advantage of > xcap URI interdependencies to improve performance. Putting that aside, > subsequent requests for the same URI/resource could fetch the content > from a cache. That would be OK. The server probably wants to set the > max-age such that the content expires relatively quickly, but this > probably depends on the application usage. > > As long as all of that sounds fine, I will add text explaining this in a > new section on caching. > > -Jonathan R. > What worries me here mostly is that after partial delete/put caches may send incorrect content (e.g. when getting the whole document). This is a similar problem as what we have with ETags, because a single document contains many resources which are somehow related. Thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 08:50:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03778; Mon, 2 Aug 2004 08:50:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrcJb-0004uM-Do; Mon, 02 Aug 2004 08:53:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrcBf-0000dH-NN; Mon, 02 Aug 2004 08:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrcB6-0000FZ-6k for simple@megatron.ietf.org; Mon, 02 Aug 2004 08:44:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03582 for ; Mon, 2 Aug 2004 08:44:30 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrcDw-0004qa-Cj for simple@ietf.org; Mon, 02 Aug 2004 08:47:29 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72ChfO26514; Mon, 2 Aug 2004 15:43:41 +0300 (EET DST) X-Scanned: Mon, 2 Aug 2004 15:43:09 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i72Ch94p028194; Mon, 2 Aug 2004 15:43:09 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00BexwxL; Mon, 02 Aug 2004 15:43:07 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72Ch1u09985; Mon, 2 Aug 2004 15:43:01 +0300 (EET DST) Subject: Re: [Simple] XCAP - Idempotent Delete From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <410D2593.1040203@dynamicsoft.com> References: <5.1.0.14.0.20040801121624.023dd520@localhost> <410D2593.1040203@dynamicsoft.com> Content-Type: text/plain Message-Id: <1091450480.4902.117.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 02 Aug 2004 15:42:14 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit On Sun, 2004-08-01 at 20:17, ext Jonathan Rosenberg wrote: > Joel M. Halpern wrote: > > > I noticed in reading the recent XCAP draft that in making everything > > Idempotent, certain restrictions were introduced. > > > > Given a document > > > > contenta > > contentb > > contentc > > > > one can replace the second bar with a path of the form /foo/bar[2]. > > However, one can not delete that second element with /foo/bar[2], > > because that delete, if applied a second time, would produce a different > > document (i.e. it is not idempotent.) > > That's not the intent. The intent is that it is allowed. > > The definition of idempotent is that a series of N operations have the > same effect as 1. If I do N DELETE operations to foo/bar[2], the first > causes the delete, and the rest generate 404. The net result is that N > of the operations have the same result as 1, and thus the operation is > idempotent. ok, given this definition for idempotent delete I'll agree with Joel as the second delete will find contentc which is another resource (!). But then deleting /foo/bar[3] would be idempotent and all of the similar delete requests are still unambiguous. > > > > I can live with this restriction. > > But it does awkward. > > Also, the server is require to check the condition, which makes for some > > interesting error checking code. > it is easy to implement if you just have to check after successful delete that you'll don't find anything. Anyway, I'll fully agree that this idempotency requirement introduces protocol ugliness but apparently we have to comply with rfc2616... > Jari had a similar impression, so clearly there is text in here that is > conveying an intent that I am not seeing. Can you point to the specific > text that is leading you to this conclusion? > > Thanks, > Jonathan R. > br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 08:54:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03992; Mon, 2 Aug 2004 08:54:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrcNH-0004yA-Ou; Mon, 02 Aug 2004 08:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrcIP-0003dG-5o; Mon, 02 Aug 2004 08:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrcDo-0001li-LN for simple@megatron.ietf.org; Mon, 02 Aug 2004 08:47:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03674 for ; Mon, 2 Aug 2004 08:47:19 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrcGf-0004sy-Al for simple@ietf.org; Mon, 02 Aug 2004 08:50:18 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72CkrV16968; Mon, 2 Aug 2004 15:46:53 +0300 (EET DST) X-Scanned: Mon, 2 Aug 2004 15:46:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i72Ckaum026871; Mon, 2 Aug 2004 15:46:36 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00yNVrx2; Mon, 02 Aug 2004 15:46:34 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72CkSn07400; Mon, 2 Aug 2004 15:46:28 +0300 (EET DST) Subject: Re: [Simple] XCAP - Idempotent Delete From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <410D2593.1040203@dynamicsoft.com> References: <5.1.0.14.0.20040801121624.023dd520@localhost> <410D2593.1040203@dynamicsoft.com> Content-Type: text/plain Message-Id: <1091450740.5119.4.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 02 Aug 2004 15:45:40 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit On Sun, 2004-08-01 at 20:17, ext Jonathan Rosenberg wrote: > Joel M. Halpern wrote: > > > I noticed in reading the recent XCAP draft that in making everything > > Idempotent, certain restrictions were introduced. > > > > Given a document > > > > contenta > > contentb > > contentc > > > > one can replace the second bar with a path of the form /foo/bar[2]. > > However, one can not delete that second element with /foo/bar[2], > > because that delete, if applied a second time, would produce a different > > document (i.e. it is not idempotent.) > > That's not the intent. The intent is that it is allowed. > > The definition of idempotent is that a series of N operations have the > same effect as 1. If I do N DELETE operations to foo/bar[2], the first > causes the delete, and the rest generate 404. The net result is that N > of the operations have the same result as 1, and thus the operation is > idempotent. ok, given this definition for idempotent delete I'll agree with Joel as the second delete will find contentc which is another resource (!). But then deleting /foo/bar[3] would be idempotent and all of the similar delete requests are still unambiguous. > > > > I can live with this restriction. > > But it does awkward. > > Also, the server is require to check the condition, which makes for some > > interesting error checking code. it is easy to implement if you just have to check after successful delete that you'll don't find anything. Anyway, I'll fully agree that this idempotency requirement introduces protocol ugliness but apparently we have to comply with rfc2616... > Jari had a similar impression, so clearly there is text in here that is > conveying an intent that I am not seeing. Can you point to the specific > text that is leading you to this conclusion? > > Thanks, > Jonathan R. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 11:01:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12046; Mon, 2 Aug 2004 11:01:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BreME-0006ih-8Q; Mon, 02 Aug 2004 11:04:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bre34-00071q-FG; Mon, 02 Aug 2004 10:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brduz-0003mj-Sz for simple@megatron.ietf.org; Mon, 02 Aug 2004 10:36:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11031 for ; Mon, 2 Aug 2004 10:36:00 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brdxs-0006Rn-Mg for simple@ietf.org; Mon, 02 Aug 2004 10:39:00 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i72EUXKZ015313; Mon, 2 Aug 2004 10:30:35 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 10:28:34 -0400 Message-ID: From: Eric Burger To: seancolson@yahoo.com Subject: RE: Chunking driver (was RE: [Simple] MSRP Boundary header) Date: Mon, 2 Aug 2004 10:28:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Actually, -07 clearly explains why chunking is needed (finally!). It is for when you have a single pipe with multiple sessions, and you want to ensure some sort of "fairness" algorithm. The concept really looks good when we introduce Relays. Thus, I am on board, and 2K or 8K is quite livable. > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Sunday, July 18, 2004 12:48 PM > To: 'Eric Burger' > Cc: simple@ietf.org > Subject: RE: Chunking driver (was RE: [Simple] MSRP Boundary header) > > > Perfect. Move that number to 8K. That just makes the argument > stronger. The > point is that you can make an intelligent decision about the > dividing line > between where to chunk and where not to. Of course in that 8K > packet, you > are likely to put quite a few small IMs (for the relay and > MCU scnearios). > Which is even more reason not mess with scanning for a boundary. > > -----Original Message----- > From: Eric Burger [mailto:eburger@brooktrout.com] > Sent: Saturday, July 17, 2004 11:33 PM > To: seancolson@yahoo.com > Cc: simple@ietf.org > Subject: Chunking driver (was RE: [Simple] MSRP Boundary header) > > Ummm. Isn't the transport TCP? If you are on a LAN, aren't > you going to be > using 8K packets, anyway? E.g., I really don't get the > chunking drive. > > Can't claim "small device": are you saying that these devices won't be > surfing the web, getting e-mail, etc.? > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Tuesday, June 29, 2004 10:48 PM > > To: 'Vijay Hampapur Hampapur Parthasarathy'; 'Ben Campbell' > > Cc: simple@ietf.org > > Subject: RE: [Simple] MSRP Boundary header > > > [snip] > > > > The choice of which to use will typically be made based on content > > size and is a simple implementation decision. > > For example, for messages larger than 2K, it probably makes > sense to > > chunk up the content. Otherwise, why not use a simpler approach. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 11:29:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13448; Mon, 2 Aug 2004 11:29:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brend-0007B5-K3; Mon, 02 Aug 2004 11:32:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Breai-0003Sw-Tb; Mon, 02 Aug 2004 11:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BreNE-0006yu-8l for simple@megatron.ietf.org; Mon, 02 Aug 2004 11:05:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12279 for ; Mon, 2 Aug 2004 11:05:10 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BreQ6-0006nN-Bj for simple@ietf.org; Mon, 02 Aug 2004 11:08:11 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i72EwsKZ025498 for ; Mon, 2 Aug 2004 10:58:56 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 10:56:54 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Mon, 2 Aug 2004 10:56:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Simple] MSRP-07 and report failure X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab This description is much, much, much more clear and sensible. One thing I want to confirm: If I send a message with "Report-Failure: Yes", I will not get 200 OK's to my successful SENDs. That said, let us say one sets "Report-Failure: partial", and the session times out. I would suggest adding normative language to section 4.3 (first paragraph of page 12): "MUST inform the user if receives a non-recoverable error response to the transaction *and terminate the session*." On the issue of restarting sessions (last bit of 4.3 on page 13), do we really want to specify normative behavior for different reconnection schemes, or is this more of a BCP? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 11:45:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14608; Mon, 2 Aug 2004 11:45:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brf2n-0007SY-0i; Mon, 02 Aug 2004 11:48:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrepQ-0001gJ-Cw; Mon, 02 Aug 2004 11:34:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bregv-0005Id-Ts for simple@megatron.ietf.org; Mon, 02 Aug 2004 11:25:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13243 for ; Mon, 2 Aug 2004 11:25:31 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brejo-000776-0T for simple@ietf.org; Mon, 02 Aug 2004 11:28:33 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i72FEj33000483; Mon, 2 Aug 2004 11:14:47 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 11:12:45 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Mon, 2 Aug 2004 11:12:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Paul Kyzivat \(E-mail\)" Subject: [Simple] MSRP-07 - Dropping Content X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a When dealing with multipart/mixed and multipart/alternative, especially for gateway use, I would propose leveraging the Critical-Content work of RFC 3459. One useful thing is that would answer the question Paul raised with what do you do with a message that violates one quota: Quota for text/plain: 128; quota for text/html: 1024 With a message with multipart/alternative and a text/plain of 256 and text/html of 512, I would offer the gateway silently deletes the text/plain alternative. That is WHY the sender specified multiplart/alternative in the first place. Now let's say the message is not multipart/alternative, but is multipart/mixed. Let us also assume that the sizes and quotas are the same. We could reject the entire message, which is the current language. I would offer that we introduce RFC 3459, critical-content, which allows the sender to mark which parts, if any MUST get gatewayed, and which MAY be silently deleted. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 11:55:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15167; Mon, 2 Aug 2004 11:55:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrfCf-0007cW-Bz; Mon, 02 Aug 2004 11:58:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brf4y-0000IO-5g; Mon, 02 Aug 2004 11:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brev4-0004Cf-Ki for simple@megatron.ietf.org; Mon, 02 Aug 2004 11:40:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14250 for ; Mon, 2 Aug 2004 11:40:08 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brexv-0007Mj-1l for simple@ietf.org; Mon, 02 Aug 2004 11:43:10 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i72FYa33008347 for ; Mon, 2 Aug 2004 11:34:37 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 11:32:36 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Mon, 2 Aug 2004 11:32:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] MSRP-07 - Multiple URL path attributes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 The text states: "If an endpoint puts more than one URL in a path attribute, the final URL in the path (the peer URL) attribute MUST exhibit the uniqueness properties described above." Aren't relays left-to-right? Should not the First URL be locally unique? Isn't one of the major use cases of relays to cross administrative domains where people are freely allowed to do something weird, but legal? For example, my URL is msrps://10.1.1.12:12345/random. The URL of the other endpoint, which sits behind two relays, is msrps://10.1.1.12:12345/random. It is not unique, but that is NOT a problem, because presumable the next to last relay handed out something like msrps://natbox.example.com/unit12-fuzz to the embedded endpoint to use. Or did I miss how relays work, and the endpoint would never use msrps://10.1.1.12:12345 and instead ONLY use msrps://natbox.example.com/unit12-fuzz? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 11:59:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15335; Mon, 2 Aug 2004 11:59:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrfGQ-0007fC-QD; Mon, 02 Aug 2004 12:02:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brf4z-0000JW-Ae; Mon, 02 Aug 2004 11:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brev1-0004Ca-8J for simple@megatron.ietf.org; Mon, 02 Aug 2004 11:40:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14247 for ; Mon, 2 Aug 2004 11:40:05 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brext-0007Mj-J1 for simple@ietf.org; Mon, 02 Aug 2004 11:43:06 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i72FYa33008348 for ; Mon, 2 Aug 2004 11:34:38 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 11:32:36 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Mon, 2 Aug 2004 11:32:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Simple] MSRP-07 - DSN codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 OK, so this isn't going away. Here is why you DON'T want to just copy the result code into the DSN status code, as stated in section 8.7. Per RFC 3463 (1894 is Obsolete...), we MUST use the following error codes: Section 10 DSN code Meaning 200 2.0.0 Unknown success (probably OK) 400 4.0.0 Unknown persistent temporary failure (probably OK) 403 4.5.1 Protocol error (5), invalid command (1) 415 4.6.1 Message/Media error (6), media not supported (1) 426 4.7.8 Security error (7), TLS required (proposed as 8) 481 4.4.2 Network error (4), excessive dropouts? (2, or new code) 506 5.4.8 Network error (4), connection exists (proposed as 8) So, do you want to change 403 to 451, 415 to 461, 426 to 478, 481 to 442, and 506 to 548? That works, but... Per RFC 3463, the error type and specific error codes are three digit numbers. Thus SIMPLE response codes would be NXXXXXX, not NXX, where N=[2-5] and X=[0-9]. Is that what we want? It actually might no be so bad to have finer structure to the error code. Things are pretty ad hoc beyond the N in NXX. It does mean that SIMPLE error codes would be more in line with SMTP error codes and not necessarily in line with SIP error codes. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 12:40:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17669; Mon, 2 Aug 2004 12:40:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brftv-0008KZ-Hi; Mon, 02 Aug 2004 12:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrfgO-0008I6-OA; Mon, 02 Aug 2004 12:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrfT2-0001ia-JI for simple@megatron.ietf.org; Mon, 02 Aug 2004 12:15:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16101 for ; Mon, 2 Aug 2004 12:15:13 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrfVu-0007u5-J1 for simple@ietf.org; Mon, 02 Aug 2004 12:18:16 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i72GAJZB018300 for ; Mon, 2 Aug 2004 12:10:24 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 12:08:19 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Date: Mon, 2 Aug 2004 12:08:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Simple] e2e security X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Something I realized when reviewing relays is that we may wish to comment somewhere (probably once in MSRP, and again in Relays w.r.t. changing chunking) that S/MIME will only work on the entire message. While one MIGHT be tempted to secure a chunk, that will break when it gets chopped up by relays. However, by having the endpoint reassemble the full message, S/MIME will work if you consider it over the entire message. In the relay draft, it may be worth noting in section 3 (page 7) that header encryption is clearly hop-by-hop only. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 12:49:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18115; Mon, 2 Aug 2004 12:49:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brg2j-0008Rr-Bf; Mon, 02 Aug 2004 12:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrfgT-0008Jd-Hi; Mon, 02 Aug 2004 12:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrfWJ-0002l9-Fi for simple@megatron.ietf.org; Mon, 02 Aug 2004 12:18:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16361 for ; Mon, 2 Aug 2004 12:18:37 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrfZB-0007yB-QE for simple@ietf.org; Mon, 02 Aug 2004 12:21:39 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72GILO27814; Mon, 2 Aug 2004 19:18:21 +0300 (EET DST) X-Scanned: Mon, 2 Aug 2004 19:18:01 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i72GI1GU026752; Mon, 2 Aug 2004 19:18:01 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00Ict0Yj; Mon, 02 Aug 2004 19:18:00 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72GHtu07521; Mon, 2 Aug 2004 19:17:55 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 2 Aug 2004 19:17:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP - Idempotent Delete Date: Mon, 2 Aug 2004 19:17:54 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEBA5@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP - Idempotent Delete Thread-Index: AcR37Sw/bdmDvvEUTL6u9O3rVpaRwQAvr/uQ To: , X-OriginalArrivalTime: 02 Aug 2004 16:17:54.0614 (UTC) FILETIME=[44241560:01C478AC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 01.August.2004 20:17 > To: Joel M. Halpern > Cc: simple@ietf.org > Subject: Re: [Simple] XCAP - Idempotent Delete >=20 >=20 >=20 >=20 > Joel M. Halpern wrote: >=20 > > I noticed in reading the recent XCAP draft that in making=20 > everything=20 > > Idempotent, certain restrictions were introduced. > >=20 > > Given a document > > > > contenta > > contentb > > contentc > > > > one can replace the second bar with a path of the form /foo/bar[2]. > > However, one can not delete that second element with /foo/bar[2],=20 > > because that delete, if applied a second time, would=20 > produce a different=20 > > document (i.e. it is not idempotent.) >=20 > That's not the intent. The intent is that it is allowed. >=20 > The definition of idempotent is that a series of N operations=20 > have the=20 > same effect as 1. If I do N DELETE operations to foo/bar[2],=20 > the first=20 > causes the delete, and the rest generate 404. The net result=20 > is that N=20 > of the operations have the same result as 1, and thus the=20 > operation is=20 > idempotent. If I do the first DELETE on foo/bar[2], I end up with contenta contentc If I do a second DELETE on foo/bar[2], I end up with contenta Since the with value "contectc" is now the element in the = second position. Is the idempotent? Regards, Hisham >=20 >=20 > >=20 > > I can live with this restriction. > > But it does awkward. > > Also, the server is require to check the condition, which=20 > makes for some=20 > > interesting error checking code. >=20 > Jari had a similar impression, so clearly there is text in=20 > here that is=20 > conveying an intent that I am not seeing. Can you point to=20 > the specific=20 > text that is leading you to this conclusion? >=20 > Thanks, > Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 14:03:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22776; Mon, 2 Aug 2004 14:03:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrhCB-0001Jv-OQ; Mon, 02 Aug 2004 14:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brgsh-0007h0-5d; Mon, 02 Aug 2004 13:45:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brgai-0008Kf-C9 for simple@megatron.ietf.org; Mon, 02 Aug 2004 13:27:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20481 for ; Mon, 2 Aug 2004 13:27:15 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brgdb-0000eC-5y for simple@ietf.org; Mon, 02 Aug 2004 13:30:16 -0400 Received: from nokia.com (esnira-pool4015128.nokia.com [10.162.15.128]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i72HR7O24499; Mon, 2 Aug 2004 20:27:08 +0300 (EET DST) Message-ID: <410E796A.8080504@nokia.com> Date: Mon, 02 Aug 2004 20:27:06 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] WGLC: XCAP Base References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> In-Reply-To: <410D0B5B.6060503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Jari Urpalainen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Thanks for your comments, Jari. Responses inline. > > Jari Urpalainen wrote: > >> A few comments/questions. >> >> 8.5 Managing Etags >> >> As Jonathan has interpreted (complying with rfc2616) that a node or >> even an attribute of an xml-document can be regarded as a resource is >> it allowable to send the document ETag after partial delete which is >> then actually an ETag of a different resource ? > > > I don't know. I fear that the answer is no; after a DELETE, the resource > is deleted, so by definition THAT resource doesn't have an etag anymore. Although I agree, one can think of a few tricks that would help to transport the new etag of the new version of the document. For instance, you can think of first allocating a new etag to the resource to be deleted, then executing the delete operation. The 200 OK for the DELETE contains the etag of the resource right before its deletion. This happens to be the etag of the new remaining document. I also found that RFC 2616 says: "In order to be legal, a strong entity tag MUST change whenever the associated entity value changes in any way." Does "in any way" include "when the resource is deleted? I am trying to find if it is fine to create a new entity value for a deleted resource. > >> I would certainly prefer that it is still being sent as otherwise you >> introduce a second deficiency into safe updates of the document (the >> first one being partial append). > > > I'm not sure what ability we have to mandate this. Since we're using > HTTP, its going to depend on what HTTP says. I looked around for any > text which talks about etags in DELETE responses, and didnt see anything. I looked around and I didn't see that is forbidden. On the other hand, I suspect that in an XCAP server modeled as a layer of an HTTP stack and an XCAP application, the XCAP application will choose the etag value and pass it through an internal API to the HTTP stack; the HTTP stack will encod it in a Etag header according to HTTP. In other words, since the value of the Etag is selected by the XCAP application and pass to the HTTP stack, we don't break HTTP by including it in a 200 OK for a DELETE response. Comments? Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 14:24:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24820; Mon, 2 Aug 2004 14:24:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrhWs-0001w7-3i; Mon, 02 Aug 2004 14:27:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrhKr-0005FL-TO; Mon, 02 Aug 2004 14:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpdZi-0002ia-1I for simple@megatron.ietf.org; Tue, 27 Jul 2004 21:49:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27462 for ; Tue, 27 Jul 2004 21:49:44 -0400 (EDT) Message-Id: <200407280149.VAA27462@ietf.org> Received: from [218.1.66.102] (helo=mail.citiz.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BpdbO-0004AY-Ko for simple@ietf.org; Tue, 27 Jul 2004 21:51:33 -0400 Received: (umta 7583 invoked by alias); 28 Jul 2004 01:49:30 -0000 X-Lasthop: 218.1.121.106 Received: from unknown (HELO ZPH-N2C) (unknown@218.1.121.106) by localhost with SMTP; 28 Jul 2004 01:49:30 -0000 Date: Wed, 28 Jul 2004 09:49:23 +0800 From: "zhangpeihao" To: "SIMPLE" , "sip-implementors" , "sip@ietf.org" X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 02 Aug 2004 14:14:56 -0400 Subject: [Simple] Where can I find a free SIMPLE server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhangpeihao@citiz.net List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi all, I have created a SIMPLE client, I want test it now. Where can I find a free SIMPLE server for test? Thanks, zhangpeihao zhangpeihao@citiz.net 2004-07-28 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 14:24:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24872; Mon, 2 Aug 2004 14:24:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrhXE-0001wZ-9l; Mon, 02 Aug 2004 14:27:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrhKs-0005Fv-EP; Mon, 02 Aug 2004 14:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpiRL-0001cA-9K for simple@megatron.ietf.org; Wed, 28 Jul 2004 03:01:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09507 for ; Wed, 28 Jul 2004 03:01:26 -0400 (EDT) Received: from web51510.mail.yahoo.com ([206.190.38.202]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BpiT5-000099-G4 for simple@ietf.org; Wed, 28 Jul 2004 03:03:17 -0400 Message-ID: <20040728070054.35436.qmail@web51510.mail.yahoo.com> Received: from [202.224.193.183] by web51510.mail.yahoo.com via HTTP; Wed, 28 Jul 2004 00:00:54 PDT Date: Wed, 28 Jul 2004 00:00:54 -0700 (PDT) From: Koyama Zehi To: zhangpeihao@citiz.net, SIMPLE , sip-implementors , "sip@ietf.org" In-Reply-To: <200407280149.i6S1nWlC003922@cs.columbia.edu> MIME-Version: 1.0 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Mon, 02 Aug 2004 14:14:56 -0400 Subject: [Simple] Re: [Sip-implementors] Where can I find a free SIMPLE server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0289816792==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============0289816792== Content-Type: multipart/alternative; boundary="0-82793606-1090998054=:34763" --0-82793606-1090998054=:34763 Content-Type: text/plain; charset=us-ascii you can download "SER" from http://www.iptel.org best of luck zhangpeihao wrote: Hi all, I have created a SIMPLE client, I want test it now. Where can I find a free SIMPLE server for test? Thanks, zhangpeihao zhangpeihao@citiz.net 2004-07-28 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! --0-82793606-1090998054=:34763 Content-Type: text/html; charset=us-ascii
you can download "SER" from http://www.iptel.org
best of luck


zhangpeihao <zhangpeihao@citiz.net> wrote:
Hi all,

I have created a SIMPLE client, I want test it now.

Where can I find a free SIMPLE server for test?

Thanks,

zhangpeihao
zhangpeihao@citiz.net
2004-07-28


_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage! --0-82793606-1090998054=:34763-- --===============0289816792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0289816792==-- From simple-bounces@ietf.org Mon Aug 2 14:36:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25661; Mon, 2 Aug 2004 14:36:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrhiP-00028P-A9; Mon, 02 Aug 2004 14:39:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrhZh-0003nk-Fe; Mon, 02 Aug 2004 14:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrhOy-0006KD-U5 for simple@megatron.ietf.org; Mon, 02 Aug 2004 14:19:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24324 for ; Mon, 2 Aug 2004 14:19:11 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrhRs-0001oE-39 for simple@ietf.org; Mon, 02 Aug 2004 14:22:13 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i72IIseE008296; Mon, 2 Aug 2004 14:18:55 -0400 (EDT) Message-ID: <410E857A.40504@dynamicsoft.com> Date: Mon, 02 Aug 2004 14:18:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] XCAP - Idempotent Delete References: <2038BCC78B1AD641891A0D1AE133DBB7023EEBA5@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEBA5@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: joel@stevecrocker.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: >>>Given a document >>> >>> contenta >>> contentb >>> contentc >>> >>>one can replace the second bar with a path of the form /foo/bar[2]. >>>However, one can not delete that second element with /foo/bar[2], >>>because that delete, if applied a second time, would >> >>produce a different >> >>>document (i.e. it is not idempotent.) >> >>That's not the intent. The intent is that it is allowed. >> >>The definition of idempotent is that a series of N operations >>have the >>same effect as 1. If I do N DELETE operations to foo/bar[2], >>the first >>causes the delete, and the rest generate 404. The net result >>is that N >>of the operations have the same result as 1, and thus the >>operation is >>idempotent. > > > If I do the first DELETE on foo/bar[2], I end up with > > > contenta > contentc > > > If I do a second DELETE on foo/bar[2], I end up with > > > contenta > > > Since the with value "contectc" is now the element in the second position. Is the idempotent? No, it is not. My bad. I had missed this case. I think Jari has been trying to point this out but somehow I could not get it into my head. In this context, yes, I think we need to prohibit this. The server would need to check that, after the DELETE, the URI in the r-uri does not evaluate to an existing resource. This problem only arises with positional deletions. Using absolute ones (i.e,. using an index), or even positional+attribute, you will never run into this problem, and I think its a good idea to note this. Its the same kind of problem as insertion - the URI needs to be built to satisfy TWO properties - it identifies the resource after insertion, but doesnt exist before. Deletion is just the opposite, it identifies the resource before deletion, and nothing afterwards. THus, its the inverse of the insertion constraint. So, I will document this further restriction and the workarounds. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 14:45:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26099; Mon, 2 Aug 2004 14:45:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrhrC-0002Gj-9c; Mon, 02 Aug 2004 14:48:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrhbY-0004mk-Uf; Mon, 02 Aug 2004 14:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrhYz-0003Jf-FM for simple@megatron.ietf.org; Mon, 02 Aug 2004 14:29:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25161 for ; Mon, 2 Aug 2004 14:29:32 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brhbu-00020i-3Y for simple@ietf.org; Mon, 02 Aug 2004 14:32:34 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i72ITJeE008302; Mon, 2 Aug 2004 14:29:20 -0400 (EDT) Message-ID: <410E87EC.6020200@dynamicsoft.com> Date: Mon, 02 Aug 2004 14:29:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] WGLC: XCAP Base References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> <1091442424.4525.270.camel@xitami.research.nokia.com> In-Reply-To: <1091442424.4525.270.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Jari Urpalainen wrote: >>I'm hoping that I've just misunderstood how to construct the namespace >>context for xpath expression evaluations.... >> > > As you can't send namespace prefix and corresponding namespace uris with > queries (unless you use namepace-uri() and local-name() functions) you > have to use in-scope definitions that you find from the document. Given > your example I don't see a problem: does not know test or other > namespace definitions only 's have in-scope definitions. So you can > do relative selections like "test:bar[condition xxx]" within > context as (which is a child node of Here is where I don't follow. Within foo, the namespace "test" is NOT defined. So, how can I possibly canonicalize it in order to do an equality check? Remember, equality checks with namespaces require canonicalization to the namespace URI; that is, the prefix is always an alias to the namepsace URI. Thus, the following two elements are equal: -> also a new location > step) clearly belongs to test:.. namespace. So when doing > implementations location step parsers have to be aware of all in-scope > namespace definitions. Right, I agree. But the two namespaces I need to select the children are not in scope! (and if you use fully xpath 1.0 compatible > libraries they'll most likely have some "hooks" where namepaces can be > "registered" when evaluating xpath expressions). I'll also remind that > with XCAP it was agreed that namespace definitions can not be added like > attributes, so during insert you can not just insert (as it > has namespace definition), instead you have to insert . No, xcap does not say this. It says you cannot SELECT based on a namespace attribute. That does NOT mean that an inserted element (i.e., the thing in the body of the PUT) cannot contain a namespace declaration attribute. >>>--------------- >>>I still miss non-default namespace examples. >> >>Once I figure out how this works, I will add them. The norm for us will >>include non-default namespaces, so, in fact, I will change all of them >>to use non-defaults. >> > > as both models are allowed it would imo be best to have also both > examples. OK. >> >>Good point. Caching responses is OK, I think. If a client is GETing lots >>of different elements within the document, the caching won't be very >>effective. A cache won't know how to relate the URI for the document >>with the URIs for the elements and attributes within the document, but >>thats OK. The caching isn't broken; its just not taking advantage of >>xcap URI interdependencies to improve performance. Putting that aside, >>subsequent requests for the same URI/resource could fetch the content >>from a cache. That would be OK. The server probably wants to set the >>max-age such that the content expires relatively quickly, but this >>probably depends on the application usage. >> >>As long as all of that sounds fine, I will add text explaining this in a >>new section on caching. >> >>-Jonathan R. >> > > What worries me here mostly is that after partial delete/put caches may > send incorrect content (e.g. when getting the whole document). This is a > similar problem as what we have with ETags, because a single document > contains many resources which are somehow related. Ahh, interesting. You are correct. A cache knows to invalidate when it gets a PUT to a resource, but not when it sees a PUT to another resource which invalidates the cache. Of course, with ANY caching scheme, the resource could change by a PUT to that resource that doesn't go through the cache. Thats a consequence of caching. I don't think XCAP changes anything there. The same caveats apply; if you cache, the document may be stale. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 2 14:50:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26424; Mon, 2 Aug 2004 14:50:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brhvk-0002Md-Dh; Mon, 02 Aug 2004 14:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrhoY-00012b-4m; Mon, 02 Aug 2004 14:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brhc2-0004pz-0h for simple@megatron.ietf.org; Mon, 02 Aug 2004 14:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25436 for ; Mon, 2 Aug 2004 14:32:40 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brhew-00024y-Q1 for simple@ietf.org; Mon, 02 Aug 2004 14:35:43 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i72IWTeE008306; Mon, 2 Aug 2004 14:32:29 -0400 (EDT) Message-ID: <410E88A9.7040408@dynamicsoft.com> Date: Mon, 02 Aug 2004 14:32:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] WGLC: XCAP Base References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> <410E796A.8080504@nokia.com> In-Reply-To: <410E796A.8080504@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: Jari Urpalainen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit inline. Miguel Garcia wrote: > > > Jonathan Rosenberg wrote: > >> Thanks for your comments, Jari. Responses inline. >> >> Jari Urpalainen wrote: >> >>> A few comments/questions. >>> >>> 8.5 Managing Etags >>> >>> As Jonathan has interpreted (complying with rfc2616) that a node or >>> even an attribute of an xml-document can be regarded as a resource is >>> it allowable to send the document ETag after partial delete which is >>> then actually an ETag of a different resource ? >> >> >> >> I don't know. I fear that the answer is no; after a DELETE, the >> resource is deleted, so by definition THAT resource doesn't have an >> etag anymore. > > > Although I agree, one can think of a few tricks that would help to > transport the new etag of the new version of the document. For instance, > you can think of first allocating a new etag to the resource to be > deleted, then executing the delete operation. The 200 OK for the DELETE > contains the etag of the resource right before its deletion. This > happens to be the etag of the new remaining document. Thats not a valid usage of etag. > > I also found that RFC 2616 says: > > "In order to be legal, a strong entity tag MUST change whenever the > associated entity value changes in any way." > > Does "in any way" include "when the resource is deleted? I am trying to > find if it is fine to create a new entity value for a deleted resource. I doubt it, but again, will ask around while here. > > >> >>> I would certainly prefer that it is still being sent as otherwise you >>> introduce a second deficiency into safe updates of the document (the >>> first one being partial append). >> >> >> >> I'm not sure what ability we have to mandate this. Since we're using >> HTTP, its going to depend on what HTTP says. I looked around for any >> text which talks about etags in DELETE responses, and didnt see anything. > > > I looked around and I didn't see that is forbidden. On the other hand, I > suspect that in an XCAP server modeled as a layer of an HTTP stack and > an XCAP application, the XCAP application will choose the etag value and > pass it through an internal API to the HTTP stack; the HTTP stack will > encod it in a Etag header according to HTTP. In other words, since the > value of the Etag is selected by the XCAP application and pass to the > HTTP stack, we don't break HTTP by including it in a 200 OK for a DELETE > response. Comments? Just because an API might allow it, doesnt mean its right or a good idea. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 3 06:06:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29450; Tue, 3 Aug 2004 06:06:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrwEt-0007FK-5v; Tue, 03 Aug 2004 06:09:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brvtr-0007TU-Op; Tue, 03 Aug 2004 05:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrvDd-0002Qt-D1 for simple@megatron.ietf.org; Tue, 03 Aug 2004 05:04:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25886 for ; Tue, 3 Aug 2004 05:04:23 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrvGf-0006Uj-TS for simple@ietf.org; Tue, 03 Aug 2004 05:07:34 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7394JO19180; Tue, 3 Aug 2004 12:04:20 +0300 (EET DST) X-Scanned: Tue, 3 Aug 2004 12:03:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7393aHD011731; Tue, 3 Aug 2004 12:03:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 008jAKeR; Tue, 03 Aug 2004 12:03:33 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7393Tu06482; Tue, 3 Aug 2004 12:03:29 +0300 (EET DST) Subject: Re: [Simple] WGLC: XCAP Base From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <410E87EC.6020200@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> <1091442424.4525.270.camel@xitami.research.nokia.com> <410E87EC.6020200@dynamicsoft.com> Content-Type: text/plain Message-Id: <1091523760.6357.188.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 03 Aug 2004 12:02:40 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit On Mon, 2004-08-02 at 21:29, ext Jonathan Rosenberg wrote: > Jari Urpalainen wrote: > > >>I'm hoping that I've just misunderstood how to construct the namespace > >>context for xpath expression evaluations.... > >> > > > > As you can't send namespace prefix and corresponding namespace uris with > > queries (unless you use namepace-uri() and local-name() functions) you > > have to use in-scope definitions that you find from the document. Given > > your example I don't see a problem: does not know test or other > > namespace definitions only 's have in-scope definitions. So you can > > do relative selections like "test:bar[condition xxx]" within > > context as (which is a child node of > > Here is where I don't follow. Within foo, the namespace "test" is NOT > defined. So, how can I possibly canonicalize it in order to do an > equality check? Remember, equality checks with namespaces require > canonicalization to the namespace URI; that is, the prefix is always an > alias to the namepsace URI. Thus, the following two elements are equal: > > > > > > right. > > -> also a new location > > step) clearly belongs to test:.. namespace. So when doing > > implementations location step parsers have to be aware of all in-scope > > namespace definitions. > > Right, I agree. But the two namespaces I need to select the children are > not in scope! > right, not in-scope of but instead in-scope of the child of . So if you select from foo's parent context with relative request foo/test:bar you'll first find (lets's say no default namespace defined) as no prefix no namespace expansion. Then you take the next step, the bar node which happens to have prefix and in-scope namespace definition so you have to compare the namespace uri and element name in context. Similarly, if happens to be a root node of the document and you have namespace definition there, then you also have "in-scope" namespace definitions that has to be followed: selecting with absolute query /foo will fail with xpath 1.0 compatible query because has in-scope namespace definition. For the request to succeed you should provide a query like /ns:foo where ns="namespace". With xpath 1.0 you can have /*[local-name()="foo"][namespace-uri()="namespace"] This syntax is of course "not so nice" and it is desirable to use the in-scope namespace definition which is defined in this case within the child element. So the confusion seems to be where the in-scope namespace is defined and how the query is interpreted. > (and if you use fully xpath 1.0 compatible > > libraries they'll most likely have some "hooks" where namepaces can be > > "registered" when evaluating xpath expressions). I'll also remind that > > with XCAP it was agreed that namespace definitions can not be added like > > attributes, so during insert you can not just insert (as it > > has namespace definition), instead you have to insert . > > No, xcap does not say this. It says you cannot SELECT based on a > namespace attribute. That does NOT mean that an inserted element (i.e., > the thing in the body of the PUT) cannot contain a namespace > declaration attribute. > ok, that's better than my incorrect interpretation. This is definitely worth mentioning more clearly in the draft, because it needs some handling during implementation. Even an example would not be bad... > > >>>--------------- > >>>I still miss non-default namespace examples. > >> > >>Once I figure out how this works, I will add them. The norm for us will > >>include non-default namespaces, so, in fact, I will change all of them > >>to use non-defaults. > >> > > > > as both models are allowed it would imo be best to have also both > > examples. > > OK. > > > >> > >>Good point. Caching responses is OK, I think. If a client is GETing lots > >>of different elements within the document, the caching won't be very > >>effective. A cache won't know how to relate the URI for the document > >>with the URIs for the elements and attributes within the document, but > >>thats OK. The caching isn't broken; its just not taking advantage of > >>xcap URI interdependencies to improve performance. Putting that aside, > >>subsequent requests for the same URI/resource could fetch the content > >>from a cache. That would be OK. The server probably wants to set the > >>max-age such that the content expires relatively quickly, but this > >>probably depends on the application usage. > >> > >>As long as all of that sounds fine, I will add text explaining this in a > >>new section on caching. > >> > >>-Jonathan R. > >> > > > > What worries me here mostly is that after partial delete/put caches may > > send incorrect content (e.g. when getting the whole document). This is a > > similar problem as what we have with ETags, because a single document > > contains many resources which are somehow related. > > Ahh, interesting. You are correct. A cache knows to invalidate when it > gets a PUT to a resource, but not when it sees a PUT to another resource > which invalidates the cache. > > Of course, with ANY caching scheme, the resource could change by a PUT > to that resource that doesn't go through the cache. Thats a consequence > of caching. I don't think XCAP changes anything there. The same caveats > apply; if you cache, the document may be stale. that's right that caches may miss requests (e.g. different route), but in order for them to be efficient they should also know xcap semantics the requirement of which is not desirable. > -Jonathan R. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 3 17:57:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15383; Tue, 3 Aug 2004 17:57:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7L1-0002Fr-Jw; Tue, 03 Aug 2004 18:00:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7BQ-0000wU-J6; Tue, 03 Aug 2004 17:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs79v-0000gR-1A for simple@megatron.ietf.org; Tue, 03 Aug 2004 17:49:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14845 for ; Tue, 3 Aug 2004 17:49:20 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7D4-000288-Gs for simple@ietf.org; Tue, 03 Aug 2004 17:52:39 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73LnIk17183; Wed, 4 Aug 2004 00:49:18 +0300 (EET DST) X-Scanned: Wed, 4 Aug 2004 00:49:10 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i73LnACC010003; Wed, 4 Aug 2004 00:49:10 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 008ASCEf; Wed, 04 Aug 2004 00:49:10 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i73Ln4u03170; Wed, 4 Aug 2004 00:49:04 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 4 Aug 2004 00:49:00 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 10.241.58.224 10.241.58.224 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by esebe013.ntc.nokia.com; 04 Aug 2004 00:48:55 +0300 Subject: Re: [Simple] WGLC: XCAP Base From: Aki Niemi To: ext Jonathan Rosenberg In-Reply-To: <410D0B5B.6060503@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1091569735.21927.61.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 04 Aug 2004 00:48:55 +0300 X-OriginalArrivalTime: 03 Aug 2004 21:49:00.0189 (UTC) FILETIME=[AF5C04D0:01C479A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Jari Urpalainen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On Sun, 2004-08-01 at 18:25, ext Jonathan Rosenberg wrote: > Thanks for your comments, Jari. Responses inline. > > Jari Urpalainen wrote: > > > A few comments/questions. > > > > 8.5 Managing Etags > > > > As Jonathan has interpreted (complying with rfc2616) that a node or even > > an attribute of an xml-document can be regarded as a resource is it > > allowable to send the document ETag after partial delete which is then > > actually an ETag of a different resource ? > > I don't know. I fear that the answer is no; after a DELETE, the resource > is deleted, so by definition THAT resource doesn't have an etag anymore. There is something with Etags here that keeps worrying me. Because of the way that etags are distributed over an XCAP document (i.e., all elements/resources share the same etag value), it seems that we lose some important property for some XCAP applications. Let's say we have an XML document that has two sub trees. In one subtree (called ) you have a flat list of properly indexed, simple elements, like TRUE Naturally updating this list doesn't require safe updates at all. One could simply PUT/GET/DELETE blindly using the name attribute as selection key. Now let's say that the other subtree (called ) is a much more elaborate object, where safe updates are required. SOmething akin to common policy for example. Because of the way we have currently defined etags usage, I believe any blind update to the subtree automatically forces also getting the subtree, because the etags have changed. I think this is really suboptimal, and it would be great if it could be somehow avoided. For example, having the possibility for an application to define etag "ranges". In the above example, there would be three ranges defined: One for the root element of the document, second for the bar subtree and the third for the baz tree. A change would only propagate within a single range. The application could still GET the whole document by selecting the root element, but it would need to do separate GETs for each of the subtrees ot get their respective etags. A HEAD to each subtree might suffice as well, at least to some extent. Thoughts? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 3 20:39:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26320; Tue, 3 Aug 2004 20:39:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9rh-00053g-G7; Tue, 03 Aug 2004 20:42:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9kS-0003H2-ON; Tue, 03 Aug 2004 20:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9g7-0002SH-3u for simple@megatron.ietf.org; Tue, 03 Aug 2004 20:30:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25673 for ; Tue, 3 Aug 2004 20:30:45 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9jH-0004qu-8a for simple@ietf.org; Tue, 03 Aug 2004 20:34:04 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i740UXeE009102; Tue, 3 Aug 2004 20:30:33 -0400 (EDT) Message-ID: <41102E12.8030303@dynamicsoft.com> Date: Tue, 03 Aug 2004 20:30:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] WGLC: XCAP Base References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> <1091569735.21927.61.camel@localhost.localdomain> In-Reply-To: <1091569735.21927.61.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Jari Urpalainen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit inline. Aki Niemi wrote: >>I don't know. I fear that the answer is no; after a DELETE, the resource >>is deleted, so by definition THAT resource doesn't have an etag anymore. > > > There is something with Etags here that keeps worrying me. Because of > the way that etags are distributed over an XCAP document (i.e., all > elements/resources share the same etag value), it seems that we lose > some important property for some XCAP applications. > > Let's say we have an XML document that has two sub trees. In one subtree > (called ) you have a flat list of properly indexed, simple > elements, like > > TRUE > > Naturally updating this list doesn't require safe updates at all. One > could simply PUT/GET/DELETE blindly using the name attribute as > selection key. > > Now let's say that the other subtree (called ) is a much more > elaborate object, where safe updates are required. SOmething akin to > common policy for example. > > Because of the way we have currently defined etags usage, I believe any > blind update to the subtree automatically forces also getting the > subtree, because the etags have changed. > > I think this is really suboptimal, and it would be great if it could be > somehow avoided. For example, having the possibility for an application > to define etag "ranges". In the above example, there would be three > ranges defined: One for the root element of the document, second for the > bar subtree and the third for the baz tree. A change would only > propagate within a single range. We've been through this, Aki. I proposed extensive text onto the list (on 6/24/04) on a framework for Etag scopes that we *could* support in order to allow what you are talking about. As I wrote up the details, the complexity just grew and grew, and it hit the point that I didnt have any good ideas on how to practically implement it. As such, an open issue was raised (Issue 8), and the list consensus was to simplify, and keep etags scoped to a document. We also heard from Scott Lawrence today that having the etag scope to a document was really an essential feature for using HTTP as well. As such, I am disinclined to revisit this open issue, as we've been through it a few times already. Unless you can bring a new workable proposal to the table, I think we should stay with the current solution. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 3 21:00:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27809; Tue, 3 Aug 2004 21:00:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsACF-0005Ra-2G; Tue, 03 Aug 2004 21:03:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsA66-0007Nb-VF; Tue, 03 Aug 2004 20:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsA27-0006oX-IU for simple@megatron.ietf.org; Tue, 03 Aug 2004 20:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27358 for ; Tue, 3 Aug 2004 20:53:30 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsA5G-0005Ix-D8 for simple@ietf.org; Tue, 03 Aug 2004 20:56:49 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i740rGeE009121; Tue, 3 Aug 2004 20:53:16 -0400 (EDT) Message-ID: <41103367.5000207@dynamicsoft.com> Date: Tue, 03 Aug 2004 20:52:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] WGLC: XCAP Base References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> <1091442424.4525.270.camel@xitami.research.nokia.com> <410E87EC.6020200@dynamicsoft.com> <1091523760.6357.188.camel@xitami.research.nokia.com> In-Reply-To: <1091523760.6357.188.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit inline. Jari Urpalainen wrote: > On Mon, 2004-08-02 at 21:29, ext Jonathan Rosenberg wrote: > >>Jari Urpalainen wrote: >> >> >>>>I'm hoping that I've just misunderstood how to construct the namespace >>>>context for xpath expression evaluations.... >>>> >>> >>>As you can't send namespace prefix and corresponding namespace uris with >>>queries (unless you use namepace-uri() and local-name() functions) you >>>have to use in-scope definitions that you find from the document. Given >>>your example I don't see a problem: does not know test or other >>>namespace definitions only 's have in-scope definitions. So you can >>>do relative selections like "test:bar[condition xxx]" within >>>context as (which is a child node of >> >>Here is where I don't follow. Within foo, the namespace "test" is NOT >>defined. So, how can I possibly canonicalize it in order to do an >>equality check? Remember, equality checks with namespaces require >>canonicalization to the namespace URI; that is, the prefix is always an >>alias to the namepsace URI. Thus, the following two elements are equal: >> >> >> >> >> >> > > right. > > >>-> also a new location >> >>>step) clearly belongs to test:.. namespace. So when doing >>>implementations location step parsers have to be aware of all in-scope >>>namespace definitions. >> >>Right, I agree. But the two namespaces I need to select the children are >>not in scope! >> > > > right, not in-scope of but instead in-scope of the child of > . Right; but we are selecting based on foo's context! > So if you select from foo's parent context with relative request > foo/test:bar you'll first find (lets's say no default namespace > defined) as no prefix no namespace expansion. Then you take the next > step, the bar node which happens to have prefix and in-scope namespace > definition so you have to compare the namespace uri and element name in > context. Your assumption here is that the context is modified each time we do an equality comparison. That is, when I check to see if the location step matches a particular child, I adopt the namespace context in scope for that child. This seems circular to me, and not what the Xpath spec is saying (I thought). > > Similarly, if happens to be a root node of the document and you > have namespace definition there, then you also have "in-scope" namespace > definitions that has to be followed: > > > > > selecting with absolute query /foo will fail with xpath 1.0 compatible > query because has in-scope namespace definition. For the request > to succeed you should provide a query like /ns:foo where ns="namespace". > With xpath 1.0 you can have > /*[local-name()="foo"][namespace-uri()="namespace"] > This syntax is of course "not so nice" and it is desirable to use the > in-scope namespace definition which is defined in this case within the > child element. So the confusion seems to be where the in-scope namespace > is defined and how the query is interpreted. Right. So, are you saying that XPath 2.0 says that, when evaluating steps along a child axes, you define the scope as the scope of that child when performing the evaluation? > > >> (and if you use fully xpath 1.0 compatible >> >>>libraries they'll most likely have some "hooks" where namepaces can be >>>"registered" when evaluating xpath expressions). I'll also remind that >>>with XCAP it was agreed that namespace definitions can not be added like >>>attributes, so during insert you can not just insert (as it >>>has namespace definition), instead you have to insert . >> >>No, xcap does not say this. It says you cannot SELECT based on a >>namespace attribute. That does NOT mean that an inserted element (i.e., >>the thing in the body of the PUT) cannot contain a namespace >>declaration attribute. >> > > > ok, that's better than my incorrect interpretation. This is definitely > worth mentioning more clearly in the draft, because it needs some > handling during implementation. Even an example would not be bad... OK, I will clarify. > > >>>>>--------------- >>>>>I still miss non-default namespace examples. >>>> >>>>Once I figure out how this works, I will add them. The norm for us will >>>>include non-default namespaces, so, in fact, I will change all of them >>>>to use non-defaults. >>>> >>> >>>as both models are allowed it would imo be best to have also both >>>examples. >> >>OK. >> >> >> >>>>Good point. Caching responses is OK, I think. If a client is GETing lots >>>>of different elements within the document, the caching won't be very >>>>effective. A cache won't know how to relate the URI for the document >>>>with the URIs for the elements and attributes within the document, but >>>>thats OK. The caching isn't broken; its just not taking advantage of >>>>xcap URI interdependencies to improve performance. Putting that aside, >>>>subsequent requests for the same URI/resource could fetch the content >>> >>>>from a cache. That would be OK. The server probably wants to set the >>> >>>>max-age such that the content expires relatively quickly, but this >>>>probably depends on the application usage. >>>> >>>>As long as all of that sounds fine, I will add text explaining this in a >>>>new section on caching. >>>> >>>>-Jonathan R. >>>> >>> >>>What worries me here mostly is that after partial delete/put caches may >>>send incorrect content (e.g. when getting the whole document). This is a >>>similar problem as what we have with ETags, because a single document >>>contains many resources which are somehow related. >> >>Ahh, interesting. You are correct. A cache knows to invalidate when it >>gets a PUT to a resource, but not when it sees a PUT to another resource >>which invalidates the cache. >> >>Of course, with ANY caching scheme, the resource could change by a PUT >>to that resource that doesn't go through the cache. Thats a consequence >>of caching. I don't think XCAP changes anything there. The same caveats >>apply; if you cache, the document may be stale. > > > that's right that caches may miss requests (e.g. different route), but > in order for them to be efficient they should also know xcap semantics > the requirement of which is not desirable. Well, we can't (and shouldn't) ask for caches to change. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 4 09:20:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03810; Wed, 4 Aug 2004 09:20:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsLjs-0008Bi-BU; Wed, 04 Aug 2004 09:23:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsLaX-0003co-8Y; Wed, 04 Aug 2004 09:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsLYw-0003Ic-HL for simple@megatron.ietf.org; Wed, 04 Aug 2004 09:12:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03034 for ; Wed, 4 Aug 2004 09:12:08 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsLcE-0007xB-06 for simple@ietf.org; Wed, 04 Aug 2004 09:15:34 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74DC4E28958; Wed, 4 Aug 2004 16:12:05 +0300 (EET DST) X-Scanned: Wed, 4 Aug 2004 16:11:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i74DBVJV009216; Wed, 4 Aug 2004 16:11:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00A3TWJQ; Wed, 04 Aug 2004 16:11:30 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74DBDn16275; Wed, 4 Aug 2004 16:11:14 +0300 (EET DST) Subject: Re: [Simple] WGLC: XCAP Base From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <41103367.5000207@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> <1091442424.4525.270.camel@xitami.research.nokia.com> <410E87EC.6020200@dynamicsoft.com> <1091523760.6357.188.camel@xitami.research.nokia.com> <41103367.5000207@dynamicsoft.com> Content-Type: text/plain Message-Id: <1091625023.7925.324.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 04 Aug 2004 16:10:24 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit On Wed, 2004-08-04 at 03:52, ext Jonathan Rosenberg wrote: > inline. > > Jari Urpalainen wrote: > > > On Mon, 2004-08-02 at 21:29, ext Jonathan Rosenberg wrote: > > > >>Jari Urpalainen wrote: > >> > >> > >>>>I'm hoping that I've just misunderstood how to construct the namespace > >>>>context for xpath expression evaluations.... > >>>> > >>> > >>>As you can't send namespace prefix and corresponding namespace uris with > >>>queries (unless you use namepace-uri() and local-name() functions) you > >>>have to use in-scope definitions that you find from the document. Given > >>>your example I don't see a problem: does not know test or other > >>>namespace definitions only 's have in-scope definitions. So you can > >>>do relative selections like "test:bar[condition xxx]" within > >>>context as (which is a child node of > >> > >>Here is where I don't follow. Within foo, the namespace "test" is NOT > >>defined. So, how can I possibly canonicalize it in order to do an > >>equality check? Remember, equality checks with namespaces require > >>canonicalization to the namespace URI; that is, the prefix is always an > >>alias to the namepsace URI. Thus, the following two elements are equal: > >> > >> > >> > >> > >> > >> > > > > right. > > > > > >>-> also a new location > >> > >>>step) clearly belongs to test:.. namespace. So when doing > >>>implementations location step parsers have to be aware of all in-scope > >>>namespace definitions. > >> > >>Right, I agree. But the two namespaces I need to select the children are > >>not in scope! > >> > > > > > > right, not in-scope of but instead in-scope of the child of > > . > > Right; but we are selecting based on foo's context! > > > So if you select from foo's parent context with relative request > > foo/test:bar you'll first find (lets's say no default namespace > > defined) as no prefix no namespace expansion. Then you take the next > > step, the bar node which happens to have prefix and in-scope namespace > > definition so you have to compare the namespace uri and element name in > > context. > > Your assumption here is that the context is modified each time we do an > equality comparison. That is, when I check to see if the location step > matches a particular child, I adopt the namespace context in scope for > that child. This seems circular to me, and not what the Xpath spec is > saying (I thought). I have just glanced at the spec but I can't imagine any other way how expression evaluation could work, because in xml you can/will attach the namespace definition to the same node where it is defined. Also XPath 1.0 spec does not say from where you do find the namespace definitions (prefix and uri), for that e.g. XPointer (look 5.2) is needed (i.e. if you don't use local-name() and namespace-uri()). If (and when) you have to rely on the document context I don't see any other options unless you have better ideas ? > > > > Similarly, if happens to be a root node of the document and you > > have namespace definition there, then you also have "in-scope" namespace > > definitions that has to be followed: > > > > > > > > > > selecting with absolute query /foo will fail with xpath 1.0 compatible > > query because has in-scope namespace definition. For the request > > to succeed you should provide a query like /ns:foo where ns="namespace". > > With xpath 1.0 you can have > > /*[local-name()="foo"][namespace-uri()="namespace"] > > This syntax is of course "not so nice" and it is desirable to use the > > in-scope namespace definition which is defined in this case within the > > child element. So the confusion seems to be where the in-scope namespace > > is defined and how the query is interpreted. > > Right. So, are you saying that XPath 2.0 says that, when evaluating > steps along a child axes, you define the scope as the scope of that > child when performing the evaluation? > if you look at the query /foo, / means document root and is the child of /, i.e. the document root. So if we select from the document root we'll find the child the node and yes the context in is different from / as it is another step, right ? And if you have a query like /ns:foo it is clear to me that you start searching for definition for ns from context given the xml namespace model. The bogus default namespace behavior in xpath 1.0 is a well known feature (deficiency) and I just assume that 2.0 will have that fixed by this in-scope namespace definition. Also I assume that declaration of namespaces in queries are left to XQuery so that XPath 2.0 don't either have them (I might be wrong here). However, imo it doesn't matter that much how it will be handled in the new xpath 2.0 spec because XCAP is having an own bnf which is otherwise compatible with xpath 1.0, but default namespace handling just needs to be different (i.e. sensible) and that search for non-default namespace definitions should also be defined in the draft. I am aware that using document context is far from optimal (or elegant) but do we really have any good options ? Furthermore, all of the libraries that I am aware of and claim to be XPath 1.0 compatible leave this non-default namespace definitions search out of the query, so you have to "register" namespace definitions separately. This is certainly a problem (as you have said) but imo it is up to us to find a proper search model. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 4 14:38:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27217; Wed, 4 Aug 2004 14:38:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQiK-0005jO-70; Wed, 04 Aug 2004 14:42:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQQA-0005HC-19; Wed, 04 Aug 2004 14:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQHu-0003b5-7V for simple@megatron.ietf.org; Wed, 04 Aug 2004 14:14:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25279 for ; Wed, 4 Aug 2004 14:14:52 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQLD-0005Df-OF for simple@ietf.org; Wed, 04 Aug 2004 14:18:21 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74IEkl23135; Wed, 4 Aug 2004 21:14:46 +0300 (EET DST) X-Scanned: Wed, 4 Aug 2004 21:14:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i74IEVcn013946; Wed, 4 Aug 2004 21:14:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00otCHoU; Wed, 04 Aug 2004 21:14:31 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i74IEVu08414; Wed, 4 Aug 2004 21:14:31 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 4 Aug 2004 21:14:31 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 4 Aug 2004 21:14:31 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 10.241.58.244 10.241.58.244 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by esebe013.ntc.nokia.com; 04 Aug 2004 21:14:27 +0300 Subject: Re: [Simple] WGLC: XCAP Base From: Aki Niemi To: ext Jonathan Rosenberg In-Reply-To: <41102E12.8030303@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB7023EEB40@esebe019.ntc.nokia.com> <41076D39.9090508@nokia.com> <410D0B5B.6060503@dynamicsoft.com> <1091569735.21927.61.camel@localhost.localdomain> <41102E12.8030303@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1091643267.5539.134.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 04 Aug 2004 21:14:27 +0300 X-OriginalArrivalTime: 04 Aug 2004 18:14:31.0505 (UTC) FILETIME=[E3706C10:01C47A4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Jari Urpalainen , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit On Wed, 2004-08-04 at 03:30, ext Jonathan Rosenberg wrote: > We've been through this, Aki. Sorry about that, Jonathan. I now remember seeing the issue on the list but with vacations and all it had simply slipped out of the memory banks... > I proposed extensive text onto the list (on 6/24/04) on a framework for > Etag scopes that we *could* support in order to allow what you are > talking about. As I wrote up the details, the complexity just grew and > grew, and it hit the point that I didnt have any good ideas on how to > practically implement it. As such, an open issue was raised (Issue 8), > and the list consensus was to simplify, and keep etags scoped to a document. I agree with the complexity this would bring. In fact, reading the concrete proposal text made my stomach turn ;) Since the scope markers would simply have the same effect as splitting the document would have, why bother. > We also heard from Scott Lawrence today that having the etag scope to a > document was really an essential feature for using HTTP as well. > > As such, I am disinclined to revisit this open issue, as we've been > through it a few times already. Unless you can bring a new workable > proposal to the table, I think we should stay with the current solution. Agreed, so let's stick to option 1 (scope is always the full document). That in mind, perhaps we could add text to the chapter that contains guidelines to application usage that highlights this issue, and explains how one might go about avoiding this. Namely, that splitting the document into several documents, where it is important to have etags apply to a certain place only. (That combined with naming conventions for the "starting place" will do exactly what I was actually looking for). Again sorry for totally missing the discussion of this issue the first time around. Cheers, Aki > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 4 23:45:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04197; Wed, 4 Aug 2004 23:45:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsZFa-0006bu-6x; Wed, 04 Aug 2004 23:49:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsZ7v-0006G0-BA; Wed, 04 Aug 2004 23:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsZ3Z-0005ji-Aq for simple@megatron.ietf.org; Wed, 04 Aug 2004 23:36:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03719 for ; Wed, 4 Aug 2004 23:36:38 -0400 (EDT) Received: from itri.org.tw ([210.68.176.20] helo=maillog.itri.org.tw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsZ6v-0006Ud-Ep for simple@ietf.org; Wed, 04 Aug 2004 23:40:12 -0400 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id i753coG17455 for ; Thu, 5 Aug 2004 11:38:50 +0800 (CST) Received: from ms2.itri.org.tw (ms2.itri.org.tw [140.96.147.44]) by mail.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id i753VEJ23397 for ; Thu, 5 Aug 2004 11:31:15 +0800 (CST) Received: from 11091017891 ([140.96.254.153]) by ms2.itri.org.tw (Lotus Domino Release 5.0.11) with ESMTP id 2004080511343832:24615 ; Thu, 5 Aug 2004 11:34:38 +0800 From: =?big5?B?s6+rVMx4IFwoSmltbXkgQ2hlblwp?= To: "'SIMPLE'" Subject: [Simple] About protocol interface between XCAP server and PS... Date: Thu, 5 Aug 2004 11:34:36 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200407280149.VAA27462@ietf.org> thread-index: AcR4vfZS/LrzByWrSlWgA11NvnSi1wB2nGww X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-MIMETrack: Itemize by SMTP Server on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2004-08-05 11:34:38 AM, Serialize by Router on MS2/ITRI(Release 5.0.11 |July 24, 2002) at 2004-08-05 11:35:57 AM, Serialize complete at 2004-08-05 11:35:57 AM Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi all, Is there any document that specify the interface between XCAP server and Presence Server? If not, any plans? Thanks, Jimmy Chen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 5 23:16:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07817; Thu, 5 Aug 2004 23:16:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsvHW-0003IY-A8; Thu, 05 Aug 2004 23:20:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsvA8-0003Wp-Nt; Thu, 05 Aug 2004 23:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsv91-0003Ku-BT for simple@megatron.ietf.org; Thu, 05 Aug 2004 23:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07566 for ; Thu, 5 Aug 2004 23:11:44 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsvCZ-0003D2-Iz for simple@ietf.org; Thu, 05 Aug 2004 23:15:31 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i763BReE010506; Thu, 5 Aug 2004 23:11:30 -0400 (EDT) Message-ID: <4112F6C8.2040704@dynamicsoft.com> Date: Thu, 05 Aug 2004 23:11:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?Big5?B?IrOvq1TMeCBcXChKaW1teSBDaGVuXFwpIg==?= Subject: Re: [Simple] About protocol interface between XCAP server and PS... References: In-Reply-To: Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i763BReE010506 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: "'SIMPLE'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable If you want to use a standard interface, you would use XCAP itself. I expect many systems will co-locate these, or provide them as part of a common solution and thus use proprietary technologies. -Jonathan R. =B3=AF=ABT=CCx (Jimmy Chen) wrote: > Hi all, >=20 > Is there any document that specify the interface between XCAP server an= d > Presence Server? >=20 > If not, any plans? >=20 > Thanks, > Jimmy Chen >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 6 01:00:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15138; Fri, 6 Aug 2004 01:00:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bswtq-0005UW-8D; Fri, 06 Aug 2004 01:04:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bswoh-0003tm-UG; Fri, 06 Aug 2004 00:58:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bswm1-0003OJ-78 for simple@megatron.ietf.org; Fri, 06 Aug 2004 00:56:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14809 for ; Fri, 6 Aug 2004 00:56:05 -0400 (EDT) Received: from [65.208.0.180] (helo=spectra.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bswpe-0005Nh-3h for simple@ietf.org; Fri, 06 Aug 2004 00:59:55 -0400 Received: from [130.129.128.127] (opene-130-129-128-127.ietf60.ietf.org [130.129.128.127]) (authenticated bits=0) by spectra.softarmor.com (8.12.8/8.12.8) with ESMTP id i764tPBU025992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Aug 2004 23:55:27 -0500 Message-ID: <41130F37.4060005@softarmor.com> Date: Thu, 05 Aug 2004 23:55:19 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , "'SIMPLE'" Subject: Re: [Simple] About protocol interface between XCAP server and PS... References: <4112F6C8.2040704@dynamicsoft.com> In-Reply-To: <4112F6C8.2040704@dynamicsoft.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: =?Big5?B?IrOvq1TMeCBcXChKaW1teSBDaGVuXFwpIg==?= X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > If you want to use a standard interface, you would use XCAP itself. I > expect many systems will co-locate these, or provide them as part of a > common solution and thus use proprietary technologies. > Umm, I was thinking I might use the old xcap-package or the new config package. Here's the scenario: The memberhsip of a list is stored on an XCAP server, which we might call a "contact list server". This thing understands XCAP, and understands some sort of event package that can inform watchers about changes in the contents of the "contact lists". The "presence server" acts as a "resource list sever" to provide aggregation of presence subscription and notification to the users listed on "contact lists". The "presence server" SUBSCRIBES to notification of changes to "contact lists". Users use XCAP to twiddle the membership of their "contact lists". The "contact list server" then sends a NOTIFY to the "presence server" which either contains the relevant list change, or tells the presence server enough that it can re-fetch the list using XCAP. The "presence server" then constructs a resource list from the "contact list" and sets up back-end subscriptions as per the example in the event-list draft. I realize that this model is inconsistent with how many in SIMPLE think of the problem, but it's fairly consistent with how I think OMA is envisioning the presence architecture supporting PoC. Now, with the recent elimination of the xcap-package and its merger into the config-package, I'm a little confused as to how this comes together. Help? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 10:00:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29668; Mon, 9 Aug 2004 10:00:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuAlX-0005KZ-Kj; Mon, 09 Aug 2004 10:04:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuAZw-0004LT-Dc; Mon, 09 Aug 2004 09:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuAYy-0004C0-K4 for simple@megatron.ietf.org; Mon, 09 Aug 2004 09:51:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29269 for ; Mon, 9 Aug 2004 09:51:42 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuAdJ-0005Dx-MK for simple@ietf.org; Mon, 09 Aug 2004 09:56:14 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i79Dpf327209 for ; Mon, 9 Aug 2004 16:51:41 +0300 (EET DST) X-Scanned: Mon, 9 Aug 2004 16:51:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i79DpREr018249 for ; Mon, 9 Aug 2004 16:51:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00UfGe0V; Mon, 09 Aug 2004 16:51:25 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i79DpPu14099 for ; Mon, 9 Aug 2004 16:51:25 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Aug 2004 16:51:25 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id 3FD1193B75 for ; Mon, 9 Aug 2004 16:51:25 +0300 (EEST) Received: from agni.research.nokia.com (news.netsonic.fi [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i79DfSWn016834 for ; Mon, 9 Aug 2004 16:41:28 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i79DfRLL016833; Mon, 9 Aug 2004 16:41:27 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Mon, 09 Aug 2004 16:41:27 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 09 Aug 2004 13:51:25.0682 (UTC) FILETIME=[F66BBD20:01C47E17] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Simple] MSRP-07 and charsets X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hello all, There is no mention about charsets in MSRP except for the SDP attributes used by session setup. I think the MSRP spec was supposed to declare UTF-8 as the default charset. A message without a charset parameter in Content-Type would default to UTF-8, and all the endpoints should accept messages using UTF-8. However, I'm afraid it will take some time before UTF-8 will be universally available, so it might be worthwhile to negotiate the charsets for the MSRP session. HTTP uses Accept-Charset header for that purpose. We could define a accept-charset attribute. Here is a proposal based on cut'n'paste from RFC 2616. --Pekka ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--- X.X.X The accept-charset attribute The accept-charset attribute can be used to indicate what character sets are acceptable for the endpoint. The attribute allows endpoints capable of understanding more special-purpose character sets to announce their capabilities. accept-charset = accept-charset-label ":" charset-list accept-charset-label = "accept-charset" charset-list = chatset-entry *( SP charset-entry) chatset-entry = token | "*" Character set values are described in [17]. An example is a=accept-charset:iso-8859-15,iso-8859-1,utf-8 The special value "*", if present in the accept-charset attribute, matches every character set. Even if no "*" is present in an accept-charset attribute, the endpoint is required to accept UTF-8 encoded text. OPEN ISSUE: is this reasonable requirement? Unicode fonts may be an overkill for very simple devices with text-only display. If no accept-charset attribute is present in SDP sent by the endpoint, the default is that any character set is acceptable. If an accept-charset attribute is present, and if the other endpoint cannot send messages which are acceptable according to the accept-charset attribute, then the endpoint may reject the session. Alternatively, if the endpoint accepts the session and if the session is set up with SIP, the endpoint may issue Warning code 305. --->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--- ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--- 15.3.5 Accept Charsets Attribute-name: accept-charsets Long-form Attribute Name: MSRP Charsets Type: Media level Subject to Charset Attribute: No Purpose and Appropriate Values: See Section X.X.X --->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 10:01:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29735; Mon, 9 Aug 2004 10:01:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuAmV-0005LS-Fa; Mon, 09 Aug 2004 10:05:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuAbx-0004NC-Sz; Mon, 09 Aug 2004 09:54:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuAZq-0004H1-7c for simple@megatron.ietf.org; Mon, 09 Aug 2004 09:52:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29339 for ; Mon, 9 Aug 2004 09:52:36 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuAeB-0005El-DI for simple@ietf.org; Mon, 09 Aug 2004 09:57:07 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i79Dqa328610 for ; Mon, 9 Aug 2004 16:52:36 +0300 (EET DST) X-Scanned: Mon, 9 Aug 2004 16:52:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i79DqR17022603 for ; Mon, 9 Aug 2004 16:52:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00gQ4ndI; Mon, 09 Aug 2004 16:52:26 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i79DqPu15726 for ; Mon, 9 Aug 2004 16:52:25 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Aug 2004 16:51:53 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id DC3FE93B75 for ; Mon, 9 Aug 2004 16:51:53 +0300 (EEST) Received: from agni.research.nokia.com (news.netsonic.fi [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i79DmgWn016860 for ; Mon, 9 Aug 2004 16:48:42 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i79DmgE8016859; Mon, 9 Aug 2004 16:48:42 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Mon, 09 Aug 2004 16:48:42 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 09 Aug 2004 13:51:53.0786 (UTC) FILETIME=[072C11A0:01C47E18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Simple] MSRP-07 ABNF issues X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hello all, There are a few issues related to ABNF and the text in MSRP-07. Most of them are just nits, but.. 1) The protocol token and method name defintions must have explicit base character 'x' after the '%' sign. I think this is correct form: pMSRP = %x4D.53.52.50 ; MSRP in caps 2) There is no definition for UPALPHA or DIGIT or HT or SP or... I presume: CRLF = %x0D.0A HT = %x09 SP = %x20 UPALPHA = %x41-5A LOWALPHA = %x61-7A DIGIT = %x30-39 ALPHANUM = LOWALPHA / UPALPHA / DIGIT 3) The 'header' can expand to Mime-Header. Mime-Header is not defined anywhere. Left-over from earlier days? 4) The text discusses about "none" as value to Report-Failure. However, ABNF values are "yes", "no" or "partial". 5) "Token" has no closing parenthesis in its expansion. Token definition is again different from everything else. For example, RFC 2045 and sdp-new define "token" like this: token = 1*(%x21 / %xx23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E) 6) Speaking of token, I don't think it is a good idea to have "token" in the MSRP URL. Using "%", for instance, is very very confusing. Instead, transport could be defined separately as a subset of token and unreserved: transport = "tcp" / ttoken ttoken = 1*( ALPHANUM / "-" / "_" / "." / "!" / "~" / "*" / "'" ) 7) Only the first two examples are valid according to the ABNF. There are extra quotation marks or whitespace is missing. Curiously, the examples have data with a CRLF in the beginning (two empty lines after headers) but not at the end (no empty line before end-line). Leftover from message/cpim? --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 11:34:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06301; Mon, 9 Aug 2004 11:34:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuCEW-0006ni-Uj; Mon, 09 Aug 2004 11:38:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuC80-0005Qm-Vp; Mon, 09 Aug 2004 11:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuC5T-0005E2-B2 for simple@megatron.ietf.org; Mon, 09 Aug 2004 11:29:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05998 for ; Mon, 9 Aug 2004 11:29:20 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuC9o-0006jJ-5v for simple@ietf.org; Mon, 09 Aug 2004 11:33:53 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i79FS1XW028097 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 9 Aug 2004 10:28:02 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Mon, 9 Aug 2004 10:27:58 -0500 To: Hisham khartabil , Orit Levin , Rohan Mahy , Chris Boulton , Adam Roach , Cullen Jennings , Robert Sparks , Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] MSRP: Contributor ID X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Hi, In last week's SIMPLE meeting, Orit brought up an issue about how we planned to identify contributors when MSRP is used with a conference focus. Previously, we had discussed using message/cpim wrappers for this purpose. After thinking through the use case, I think Orit may be correct that cpim is unwieldy for this purpose. The use case I think we have in mind is, you have a text conference where each participant has an independent MSRP session with the conference focus. The focus acts as a reflector, forwarding messages that come in on one participant session to each of the other participants. It needs a way to tell the receiving parties which participant sent the message. _How_ it determines what contributor ID to attach to a given message is out of scope for MSRP--that problem belongs to XCON. We had previously assumed the focus would simply wrap the inbound message in a message/cpim document, and use the CPIM "from" field for this purpose. This, however, is problematic for chunked messages, as the focus would need to buffer the message until it had received all the chunks, wrap the completed message in the cpim document, and then send that message out to the other participants, possibly re-chunking in the process. This does seem to me to be burdensome on the focus; it would be nicer if the focus could simply forward the individual chunks, and let the endpoints deal with re-assembling them. Another approach would be to have the focus force the endpoints to use a cpim envelope. However, there may be times where the identity that the focus wants to insert may be different than the identity that the endpoint inserts. Therefore, I propose we add a new optional header called Contributor-ID, which can carry a name-addr. Normal endpoints would never insert this, but a conference focus could insert this header on a per-chunk basis, and avoid the buffering requirement mentioned above. What do others think? Am I completely off base? Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 14:58:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27385; Mon, 9 Aug 2004 14:58:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFQJ-0004Mo-RD; Mon, 09 Aug 2004 15:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuF3T-0008Nl-TK; Mon, 09 Aug 2004 14:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEtU-00059J-20 for simple@megatron.ietf.org; Mon, 09 Aug 2004 14:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23907 for ; Mon, 9 Aug 2004 14:29:10 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuExn-0003OX-Hy for simple@ietf.org; Mon, 09 Aug 2004 14:33:44 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i79IStLD042135 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 9 Aug 2004 13:28:56 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <410C53B4.8020809@dynamicsoft.com> References: <1091061664.1984.12.camel@localhost.localdomain> <4108DA56.1060803@dynamicsoft.com> <222EC56B-E236-11D8-93B7-000D93B0AE1A@nostrum.com> <410C53B4.8020809@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] WG call for comment: Auth48 changes to winfo-package Date: Mon, 9 Aug 2004 13:28:52 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Robert Sparks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Inline: On Jul 31, 2004, at 9:21 PM, Jonathan Rosenberg wrote: >>> [...] >>> Each watcherinfo subscription is associated with a set of "inner" >>> subscriptions being watched. This set is defined by the URI in the >>> Request URI of the watcherinfo SUBSCRIBE request, along with the >>> parent event package of the watcherinfo subscription. The parent >>> event package is obtained by removing the trailing ".winfo" from the >>> value of the Event header field from the watcherinfo SUBSCRIBE >>> request. If the Event header field in the watcherinfo subscription >>> has a value of "presence.winfo", the parent event package is >>> "presence". If the Event header field has a value of >>> "presence.winfo.winfo", the parent event package is >>> "presence.winfo". Normally, the URI in the Request URI of the >>> watcherinfo SUBSCRIBE identifies an address-of-record within the >>> domain. In that case, the set of subscriptions to be watched are all >>> of the subscriptions for the parent event package that have been >>> made to the resource in the Request URI of the watcherinfo >>> SUBSCRIBE. However, the Request URI can contin a URI that defines a >>> larger collection of resources. For example, >>> sip:all-resources@example.com might be defined within example.com to >>> refer to all resources. In that case, a watcherinfo subscription for >>> "presence.winfo" to sip:all-resources@example.com is requesting >>> notifications any time the state of any presence subscription for >>> any resource within example.com changes. A watcherinfo notifier MAY >>> generate a notification any time the state of any of the watched >>> subscriptions changes. >>> >> Do you mean to only allow winfo subscriptions to _larger_ scopes that >> "all subscribers to a resource?" Is it possible to have something >> like "sip:AoLUsersWatchingBen@example.com" that only tells me about >> watchers in the AoL domain, but not watchers from some other domain? > > I'm not sure I follow. > > The problem which caused me to introduce this text is that winfo is > based on a subscription to subscriptions, but it never actually > explicitly says how you identify the "inner" subscriptions that your > winfo subscription applies to! We *assumed* that, if the r-uri of the > winfo subscribe was an AOR, this meant, "I'm interested in all > subscriptions to this AOR". However, we explicitly designed winfo > format to allow for more than one resource to be reported, so > presumably, the request URI could identify a larger set of resources > than just one user. The text above clarifies that, and gives an > example of a URI that identifies all of the users in a domain. > > I'm not sure I see how your example differs from the one in the text I > have suggested. > > -Jonathan R. In retrospect, I do not think my question has any interoperability impact, so please do not block the author's 48 on this discussion. The point of my question was, is this mechanism intended _only_ for creating subscriptions to inner subscriptions of more than one AoR at a time (i.e. at scopes larger than "all subscriptions to one AoR:", or can it be used to identify _any_ set of inner subscriptions. My example was intended to portray a scope of " some subscriptions to an AoR", as a smaller scope than "all subscriptions to an AoR" Or more succinctly, do we intend the R-URI of a winfo subscription to be able to refer to any arbitrary named set of inner subscriptions, or do we intend it to only be able to refer to all inner subscriptions for one AoR or a group of AoRs? > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 15:16:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00069; Mon, 9 Aug 2004 15:16:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFhC-0004pu-Pm; Mon, 09 Aug 2004 15:20:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFUU-00040k-Hv; Mon, 09 Aug 2004 15:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuF4O-0000PQ-ET for simple@megatron.ietf.org; Mon, 09 Aug 2004 14:40:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25830 for ; Mon, 9 Aug 2004 14:40:26 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuF8l-0003t4-4f for simple@ietf.org; Mon, 09 Aug 2004 14:45:00 -0400 Received: from dynamicsoft.com ([63.113.46.60]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i79IeDeE012388; Mon, 9 Aug 2004 14:40:13 -0400 (EDT) Message-ID: <4117C4F9.2030607@dynamicsoft.com> Date: Mon, 09 Aug 2004 14:39:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] WG call for comment: Auth48 changes to winfo-package References: <1091061664.1984.12.camel@localhost.localdomain> <4108DA56.1060803@dynamicsoft.com> <222EC56B-E236-11D8-93B7-000D93B0AE1A@nostrum.com> <410C53B4.8020809@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Robert Sparks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Inline: > > On Jul 31, 2004, at 9:21 PM, Jonathan Rosenberg wrote: > >>>> > > [...] > >>>> Each watcherinfo subscription is associated with a set of "inner" >>>> subscriptions being watched. This set is defined by the URI in the >>>> Request URI of the watcherinfo SUBSCRIBE request, along with the >>>> parent event package of the watcherinfo subscription. The parent >>>> event package is obtained by removing the trailing ".winfo" from the >>>> value of the Event header field from the watcherinfo SUBSCRIBE >>>> request. If the Event header field in the watcherinfo subscription >>>> has a value of "presence.winfo", the parent event package is >>>> "presence". If the Event header field has a value of >>>> "presence.winfo.winfo", the parent event package is >>>> "presence.winfo". Normally, the URI in the Request URI of the >>>> watcherinfo SUBSCRIBE identifies an address-of-record within the >>>> domain. In that case, the set of subscriptions to be watched are all >>>> of the subscriptions for the parent event package that have been >>>> made to the resource in the Request URI of the watcherinfo >>>> SUBSCRIBE. However, the Request URI can contin a URI that defines a >>>> larger collection of resources. For example, >>>> sip:all-resources@example.com might be defined within example.com to >>>> refer to all resources. In that case, a watcherinfo subscription for >>>> "presence.winfo" to sip:all-resources@example.com is requesting >>>> notifications any time the state of any presence subscription for >>>> any resource within example.com changes. A watcherinfo notifier MAY >>>> generate a notification any time the state of any of the watched >>>> subscriptions changes. >>>> >>> Do you mean to only allow winfo subscriptions to _larger_ scopes that >>> "all subscribers to a resource?" Is it possible to have something >>> like "sip:AoLUsersWatchingBen@example.com" that only tells me about >>> watchers in the AoL domain, but not watchers from some other domain? >> >> >> I'm not sure I follow. >> >> The problem which caused me to introduce this text is that winfo is >> based on a subscription to subscriptions, but it never actually >> explicitly says how you identify the "inner" subscriptions that your >> winfo subscription applies to! We *assumed* that, if the r-uri of the >> winfo subscribe was an AOR, this meant, "I'm interested in all >> subscriptions to this AOR". However, we explicitly designed winfo >> format to allow for more than one resource to be reported, so >> presumably, the request URI could identify a larger set of resources >> than just one user. The text above clarifies that, and gives an >> example of a URI that identifies all of the users in a domain. >> >> I'm not sure I see how your example differs from the one in the text I >> have suggested. >> >> -Jonathan R. > > > In retrospect, I do not think my question has any interoperability > impact, so please do not block the author's 48 on this discussion. > > The point of my question was, is this mechanism intended _only_ for > creating subscriptions to inner subscriptions of more than one AoR at a > time (i.e. at scopes larger than "all subscriptions to one AoR:", or can > it be used to identify _any_ set of inner subscriptions. My example was > intended to portray a scope of " some subscriptions to an AoR", as a > smaller scope than "all subscriptions to an AoR". Ah, I understand. > > Or more succinctly, do we intend the R-URI of a winfo subscription to be > able to refer to any arbitrary named set of inner subscriptions, or do > we intend it to only be able to refer to all inner subscriptions for one > AoR or a group of AoRs? I think its a matter of policy. If the administrator of a domain wishes for a URI to be defined which defines a subset of the subscriptions to an AOR, it can do that. Indeed, even if the URI *is* the AOR for a user (i.e., ben@nostrum.com), the winfo subscription might only convey a subset of the inner subscriptions. This is explicitly called out in the document, which talks about the fact that a user can subscribe to winfo for a resource, and only get winfo notifications about their own subscriptions. I suggest changing this line above: However, the Request URI can contin a URI that defines a larger collection of resources. to: However, the Request URI can contain a URI that identifies any set of subscriptions, including the subscriptions to a larger collection of resources. Does that clarify? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 15:22:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01219; Mon, 9 Aug 2004 15:22:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFnN-0004zo-Q5; Mon, 09 Aug 2004 15:26:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFUd-0004CR-Gh; Mon, 09 Aug 2004 15:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuF9f-0001Eq-Ot for simple@megatron.ietf.org; Mon, 09 Aug 2004 14:45:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26214 for ; Mon, 9 Aug 2004 14:45:53 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFE0-00040H-G8 for simple@ietf.org; Mon, 09 Aug 2004 14:50:27 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i79IjgDP043476 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 9 Aug 2004 13:45:43 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4117C4F9.2030607@dynamicsoft.com> References: <1091061664.1984.12.camel@localhost.localdomain> <4108DA56.1060803@dynamicsoft.com> <222EC56B-E236-11D8-93B7-000D93B0AE1A@nostrum.com> <410C53B4.8020809@dynamicsoft.com> <4117C4F9.2030607@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4EF56208-EA34-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] WG call for comment: Auth48 changes to winfo-package Date: Mon, 9 Aug 2004 13:45:39 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Robert Sparks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Aug 9, 2004, at 1:39 PM, Jonathan Rosenberg wrote: > > I think its a matter of policy. If the administrator of a domain > wishes for a URI to be defined which defines a subset of the > subscriptions to an AOR, it can do that. Indeed, even if the URI *is* > the AOR for a user (i.e., ben@nostrum.com), the winfo subscription > might only convey a subset of the inner subscriptions. This is > explicitly called out in the document, which talks about the fact that > a user can subscribe to winfo for a resource, and only get winfo > notifications about their own subscriptions. > > > I suggest changing this line above: > > However, the Request URI can contin a URI that defines a > larger collection of resources. > > to: > > However, the Request URI can contain a URI that identifies any set of > subscriptions, including the subscriptions to a larger collection of > resources. > > > Does that clarify? > Yes, thank you--that is exactly what I was trying to say. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 15:24:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01436; Mon, 9 Aug 2004 15:24:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFpL-00052g-F2; Mon, 09 Aug 2004 15:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFUh-0004G8-9Q; Mon, 09 Aug 2004 15:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFCR-0001VZ-2t for simple@megatron.ietf.org; Mon, 09 Aug 2004 14:48:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26438 for ; Mon, 9 Aug 2004 14:48:45 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFGo-00044i-Ua for simple@ietf.org; Mon, 09 Aug 2004 14:53:19 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Aug 2004 11:50:13 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i79IlgH5007896; Mon, 9 Aug 2004 11:48:11 -0700 (PDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS30097; Mon, 9 Aug 2004 14:47:41 -0400 (EDT) Message-ID: <4117C6CD.8060508@cisco.com> Date: Mon, 09 Aug 2004 14:47:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit comments inline. Paul Ben Campbell wrote: > Hi, > > In last week's SIMPLE meeting, Orit brought up an issue about how we > planned to identify contributors when MSRP is used with a conference > focus. Previously, we had discussed using message/cpim wrappers for this > purpose. > > After thinking through the use case, I think Orit may be correct that > cpim is unwieldy for this purpose. > > The use case I think we have in mind is, you have a text conference > where each participant has an independent MSRP session with the > conference focus. The focus acts as a reflector, forwarding messages > that come in on one participant session to each of the other > participants. It needs a way to tell the receiving parties which > participant sent the message. _How_ it determines what contributor ID to > attach to a given message is out of scope for MSRP--that problem belongs > to XCON. > > We had previously assumed the focus would simply wrap the inbound > message in a message/cpim document, and use the CPIM "from" field for > this purpose. This, however, is problematic for chunked messages, as the > focus would need to buffer the message until it had received all the > chunks, wrap the completed message in the cpim document, and then send > that message out to the other participants, possibly re-chunking in the > process. This does seem to me to be burdensome on the focus; it would be > nicer if the focus could simply forward the individual chunks, and let > the endpoints deal with re-assembling them. I haven't thought this thru carefully, but I think it should be possible to wrap the message in a CPIM wrapper without reassembling it first. It is just a matter of inserting some bytes for the wrapper in the first chunk. If that pushes the first chunk over 2k then it might have to be sent as two chunks, then so be it. If the actual length of the message was provided, then it would need to be changed. And then each other chunk of the message would need to have its byte range adjusted. Then, when the last chunk is found, it needs to have a suffix appended to it to wrap out the CPIM wrapper. (Actually I don't recall the details of CPIM to know if that is needed.) So, it takes a bit of work, but not a huge amount. > Another approach would be to have the focus force the endpoints to use a > cpim envelope. However, there may be times where the identity that the > focus wants to insert may be different than the identity that the > endpoint inserts. > > Therefore, I propose we add a new optional header called Contributor-ID, > which can carry a name-addr. Normal endpoints would never insert this, > but a conference focus could insert this header on a per-chunk basis, > and avoid the buffering requirement mentioned above. > > What do others think? Am I completely off base? I think the two approaches aren't different enough in the work required that they should be judged based on that. Its probably more important to get the semantics right. Suppose we were to go with this new header. And then suppose we had conference participants sending CPIM wrapped messages that contain a From header. What identity should the recipient display? I think it is probably better for the focus to confront this from the beginning, resolving any conflict there might be. This could be resolved with either approach, but I think it is cleaner if you don't present the recipient with any potential conflict. So I would prefer to use CPIM wrappers for this purpose. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 15:28:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02017; Mon, 9 Aug 2004 15:28:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFtf-00059r-Om; Mon, 09 Aug 2004 15:33:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFVM-0004wW-Vq; Mon, 09 Aug 2004 15:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFM3-0003yk-V0 for simple@megatron.ietf.org; Mon, 09 Aug 2004 14:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27415 for ; Mon, 9 Aug 2004 14:58:42 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFQR-0004N7-Ki for simple@ietf.org; Mon, 09 Aug 2004 15:03:16 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i79IuRfe044496 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 9 Aug 2004 13:56:31 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4117C6CD.8060508@cisco.com> References: <4117C6CD.8060508@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Mon, 9 Aug 2004 13:56:23 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: > comments inline. > > Paul > > Ben Campbell wrote: >> Hi, >> In last week's SIMPLE meeting, Orit brought up an issue about how we >> planned to identify contributors when MSRP is used with a conference >> focus. Previously, we had discussed using message/cpim wrappers for >> this purpose. >> After thinking through the use case, I think Orit may be correct that >> cpim is unwieldy for this purpose. >> The use case I think we have in mind is, you have a text conference >> where each participant has an independent MSRP session with the >> conference focus. The focus acts as a reflector, forwarding messages >> that come in on one participant session to each of the other >> participants. It needs a way to tell the receiving parties which >> participant sent the message. _How_ it determines what contributor ID >> to attach to a given message is out of scope for MSRP--that problem >> belongs to XCON. >> We had previously assumed the focus would simply wrap the inbound >> message in a message/cpim document, and use the CPIM "from" field for >> this purpose. This, however, is problematic for chunked messages, as >> the focus would need to buffer the message until it had received all >> the chunks, wrap the completed message in the cpim document, and then >> send that message out to the other participants, possibly re-chunking >> in the process. This does seem to me to be burdensome on the focus; >> it would be nicer if the focus could simply forward the individual >> chunks, and let the endpoints deal with re-assembling them. > > I haven't thought this thru carefully, but I think it should be > possible to wrap the message in a CPIM wrapper without reassembling it > first. It is just a matter of inserting some bytes for the wrapper in > the first chunk. If that pushes the first chunk over 2k then it might > have to be sent as two chunks, then so be it. If the actual length of > the message was provided, then it would need to be changed. And then > each other chunk of the message would need to have its byte range > adjusted. Then, when the last chunk is found, it needs to have a > suffix appended to it to wrap out the CPIM wrapper. (Actually I don't > recall the details of CPIM to know if that is needed.) > > So, it takes a bit of work, but not a huge amount. > I agree this is true, assuming the use of cpim is always that simple. Do we run into any problem if the chunk contained signed or encrypted data? Will the focus ever need to sign or encrypt the data itself? >> Another approach would be to have the focus force the endpoints to >> use a cpim envelope. However, there may be times where the identity >> that the focus wants to insert may be different than the identity >> that the endpoint inserts. >> Therefore, I propose we add a new optional header called >> Contributor-ID, which can carry a name-addr. Normal endpoints would >> never insert this, but a conference focus could insert this header on >> a per-chunk basis, and avoid the buffering requirement mentioned >> above. >> What do others think? Am I completely off base? > > I think the two approaches aren't different enough in the work > required that they should be judged based on that. > > Its probably more important to get the semantics right. Suppose we > were to go with this new header. And then suppose we had conference > participants sending CPIM wrapped messages that contain a From header. > What identity should the recipient display? It seems to me that this is a matter for the conference policy to solve, and is not significantly different than if you have a voice conference, and a caller has a different identity in the credentials for a SIP dialog than in the conference policy. > > I think it is probably better for the focus to confront this from the > beginning, resolving any conflict there might be. This could be > resolved with either approach, but I think it is cleaner if you don't > present the recipient with any potential conflict. So I would prefer > to use CPIM wrappers for this purpose. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 17:02:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17090; Mon, 9 Aug 2004 17:02:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuHM7-0001VM-Tw; Mon, 09 Aug 2004 17:06:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuGzp-0001Wg-LX; Mon, 09 Aug 2004 16:43:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuG7n-0008EL-En for simple@megatron.ietf.org; Mon, 09 Aug 2004 15:48:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04704 for ; Mon, 9 Aug 2004 15:48:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuGCB-0005o3-M2 for simple@ietf.org; Mon, 09 Aug 2004 15:52:36 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Aug 2004 12:49:30 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i79JlMHB025143; Mon, 9 Aug 2004 12:47:28 -0700 (PDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS34019; Mon, 9 Aug 2004 15:34:58 -0400 (EDT) Message-ID: <4117D1E2.8060406@cisco.com> Date: Mon, 09 Aug 2004 15:34:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID References: <4117C6CD.8060508@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: > >> comments inline. >> >> Paul >> >> Ben Campbell wrote: >> >>> Hi, >>> In last week's SIMPLE meeting, Orit brought up an issue about how we >>> planned to identify contributors when MSRP is used with a conference >>> focus. Previously, we had discussed using message/cpim wrappers for >>> this purpose. >>> After thinking through the use case, I think Orit may be correct that >>> cpim is unwieldy for this purpose. >>> The use case I think we have in mind is, you have a text conference >>> where each participant has an independent MSRP session with the >>> conference focus. The focus acts as a reflector, forwarding messages >>> that come in on one participant session to each of the other >>> participants. It needs a way to tell the receiving parties which >>> participant sent the message. _How_ it determines what contributor ID >>> to attach to a given message is out of scope for MSRP--that problem >>> belongs to XCON. >>> We had previously assumed the focus would simply wrap the inbound >>> message in a message/cpim document, and use the CPIM "from" field for >>> this purpose. This, however, is problematic for chunked messages, as >>> the focus would need to buffer the message until it had received all >>> the chunks, wrap the completed message in the cpim document, and then >>> send that message out to the other participants, possibly re-chunking >>> in the process. This does seem to me to be burdensome on the focus; >>> it would be nicer if the focus could simply forward the individual >>> chunks, and let the endpoints deal with re-assembling them. >> >> >> I haven't thought this thru carefully, but I think it should be >> possible to wrap the message in a CPIM wrapper without reassembling it >> first. It is just a matter of inserting some bytes for the wrapper in >> the first chunk. If that pushes the first chunk over 2k then it might >> have to be sent as two chunks, then so be it. If the actual length of >> the message was provided, then it would need to be changed. And then >> each other chunk of the message would need to have its byte range >> adjusted. Then, when the last chunk is found, it needs to have a >> suffix appended to it to wrap out the CPIM wrapper. (Actually I don't >> recall the details of CPIM to know if that is needed.) >> >> So, it takes a bit of work, but not a huge amount. >> > > I agree this is true, assuming the use of cpim is always that simple. Do > we run into any problem if the chunk contained signed or encrypted data? > Will the focus ever need to sign or encrypt the data itself? Well, what are the cases? - the message arriving at the mixer could be signed, encrypted, both, neither - by the sender. - the outgoing message from the mixer could any signing/encryping of the incoming message alone, or could remove one or the other. - the outgoing message from the mixer could be signed, encrypted, both or neither - by the mixer. I'm not sure how many of those combinations are meaningful - not very many I think. If the message is encrypted, and the mixer needs to remove that encryption, then it cannot escape buffering the whole message. If the message is not encrypted, but it is signed with multipart/signed, then it should be possible to remove the signature on the fly. If the message is to be signed and/or encrypted by the mixer, then given a suitable algorith, I think it is possible to do it on the fly, with the restriction that any out-of-order chunks will need to be buffered until their turn arrives. All the stuff that wraps the actual encrypted text can still be inserted at the beginning or end. I'm not sure of this - would need to study the encoding more carefully to be sure, but I think this should work. Note that all of this is independent of whether a CPIM wrapper is being added or not. >> I think the two approaches aren't different enough in the work >> required that they should be judged based on that. >> >> Its probably more important to get the semantics right. Suppose we >> were to go with this new header. And then suppose we had conference >> participants sending CPIM wrapped messages that contain a From header. >> What identity should the recipient display? > > It seems to me that this is a matter for the conference policy to solve, > and is not significantly different than if you have a voice conference, > and a caller has a different identity in the credentials for a SIP > dialog than in the conference policy. Certainly it *can*. But as long as the endpoint can receive identity information in two ways there will always be more confusion that if there is only one way. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 17:03:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17150; Mon, 9 Aug 2004 17:03:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuHMt-0001Wi-Dg; Mon, 09 Aug 2004 17:07:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuH1X-0002A9-RU; Mon, 09 Aug 2004 16:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuGFk-0002Fo-Qe for simple@megatron.ietf.org; Mon, 09 Aug 2004 15:56:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05919 for ; Mon, 9 Aug 2004 15:56:14 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuGK5-0006Ek-Ru for simple@ietf.org; Mon, 09 Aug 2004 16:00:49 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i79JsOjF048929 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 9 Aug 2004 14:54:25 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4117D1E2.8060406@cisco.com> References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Mon, 9 Aug 2004 14:54:21 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit On Aug 9, 2004, at 2:34 PM, Paul Kyzivat wrote: > > > Ben Campbell wrote: >> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: >>> comments inline. >>> >>> Paul >>> >>> Ben Campbell wrote: >>> >>>> Hi, >>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>> we planned to identify contributors when MSRP is used with a >>>> conference focus. Previously, we had discussed using message/cpim >>>> wrappers for this purpose. >>>> After thinking through the use case, I think Orit may be correct >>>> that cpim is unwieldy for this purpose. >>>> The use case I think we have in mind is, you have a text conference >>>> where each participant has an independent MSRP session with the >>>> conference focus. The focus acts as a reflector, forwarding >>>> messages that come in on one participant session to each of the >>>> other participants. It needs a way to tell the receiving parties >>>> which participant sent the message. _How_ it determines what >>>> contributor ID to attach to a given message is out of scope for >>>> MSRP--that problem belongs to XCON. >>>> We had previously assumed the focus would simply wrap the inbound >>>> message in a message/cpim document, and use the CPIM "from" field >>>> for this purpose. This, however, is problematic for chunked >>>> messages, as the focus would need to buffer the message until it >>>> had received all the chunks, wrap the completed message in the cpim >>>> document, and then send that message out to the other participants, >>>> possibly re-chunking in the process. This does seem to me to be >>>> burdensome on the focus; it would be nicer if the focus could >>>> simply forward the individual chunks, and let the endpoints deal >>>> with re-assembling them. >>> >>> >>> I haven't thought this thru carefully, but I think it should be >>> possible to wrap the message in a CPIM wrapper without reassembling >>> it first. It is just a matter of inserting some bytes for the >>> wrapper in the first chunk. If that pushes the first chunk over 2k >>> then it might have to be sent as two chunks, then so be it. If the >>> actual length of the message was provided, then it would need to be >>> changed. And then each other chunk of the message would need to have >>> its byte range adjusted. Then, when the last chunk is found, it >>> needs to have a suffix appended to it to wrap out the CPIM wrapper. >>> (Actually I don't recall the details of CPIM to know if that is >>> needed.) >>> >>> So, it takes a bit of work, but not a huge amount. >>> >> I agree this is true, assuming the use of cpim is always that simple. >> Do we run into any problem if the chunk contained signed or encrypted >> data? Will the focus ever need to sign or encrypt the data itself? > > Well, what are the cases? > - the message arriving at the mixer could be signed, encrypted, both, > neither - by the sender. > - the outgoing message from the mixer could any signing/encryping of > the incoming message alone, or could remove one or the other. > - the outgoing message from the mixer could be signed, encrypted, both > or neither - by the mixer. > > I'm not sure how many of those combinations are meaningful - not very > many I think. > > If the message is encrypted, and the mixer needs to remove that > encryption, then it cannot escape buffering the whole message. > > If the message is not encrypted, but it is signed with > multipart/signed, then it should be possible to remove the signature > on the fly. > > If the message is to be signed and/or encrypted by the mixer, then > given a suitable algorith, I think it is possible to do it on the fly, > with the restriction that any out-of-order chunks will need to be > buffered until their turn arrives. All the stuff that wraps the actual > encrypted text can still be inserted at the beginning or end. > > I'm not sure of this - would need to study the encoding more carefully > to be sure, but I think this should work. > > Note that all of this is independent of whether a CPIM wrapper is > being added or not. > >>> I think the two approaches aren't different enough in the work >>> required that they should be judged based on that. >>> >>> Its probably more important to get the semantics right. Suppose we >>> were to go with this new header. And then suppose we had conference >>> participants sending CPIM wrapped messages that contain a From >>> header. What identity should the recipient display? >> It seems to me that this is a matter for the conference policy to >> solve, and is not significantly different than if you have a voice >> conference, and a caller has a different identity in the credentials >> for a SIP dialog than in the conference policy. > > Certainly it *can*. But as long as the endpoint can receive identity > information in two ways there will always be more confusion that if > there is only one way. It seems like the same problem can exist, regardless of whether we use cpim or a header for this. Even if we just use cpim, you could still have an endpoint use a cpim envelope, just to have the focus blindly stick that inside _another_ cpim envelope. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 9 17:46:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22135; Mon, 9 Aug 2004 17:46:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuI2y-0002rz-17; Mon, 09 Aug 2004 17:51:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHlb-0001cV-U3; Mon, 09 Aug 2004 17:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHTa-0005Xc-0x for simple@megatron.ietf.org; Mon, 09 Aug 2004 17:14:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18825 for ; Mon, 9 Aug 2004 17:14:35 -0400 (EDT) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuHXy-0001wx-2b for simple@ietf.org; Mon, 09 Aug 2004 17:19:11 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by syd-iport-1.cisco.com with ESMTP; 10 Aug 2004 07:23:48 +1000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i79LDYVh024062; Mon, 9 Aug 2004 14:13:36 -0700 (PDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS42780; Mon, 9 Aug 2004 17:13:47 -0400 (EDT) Message-ID: <4117E90B.9090707@cisco.com> Date: Mon, 09 Aug 2004 17:13:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>>> I think the two approaches aren't different enough in the work >>>> required that they should be judged based on that. >>>> >>>> Its probably more important to get the semantics right. Suppose we >>>> were to go with this new header. And then suppose we had conference >>>> participants sending CPIM wrapped messages that contain a From >>>> header. What identity should the recipient display? >>> >>> It seems to me that this is a matter for the conference policy to >>> solve, and is not significantly different than if you have a voice >>> conference, and a caller has a different identity in the credentials >>> for a SIP dialog than in the conference policy. >> >> Certainly it *can*. But as long as the endpoint can receive identity >> information in two ways there will always be more confusion that if >> there is only one way. > > It seems like the same problem can exist, regardless of whether we use > cpim or a header for this. Even if we just use cpim, you could still > have an endpoint use a cpim envelope, just to have the focus blindly > stick that inside _another_ cpim envelope. Well, maybe that is the case. I wouldn't expect the mixer to put another CPIM wrapper around a message that already had one. I would expect it to either adjust the existing wrapper, possibly changing the From header; OR, (equivalently) remove the incoming CPIM wrapper and replace it with a new one constructed by the mixer, possibly using some of the header values from the incoming one. If this new header is added, then either the mixer should remove the From header from any CPIM wrapper, or else should force the two to be the same. I think I am still inclined to prefer using CPIM, but I don't have any compelling arguments for it. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 10 07:24:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14927; Tue, 10 Aug 2004 07:24:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUop-00020b-Jl; Tue, 10 Aug 2004 07:29:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUcc-0000im-Bx; Tue, 10 Aug 2004 07:16:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUZB-0008S7-KG for simple@megatron.ietf.org; Tue, 10 Aug 2004 07:13:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14185 for ; Tue, 10 Aug 2004 07:13:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUdi-0001op-Ac for simple@ietf.org; Tue, 10 Aug 2004 07:17:58 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AB8o625927; Tue, 10 Aug 2004 14:08:50 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 14:08:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7AB86Ic024276; Tue, 10 Aug 2004 14:08:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00u9JHzv; Tue, 10 Aug 2004 14:08:05 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AB83n12445; Tue, 10 Aug 2004 14:08:03 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 14:08:02 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Tue, 10 Aug 2004 14:08:01 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEBD8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcR+VeTZy1cmxfTTQRu6BHz7E9ObQwAc0ZPw To: , X-OriginalArrivalTime: 10 Aug 2004 11:08:02.0121 (UTC) FILETIME=[4D74CB90:01C47ECA] X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, rohan@cisco.com, oritl@microsoft.com, adam@dynamicsoft.com, rsparks@dynamicsoft.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Does it seem reasonable to require the focus to wrap each chunk with = cpim mime type and then having the end point unwrap it? or it is better = that the focus just inserts a header indicating the sender? To me, it = seems the latter is more straight forward. In either case, we need to state conflict resolution: for the former, it = can be stated that if the sender wrapped the message with cpim itself, = the outer most cpim from-header wins. For the latter, the msrp header = wins over any cpim from-header. This should be normative text for the = receiver. Also, I don't like the name "Contributor-ID". What is he contributing? I = prefer something like "Sender". /Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 10.August.2004 00:14 > To: Ben Campbell > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Orit Levin; Rohan Mahy; > Chris Boulton; Adam Roach; Cullen Jennings; Robert Sparks; Simple WG > Subject: Re: [Simple] MSRP: Contributor ID >=20 >=20 >=20 >=20 > Ben Campbell wrote: > >=20 > >>>> I think the two approaches aren't different enough in the work=20 > >>>> required that they should be judged based on that. > >>>> > >>>> Its probably more important to get the semantics right.=20 > Suppose we=20 > >>>> were to go with this new header. And then suppose we had=20 > conference=20 > >>>> participants sending CPIM wrapped messages that contain a From=20 > >>>> header. What identity should the recipient display? > >>> > >>> It seems to me that this is a matter for the conference policy to=20 > >>> solve, and is not significantly different than if you=20 > have a voice=20 > >>> conference, and a caller has a different identity in the=20 > credentials=20 > >>> for a SIP dialog than in the conference policy. > >> > >> Certainly it *can*. But as long as the endpoint can=20 > receive identity=20 > >> information in two ways there will always be more=20 > confusion that if=20 > >> there is only one way. > >=20 > > It seems like the same problem can exist, regardless of=20 > whether we use=20 > > cpim or a header for this. Even if we just use cpim, you=20 > could still=20 > > have an endpoint use a cpim envelope, just to have the=20 > focus blindly=20 > > stick that inside _another_ cpim envelope. >=20 > Well, maybe that is the case. I wouldn't expect the mixer to=20 > put another=20 > CPIM wrapper around a message that already had one. I would=20 > expect it to=20 > either adjust the existing wrapper, possibly changing the From header; >=20 > OR, (equivalently) remove the incoming CPIM wrapper and=20 > replace it with=20 > a new one constructed by the mixer, possibly using some of the header=20 > values from the incoming one. >=20 > If this new header is added, then either the mixer should remove the=20 > From header from any CPIM wrapper, or else should force the=20 > two to be=20 > the same. >=20 > I think I am still inclined to prefer using CPIM, but I don't=20 > have any=20 > compelling arguments for it. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 10 23:47:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00354; Tue, 10 Aug 2004 23:47:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buk9y-0005am-RV; Tue, 10 Aug 2004 23:52:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buk45-0000so-G7; Tue, 10 Aug 2004 23:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BujwU-0008IN-3U for simple@megatron.ietf.org; Tue, 10 Aug 2004 23:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29892 for ; Tue, 10 Aug 2004 23:38:19 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buk18-0005SO-Qx for simple@ietf.org; Tue, 10 Aug 2004 23:43:12 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 10 Aug 2004 20:37:44 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 20:37:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Tue, 10 Aug 2004 20:37:49 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcR/Mbj8GuWivknCSvCv+Y/lB4Gu6gAH8WiA From: "Orit Levin" To: "Rohan Mahy" , "Paul Kyzivat" X-OriginalArrivalTime: 11 Aug 2004 03:37:40.0294 (UTC) FILETIME=[8D9AF660:01C47F54] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable I obviously think that we should NOT use CPIM for "wrapping" MSRP inside MSRP network. Wasn't the CPIM concept designed for **translation** of a specific protocol address information into a common format in order to bridge **between** different IM systems? Why would any entity (which is not a GW) just wrap an MSRP message into CPIM before sending it to an MSRP focus/MCU? Even if there is a usage case - hopefully it is not the type of scenarios we would like to optimize MSRP for. I would say that the existence of the source address in CPIM just reinforces the point that this is a basic piece of information that every IM protocol needs to have. I would like to raise additional related question. The MSRP "Source ID" itself: does it belong to MSRP (i.e. is it an MSRP URN) or does it belong to "conferencing"/"mixing"/"transcoding" application (in this case we could choose any arbitrary identifier)? What would be your thoughts on this? Orit. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 05:57:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16898; Wed, 11 Aug 2004 05:57:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bupvw-0002ge-Qc; Wed, 11 Aug 2004 06:02:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BupqD-0008RZ-Hu; Wed, 11 Aug 2004 05:56:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bupo9-0007yx-FQ for simple@megatron.ietf.org; Wed, 11 Aug 2004 05:54:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16739 for ; Wed, 11 Aug 2004 05:54:07 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bupsr-0002d0-EE for simple@ietf.org; Wed, 11 Aug 2004 05:59:02 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7B9s4V29842; Wed, 11 Aug 2004 12:54:04 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 12:50:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7B9oQRB018017; Wed, 11 Aug 2004 12:50:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00CsnRkb; Wed, 11 Aug 2004 12:50:16 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7B9oEn29969; Wed, 11 Aug 2004 12:50:15 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 12:49:51 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id 4F2F493B77; Wed, 11 Aug 2004 12:49:50 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7B9noU5006035; Wed, 11 Aug 2004 12:49:50 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7B9nmtP006034; Wed, 11 Aug 2004 12:49:48 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Simple WG Subject: Re: [Simple] MSRP: Contributor ID X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Orit Levin's message of "Tue, 10 Aug 2004 20:37:49 -0700") References: Date: Wed, 11 Aug 2004 12:49:48 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 11 Aug 2004 09:49:51.0321 (UTC) FILETIME=[8BEF4490:01C47F88] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Orit Levin X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Orit Levin writes: >I obviously think that we should NOT use CPIM for "wrapping" MSRP inside >MSRP network. >Wasn't the CPIM concept designed for **translation** of a specific >protocol address information into a common format in order to bridge >**between** different IM systems? With CPIM, all the IM systems have a common format so that, for instance, sender's and recipient's addresses could be included with the IM in a way that is understood by all. The main purpose of CPIM is that a IM could be delivered *without* any translations end-to-end, because translations make end-to-end security impossible. >Why would any entity (which is not a GW) just wrap an MSRP >message into CPIM before sending it to an MSRP focus/MCU? They would like to include their and destination's im: URI in the message and sign it? Even if they do not sign it, it would be more convenient for them to do one thing always (use CPIM wrapper) instead of sometimes wrapping (when signing) and sometimes not. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 07:35:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22167; Wed, 11 Aug 2004 07:35:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BurTD-00046I-Uk; Wed, 11 Aug 2004 07:40:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurLH-0006f9-N5; Wed, 11 Aug 2004 07:32:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurKY-0006Xu-6M for simple@megatron.ietf.org; Wed, 11 Aug 2004 07:31:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22012 for ; Wed, 11 Aug 2004 07:31:41 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BurPH-00042m-S0 for simple@ietf.org; Wed, 11 Aug 2004 07:36:36 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBVd321554 for ; Wed, 11 Aug 2004 14:31:39 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 14:30:59 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7BBUxUa007362 for ; Wed, 11 Aug 2004 14:30:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00f3DrKc; Wed, 11 Aug 2004 14:30:59 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBUln09693 for ; Wed, 11 Aug 2004 14:30:47 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 14:30:48 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 14:30:47 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Aug 2004 14:30:46 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEBEC@esebe019.ntc.nokia.com> Thread-Topic: WGLC Summary for Event Filtering drafts Thread-Index: AcR/lqTSpcbrB9f7S2WSzEx15K6IBg== To: X-OriginalArrivalTime: 11 Aug 2004 11:30:47.0426 (UTC) FILETIME=[A5A78E20:01C47F96] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: [Simple] WGLC Summary for Event Filtering drafts X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable I just submitted an updated version of the 2 event filtering drafts. = Until they appear on the archive, you can fetch a copy from: http://www.imsbook.com/hisham/draft-ietf-simple-filter-format-02.txt http://www.imsbook.com/hisham/draft-ietf-simple-event-filter-funct-02.txt= - Added a element so the server can learn the namespace = qualifications used within the XPATH expression - Corrected examples where incorrect use of XPATH was made - Removed all the normative text describing the XML schema. The text is = now descriptive. - Added clarifying text here and there. - miscellaneous Typos corrected. I believe these drafts are now ready to be sent to IESG. Thanks to everyone who sent comments in. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 07:46:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22970; Wed, 11 Aug 2004 07:46:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Burdu-0004Je-Kw; Wed, 11 Aug 2004 07:51:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurX9-0000Kt-Ka; Wed, 11 Aug 2004 07:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurUo-00088x-Jo for simple@megatron.ietf.org; Wed, 11 Aug 2004 07:42:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22604 for ; Wed, 11 Aug 2004 07:42:17 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BurZV-0004Cn-GZ for simple@ietf.org; Wed, 11 Aug 2004 07:47:12 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBgCB02058 for ; Wed, 11 Aug 2004 14:42:13 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 14:41:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7BBfnaD018706 for ; Wed, 11 Aug 2004 14:41:49 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MmRQbT; Wed, 11 Aug 2004 14:41:48 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBfmu20268 for ; Wed, 11 Aug 2004 14:41:48 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 14:41:33 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: XCAP Usage for Manipulating Presence DocumentContents Date: Wed, 11 Aug 2004 14:41:32 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEBF2@esebe019.ntc.nokia.com> Thread-Topic: WGLC: XCAP Usage for Manipulating Presence Document Contents Thread-Index: AcRy9mnVYL8o8t/mTcySzuHzSzCl3wMobL3Q To: X-OriginalArrivalTime: 11 Aug 2004 11:41:33.0545 (UTC) FILETIME=[26C57D90:01C47F98] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable The WGLC is now finished. The authors will send a summary email = detailing WGLC comments and fixes. Thanks to everyone who participated. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 26.July.2004 12:54 > To: simple@ietf.org > Subject: [Simple] WGLC: XCAP Usage for Manipulating Presence > DocumentContents >=20 >=20 > The WG chairs would like to start a Working Group Last Call=20 > on the following internet draft as part of the SIMPLE Data=20 > Manipulation work to be submitted to IESG: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pid > f-manipulation-usage-01.txt >=20 > This WGLC is 2 weeks long and will end on August 8th. >=20 > Please send your comments to this mailing list and to the authors.=20 >=20 > If you reviewed the draft and found no issues, please=20 > indicate so on the mailing list. This will help us evaluate=20 > the level of review and group consensus. >=20 > Thanks, > Hisham >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 07:47:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23072; Wed, 11 Aug 2004 07:47:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Burex-0004LT-I1; Wed, 11 Aug 2004 07:52:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurXC-0000Ly-Gl; Wed, 11 Aug 2004 07:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurVw-00005L-0n for simple@megatron.ietf.org; Wed, 11 Aug 2004 07:43:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22687 for ; Wed, 11 Aug 2004 07:43:27 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Burae-0004EJ-Sb for simple@ietf.org; Wed, 11 Aug 2004 07:48:22 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBhOV09130 for ; Wed, 11 Aug 2004 14:43:24 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 14:43:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7BBhBYZ007951 for ; Wed, 11 Aug 2004 14:43:11 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00bMRhKM; Wed, 11 Aug 2004 14:41:19 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBfIn19675 for ; Wed, 11 Aug 2004 14:41:18 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 14:41:10 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: XCAP List Usage Date: Wed, 11 Aug 2004 14:41:09 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEBF1@esebe019.ntc.nokia.com> Thread-Topic: WGLC: XCAP List Usage Thread-Index: AcRtceJtYGGB4eV5SNuCFnjCsoByqwSJi+Ig To: X-OriginalArrivalTime: 11 Aug 2004 11:41:10.0978 (UTC) FILETIME=[19520A20:01C47F98] X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable The WGLC is now finished. The author will send a summary email detailing = WGLC comments and fixes. Thanks to everyone who participated. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 19.July.2004 12:22 > To: simple@ietf.org > Subject: [Simple] WGLC: XCAP List Usage >=20 >=20 > The WG chairs would like to start a Working Group Last Call=20 > on the following internet draft as part of the SIMPLE Data=20 > Manipulation work to be submitted to IESG: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-lis > t-usage-03.txt >=20 > (The draft may not be available on the above link for another=20 > couple of days or so. Until it does, please fetch it from=20 > http://www.softarmor.com/wgdb/docs/draft-ietf-simple-xcap-list > -usage-03.txt) >=20 > This WGLC is 3 weeks long and will end on August 8th. >=20 > Please send your comments to this mailing list and to the authors.=20 >=20 > If you reviewed the draft and found no issues, please=20 > indicate so on the mailing list. This will help us evaluate=20 > the level of review and group consensus. >=20 > Thanks, > Hisham >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 07:51:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23319; Wed, 11 Aug 2004 07:51:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuriI-0004PL-0O; Wed, 11 Aug 2004 07:56:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurXD-0000M3-2H; Wed, 11 Aug 2004 07:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurVy-00005N-CF for simple@megatron.ietf.org; Wed, 11 Aug 2004 07:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22691 for ; Wed, 11 Aug 2004 07:43:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buraf-0004EK-Bu for simple@ietf.org; Wed, 11 Aug 2004 07:48:24 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBhOB03555 for ; Wed, 11 Aug 2004 14:43:24 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 14:43:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7BBh2aI007092 for ; Wed, 11 Aug 2004 14:43:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00nbUjQb; Wed, 11 Aug 2004 14:41:01 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBexn19377 for ; Wed, 11 Aug 2004 14:40:59 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 14:40:53 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: XCAP Base Date: Wed, 11 Aug 2004 14:40:52 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEBF0@esebe019.ntc.nokia.com> Thread-Topic: WGLC: XCAP Base Thread-Index: AcRtcZVAzp0/SdI1T9SesxqVZ4UV4gSJj89g To: X-OriginalArrivalTime: 11 Aug 2004 11:40:53.0358 (UTC) FILETIME=[0ED170E0:01C47F98] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable The WGLC is now finished. The author will send a summary email detailing = WGLC comments and fixes. Thanks to everyone who participated. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 19.July.2004 12:20 > To: simple@ietf.org > Subject: [Simple] WGLC: XCAP Base >=20 >=20 > The WG chairs would like to start a Working Group Last Call=20 > on the following internet draft as part of the SIMPLE Data=20 > Manipulation work to be submitted to IESG: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-03.txt >=20 > (The draft may not be available on the above link for another=20 > couple of days or so. Until it does, please fetch it from=20 > http://www.softarmor.com/wgdb/docs/draft-ietf-simple-xcap-03.txt) >=20 > This WGLC is 3 weeks long and will end on August 8th. >=20 > Please send your comments to this mailing list and to the authors.=20 >=20 > If you reviewed the draft and found no issues, please=20 > indicate so on the mailing list. This will help us evaluate=20 > the level of review and group consensus. >=20 > Thanks, > Hisham >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 09:07:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01840; Wed, 11 Aug 2004 09:07:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bustk-00076e-Ez; Wed, 11 Aug 2004 09:12:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BushZ-0003Bn-RC; Wed, 11 Aug 2004 08:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buscg-0002HR-Ak for simple@megatron.ietf.org; Wed, 11 Aug 2004 08:54:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01044 for ; Wed, 11 Aug 2004 08:54:28 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BushP-0006rB-OS for simple@ietf.org; Wed, 11 Aug 2004 08:59:25 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BCsOj12161; Wed, 11 Aug 2004 15:54:24 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 15:54:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7BCsDmC025227; Wed, 11 Aug 2004 15:54:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00lZC7CM; Wed, 11 Aug 2004 15:54:12 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BCs9n02280; Wed, 11 Aug 2004 15:54:09 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 15:53:43 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 11 Aug 2004 15:53:42 +0300 From: Aki Niemi To: Jonathan Rosenberg Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1092228822.7335.39.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 15:53:42 +0300 X-OriginalArrivalTime: 11 Aug 2004 12:53:43.0413 (UTC) FILETIME=[3B92EA50:01C47FA2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: SIMPLE WG Subject: [Simple] Nits on XCAP -03 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Squeezing these in at the last moment, These are nits that I found with the XCAP base spec. The bigger issues I suspect have been resolved on the list already. There is one controversial idea I'm going to put on the list, but outside of that, XCAP is good to go IMO. Cheers, Aki --- 1) Ch 1., 2nd para., 3rd sentence: "...for the list of is to..." is unclear. 2) Next sentence, add space after [15]. 3) Ch 2., 1st para, "...the HTTP URIs used by XCAP point a document..." ^to 4) Ch 3., s/RFC 2119/RFC 2119, BCP 14, 5) Ch 4., should add line feeds between definitions to improve readability. 6) Ch 5.1, half way through 1st paragraph: "...reverse domain name name of the..." extra "name" 7) Ch 6.1, 1st para., 4th s.: s/doesnt/doesn't 8) Don't understand last sentence of Ch 6.1: if there are two root URIs "http://192.168.0.1:80/blah/blah/blah" and "http://my.example.com/blah/blah/blah", then there is clearly interaction between the resources, no? 9) slash is represented as ("/") in the text. Recommend representing double tilde the same way, i.e., ("~~"), instead of (~~) 10) Last sentence of Ch 6.2 is hard to parse. 11) Ch 6.3, BNF definition flows over I-D's 72 or so char line 12) After BNF, "...is defined the XML..." ^ in 13) Page 19, 2nd para, 3rd sentence, s/an examples/of examples 13b) same sentence, starting after comma is hard to understand 14) Inconsistent usage of HTTP URL/URI throughout. Recommend choosing one, and doing a replace all with it. 15) Page 19, last para.: "An elements name is a match..." ^' 16) Page 20, 1st para., 4th sentence: "If the content of the content..." "s/content/predicate" for the second appearance of it 17) Page 20, 2nd para.: it would probably be wise to give a reason why selection based on xmlns attribute is not possible (that is, because XML says so...) 18) In Fig 3., text above caption should be in caption (in title="" attribute" 19) Perhaps should stick a comment inside the element in the example, since the text above the figure sort of suggests it 20) Ch 7. second para., is there a reason why "SHOULD" and not "MUST" in this passage? I'd say MUST is better, or else give a valid reason for not doing it. 21) Same goes for the 4th para of Ch 7. about retransmitting 22) Ch 7., para 5, 1st sentence: "...dictate involve..." which one is it? 23) There are several occurrences of "position-th" in the document. This may not be self-explanatory to folks, so suggest some text explaining what that means after the first occurrence. 24) Example request overflows in Ch 7.4. 25) Ch 7.6, 2nd para.: would return all comments, CDATA segments within those elements as well. Maybe worth noting that. 26) Ch 7.7, 2nd para.: should include a reference for XML 1.0? 27) Example request overflows in Ch 7.7 28) In Ch 8.2.1, 1st para: s/doocuments/documents 29) In ch 8.2.1, 4th para., 1st sentence: s/evaluates in/evaluates it 39) Page 31, 2nd paragrapch: this is specified in detail in the client section - why not with the same detail here? 40) Page 34, 3rd para.: s/interdependcies/interdependencies 40) Same page, and para: elsewhere in the doc status codes are without status phrase, however, here they are included for 200/201. 41) Page 35, 2nd para.: s/interdependcies/interdependencies 42) Ch 9.1, definition of says can contain alternate values. Suggest adding that those would go in the element. That's all! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 09:52:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04932; Wed, 11 Aug 2004 09:52:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Butbs-00081A-3Z; Wed, 11 Aug 2004 09:57:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ButNg-0002oe-Iq; Wed, 11 Aug 2004 09:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ButHe-0001vI-PA for simple@megatron.ietf.org; Wed, 11 Aug 2004 09:36:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04049 for ; Wed, 11 Aug 2004 09:36:48 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ButMO-0007lg-M4 for simple@ietf.org; Wed, 11 Aug 2004 09:41:46 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BDalj11426 for ; Wed, 11 Aug 2004 16:36:47 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 16:36:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7BDaZ7C017143 for ; Wed, 11 Aug 2004 16:36:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00kCYVbM; Wed, 11 Aug 2004 16:36:33 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BDaWn14336 for ; Wed, 11 Aug 2004 16:36:32 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 16:36:32 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 11 Aug 2004 16:36:29 +0300 From: Aki Niemi To: SIMPLE WG Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1092231389.7335.92.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 16:36:29 +0300 X-OriginalArrivalTime: 11 Aug 2004 13:36:32.0409 (UTC) FILETIME=[36D09890:01C47FA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP URI Scheme? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi All, This came up in the past in terms of whether or not XCAP is a new protocol based on HTTP or not. I think we are clearly talking about HTTP, but there is I think another aspect to this. Where a new xcap URI scheme would be very beneficial would be in guiding a non-XCAP application in deciding which application to dispatch for the URI. For example, if included in a web page, or email message, with an xcap URI the client could be configured to dispatch an XCAP client instead of the default for http, which is usually just a web browser. GETs would still (kind of) work without an xcap URI, but in order to do anything more elaborate, the client really needs to understand XCAP. (in fact, there would need to be even a second level of dispatch based on AUID, but that's a separate issue.) The schema really would be just for this purpose of dispatching, and abstract in a sense, since the XCAP client would handle the URI simply by replacing the "xcap:" with "http:". Having said that, I don't know how well such a thing would merit defining a new URI scheme. It also seems that the process for defining new URI schemes is not the most straight forward - even though in this case the actual definition would be a trivial one. Thoughts? Cheers, AKi _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 10:26:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08149; Wed, 11 Aug 2004 10:26:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buu87-00007K-J0; Wed, 11 Aug 2004 10:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ButyS-00073r-4I; Wed, 11 Aug 2004 10:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Butt1-00056j-Lh for simple@megatron.ietf.org; Wed, 11 Aug 2004 10:15:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07262 for ; Wed, 11 Aug 2004 10:15:25 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Butxj-0008P8-HD for simple@ietf.org; Wed, 11 Aug 2004 10:20:23 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7BECYNs045342 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 11 Aug 2004 09:12:35 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <381D0596-EB25-11D8-A01A-0003938AF740@cisco.com> References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> <381D0596-EB25-11D8-A01A-0003938AF740@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7DBA6AF0-EBA0-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 09:12:34 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , Adam Roach , Robert Sparks , Paul Kyzivat , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Content-Transfer-Encoding: 7bit So, since the crypto usage does not seem to break anything, it looks like cpim can work. In fact, since we had a prior consensus to use cpim for this, anything but clear consensus to change things should mean we leave things as they are. But, Rohan said he things cpim is kind of ugly for this purpose, and I tend to agree now that we have chunking in the core protocol. If we use cpim, it seems like the focus has to do the following: Check if this is the first chunk. If so, change the content-type to message/cpim, add the cpim headers to the head of the body. Adjust the byte-range header to match the new range. Optionally re-chunk if this pushes the chunk above 2k (actually, this part is probably not worth doing, as we are increasing the size by only a little.) If this is any chunk other than the first, just change the content-type and the byte-range headers. (Note that fixing up the byte-range header will require keeping a small amount of state until all chunks of the message have been processed.) If we use Contributor-ID (or whatever we choose to call it, the focus does the following: Add the header, if it is not already there. But, I have a concern that Contributor-ID may not be robust enough. What happens if my message crosses _two_ focuses? Do I need a way to put in multiple identities, one from the perspective of each focus? Do I need a way for each focus to sign the identity it put in? If these are needed, then we need something more complex than contributor-ID. Something more like the SIP identity draft would be in order. f this is the case, then I really think that the problem solution is out of scope for the core protocol. On Aug 10, 2004, at 6:30 PM, Rohan Mahy wrote: > Paul, > > I am not arguing for using CPIM. I actually feel its kind of ugly, > but in the interest of describing what you need to do to use CPIM, I > think you missed a few cases. I believe there are 2 axes here > (signature, and crypto) > > 1. Unsigned > 2. Signed by the participant > 3. Signed by the focus > 4. Signed by both the participant and the focus > > A. Unencrypted > B. Encrypted with a group key to whole conference > C. Encrypted to Focus, Re-encrypted to Target Participant > > On the signature axis, the focus just needs to add a new message/cpim > envelope, and can do this in all 4 cases. > > 1. Unsigned > BEFORE > ... > Content-Type: text/plain > > Hi > -------foo$ > > AFTER > ... > Content-Type: message/cpim > > From: > > Content-Type: text/plain > > Hi > -------foo$ > > 2. Signed by Participant > BEFORE > ... > Content-Type: multipart/signed;boudary=bar > > --bar > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > AFTER > ... > Content-Type: message/cpim > > From: Alice > > Content-Type: multipart/signed;boudary=bar > > --bar > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > > 3. Signed by Focus > BEFORE > ... > Content-Type: text/plain > > Hi > -------foo$ > > AFTER > ... > Content-Type: multipart/signed;boundary=bar > > --bar > Content-Type: message/cpim > > From: Alice > > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > 4. Signed by Both > BEFORE > ... > Content-Type: multipart/signed;boudary=bar > > --bar > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > > AFTER > ... > Content-Type: multipart/signed;boundary=focus-bound > > --focus-bound > Content-Type: message/cpim > > From: Alice > > Content-Type: multipart/signed;boundary=godzilla > > --godzilla > Content-Type: text/plain > > Hi > --godzilla > Content-Type: application/pkcs7-mime > > > --godzilla > --focus-bound > Content-Type: application/pkcs7-mime > > > --focus-bound > -------foo$ > > None of the signature combos requires the whole message. You insert > some stuff at the top, and and the end. you need to keep a running > hash going in the middle to generate or verify the signature at the > end, but you don't need the whole message to start writing. > > For the encryption axis, obviously all the signature examples were > unencrypted and work fine. If a message is encrypted for a group, the > focus just treats this like any other type of body and slaps a > message/cpim envelope around it to assert who it thinks the From is > (**). The only time the focus needs to grab the whole message, is > when it is encrypted for the focus and nobody else has the key. > Obviously here, you need the whole message anyway, so CPIM is hardly > the limiting factor. > > (**) example: > > B. Encrypted with group key > BEFORE > ... > Content-Type: application/pkcs7mime > > ***********ciphertext********* > -------foo$ > > AFTER > ... > Content-Type: message/cpim > > From: Alice > > Content-Type: application/pkcs7mime > > ***********ciphertext********* > -------foo$ > > thanks. > -rohan > > > > > > On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote: > >> >> >> Ben Campbell wrote: >>> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: >>>> comments inline. >>>> >>>> Paul >>>> >>>> Ben Campbell wrote: >>>> >>>>> Hi, >>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>> we planned to identify contributors when MSRP is used with a >>>>> conference focus. Previously, we had discussed using message/cpim >>>>> wrappers for this purpose. >>>>> After thinking through the use case, I think Orit may be correct >>>>> that cpim is unwieldy for this purpose. >>>>> The use case I think we have in mind is, you have a text >>>>> conference where each participant has an independent MSRP session >>>>> with the conference focus. The focus acts as a reflector, >>>>> forwarding messages that come in on one participant session to >>>>> each of the other participants. It needs a way to tell the >>>>> receiving parties which participant sent the message. _How_ it >>>>> determines what contributor ID to attach to a given message is out >>>>> of scope for MSRP--that problem belongs to XCON. >>>>> We had previously assumed the focus would simply wrap the inbound >>>>> message in a message/cpim document, and use the CPIM "from" field >>>>> for this purpose. This, however, is problematic for chunked >>>>> messages, as the focus would need to buffer the message until it >>>>> had received all the chunks, wrap the completed message in the >>>>> cpim document, and then send that message out to the other >>>>> participants, possibly re-chunking in the process. This does seem >>>>> to me to be burdensome on the focus; it would be nicer if the >>>>> focus could simply forward the individual chunks, and let the >>>>> endpoints deal with re-assembling them. >>>> >>>> >>>> I haven't thought this thru carefully, but I think it should be >>>> possible to wrap the message in a CPIM wrapper without reassembling >>>> it first. It is just a matter of inserting some bytes for the >>>> wrapper in the first chunk. If that pushes the first chunk over 2k >>>> then it might have to be sent as two chunks, then so be it. If the >>>> actual length of the message was provided, then it would need to be >>>> changed. And then each other chunk of the message would need to >>>> have its byte range adjusted. Then, when the last chunk is found, >>>> it needs to have a suffix appended to it to wrap out the CPIM >>>> wrapper. (Actually I don't recall the details of CPIM to know if >>>> that is needed.) >>>> >>>> So, it takes a bit of work, but not a huge amount. >>>> >>> I agree this is true, assuming the use of cpim is always that >>> simple. Do we run into any problem if the chunk contained signed or >>> encrypted data? Will the focus ever need to sign or encrypt the data >>> itself? >> >> Well, what are the cases? >> - the message arriving at the mixer could be signed, encrypted, both, >> neither - by the sender. >> - the outgoing message from the mixer could any signing/encryping of >> the incoming message alone, or could remove one or the other. >> - the outgoing message from the mixer could be signed, encrypted, both >> or neither - by the mixer. >> >> I'm not sure how many of those combinations are meaningful - not very >> many I think. >> >> If the message is encrypted, and the mixer needs to remove that >> encryption, then it cannot escape buffering the whole message. >> >> If the message is not encrypted, but it is signed with >> multipart/signed, then it should be possible to remove the signature >> on the fly. >> >> If the message is to be signed and/or encrypted by the mixer, then >> given a suitable algorith, I think it is possible to do it on the >> fly, with the restriction that any out-of-order chunks will need to >> be buffered until their turn arrives. All the stuff that wraps the >> actual encrypted text can still be inserted at the beginning or end. >> >> I'm not sure of this - would need to study the encoding more >> carefully to be sure, but I think this should work. >> >> Note that all of this is independent of whether a CPIM wrapper is >> being added or not. >> >>>> I think the two approaches aren't different enough in the work >>>> required that they should be judged based on that. >>>> >>>> Its probably more important to get the semantics right. Suppose we >>>> were to go with this new header. And then suppose we had conference >>>> participants sending CPIM wrapped messages that contain a From >>>> header. What identity should the recipient display? >>> It seems to me that this is a matter for the conference policy to >>> solve, and is not significantly different than if you have a voice >>> conference, and a caller has a different identity in the credentials >>> for a SIP dialog than in the conference policy. >> >> Certainly it *can*. But as long as the endpoint can receive identity >> information in two ways there will always be more confusion that if >> there is only one way. >> >> Paul >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 10:26:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08187; Wed, 11 Aug 2004 10:26:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buu8j-00007r-L5; Wed, 11 Aug 2004 10:31:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ButyS-00073w-MG; Wed, 11 Aug 2004 10:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ButtE-00059X-63 for simple@megatron.ietf.org; Wed, 11 Aug 2004 10:15:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07286 for ; Wed, 11 Aug 2004 10:15:38 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Butxw-0008PI-2D for simple@ietf.org; Wed, 11 Aug 2004 10:20:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2004 07:18:00 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7BEExVF006594; Wed, 11 Aug 2004 07:15:01 -0700 (PDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT59363; Wed, 11 Aug 2004 10:14:57 -0400 (EDT) Message-ID: <411A29E1.1060404@cisco.com> Date: Wed, 11 Aug 2004 10:14:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] MSRP: Contributor ID References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> <381D0596-EB25-11D8-A01A-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Content-Transfer-Encoding: 7bit Rohan, Thanks for filling in details. You do help make the fundamental point that CPIM is not substantially more complex than an new header for this purpose. Most of the issues that Ben brought up are the same for both. So I continue to think the decision on which way to go should be based on other criteria. The numerous extra cases you bring up are interesting. An important question is how the mixer in fact determines what strategy to take with a given message? If a message is signed and not encrypted then I guess there is never any reason for the focus to remove that signature - it can just add another one if it wishes. But if a message is encrypted, and the mixer knows how to decrypt it, it needs to decide if it should do so (because some or all the the participants may not be able to decrypt it), or leave it alone. And then it needs to decide if it should re-encrypt it. Some of this is simply policy, but there probably need to be some standards for how this should be done if there is to be any prayer of interoperability. Paul Rohan Mahy wrote: > Paul, > > I am not arguing for using CPIM. I actually feel its kind of ugly, but > in the interest of describing what you need to do to use CPIM, I think > you missed a few cases. I believe there are 2 axes here (signature, and > crypto) > > 1. Unsigned > 2. Signed by the participant > 3. Signed by the focus > 4. Signed by both the participant and the focus > > A. Unencrypted > B. Encrypted with a group key to whole conference > C. Encrypted to Focus, Re-encrypted to Target Participant > > On the signature axis, the focus just needs to add a new message/cpim > envelope, and can do this in all 4 cases. > > 1. Unsigned > BEFORE > ... > Content-Type: text/plain > > Hi > -------foo$ > > AFTER > ... > Content-Type: message/cpim > > From: > > Content-Type: text/plain > > Hi > -------foo$ > > 2. Signed by Participant > BEFORE > ... > Content-Type: multipart/signed;boudary=bar > > --bar > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > AFTER > ... > Content-Type: message/cpim > > From: Alice > > Content-Type: multipart/signed;boudary=bar > > --bar > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > > 3. Signed by Focus > BEFORE > ... > Content-Type: text/plain > > Hi > -------foo$ > > AFTER > ... > Content-Type: multipart/signed;boundary=bar > > --bar > Content-Type: message/cpim > > From: Alice > > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > 4. Signed by Both > BEFORE > ... > Content-Type: multipart/signed;boudary=bar > > --bar > Content-Type: text/plain > > Hi > --bar > Content-Type: application/pkcs7-mime > > > --bar > -------foo$ > > > AFTER > ... > Content-Type: multipart/signed;boundary=focus-bound > > --focus-bound > Content-Type: message/cpim > > From: Alice > > Content-Type: multipart/signed;boundary=godzilla > > --godzilla > Content-Type: text/plain > > Hi > --godzilla > Content-Type: application/pkcs7-mime > > > --godzilla > --focus-bound > Content-Type: application/pkcs7-mime > > > --focus-bound > -------foo$ > > None of the signature combos requires the whole message. You insert some > stuff at the top, and and the end. you need to keep a running hash > going in the middle to generate or verify the signature at the end, but > you don't need the whole message to start writing. > > For the encryption axis, obviously all the signature examples were > unencrypted and work fine. If a message is encrypted for a group, the > focus just treats this like any other type of body and slaps a > message/cpim envelope around it to assert who it thinks the From is > (**). The only time the focus needs to grab the whole message, is when > it is encrypted for the focus and nobody else has the key. Obviously > here, you need the whole message anyway, so CPIM is hardly the limiting > factor. > > (**) example: > > B. Encrypted with group key > BEFORE > ... > Content-Type: application/pkcs7mime > > ***********ciphertext********* > -------foo$ > > AFTER > ... > Content-Type: message/cpim > > From: Alice > > Content-Type: application/pkcs7mime > > ***********ciphertext********* > -------foo$ > > thanks. > -rohan > > > > > > On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote: > >> >> >> Ben Campbell wrote: >> >>> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: >>> >>>> comments inline. >>>> >>>> Paul >>>> >>>> Ben Campbell wrote: >>>> >>>>> Hi, >>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>> we planned to identify contributors when MSRP is used with a >>>>> conference focus. Previously, we had discussed using message/cpim >>>>> wrappers for this purpose. >>>>> After thinking through the use case, I think Orit may be correct >>>>> that cpim is unwieldy for this purpose. >>>>> The use case I think we have in mind is, you have a text conference >>>>> where each participant has an independent MSRP session with the >>>>> conference focus. The focus acts as a reflector, forwarding >>>>> messages that come in on one participant session to each of the >>>>> other participants. It needs a way to tell the receiving parties >>>>> which participant sent the message. _How_ it determines what >>>>> contributor ID to attach to a given message is out of scope for >>>>> MSRP--that problem belongs to XCON. >>>>> We had previously assumed the focus would simply wrap the inbound >>>>> message in a message/cpim document, and use the CPIM "from" field >>>>> for this purpose. This, however, is problematic for chunked >>>>> messages, as the focus would need to buffer the message until it >>>>> had received all the chunks, wrap the completed message in the cpim >>>>> document, and then send that message out to the other participants, >>>>> possibly re-chunking in the process. This does seem to me to be >>>>> burdensome on the focus; it would be nicer if the focus could >>>>> simply forward the individual chunks, and let the endpoints deal >>>>> with re-assembling them. >>>> >>>> >>>> >>>> I haven't thought this thru carefully, but I think it should be >>>> possible to wrap the message in a CPIM wrapper without reassembling >>>> it first. It is just a matter of inserting some bytes for the >>>> wrapper in the first chunk. If that pushes the first chunk over 2k >>>> then it might have to be sent as two chunks, then so be it. If the >>>> actual length of the message was provided, then it would need to be >>>> changed. And then each other chunk of the message would need to have >>>> its byte range adjusted. Then, when the last chunk is found, it >>>> needs to have a suffix appended to it to wrap out the CPIM wrapper. >>>> (Actually I don't recall the details of CPIM to know if that is >>>> needed.) >>>> >>>> So, it takes a bit of work, but not a huge amount. >>>> >>> I agree this is true, assuming the use of cpim is always that simple. >>> Do we run into any problem if the chunk contained signed or encrypted >>> data? Will the focus ever need to sign or encrypt the data itself? >> >> >> Well, what are the cases? >> - the message arriving at the mixer could be signed, encrypted, both, >> neither - by the sender. >> - the outgoing message from the mixer could any signing/encryping of >> the incoming message alone, or could remove one or the other. >> - the outgoing message from the mixer could be signed, encrypted, both >> or neither - by the mixer. >> >> I'm not sure how many of those combinations are meaningful - not very >> many I think. >> >> If the message is encrypted, and the mixer needs to remove that >> encryption, then it cannot escape buffering the whole message. >> >> If the message is not encrypted, but it is signed with >> multipart/signed, then it should be possible to remove the signature >> on the fly. >> >> If the message is to be signed and/or encrypted by the mixer, then >> given a suitable algorith, I think it is possible to do it on the fly, >> with the restriction that any out-of-order chunks will need to be >> buffered until their turn arrives. All the stuff that wraps the actual >> encrypted text can still be inserted at the beginning or end. >> >> I'm not sure of this - would need to study the encoding more carefully >> to be sure, but I think this should work. >> >> Note that all of this is independent of whether a CPIM wrapper is >> being added or not. >> >>>> I think the two approaches aren't different enough in the work >>>> required that they should be judged based on that. >>>> >>>> Its probably more important to get the semantics right. Suppose we >>>> were to go with this new header. And then suppose we had conference >>>> participants sending CPIM wrapped messages that contain a From >>>> header. What identity should the recipient display? >>> >>> It seems to me that this is a matter for the conference policy to >>> solve, and is not significantly different than if you have a voice >>> conference, and a caller has a different identity in the credentials >>> for a SIP dialog than in the conference policy. >> >> >> Certainly it *can*. But as long as the endpoint can receive identity >> information in two ways there will always be more confusion that if >> there is only one way. >> >> Paul >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 10:44:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09415; Wed, 11 Aug 2004 10:44:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuPg-0000RC-OY; Wed, 11 Aug 2004 10:49:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuCi-00015g-KQ; Wed, 11 Aug 2004 10:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buu0w-0007VO-MD for simple@megatron.ietf.org; Wed, 11 Aug 2004 10:23:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08019 for ; Wed, 11 Aug 2004 10:23:36 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buu5h-00005I-1l for simple@ietf.org; Wed, 11 Aug 2004 10:28:34 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7BELPoX045955 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 11 Aug 2004 09:21:26 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 09:21:25 -0500 To: "Orit Levin" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Adam Roach , Robert Sparks , Paul Kyzivat , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit On Aug 10, 2004, at 10:37 PM, Orit Levin wrote: > I obviously think that we should NOT use CPIM for "wrapping" MSRP > inside > MSRP network. > > Wasn't the CPIM concept designed for **translation** of a specific > protocol address information into a common format in order to bridge > **between** different IM systems? Why would any entity (which is not a > GW) just wrap an MSRP message into CPIM before sending it to an MSRP > focus/MCU? > message/cpim was designed to allow e2e signatures across disparate IM transports. It was really designed as an e2e mechanism, and I agree that having intermediary devices wrap things in cpim can be ugly in the face of chunking (see my other email on the subject.) > Even if there is a usage case - hopefully it is not the type of > scenarios we would like to optimize MSRP for. > > I would say that the existence of the source address in CPIM just > reinforces the point that this is a basic piece of information that > every IM protocol needs to have. > > I would like to raise additional related question. The MSRP "Source ID" > itself: does it belong to MSRP (i.e. is it an MSRP URN) or does it > belong to "conferencing"/"mixing"/"transcoding" application (in this > case we could choose any arbitrary identifier)? > > What would be your thoughts on this? In the main use case for MSRP, the source identification is inferred from the session itself. So, I do not think this is a requirement for the core protocol. It only becomes an issue when a single session can carry messages from more than one contributor. Therefore, I think that _most_ of this problem belongs to XCON or somewhere similar. That being said, we should put in the necessary hooks so that XCON _can_ solve this problem. My concern is, we have not fully explored the conferencing requirements here, so we can only make some guesses as to what hooks are needed. Furthermore, I don't think it is _appropriate_ for us to fully explore those requirements, as they are not in scope for SIMPLE, and could turn into a significant effort. Perhaps the chairs have some comment on this? > > Orit. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 10:45:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09532; Wed, 11 Aug 2004 10:45:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuR2-0000TF-Jd; Wed, 11 Aug 2004 10:50:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuEw-0001RF-NG; Wed, 11 Aug 2004 10:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buu69-0008TY-07 for simple@megatron.ietf.org; Wed, 11 Aug 2004 10:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08365 for ; Wed, 11 Aug 2004 10:28:58 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuAq-0000Aq-VN for simple@ietf.org; Wed, 11 Aug 2004 10:33:56 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7BEQuxR046478 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 11 Aug 2004 09:26:56 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <411A29E1.1060404@cisco.com> References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> <381D0596-EB25-11D8-A01A-0003938AF740@cisco.com> <411A29E1.1060404@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7F3535A8-EBA2-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 09:26:55 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: 7bit On Aug 11, 2004, at 9:14 AM, Paul Kyzivat wrote: > Rohan, > > Thanks for filling in details. You do help make the fundamental point > that CPIM is not substantially more complex than an new header for > this purpose. Most of the issues that Ben brought up are the same for > both. So I continue to think the decision on which way to go should be > based on other criteria. > > The numerous extra cases you bring up are interesting. An important > question is how the mixer in fact determines what strategy to take > with a given message? > > If a message is signed and not encrypted then I guess there is never > any reason for the focus to remove that signature - it can just add > another one if it wishes. > > But if a message is encrypted, and the mixer knows how to decrypt it, > it needs to decide if it should do so (because some or all the the > participants may not be able to decrypt it), or leave it alone. And > then it needs to decide if it should re-encrypt it. > > Some of this is simply policy, but there probably need to be some > standards for how this should be done if there is to be any prayer of > interoperability. > I really think that defining a conferencing application is out of scope. All we are trying to do is build in a hook, so that it is possible to build a conferencing application. > Paul > > Rohan Mahy wrote: >> Paul, >> I am not arguing for using CPIM. I actually feel its kind of ugly, >> but in the interest of describing what you need to do to use CPIM, I >> think you missed a few cases. I believe there are 2 axes here >> (signature, and crypto) >> 1. Unsigned >> 2. Signed by the participant >> 3. Signed by the focus >> 4. Signed by both the participant and the focus >> A. Unencrypted >> B. Encrypted with a group key to whole conference >> C. Encrypted to Focus, Re-encrypted to Target Participant >> On the signature axis, the focus just needs to add a new message/cpim >> envelope, and can do this in all 4 cases. >> 1. Unsigned >> BEFORE >> ... >> Content-Type: text/plain >> Hi >> -------foo$ >> AFTER >> ... >> Content-Type: message/cpim >> From: >> Content-Type: text/plain >> Hi >> -------foo$ >> 2. Signed by Participant >> BEFORE >> ... >> Content-Type: multipart/signed;boudary=bar >> --bar >> Content-Type: text/plain >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> --bar >> -------foo$ >> AFTER >> ... >> Content-Type: message/cpim >> From: Alice >> Content-Type: multipart/signed;boudary=bar >> --bar >> Content-Type: text/plain >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> --bar >> -------foo$ >> 3. Signed by Focus >> BEFORE >> ... >> Content-Type: text/plain >> Hi >> -------foo$ >> AFTER >> ... >> Content-Type: multipart/signed;boundary=bar >> --bar >> Content-Type: message/cpim >> From: Alice >> Content-Type: text/plain >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> --bar >> -------foo$ >> 4. Signed by Both >> BEFORE >> ... >> Content-Type: multipart/signed;boudary=bar >> --bar >> Content-Type: text/plain >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> --bar >> -------foo$ >> AFTER >> ... >> Content-Type: multipart/signed;boundary=focus-bound >> --focus-bound >> Content-Type: message/cpim >> From: Alice >> Content-Type: multipart/signed;boundary=godzilla >> --godzilla >> Content-Type: text/plain >> Hi >> --godzilla >> Content-Type: application/pkcs7-mime >> >> --godzilla >> --focus-bound >> Content-Type: application/pkcs7-mime >> >> --focus-bound >> -------foo$ >> None of the signature combos requires the whole message. You insert >> some stuff at the top, and and the end. you need to keep a running >> hash going in the middle to generate or verify the signature at the >> end, but you don't need the whole message to start writing. >> For the encryption axis, obviously all the signature examples were >> unencrypted and work fine. If a message is encrypted for a group, >> the focus just treats this like any other type of body and slaps a >> message/cpim envelope around it to assert who it thinks the From is >> (**). The only time the focus needs to grab the whole message, is >> when it is encrypted for the focus and nobody else has the key. >> Obviously here, you need the whole message anyway, so CPIM is hardly >> the limiting factor. >> (**) example: >> B. Encrypted with group key >> BEFORE >> ... >> Content-Type: application/pkcs7mime >> ***********ciphertext********* >> -------foo$ >> AFTER >> ... >> Content-Type: message/cpim >> From: Alice >> Content-Type: application/pkcs7mime >> ***********ciphertext********* >> -------foo$ >> thanks. >> -rohan >> On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote: >>> >>> >>> Ben Campbell wrote: >>> >>>> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: >>>> >>>>> comments inline. >>>>> >>>>> Paul >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> Hi, >>>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>>> we planned to identify contributors when MSRP is used with a >>>>>> conference focus. Previously, we had discussed using message/cpim >>>>>> wrappers for this purpose. >>>>>> After thinking through the use case, I think Orit may be correct >>>>>> that cpim is unwieldy for this purpose. >>>>>> The use case I think we have in mind is, you have a text >>>>>> conference where each participant has an independent MSRP session >>>>>> with the conference focus. The focus acts as a reflector, >>>>>> forwarding messages that come in on one participant session to >>>>>> each of the other participants. It needs a way to tell the >>>>>> receiving parties which participant sent the message. _How_ it >>>>>> determines what contributor ID to attach to a given message is >>>>>> out of scope for MSRP--that problem belongs to XCON. >>>>>> We had previously assumed the focus would simply wrap the inbound >>>>>> message in a message/cpim document, and use the CPIM "from" field >>>>>> for this purpose. This, however, is problematic for chunked >>>>>> messages, as the focus would need to buffer the message until it >>>>>> had received all the chunks, wrap the completed message in the >>>>>> cpim document, and then send that message out to the other >>>>>> participants, possibly re-chunking in the process. This does seem >>>>>> to me to be burdensome on the focus; it would be nicer if the >>>>>> focus could simply forward the individual chunks, and let the >>>>>> endpoints deal with re-assembling them. >>>>> >>>>> >>>>> >>>>> I haven't thought this thru carefully, but I think it should be >>>>> possible to wrap the message in a CPIM wrapper without >>>>> reassembling it first. It is just a matter of inserting some bytes >>>>> for the wrapper in the first chunk. If that pushes the first chunk >>>>> over 2k then it might have to be sent as two chunks, then so be >>>>> it. If the actual length of the message was provided, then it >>>>> would need to be changed. And then each other chunk of the message >>>>> would need to have its byte range adjusted. Then, when the last >>>>> chunk is found, it needs to have a suffix appended to it to wrap >>>>> out the CPIM wrapper. (Actually I don't recall the details of CPIM >>>>> to know if that is needed.) >>>>> >>>>> So, it takes a bit of work, but not a huge amount. >>>>> >>>> I agree this is true, assuming the use of cpim is always that >>>> simple. Do we run into any problem if the chunk contained signed or >>>> encrypted data? Will the focus ever need to sign or encrypt the >>>> data itself? >>> >>> >>> Well, what are the cases? >>> - the message arriving at the mixer could be signed, encrypted, both, >>> neither - by the sender. >>> - the outgoing message from the mixer could any signing/encryping of >>> the incoming message alone, or could remove one or the other. >>> - the outgoing message from the mixer could be signed, encrypted, >>> both >>> or neither - by the mixer. >>> >>> I'm not sure how many of those combinations are meaningful - not >>> very many I think. >>> >>> If the message is encrypted, and the mixer needs to remove that >>> encryption, then it cannot escape buffering the whole message. >>> >>> If the message is not encrypted, but it is signed with >>> multipart/signed, then it should be possible to remove the signature >>> on the fly. >>> >>> If the message is to be signed and/or encrypted by the mixer, then >>> given a suitable algorith, I think it is possible to do it on the >>> fly, with the restriction that any out-of-order chunks will need to >>> be buffered until their turn arrives. All the stuff that wraps the >>> actual encrypted text can still be inserted at the beginning or end. >>> >>> I'm not sure of this - would need to study the encoding more >>> carefully to be sure, but I think this should work. >>> >>> Note that all of this is independent of whether a CPIM wrapper is >>> being added or not. >>> >>>>> I think the two approaches aren't different enough in the work >>>>> required that they should be judged based on that. >>>>> >>>>> Its probably more important to get the semantics right. Suppose we >>>>> were to go with this new header. And then suppose we had >>>>> conference participants sending CPIM wrapped messages that contain >>>>> a From header. What identity should the recipient display? >>>> >>>> It seems to me that this is a matter for the conference policy to >>>> solve, and is not significantly different than if you have a voice >>>> conference, and a caller has a different identity in the >>>> credentials for a SIP dialog than in the conference policy. >>> >>> >>> Certainly it *can*. But as long as the endpoint can receive identity >>> information in two ways there will always be more confusion that if >>> there is only one way. >>> >>> Paul >>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 10:52:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10035; Wed, 11 Aug 2004 10:52:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuXq-0000bs-JS; Wed, 11 Aug 2004 10:57:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuFR-0001an-Ef; Wed, 11 Aug 2004 10:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuBb-0000vZ-Uu for simple@megatron.ietf.org; Wed, 11 Aug 2004 10:34:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08970 for ; Wed, 11 Aug 2004 10:34:37 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuGN-0000JK-3U for simple@ietf.org; Wed, 11 Aug 2004 10:39:35 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BEUPj00693; Wed, 11 Aug 2004 17:30:25 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 17:30:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7BEU0fY025967; Wed, 11 Aug 2004 17:30:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00slP1Mh; Wed, 11 Aug 2004 17:29:59 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BETrn00385; Wed, 11 Aug 2004 17:29:53 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 17:29:51 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 17:29:51 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 17:29:49 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEBFC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcR/rf222RxMAkhDSYKg1gzQ4XlV+AAAMfKQ To: , X-OriginalArrivalTime: 11 Aug 2004 14:29:51.0554 (UTC) FILETIME=[A9A76220:01C47FAF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f Content-Transfer-Encoding: quoted-printable There is a requirement that a chunk should not contain a body greater = than 12000 bytes in size unless it is interruptible. If a mixer is = adding extra CPIM headers to those chunks making them greater than 1200 = bytes, then the mixer needs to re-chunk. Or have I not thought this through? I'm not advocating one over the other yet, I'm just trying to collect = data to base the decision on. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 11.August.2004 17:15 > To: Rohan Mahy > Cc: Cullen Jennings; Robert Sparks; Khartabil Hisham > (Nokia-TP-MSW/Helsinki); Adam Roach; Simple WG; Orit Levin; Ben > Campbell; Chris Boulton > Subject: Re: [Simple] MSRP: Contributor ID >=20 >=20 > Rohan, >=20 > Thanks for filling in details. You do help make the fundamental point=20 > that CPIM is not substantially more complex than an new=20 > header for this=20 > purpose. Most of the issues that Ben brought up are the same=20 > for both.=20 > So I continue to think the decision on which way to go should=20 > be based=20 > on other criteria. >=20 > The numerous extra cases you bring up are interesting. An important=20 > question is how the mixer in fact determines what strategy to=20 > take with=20 > a given message? >=20 > If a message is signed and not encrypted then I guess there=20 > is never any=20 > reason for the focus to remove that signature - it can just=20 > add another=20 > one if it wishes. >=20 > But if a message is encrypted, and the mixer knows how to=20 > decrypt it, it=20 > needs to decide if it should do so (because some or all the the=20 > participants may not be able to decrypt it), or leave it=20 > alone. And then=20 > it needs to decide if it should re-encrypt it. >=20 > Some of this is simply policy, but there probably need to be some=20 > standards for how this should be done if there is to be any prayer of=20 > interoperability. >=20 > Paul >=20 > Rohan Mahy wrote: > > Paul, > >=20 > > I am not arguing for using CPIM. I actually feel its kind=20 > of ugly, but=20 > > in the interest of describing what you need to do to use=20 > CPIM, I think=20 > > you missed a few cases. I believe there are 2 axes here=20 > (signature, and=20 > > crypto) > >=20 > > 1. Unsigned > > 2. Signed by the participant > > 3. Signed by the focus > > 4. Signed by both the participant and the focus > >=20 > > A. Unencrypted > > B. Encrypted with a group key to whole conference > > C. Encrypted to Focus, Re-encrypted to Target Participant > >=20 > > On the signature axis, the focus just needs to add a new=20 > message/cpim=20 > > envelope, and can do this in all 4 cases. > >=20 > > 1. Unsigned > > BEFORE > > ... > > Content-Type: text/plain > >=20 > > Hi > > -------foo$ > >=20 > > AFTER > > ... > > Content-Type: message/cpim > >=20 > > From: > >=20 > > Content-Type: text/plain > >=20 > > Hi > > -------foo$ > >=20 > > 2. Signed by Participant > > BEFORE > > ... > > Content-Type: multipart/signed;boudary=3Dbar > >=20 > > --bar > > Content-Type: text/plain > >=20 > > Hi > > --bar > > Content-Type: application/pkcs7-mime > >=20 > > > > --bar > > -------foo$ > >=20 > > AFTER > > ... > > Content-Type: message/cpim > >=20 > > From: Alice > >=20 > > Content-Type: multipart/signed;boudary=3Dbar > >=20 > > --bar > > Content-Type: text/plain > >=20 > > Hi > > --bar > > Content-Type: application/pkcs7-mime > >=20 > > > > --bar > > -------foo$ > >=20 > >=20 > > 3. Signed by Focus > > BEFORE > > ... > > Content-Type: text/plain > >=20 > > Hi > > -------foo$ > >=20 > > AFTER > > ... > > Content-Type: multipart/signed;boundary=3Dbar > >=20 > > --bar > > Content-Type: message/cpim > >=20 > > From: Alice > >=20 > > Content-Type: text/plain > >=20 > > Hi > > --bar > > Content-Type: application/pkcs7-mime > >=20 > > > > --bar > > -------foo$ > >=20 > > 4. Signed by Both > > BEFORE > > ... > > Content-Type: multipart/signed;boudary=3Dbar > >=20 > > --bar > > Content-Type: text/plain > >=20 > > Hi > > --bar > > Content-Type: application/pkcs7-mime > >=20 > > > > --bar > > -------foo$ > >=20 > >=20 > > AFTER > > ... > > Content-Type: multipart/signed;boundary=3Dfocus-bound > >=20 > > --focus-bound > > Content-Type: message/cpim > >=20 > > From: Alice > >=20 > > Content-Type: multipart/signed;boundary=3Dgodzilla > >=20 > > --godzilla > > Content-Type: text/plain > >=20 > > Hi > > --godzilla > > Content-Type: application/pkcs7-mime > >=20 > > > > --godzilla > > --focus-bound > > Content-Type: application/pkcs7-mime > >=20 > > > > --focus-bound > > -------foo$ > >=20 > > None of the signature combos requires the whole message.=20 > You insert some=20 > > stuff at the top, and and the end. you need to keep a running hash=20 > > going in the middle to generate or verify the signature at=20 > the end, but=20 > > you don't need the whole message to start writing. > >=20 > > For the encryption axis, obviously all the signature examples were=20 > > unencrypted and work fine. If a message is encrypted for a=20 > group, the=20 > > focus just treats this like any other type of body and slaps a=20 > > message/cpim envelope around it to assert who it thinks the From is=20 > > (**). The only time the focus needs to grab the whole=20 > message, is when=20 > > it is encrypted for the focus and nobody else has the key. =20 > Obviously=20 > > here, you need the whole message anyway, so CPIM is hardly=20 > the limiting=20 > > factor. > >=20 > > (**) example: > >=20 > > B. Encrypted with group key > > BEFORE > > ... > > Content-Type: application/pkcs7mime > >=20 > > ***********ciphertext********* > > -------foo$ > >=20 > > AFTER > > ... > > Content-Type: message/cpim > >=20 > > From: Alice > >=20 > > Content-Type: application/pkcs7mime > >=20 > > ***********ciphertext********* > > -------foo$ > >=20 > > thanks. > > -rohan > >=20 > >=20 > >=20 > >=20 > >=20 > > On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote: > >=20 > >> > >> > >> Ben Campbell wrote: > >> > >>> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: > >>> > >>>> comments inline. > >>>> > >>>> Paul > >>>> > >>>> Ben Campbell wrote: > >>>> > >>>>> Hi, > >>>>> In last week's SIMPLE meeting, Orit brought up an issue=20 > about how=20 > >>>>> we planned to identify contributors when MSRP is used with a=20 > >>>>> conference focus. Previously, we had discussed using=20 > message/cpim=20 > >>>>> wrappers for this purpose. > >>>>> After thinking through the use case, I think Orit may=20 > be correct=20 > >>>>> that cpim is unwieldy for this purpose. > >>>>> The use case I think we have in mind is, you have a=20 > text conference=20 > >>>>> where each participant has an independent MSRP session with the=20 > >>>>> conference focus. The focus acts as a reflector, forwarding=20 > >>>>> messages that come in on one participant session to each of the=20 > >>>>> other participants. It needs a way to tell the=20 > receiving parties=20 > >>>>> which participant sent the message. _How_ it determines what=20 > >>>>> contributor ID to attach to a given message is out of scope for=20 > >>>>> MSRP--that problem belongs to XCON. > >>>>> We had previously assumed the focus would simply wrap=20 > the inbound=20 > >>>>> message in a message/cpim document, and use the CPIM=20 > "from" field=20 > >>>>> for this purpose. This, however, is problematic for chunked=20 > >>>>> messages, as the focus would need to buffer the message=20 > until it=20 > >>>>> had received all the chunks, wrap the completed message=20 > in the cpim=20 > >>>>> document, and then send that message out to the other=20 > participants,=20 > >>>>> possibly re-chunking in the process. This does seem to me to be=20 > >>>>> burdensome on the focus; it would be nicer if the focus could=20 > >>>>> simply forward the individual chunks, and let the=20 > endpoints deal=20 > >>>>> with re-assembling them. > >>>> > >>>> > >>>> > >>>> I haven't thought this thru carefully, but I think it should be=20 > >>>> possible to wrap the message in a CPIM wrapper without=20 > reassembling=20 > >>>> it first. It is just a matter of inserting some bytes for the=20 > >>>> wrapper in the first chunk. If that pushes the first=20 > chunk over 2k=20 > >>>> then it might have to be sent as two chunks, then so be=20 > it. If the=20 > >>>> actual length of the message was provided, then it would=20 > need to be=20 > >>>> changed. And then each other chunk of the message would=20 > need to have=20 > >>>> its byte range adjusted. Then, when the last chunk is found, it=20 > >>>> needs to have a suffix appended to it to wrap out the=20 > CPIM wrapper.=20 > >>>> (Actually I don't recall the details of CPIM to know if that is=20 > >>>> needed.) > >>>> > >>>> So, it takes a bit of work, but not a huge amount. > >>>> > >>> I agree this is true, assuming the use of cpim is always=20 > that simple.=20 > >>> Do we run into any problem if the chunk contained signed=20 > or encrypted=20 > >>> data? Will the focus ever need to sign or encrypt the data itself? > >> > >> > >> Well, what are the cases? > >> - the message arriving at the mixer could be signed,=20 > encrypted, both, > >> neither - by the sender. > >> - the outgoing message from the mixer could any=20 > signing/encryping of > >> the incoming message alone, or could remove one or the other. > >> - the outgoing message from the mixer could be signed,=20 > encrypted, both > >> or neither - by the mixer. > >> > >> I'm not sure how many of those combinations are meaningful=20 > - not very=20 > >> many I think. > >> > >> If the message is encrypted, and the mixer needs to remove that=20 > >> encryption, then it cannot escape buffering the whole message. > >> > >> If the message is not encrypted, but it is signed with=20 > >> multipart/signed, then it should be possible to remove the=20 > signature=20 > >> on the fly. > >> > >> If the message is to be signed and/or encrypted by the mixer, then=20 > >> given a suitable algorith, I think it is possible to do it=20 > on the fly,=20 > >> with the restriction that any out-of-order chunks will need to be=20 > >> buffered until their turn arrives. All the stuff that=20 > wraps the actual=20 > >> encrypted text can still be inserted at the beginning or end. > >> > >> I'm not sure of this - would need to study the encoding=20 > more carefully=20 > >> to be sure, but I think this should work. > >> > >> Note that all of this is independent of whether a CPIM wrapper is=20 > >> being added or not. > >> > >>>> I think the two approaches aren't different enough in the work=20 > >>>> required that they should be judged based on that. > >>>> > >>>> Its probably more important to get the semantics right.=20 > Suppose we=20 > >>>> were to go with this new header. And then suppose we had=20 > conference=20 > >>>> participants sending CPIM wrapped messages that contain a From=20 > >>>> header. What identity should the recipient display? > >>> > >>> It seems to me that this is a matter for the conference policy to=20 > >>> solve, and is not significantly different than if you=20 > have a voice=20 > >>> conference, and a caller has a different identity in the=20 > credentials=20 > >>> for a SIP dialog than in the conference policy. > >> > >> > >> Certainly it *can*. But as long as the endpoint can=20 > receive identity=20 > >> information in two ways there will always be more=20 > confusion that if=20 > >> there is only one way. > >> > >> Paul > >> > >=20 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 11:06:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11322; Wed, 11 Aug 2004 11:06:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuulP-0000zr-Q3; Wed, 11 Aug 2004 11:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuXr-0005jN-Av; Wed, 11 Aug 2004 10:57:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuSV-0003tz-DX for simple@megatron.ietf.org; Wed, 11 Aug 2004 10:52:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10008 for ; Wed, 11 Aug 2004 10:52:05 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuX8-0000aG-R5 for simple@ietf.org; Wed, 11 Aug 2004 10:57:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2004 10:51:24 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7BEpIui013514; Wed, 11 Aug 2004 10:51:20 -0400 (EDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT62770; Wed, 11 Aug 2004 10:51:18 -0400 (EDT) Message-ID: <411A3265.2020702@cisco.com> Date: Wed, 11 Aug 2004 10:51:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] MSRP: Contributor ID References: <2038BCC78B1AD641891A0D1AE133DBB7023EEBD8@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, oritl@microsoft.com, adam@dynamicsoft.com, rsparks@dynamicsoft.com, rohan@cisco.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Does it seem reasonable to require the focus to wrap each chunk > with cpim mime type and then having the end point unwrap it? > or it is better that the focus just inserts a header indicating > the sender? To me, it seems the latter is more straight forward. The point of this discussion has been that it isn't necessary to wrap *each chunk*. The wrapping only requires an alteration to the first chunk and the last chunk. > In either case, we need to state conflict resolution: for the former, > it can be stated that if the sender wrapped the message with cpim > itself, the outer most cpim from-header wins. For the latter, > the msrp header wins over any cpim from-header. This should be > normative text for the receiver. How does this apply to messages that pass through one or more CPIM gateways? Consider the following case: - Message comes in through CPIM gateway (say from an XMPP system). CPIM headers specify From and To, and a text/plain message. - It is sent (in CPIM format) via MSRP to a conference mixer. - The mixer stamps the message (using a TBD technique) with the identity of the sender as known to the mixer, and sends it out to the other participants. - It arrives at another CPIM gateway, where it is converted again to XMPP format. What should the XMPP recipient see? I think it should see a message that appears to come from the identity inserted by the mixer. Ideally we would be able to achieve this without changes to the RFCs 2778 and 2779. To achieve this, I think that by the time the message flows thru the outgoing gateway it should have *one* CPIM wrapper that contains the From address provided by the mixer. Perhaps this doesn't change anything - the gateway could take the Sender header from the MSRP message and insert it into the CPIM From header before passing the message on. This is a problem for messages that are to be signed or encrypted e2e (between the xmpp systems), but that is always going to be a problem in this case. It may be that in some of these cases we must live with the fact that messages may have multiple sources of sender identity, and all should be presented to the recipient. > Also, I don't like the name "Contributor-ID". What is he contributing? > I prefer something like "Sender". I agree. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 11:29:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12761; Wed, 11 Aug 2004 11:29:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buv7w-0001NZ-Sh; Wed, 11 Aug 2004 11:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buv1f-0003FE-8F; Wed, 11 Aug 2004 11:28:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buuy9-0002Wf-Oa for simple@megatron.ietf.org; Wed, 11 Aug 2004 11:24:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12342 for ; Wed, 11 Aug 2004 11:24:47 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buv2t-0001GX-Qb for simple@ietf.org; Wed, 11 Aug 2004 11:29:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2004 08:26:35 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7BFOBLg028223; Wed, 11 Aug 2004 08:24:12 -0700 (PDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT65802; Wed, 11 Aug 2004 11:24:10 -0400 (EDT) Message-ID: <411A3A1A.8060203@cisco.com> Date: Wed, 11 Aug 2004 11:24:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> <381D0596-EB25-11D8-A01A-0003938AF740@cisco.com> <7DBA6AF0-EBA0-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > So, since the crypto usage does not seem to break anything, it looks > like cpim can work. In fact, since we had a prior consensus to use cpim > for this, anything but clear consensus to change things should mean we > leave things as they are. > > But, Rohan said he things cpim is kind of ugly for this purpose, and I > tend to agree now that we have chunking in the core protocol. If we use > cpim, it seems like the focus has to do the following: > > Check if this is the first chunk. If so, change the content-type to > message/cpim, add the cpim headers to the head of the body. Adjust the > byte-range header to match the new range. Optionally re-chunk if this > pushes the chunk above 2k (actually, this part is probably not worth > doing, as we are increasing the size by only a little.) If this is any > chunk other than the first, just change the content-type and the > byte-range headers. (Note that fixing up the byte-range header will > require keeping a small amount of state until all chunks of the message > have been processed.) Note that it is possible for the mixer to receive the first chunk of a message *after* receiving one or more other chunks of the message. Unless the change in the byte range is entirely deterministic, the mixer will have to buffer chunks until it receives the first one, so it will know what alterations are required in the others. I have to think about it more to decide if the necessary delta to the byte range can be computed deterministically from any chunk. > If we use Contributor-ID (or whatever we choose to call it, the focus > does the following: > > Add the header, if it is not already there. This does seem simpler, though the computational and memory load of the two are roughly equivalent. > But, I have a concern that Contributor-ID may not be robust enough. What > happens if my message crosses _two_ focuses? Do I need a way to put in > multiple identities, one from the perspective of each focus? Do I need a > way for each focus to sign the identity it put in? Hmm. Interesting questions. I think the simple answer is that e2e identification and encryption don't make much sense in conferences. When a conference is built around a focus, each partipant is in fact communicating with the focus, and must trust that focus. The identities received in messages from the focus are simply assertions by the focus, and can't easily be proven to be correct. When there are multiple foci, then the one nearest to the participant is the only one of direct relevance to it. Information from other foci is via transitive trust. An alternative might be for the focus to simply check messages with CPIM bodies, to ensure that the From address is correct, based on its knowledge of conference participants. If not, it would simply reject the message. If so, it could pass on, possibly signing it again. > If these are needed, then we need something more complex than > contributor-ID. Something more like the SIP identity draft would be in > order. f this is the case, then I really think that the problem solution > is out of scope for the core protocol. Agree. That leaves the question of what to do for now. The simplest thing to do is nothing. That leaves the xcon guys to figure out what to do. They are free to use CPIM, or some other special body type, however they like. Paul > On Aug 10, 2004, at 6:30 PM, Rohan Mahy wrote: > >> Paul, >> >> I am not arguing for using CPIM. I actually feel its kind of ugly, >> but in the interest of describing what you need to do to use CPIM, I >> think you missed a few cases. I believe there are 2 axes here >> (signature, and crypto) >> >> 1. Unsigned >> 2. Signed by the participant >> 3. Signed by the focus >> 4. Signed by both the participant and the focus >> >> A. Unencrypted >> B. Encrypted with a group key to whole conference >> C. Encrypted to Focus, Re-encrypted to Target Participant >> >> On the signature axis, the focus just needs to add a new message/cpim >> envelope, and can do this in all 4 cases. >> >> 1. Unsigned >> BEFORE >> ... >> Content-Type: text/plain >> >> Hi >> -------foo$ >> >> AFTER >> ... >> Content-Type: message/cpim >> >> From: >> >> Content-Type: text/plain >> >> Hi >> -------foo$ >> >> 2. Signed by Participant >> BEFORE >> ... >> Content-Type: multipart/signed;boudary=bar >> >> --bar >> Content-Type: text/plain >> >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> >> --bar >> -------foo$ >> >> AFTER >> ... >> Content-Type: message/cpim >> >> From: Alice >> >> Content-Type: multipart/signed;boudary=bar >> >> --bar >> Content-Type: text/plain >> >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> >> --bar >> -------foo$ >> >> >> 3. Signed by Focus >> BEFORE >> ... >> Content-Type: text/plain >> >> Hi >> -------foo$ >> >> AFTER >> ... >> Content-Type: multipart/signed;boundary=bar >> >> --bar >> Content-Type: message/cpim >> >> From: Alice >> >> Content-Type: text/plain >> >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> >> --bar >> -------foo$ >> >> 4. Signed by Both >> BEFORE >> ... >> Content-Type: multipart/signed;boudary=bar >> >> --bar >> Content-Type: text/plain >> >> Hi >> --bar >> Content-Type: application/pkcs7-mime >> >> >> --bar >> -------foo$ >> >> >> AFTER >> ... >> Content-Type: multipart/signed;boundary=focus-bound >> >> --focus-bound >> Content-Type: message/cpim >> >> From: Alice >> >> Content-Type: multipart/signed;boundary=godzilla >> >> --godzilla >> Content-Type: text/plain >> >> Hi >> --godzilla >> Content-Type: application/pkcs7-mime >> >> >> --godzilla >> --focus-bound >> Content-Type: application/pkcs7-mime >> >> >> --focus-bound >> -------foo$ >> >> None of the signature combos requires the whole message. You insert >> some stuff at the top, and and the end. you need to keep a running >> hash going in the middle to generate or verify the signature at the >> end, but you don't need the whole message to start writing. >> >> For the encryption axis, obviously all the signature examples were >> unencrypted and work fine. If a message is encrypted for a group, the >> focus just treats this like any other type of body and slaps a >> message/cpim envelope around it to assert who it thinks the From is >> (**). The only time the focus needs to grab the whole message, is >> when it is encrypted for the focus and nobody else has the key. >> Obviously here, you need the whole message anyway, so CPIM is hardly >> the limiting factor. >> >> (**) example: >> >> B. Encrypted with group key >> BEFORE >> ... >> Content-Type: application/pkcs7mime >> >> ***********ciphertext********* >> -------foo$ >> >> AFTER >> ... >> Content-Type: message/cpim >> >> From: Alice >> >> Content-Type: application/pkcs7mime >> >> ***********ciphertext********* >> -------foo$ >> >> thanks. >> -rohan >> >> >> >> >> >> On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote: >> >>> >>> >>> Ben Campbell wrote: >>> >>>> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: >>>> >>>>> comments inline. >>>>> >>>>> Paul >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> Hi, >>>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>>> we planned to identify contributors when MSRP is used with a >>>>>> conference focus. Previously, we had discussed using message/cpim >>>>>> wrappers for this purpose. >>>>>> After thinking through the use case, I think Orit may be correct >>>>>> that cpim is unwieldy for this purpose. >>>>>> The use case I think we have in mind is, you have a text >>>>>> conference where each participant has an independent MSRP session >>>>>> with the conference focus. The focus acts as a reflector, >>>>>> forwarding messages that come in on one participant session to >>>>>> each of the other participants. It needs a way to tell the >>>>>> receiving parties which participant sent the message. _How_ it >>>>>> determines what contributor ID to attach to a given message is out >>>>>> of scope for MSRP--that problem belongs to XCON. >>>>>> We had previously assumed the focus would simply wrap the inbound >>>>>> message in a message/cpim document, and use the CPIM "from" field >>>>>> for this purpose. This, however, is problematic for chunked >>>>>> messages, as the focus would need to buffer the message until it >>>>>> had received all the chunks, wrap the completed message in the >>>>>> cpim document, and then send that message out to the other >>>>>> participants, possibly re-chunking in the process. This does seem >>>>>> to me to be burdensome on the focus; it would be nicer if the >>>>>> focus could simply forward the individual chunks, and let the >>>>>> endpoints deal with re-assembling them. >>>>> >>>>> >>>>> >>>>> I haven't thought this thru carefully, but I think it should be >>>>> possible to wrap the message in a CPIM wrapper without reassembling >>>>> it first. It is just a matter of inserting some bytes for the >>>>> wrapper in the first chunk. If that pushes the first chunk over 2k >>>>> then it might have to be sent as two chunks, then so be it. If the >>>>> actual length of the message was provided, then it would need to be >>>>> changed. And then each other chunk of the message would need to >>>>> have its byte range adjusted. Then, when the last chunk is found, >>>>> it needs to have a suffix appended to it to wrap out the CPIM >>>>> wrapper. (Actually I don't recall the details of CPIM to know if >>>>> that is needed.) >>>>> >>>>> So, it takes a bit of work, but not a huge amount. >>>>> >>>> I agree this is true, assuming the use of cpim is always that >>>> simple. Do we run into any problem if the chunk contained signed or >>>> encrypted data? Will the focus ever need to sign or encrypt the data >>>> itself? >>> >>> >>> Well, what are the cases? >>> - the message arriving at the mixer could be signed, encrypted, both, >>> neither - by the sender. >>> - the outgoing message from the mixer could any signing/encryping of >>> the incoming message alone, or could remove one or the other. >>> - the outgoing message from the mixer could be signed, encrypted, both >>> or neither - by the mixer. >>> >>> I'm not sure how many of those combinations are meaningful - not very >>> many I think. >>> >>> If the message is encrypted, and the mixer needs to remove that >>> encryption, then it cannot escape buffering the whole message. >>> >>> If the message is not encrypted, but it is signed with >>> multipart/signed, then it should be possible to remove the signature >>> on the fly. >>> >>> If the message is to be signed and/or encrypted by the mixer, then >>> given a suitable algorith, I think it is possible to do it on the >>> fly, with the restriction that any out-of-order chunks will need to >>> be buffered until their turn arrives. All the stuff that wraps the >>> actual encrypted text can still be inserted at the beginning or end. >>> >>> I'm not sure of this - would need to study the encoding more >>> carefully to be sure, but I think this should work. >>> >>> Note that all of this is independent of whether a CPIM wrapper is >>> being added or not. >>> >>>>> I think the two approaches aren't different enough in the work >>>>> required that they should be judged based on that. >>>>> >>>>> Its probably more important to get the semantics right. Suppose we >>>>> were to go with this new header. And then suppose we had conference >>>>> participants sending CPIM wrapped messages that contain a From >>>>> header. What identity should the recipient display? >>>> >>>> It seems to me that this is a matter for the conference policy to >>>> solve, and is not significantly different than if you have a voice >>>> conference, and a caller has a different identity in the credentials >>>> for a SIP dialog than in the conference policy. >>> >>> >>> Certainly it *can*. But as long as the endpoint can receive identity >>> information in two ways there will always be more confusion that if >>> there is only one way. >>> >>> Paul >>> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 11:41:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13551; Wed, 11 Aug 2004 11:41:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvIq-0001a4-Mw; Wed, 11 Aug 2004 11:46:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvCT-0004rp-WA; Wed, 11 Aug 2004 11:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buv7K-0003xU-Tr for simple@megatron.ietf.org; Wed, 11 Aug 2004 11:34:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12981 for ; Wed, 11 Aug 2004 11:34:16 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvC6-0001Qo-0f for simple@ietf.org; Wed, 11 Aug 2004 11:39:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2004 11:33:46 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7BFXilF019055; Wed, 11 Aug 2004 11:33:44 -0400 (EDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT66701; Wed, 11 Aug 2004 11:33:43 -0400 (EDT) Message-ID: <411A3C56.2000809@cisco.com> Date: Wed, 11 Aug 2004 11:33:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] MSRP: Contributor ID References: <2038BCC78B1AD641891A0D1AE133DBB7023EEBFC@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: rohan@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > There is a requirement that a chunk should not contain a body greater > than 12000 bytes in size unless it is interruptible. If a mixer is > adding extra CPIM headers to those chunks making them greater than > 1200 bytes, then the mixer needs to re-chunk. Yes, I agree. But this is a local phenomenon - it can be applied to each incoming chunk independently. So, the first chunk of the message will be enlarged due to the insertion of a CPIM wrapper. If that pushes it over 2k, then it needs to be split into two chunks. (Or if the mixer's message sending is interuptable it can try to send the enlarged chunk and only split it if forced to.) Any middle chunks are unchanged. The last chunk also has a few bytes added to complete the CPIM wrapper. Again if that pushes it over the 2k limit it may need to be fragmented. For a server that wants to optimize, the resulting chunks could then be placed into an outgoing queue, and potentially merged and refragmented into optimal sized chunks. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 11:45:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13722; Wed, 11 Aug 2004 11:45:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvN0-0001dC-DC; Wed, 11 Aug 2004 11:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvCU-0004s7-E2; Wed, 11 Aug 2004 11:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buv7d-00044x-LP for simple@megatron.ietf.org; Wed, 11 Aug 2004 11:34:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12990 for ; Wed, 11 Aug 2004 11:34:35 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvCO-0001RX-KZ for simple@ietf.org; Wed, 11 Aug 2004 11:39:34 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BFYMj03606; Wed, 11 Aug 2004 18:34:22 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 18:33:57 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7BFXvV9006609; Wed, 11 Aug 2004 18:33:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00xduguw; Wed, 11 Aug 2004 18:33:50 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BFXnn00479; Wed, 11 Aug 2004 18:33:49 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 18:33:48 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 11 Aug 2004 18:33:48 +0300 Subject: Re: [Simple] MSRP: Contributor ID From: Aki Niemi To: ext Ben Campbell In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1092238428.7335.256.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 18:33:48 +0300 X-OriginalArrivalTime: 11 Aug 2004 15:33:48.0930 (UTC) FILETIME=[98E87E20:01C47FB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Hi, IMO, there are two things CPIM is needed for in a conferencing scenario: 1 - In your use case below, for a focus-inserted "asserted" identity identifying the sender of the message 2 - For routing purposes, in order to route messages based on who the messages were addressed to. This is to enable whispering within a conference (i.e., sending a certain message not to the entire conference, but to one or a few of the participants). This has been discussed before at length. Clearly, CPIM (ugly as it may be) can be made to handle both of these needs. Contributor-ID will only cover the first one - unless of course we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted by the client, to cover the second need. Cheers, Aki On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote: > Hi, > > In last week's SIMPLE meeting, Orit brought up an issue about how we > planned to identify contributors when MSRP is used with a conference > focus. Previously, we had discussed using message/cpim wrappers for > this purpose. > > After thinking through the use case, I think Orit may be correct that > cpim is unwieldy for this purpose. > > The use case I think we have in mind is, you have a text conference > where each participant has an independent MSRP session with the > conference focus. The focus acts as a reflector, forwarding messages > that come in on one participant session to each of the other > participants. It needs a way to tell the receiving parties which > participant sent the message. _How_ it determines what contributor ID > to attach to a given message is out of scope for MSRP--that problem > belongs to XCON. > > We had previously assumed the focus would simply wrap the inbound > message in a message/cpim document, and use the CPIM "from" field for > this purpose. This, however, is problematic for chunked messages, as > the focus would need to buffer the message until it had received all > the chunks, wrap the completed message in the cpim document, and then > send that message out to the other participants, possibly re-chunking > in the process. This does seem to me to be burdensome on the focus; it > would be nicer if the focus could simply forward the individual chunks, > and let the endpoints deal with re-assembling them. > > Another approach would be to have the focus force the endpoints to use > a cpim envelope. However, there may be times where the identity that > the focus wants to insert may be different than the identity that the > endpoint inserts. > > Therefore, I propose we add a new optional header called > Contributor-ID, which can carry a name-addr. Normal endpoints would > never insert this, but a conference focus could insert this header on a > per-chunk basis, and avoid the buffering requirement mentioned above. > > What do others think? Am I completely off base? > > Thanks! > > Ben. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 11:55:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14453; Wed, 11 Aug 2004 11:55:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvWK-0001qK-KW; Wed, 11 Aug 2004 12:00:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvQA-0007Fr-F4; Wed, 11 Aug 2004 11:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvH0-0005hN-3S for simple@megatron.ietf.org; Wed, 11 Aug 2004 11:44:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13661 for ; Wed, 11 Aug 2004 11:44:15 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvLl-0001by-JH for simple@ietf.org; Wed, 11 Aug 2004 11:49:14 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7BFgsnp054039 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 11 Aug 2004 10:42:55 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <411A3A1A.8060203@cisco.com> References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> <381D0596-EB25-11D8-A01A-0003938AF740@cisco.com> <7DBA6AF0-EBA0-11D8-BB7E-000D93B0AE1A@nostrum.com> <411A3A1A.8060203@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1C0C64B4-EBAD-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 10:42:53 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Content-Transfer-Encoding: 7bit On Aug 11, 2004, at 10:24 AM, Paul Kyzivat wrote: > > > Ben Campbell wrote: >> So, since the crypto usage does not seem to break anything, it looks >> like cpim can work. In fact, since we had a prior consensus to use >> cpim for this, anything but clear consensus to change things should >> mean we leave things as they are. >> But, Rohan said he things cpim is kind of ugly for this purpose, and >> I tend to agree now that we have chunking in the core protocol. If we >> use cpim, it seems like the focus has to do the following: >> Check if this is the first chunk. If so, change the content-type to >> message/cpim, add the cpim headers to the head of the body. Adjust >> the byte-range header to match the new range. Optionally re-chunk if >> this >> pushes the chunk above 2k (actually, this part is probably not worth >> doing, as we are increasing the size by only a little.) If this is >> any chunk other than the first, just change the content-type and the >> byte-range headers. (Note that fixing up the byte-range header will >> require keeping a small amount of state until all chunks of the >> message have been processed.) > > Note that it is possible for the mixer to receive the first chunk of a > message *after* receiving one or more other chunks of the message. > > Unless the change in the byte range is entirely deterministic, the > mixer will have to buffer chunks until it receives the first one, so > it will know what alterations are required in the others. I have to > think about it more to decide if the necessary delta to the byte range > can be computed deterministically from any chunk. > >> If we use Contributor-ID (or whatever we choose to call it, the focus >> does the following: >> Add the header, if it is not already there. > > This does seem simpler, though the computational and memory load of > the two are roughly equivalent. > >> But, I have a concern that Contributor-ID may not be robust enough. >> What happens if my message crosses _two_ focuses? Do I need a way to >> put in multiple identities, one from the perspective of each focus? >> Do I need a way for each focus to sign the identity it put in? > > Hmm. Interesting questions. > > I think the simple answer is that e2e identification and encryption > don't make much sense in conferences. When a conference is built > around a focus, each partipant is in fact communicating with the > focus, and must trust that focus. The identities received in messages > from the focus are simply assertions by the focus, and can't easily be > proven to be correct. When there are multiple foci, then the one > nearest to the participant is the only one of direct relevance to it. > Information from other foci is via transitive trust. > I can imagine situations where one of the participants at a focus is in fact another focus. I don't know if this is in scope for xcon or not, so I don't know if we need to worry about it. > An alternative might be for the focus to simply check messages with > CPIM bodies, to ensure that the From address is correct, based on its > knowledge of conference participants. If not, it would simply reject > the message. If so, it could pass on, possibly signing it again. > >> If these are needed, then we need something more complex than >> contributor-ID. Something more like the SIP identity draft would be >> in order. f this is the case, then I really think that the problem >> solution is out of scope for the core protocol. > > Agree. That leaves the question of what to do for now. > > The simplest thing to do is nothing. That leaves the xcon guys to > figure out what to do. They are free to use CPIM, or some other > special body type, however they like. I am starting to come back to that opinion myself. It seems like we have two choices. One is to say that MSRP focus behavior is out of scope for the current specs; we think it can be solved with cpim; and cpim is must-implement. That is, do nothing now. If we are proven wrong, then xcon has some work to do. The other is to actually try to specify how we expect MSRP foci to work, based either on cpim or something else such as additional headers. I suspect this is a non-trivial task on which we do not want to block the MSRP work. > > Paul > >> On Aug 10, 2004, at 6:30 PM, Rohan Mahy wrote: >>> Paul, >>> >>> I am not arguing for using CPIM. I actually feel its kind of ugly, >>> but in the interest of describing what you need to do to use CPIM, I >>> think you missed a few cases. I believe there are 2 axes here >>> (signature, and crypto) >>> >>> 1. Unsigned >>> 2. Signed by the participant >>> 3. Signed by the focus >>> 4. Signed by both the participant and the focus >>> >>> A. Unencrypted >>> B. Encrypted with a group key to whole conference >>> C. Encrypted to Focus, Re-encrypted to Target Participant >>> >>> On the signature axis, the focus just needs to add a new >>> message/cpim envelope, and can do this in all 4 cases. >>> >>> 1. Unsigned >>> BEFORE >>> ... >>> Content-Type: text/plain >>> >>> Hi >>> -------foo$ >>> >>> AFTER >>> ... >>> Content-Type: message/cpim >>> >>> From: >>> >>> Content-Type: text/plain >>> >>> Hi >>> -------foo$ >>> >>> 2. Signed by Participant >>> BEFORE >>> ... >>> Content-Type: multipart/signed;boudary=bar >>> >>> --bar >>> Content-Type: text/plain >>> >>> Hi >>> --bar >>> Content-Type: application/pkcs7-mime >>> >>> >>> --bar >>> -------foo$ >>> >>> AFTER >>> ... >>> Content-Type: message/cpim >>> >>> From: Alice >>> >>> Content-Type: multipart/signed;boudary=bar >>> >>> --bar >>> Content-Type: text/plain >>> >>> Hi >>> --bar >>> Content-Type: application/pkcs7-mime >>> >>> >>> --bar >>> -------foo$ >>> >>> >>> 3. Signed by Focus >>> BEFORE >>> ... >>> Content-Type: text/plain >>> >>> Hi >>> -------foo$ >>> >>> AFTER >>> ... >>> Content-Type: multipart/signed;boundary=bar >>> >>> --bar >>> Content-Type: message/cpim >>> >>> From: Alice >>> >>> Content-Type: text/plain >>> >>> Hi >>> --bar >>> Content-Type: application/pkcs7-mime >>> >>> >>> --bar >>> -------foo$ >>> >>> 4. Signed by Both >>> BEFORE >>> ... >>> Content-Type: multipart/signed;boudary=bar >>> >>> --bar >>> Content-Type: text/plain >>> >>> Hi >>> --bar >>> Content-Type: application/pkcs7-mime >>> >>> >>> --bar >>> -------foo$ >>> >>> >>> AFTER >>> ... >>> Content-Type: multipart/signed;boundary=focus-bound >>> >>> --focus-bound >>> Content-Type: message/cpim >>> >>> From: Alice >>> >>> Content-Type: multipart/signed;boundary=godzilla >>> >>> --godzilla >>> Content-Type: text/plain >>> >>> Hi >>> --godzilla >>> Content-Type: application/pkcs7-mime >>> >>> >>> --godzilla >>> --focus-bound >>> Content-Type: application/pkcs7-mime >>> >>> >>> --focus-bound >>> -------foo$ >>> >>> None of the signature combos requires the whole message. You insert >>> some stuff at the top, and and the end. you need to keep a running >>> hash going in the middle to generate or verify the signature at the >>> end, but you don't need the whole message to start writing. >>> >>> For the encryption axis, obviously all the signature examples were >>> unencrypted and work fine. If a message is encrypted for a group, >>> the focus just treats this like any other type of body and slaps a >>> message/cpim envelope around it to assert who it thinks the From is >>> (**). The only time the focus needs to grab the whole message, is >>> when it is encrypted for the focus and nobody else has the key. >>> Obviously here, you need the whole message anyway, so CPIM is hardly >>> the limiting factor. >>> >>> (**) example: >>> >>> B. Encrypted with group key >>> BEFORE >>> ... >>> Content-Type: application/pkcs7mime >>> >>> ***********ciphertext********* >>> -------foo$ >>> >>> AFTER >>> ... >>> Content-Type: message/cpim >>> >>> From: Alice >>> >>> Content-Type: application/pkcs7mime >>> >>> ***********ciphertext********* >>> -------foo$ >>> >>> thanks. >>> -rohan >>> >>> >>> >>> >>> >>> On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote: >>> >>>> >>>> >>>> Ben Campbell wrote: >>>> >>>>> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: >>>>> >>>>>> comments inline. >>>>>> >>>>>> Paul >>>>>> >>>>>> Ben Campbell wrote: >>>>>> >>>>>>> Hi, >>>>>>> In last week's SIMPLE meeting, Orit brought up an issue about >>>>>>> how we planned to identify contributors when MSRP is used with a >>>>>>> conference focus. Previously, we had discussed using >>>>>>> message/cpim wrappers for this purpose. >>>>>>> After thinking through the use case, I think Orit may be correct >>>>>>> that cpim is unwieldy for this purpose. >>>>>>> The use case I think we have in mind is, you have a text >>>>>>> conference where each participant has an independent MSRP >>>>>>> session with the conference focus. The focus acts as a >>>>>>> reflector, forwarding messages that come in on one participant >>>>>>> session to each of the other participants. It needs a way to >>>>>>> tell the receiving parties which participant sent the message. >>>>>>> _How_ it determines what contributor ID to attach to a given >>>>>>> message is out of scope for MSRP--that problem belongs to XCON. >>>>>>> We had previously assumed the focus would simply wrap the >>>>>>> inbound message in a message/cpim document, and use the CPIM >>>>>>> "from" field for this purpose. This, however, is problematic for >>>>>>> chunked messages, as the focus would need to buffer the message >>>>>>> until it had received all the chunks, wrap the completed message >>>>>>> in the cpim document, and then send that message out to the >>>>>>> other participants, possibly re-chunking in the process. This >>>>>>> does seem to me to be burdensome on the focus; it would be nicer >>>>>>> if the focus could simply forward the individual chunks, and let >>>>>>> the endpoints deal with re-assembling them. >>>>>> >>>>>> >>>>>> >>>>>> I haven't thought this thru carefully, but I think it should be >>>>>> possible to wrap the message in a CPIM wrapper without >>>>>> reassembling it first. It is just a matter of inserting some >>>>>> bytes for the wrapper in the first chunk. If that pushes the >>>>>> first chunk over 2k then it might have to be sent as two chunks, >>>>>> then so be it. If the actual length of the message was provided, >>>>>> then it would need to be changed. And then each other chunk of >>>>>> the message would need to have its byte range adjusted. Then, >>>>>> when the last chunk is found, it needs to have a suffix appended >>>>>> to it to wrap out the CPIM wrapper. (Actually I don't recall the >>>>>> details of CPIM to know if that is needed.) >>>>>> >>>>>> So, it takes a bit of work, but not a huge amount. >>>>>> >>>>> I agree this is true, assuming the use of cpim is always that >>>>> simple. Do we run into any problem if the chunk contained signed >>>>> or encrypted data? Will the focus ever need to sign or encrypt the >>>>> data itself? >>>> >>>> >>>> Well, what are the cases? >>>> - the message arriving at the mixer could be signed, encrypted, >>>> both, >>>> neither - by the sender. >>>> - the outgoing message from the mixer could any signing/encryping of >>>> the incoming message alone, or could remove one or the other. >>>> - the outgoing message from the mixer could be signed, encrypted, >>>> both >>>> or neither - by the mixer. >>>> >>>> I'm not sure how many of those combinations are meaningful - not >>>> very many I think. >>>> >>>> If the message is encrypted, and the mixer needs to remove that >>>> encryption, then it cannot escape buffering the whole message. >>>> >>>> If the message is not encrypted, but it is signed with >>>> multipart/signed, then it should be possible to remove the >>>> signature on the fly. >>>> >>>> If the message is to be signed and/or encrypted by the mixer, then >>>> given a suitable algorith, I think it is possible to do it on the >>>> fly, with the restriction that any out-of-order chunks will need to >>>> be buffered until their turn arrives. All the stuff that wraps the >>>> actual encrypted text can still be inserted at the beginning or >>>> end. >>>> >>>> I'm not sure of this - would need to study the encoding more >>>> carefully to be sure, but I think this should work. >>>> >>>> Note that all of this is independent of whether a CPIM wrapper is >>>> being added or not. >>>> >>>>>> I think the two approaches aren't different enough in the work >>>>>> required that they should be judged based on that. >>>>>> >>>>>> Its probably more important to get the semantics right. Suppose >>>>>> we were to go with this new header. And then suppose we had >>>>>> conference participants sending CPIM wrapped messages that >>>>>> contain a From header. What identity should the recipient >>>>>> display? >>>>> >>>>> It seems to me that this is a matter for the conference policy to >>>>> solve, and is not significantly different than if you have a voice >>>>> conference, and a caller has a different identity in the >>>>> credentials for a SIP dialog than in the conference policy. >>>> >>>> >>>> Certainly it *can*. But as long as the endpoint can receive >>>> identity information in two ways there will always be more >>>> confusion that if there is only one way. >>>> >>>> Paul >>>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 13:24:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20632; Wed, 11 Aug 2004 13:24:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buwuq-0003Wc-UC; Wed, 11 Aug 2004 13:29:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buwns-0000uT-GU; Wed, 11 Aug 2004 13:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buwfk-000877-Le for simple@megatron.ietf.org; Wed, 11 Aug 2004 13:13:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19752 for ; Wed, 11 Aug 2004 13:13:53 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuwkW-0003IQ-Gp for simple@ietf.org; Wed, 11 Aug 2004 13:18:53 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 11 Aug 2004 10:10:45 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 10:10:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 10:10:54 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcR/umsSeIS9THujRrea3oozYmySjwABrsbA From: "Orit Levin" To: "Aki Niemi" , "ext Ben Campbell" X-OriginalArrivalTime: 11 Aug 2004 17:10:44.0654 (UTC) FILETIME=[23598CE0:01C47FC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Needlessly to say, I strongly disagree that this is out of scope to MSRP. By assuming this, we are just inviting proprietary implementations and a lot of fun at interop events. Based on the SIPPING Conferencing Requirements and Framework, conference unaware SIP UAs MUST be able to participate and be invited to a conference. What kind of experience will this participant get without having the real source of the message being displayed to him/her? Why do you expect from XCON to address MSRP as a special media type and treat it differently - when other media types (i.e. all the RTP based streams) have this information in place? BTW the "whisper" functionality, according to XCON design, is being achieved very differently from what Aki envisions. The message is supposed to be "routed" based on the media policy kept in the media policy server - not as a result of a participant inserting the "final destination" information in one of the headers of a media/data stream. Cheers, Orit. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Aki Niemi Sent: Wednesday, August 11, 2004 8:34 AM To: ext Ben Campbell Cc: SIMPLE WG Subject: Re: [Simple] MSRP: Contributor ID Hi, IMO, there are two things CPIM is needed for in a conferencing scenario: 1 - In your use case below, for a focus-inserted "asserted" identity identifying the sender of the message 2 - For routing purposes, in order to route messages based on who the messages were addressed to. This is to enable whispering within a conference (i.e., sending a certain message not to the entire conference, but to one or a few of the participants). This has been discussed before at length. Clearly, CPIM (ugly as it may be) can be made to handle both of these needs. Contributor-ID will only cover the first one - unless of course we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted by the client, to cover the second need. Cheers, Aki=20 On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote: > Hi, >=20 > In last week's SIMPLE meeting, Orit brought up an issue about how we=20 > planned to identify contributors when MSRP is used with a conference=20 > focus. Previously, we had discussed using message/cpim wrappers for=20 > this purpose. >=20 > After thinking through the use case, I think Orit may be correct that=20 > cpim is unwieldy for this purpose. >=20 > The use case I think we have in mind is, you have a text conference=20 > where each participant has an independent MSRP session with the=20 > conference focus. The focus acts as a reflector, forwarding messages=20 > that come in on one participant session to each of the other=20 > participants. It needs a way to tell the receiving parties which=20 > participant sent the message. _How_ it determines what contributor ID=20 > to attach to a given message is out of scope for MSRP--that problem=20 > belongs to XCON. >=20 > We had previously assumed the focus would simply wrap the inbound=20 > message in a message/cpim document, and use the CPIM "from" field for=20 > this purpose. This, however, is problematic for chunked messages, as=20 > the focus would need to buffer the message until it had received all=20 > the chunks, wrap the completed message in the cpim document, and then=20 > send that message out to the other participants, possibly re-chunking=20 > in the process. This does seem to me to be burdensome on the focus; it > would be nicer if the focus could simply forward the individual chunks,=20 > and let the endpoints deal with re-assembling them. >=20 > Another approach would be to have the focus force the endpoints to use > a cpim envelope. However, there may be times where the identity that=20 > the focus wants to insert may be different than the identity that the=20 > endpoint inserts. >=20 > Therefore, I propose we add a new optional header called=20 > Contributor-ID, which can carry a name-addr. Normal endpoints would=20 > never insert this, but a conference focus could insert this header on a=20 > per-chunk basis, and avoid the buffering requirement mentioned above. >=20 > What do others think? Am I completely off base? >=20 > Thanks! >=20 > Ben.=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 13:55:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22477; Wed, 11 Aug 2004 13:55:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuxOv-000433-Ob; Wed, 11 Aug 2004 14:00:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuxBN-0004GZ-CK; Wed, 11 Aug 2004 13:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bux9x-0003oo-Rb for simple@megatron.ietf.org; Wed, 11 Aug 2004 13:45:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21862 for ; Wed, 11 Aug 2004 13:45:08 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuxEk-0003sA-St for simple@ietf.org; Wed, 11 Aug 2004 13:50:07 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7BHj0VG065586 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 11 Aug 2004 12:45:01 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2AD54D79-EBBE-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 12:45:00 -0500 To: "Orit Levin" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Just to clarify: Are you saying you believe that MSRP conference focus behavior should be specified in the MSRP core spec? On Aug 11, 2004, at 12:10 PM, Orit Levin wrote: > > Needlessly to say, I strongly disagree that this is out of scope to > MSRP. By assuming this, we are just inviting proprietary > implementations > and a lot of fun at interop events. > > Based on the SIPPING Conferencing Requirements and Framework, > conference > unaware SIP UAs MUST be able to participate and be invited to a > conference. What kind of experience will this participant get without > having the real source of the message being displayed to him/her? > > Why do you expect from XCON to address MSRP as a special media type and > treat it differently - when other media types (i.e. all the RTP based > streams) have this information in place? > > BTW the "whisper" functionality, according to XCON design, is being > achieved very differently from what Aki envisions. The message is > supposed to be "routed" based on the media policy kept in the media > policy server - not as a result of a participant inserting the "final > destination" information in one of the headers of a media/data stream. > > Cheers, > Orit. > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Aki Niemi > Sent: Wednesday, August 11, 2004 8:34 AM > To: ext Ben Campbell > Cc: SIMPLE WG > Subject: Re: [Simple] MSRP: Contributor ID > > Hi, > > IMO, there are two things CPIM is needed for in a conferencing > scenario: > > 1 - In your use case below, for a focus-inserted "asserted" identity > identifying the sender of the message > > 2 - For routing purposes, in order to route messages based on who the > messages were addressed to. This is to enable whispering within a > conference (i.e., sending a certain message not to the entire > conference, but to one or a few of the participants). This has been > discussed before at length. > > Clearly, CPIM (ugly as it may be) can be made to handle both of these > needs. Contributor-ID will only cover the first one - unless of course > we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted > by the client, to cover the second need. > > Cheers, > Aki > > > On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote: >> Hi, >> >> In last week's SIMPLE meeting, Orit brought up an issue about how we >> planned to identify contributors when MSRP is used with a conference >> focus. Previously, we had discussed using message/cpim wrappers for >> this purpose. >> >> After thinking through the use case, I think Orit may be correct that >> cpim is unwieldy for this purpose. >> >> The use case I think we have in mind is, you have a text conference >> where each participant has an independent MSRP session with the >> conference focus. The focus acts as a reflector, forwarding messages >> that come in on one participant session to each of the other >> participants. It needs a way to tell the receiving parties which >> participant sent the message. _How_ it determines what contributor ID >> to attach to a given message is out of scope for MSRP--that problem >> belongs to XCON. >> >> We had previously assumed the focus would simply wrap the inbound >> message in a message/cpim document, and use the CPIM "from" field for >> this purpose. This, however, is problematic for chunked messages, as >> the focus would need to buffer the message until it had received all >> the chunks, wrap the completed message in the cpim document, and then >> send that message out to the other participants, possibly re-chunking >> in the process. This does seem to me to be burdensome on the focus; it > >> would be nicer if the focus could simply forward the individual > chunks, >> and let the endpoints deal with re-assembling them. >> >> Another approach would be to have the focus force the endpoints to use > >> a cpim envelope. However, there may be times where the identity that >> the focus wants to insert may be different than the identity that the >> endpoint inserts. >> >> Therefore, I propose we add a new optional header called >> Contributor-ID, which can carry a name-addr. Normal endpoints would >> never insert this, but a conference focus could insert this header on > a >> per-chunk basis, and avoid the buffering requirement mentioned above. >> >> What do others think? Am I completely off base? >> >> Thanks! >> >> Ben. >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 14:08:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23258; Wed, 11 Aug 2004 14:08:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buxbg-0004GI-Uj; Wed, 11 Aug 2004 14:13:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuxSy-00081G-1q; Wed, 11 Aug 2004 14:04:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuxMY-0006x7-Hs for simple@megatron.ietf.org; Wed, 11 Aug 2004 13:58:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22642 for ; Wed, 11 Aug 2004 13:58:09 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuxRK-00045s-QM for simple@ietf.org; Wed, 11 Aug 2004 14:03:08 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 11 Aug 2004 10:57:37 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 10:57:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 10:57:39 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcR/yvO1wx7+jWF2TpeevmakJTLU6QAAN9cg From: "Orit Levin" To: "Ben Campbell" X-OriginalArrivalTime: 11 Aug 2004 17:57:31.0312 (UTC) FILETIME=[AC3F9300:01C47FCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Cc: Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable I do believe that the basic MSRP "mixing" behavior should be addressed by the MSRP set of specifications. I think that it is not less important than the MSRP relays behavior (especially keeping in mind the main applications being built around IM technology). I will be happy to provide text for the MSRP spec around this or alternatively to submit a separate draft on this. Orit. -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, August 11, 2004 10:45 AM To: Orit Levin Cc: Aki Niemi; SIMPLE WG Subject: Re: [Simple] MSRP: Contributor ID Just to clarify: Are you saying you believe that MSRP conference focus=20 behavior should be specified in the MSRP core spec? On Aug 11, 2004, at 12:10 PM, Orit Levin wrote: > > Needlessly to say, I strongly disagree that this is out of scope to > MSRP. By assuming this, we are just inviting proprietary=20 > implementations > and a lot of fun at interop events. > > Based on the SIPPING Conferencing Requirements and Framework,=20 > conference > unaware SIP UAs MUST be able to participate and be invited to a > conference. What kind of experience will this participant get without > having the real source of the message being displayed to him/her? > > Why do you expect from XCON to address MSRP as a special media type and > treat it differently - when other media types (i.e. all the RTP based > streams) have this information in place? > > BTW the "whisper" functionality, according to XCON design, is being > achieved very differently from what Aki envisions. The message is > supposed to be "routed" based on the media policy kept in the media > policy server - not as a result of a participant inserting the "final > destination" information in one of the headers of a media/data stream. > > Cheers, > Orit. > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > Behalf > Of Aki Niemi > Sent: Wednesday, August 11, 2004 8:34 AM > To: ext Ben Campbell > Cc: SIMPLE WG > Subject: Re: [Simple] MSRP: Contributor ID > > Hi, > > IMO, there are two things CPIM is needed for in a conferencing=20 > scenario: > > 1 - In your use case below, for a focus-inserted "asserted" identity > identifying the sender of the message > > 2 - For routing purposes, in order to route messages based on who the > messages were addressed to. This is to enable whispering within a > conference (i.e., sending a certain message not to the entire > conference, but to one or a few of the participants). This has been > discussed before at length. > > Clearly, CPIM (ugly as it may be) can be made to handle both of these > needs. Contributor-ID will only cover the first one - unless of course > we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted > by the client, to cover the second need. > > Cheers, > Aki > > > On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote: >> Hi, >> >> In last week's SIMPLE meeting, Orit brought up an issue about how we >> planned to identify contributors when MSRP is used with a conference >> focus. Previously, we had discussed using message/cpim wrappers for >> this purpose. >> >> After thinking through the use case, I think Orit may be correct that >> cpim is unwieldy for this purpose. >> >> The use case I think we have in mind is, you have a text conference >> where each participant has an independent MSRP session with the >> conference focus. The focus acts as a reflector, forwarding messages >> that come in on one participant session to each of the other >> participants. It needs a way to tell the receiving parties which >> participant sent the message. _How_ it determines what contributor ID >> to attach to a given message is out of scope for MSRP--that problem >> belongs to XCON. >> >> We had previously assumed the focus would simply wrap the inbound >> message in a message/cpim document, and use the CPIM "from" field for >> this purpose. This, however, is problematic for chunked messages, as >> the focus would need to buffer the message until it had received all >> the chunks, wrap the completed message in the cpim document, and then >> send that message out to the other participants, possibly re-chunking >> in the process. This does seem to me to be burdensome on the focus; it > >> would be nicer if the focus could simply forward the individual > chunks, >> and let the endpoints deal with re-assembling them. >> >> Another approach would be to have the focus force the endpoints to use > >> a cpim envelope. However, there may be times where the identity that >> the focus wants to insert may be different than the identity that the >> endpoint inserts. >> >> Therefore, I propose we add a new optional header called >> Contributor-ID, which can carry a name-addr. Normal endpoints would >> never insert this, but a conference focus could insert this header on > a >> per-chunk basis, and avoid the buffering requirement mentioned above. >> >> What do others think? Am I completely off base? >> >> Thanks! >> >> Ben. >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 16:48:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13608; Wed, 11 Aug 2004 16:48:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv06J-0001my-SP; Wed, 11 Aug 2004 16:53:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuymT-0008VD-0i; Wed, 11 Aug 2004 15:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuygC-0004dU-K4; Wed, 11 Aug 2004 15:22:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00937; Wed, 11 Aug 2004 15:22:30 -0400 (EDT) Message-Id: <200408111922.PAA00937@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 Aug 2004 15:22:30 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-list-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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 Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists Author(s) : A. Roach, et al. Filename : draft-ietf-simple-event-list-05.txt Pages : 42 Date : 2004-8-11 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-event-list-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-simple-event-list-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: <2004-8-11152721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-list-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-list-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152721.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Aug 11 16:51:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14311; Wed, 11 Aug 2004 16:51:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv091-00020y-Ag; Wed, 11 Aug 2004 16:56:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuymW-00004y-7U; Wed, 11 Aug 2004 15:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuygH-0004f8-8s; Wed, 11 Aug 2004 15:22:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00967; Wed, 11 Aug 2004 15:22:35 -0400 (EDT) Message-Id: <200408111922.PAA00967@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 Aug 2004 15:22:35 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-filter-format-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --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 : An Extensible Markup Language (XML) Based Format for Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-filter-format-02.txt Pages : 23 Date : 2004-8-11 Filtering is a mechanism for defining the preferred content to be delivered and for specifying the rules for when the content should be delivered. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-filter-format-02.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-filter-format-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-11152727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-filter-format-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-filter-format-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152727.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Aug 11 16:55:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14852; Wed, 11 Aug 2004 16:55:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv0CX-0002C7-Jx; Wed, 11 Aug 2004 17:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuymY-000065-Qb; Wed, 11 Aug 2004 15:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuygL-0004hV-Ni; Wed, 11 Aug 2004 15:22:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00977; Wed, 11 Aug 2004 15:22:39 -0400 (EDT) Message-Id: <200408111922.PAA00977@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 Aug 2004 15:22:39 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-filter-funct-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --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 : Functional Description of Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-event-filter-funct-02.txt Pages : 29 Date : 2004-8-11 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-event-filter-funct-02.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-event-filter-funct-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-11152733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-filter-funct-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-filter-funct-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152733.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Aug 11 16:56:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15137; Wed, 11 Aug 2004 16:56:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv0Dv-0002HI-1X; Wed, 11 Aug 2004 17:01:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buymb-000076-CQ; Wed, 11 Aug 2004 15:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuygQ-0004k4-AY; Wed, 11 Aug 2004 15:22:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00996; Wed, 11 Aug 2004 15:22:44 -0400 (EDT) Message-Id: <200408111922.PAA00996@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 Aug 2004 15:22:44 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-iscomposing-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --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 : Indication of Message Composition for Instant Messaging Author(s) : H. Schulzrinne Filename : draft-ietf-simple-iscomposing-03.txt Pages : 14 Date : 2004-8-11 In instant messaging (IM) systems, it is useful to know during an IM conversation that the other party is composing a message, e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iscomposing-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-iscomposing-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-11152739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-iscomposing-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-iscomposing-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152739.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Aug 11 17:40:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20646; Wed, 11 Aug 2004 17:40:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv0uP-00042c-L0; Wed, 11 Aug 2004 17:45:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0WI-0006W5-7v; Wed, 11 Aug 2004 17:20:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buzsu-0000mx-VE for simple@megatron.ietf.org; Wed, 11 Aug 2004 16:39:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12338 for ; Wed, 11 Aug 2004 16:39:42 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buzxi-0001JP-L4 for simple@ietf.org; Wed, 11 Aug 2004 16:44:44 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2004 13:42:07 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7BKd4VD014429; Wed, 11 Aug 2004 13:39:04 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWC97024; Wed, 11 Aug 2004 13:37:53 -0700 (PDT) In-Reply-To: <411A3265.2020702@cisco.com> References: <2038BCC78B1AD641891A0D1AE133DBB7023EEBD8@esebe019.ntc.nokia.com> <411A3265.2020702@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 13:41:00 -0700 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, Rohan Mahy , oritl@microsoft.com, adam@dynamicsoft.com, rsparks@dynamicsoft.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit You would just wrap the complete message. However Hisham's point is still valid (although the integers were off ;-). If you were sending a complete message that is 2000 bytes, if the focus adds 100 bytes of CPIM, the resulting message will be larger than 2048 bytes and will need to interruptible or explicitly chunked. I think its reasonable to try to prevent this situation. If we do decide to use a separate header (ex: "Sender") then I suggest that the syntax allows any type of URI. thanks, -rohan On Aug 11, 2004, at 7:51 AM, Paul Kyzivat wrote: > > > hisham.khartabil@nokia.com wrote: >> Does it seem reasonable to require the focus to wrap each chunk > > with cpim mime type and then having the end point unwrap it? > > or it is better that the focus just inserts a header indicating > > the sender? To me, it seems the latter is more straight forward. > > The point of this discussion has been that it isn't necessary to wrap > *each chunk*. The wrapping only requires an alteration to the first > chunk and the last chunk. > >> In either case, we need to state conflict resolution: for the former, > > it can be stated that if the sender wrapped the message with cpim > > itself, the outer most cpim from-header wins. For the latter, > > the msrp header wins over any cpim from-header. This should be > > normative text for the receiver. > > How does this apply to messages that pass through one or more CPIM > gateways? > > Consider the following case: > > - Message comes in through CPIM gateway (say from an XMPP system). > CPIM headers specify From and To, and a text/plain message. > > - It is sent (in CPIM format) via MSRP to a conference mixer. > > - The mixer stamps the message (using a TBD technique) with the > identity of the sender as known to the mixer, and sends it out to the > other participants. > > - It arrives at another CPIM gateway, where it is converted again to > XMPP format. > > What should the XMPP recipient see? I think it should see a message > that appears to come from the identity inserted by the mixer. > > Ideally we would be able to achieve this without changes to the RFCs > 2778 and 2779. To achieve this, I think that by the time the message > flows thru the outgoing gateway it should have *one* CPIM wrapper that > contains the From address provided by the mixer. > > Perhaps this doesn't change anything - the gateway could take the > Sender header from the MSRP message and insert it into the CPIM From > header before passing the message on. This is a problem for messages > that are to be signed or encrypted e2e (between the xmpp systems), but > that is always going to be a problem in this case. > > It may be that in some of these cases we must live with the fact that > messages may have multiple sources of sender identity, and all should > be presented to the recipient. > >> Also, I don't like the name "Contributor-ID". What is he contributing? > > I prefer something like "Sender". > > I agree. > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 18:28:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26874; Wed, 11 Aug 2004 18:28:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1fC-0005aJ-BB; Wed, 11 Aug 2004 18:33:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1X9-0004j3-TX; Wed, 11 Aug 2004 18:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1FL-0004N1-5x for simple@megatron.ietf.org; Wed, 11 Aug 2004 18:06:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24404 for ; Wed, 11 Aug 2004 18:06:56 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1KA-000583-Kv for simple@ietf.org; Wed, 11 Aug 2004 18:11:59 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BM6iB09309; Thu, 12 Aug 2004 01:06:44 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 01:06:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7BM6QA7016055; Thu, 12 Aug 2004 01:06:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 0003wGR9; Thu, 12 Aug 2004 01:05:52 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BM5pn29387; Thu, 12 Aug 2004 01:05:51 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 01:05:47 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 01:05:48 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 10.162.252.113 10.162.252.113 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by esebe013.ntc.nokia.com; 12 Aug 2004 01:05:25 +0300 Subject: RE: [Simple] MSRP: Contributor ID From: Aki Niemi To: ext Orit Levin In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-M/Espoo Message-Id: <1092261924.4556.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 01:05:25 +0300 X-OriginalArrivalTime: 11 Aug 2004 22:05:48.0331 (UTC) FILETIME=[5B9047B0:01C47FEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit On Wed, 2004-08-11 at 20:10, ext Orit Levin wrote: > BTW the "whisper" functionality, according to XCON design, is being > achieved very differently from what Aki envisions. The message is > supposed to be "routed" based on the media policy kept in the media > policy server - not as a result of a participant inserting the "final > destination" information in one of the headers of a media/data stream. Uh... This has been discussed at length in the past, and I do wonder why people insist on this idea of requiring media policy manipulation in order to do a simple thing like send a private message. In any case, media policy alone still wouldn't solve the whole problem. How would the recipient know that the received message was private and not sent to all of the participants? Anyway, I thought what I described *was* the XCON design - at least that's what the conclusion we arrived somewhere around Seoul was. I agree there is some configuration present in the media policy that then allows temporary changes to happen in the mixing of an IM conference. But those changes would be brought upon by something signaled in-band in the media stream, e.g., using the CPIM To header. Cheers, Aki > Cheers, > Orit. > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Aki Niemi > Sent: Wednesday, August 11, 2004 8:34 AM > To: ext Ben Campbell > Cc: SIMPLE WG > Subject: Re: [Simple] MSRP: Contributor ID > > Hi, > > IMO, there are two things CPIM is needed for in a conferencing scenario: > > 1 - In your use case below, for a focus-inserted "asserted" identity > identifying the sender of the message > > 2 - For routing purposes, in order to route messages based on who the > messages were addressed to. This is to enable whispering within a > conference (i.e., sending a certain message not to the entire > conference, but to one or a few of the participants). This has been > discussed before at length. > > Clearly, CPIM (ugly as it may be) can be made to handle both of these > needs. Contributor-ID will only cover the first one - unless of course > we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted > by the client, to cover the second need. > > Cheers, > Aki > > > On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote: > > Hi, > > > > In last week's SIMPLE meeting, Orit brought up an issue about how we > > planned to identify contributors when MSRP is used with a conference > > focus. Previously, we had discussed using message/cpim wrappers for > > this purpose. > > > > After thinking through the use case, I think Orit may be correct that > > cpim is unwieldy for this purpose. > > > > The use case I think we have in mind is, you have a text conference > > where each participant has an independent MSRP session with the > > conference focus. The focus acts as a reflector, forwarding messages > > that come in on one participant session to each of the other > > participants. It needs a way to tell the receiving parties which > > participant sent the message. _How_ it determines what contributor ID > > to attach to a given message is out of scope for MSRP--that problem > > belongs to XCON. > > > > We had previously assumed the focus would simply wrap the inbound > > message in a message/cpim document, and use the CPIM "from" field for > > this purpose. This, however, is problematic for chunked messages, as > > the focus would need to buffer the message until it had received all > > the chunks, wrap the completed message in the cpim document, and then > > send that message out to the other participants, possibly re-chunking > > in the process. This does seem to me to be burdensome on the focus; it > > > would be nicer if the focus could simply forward the individual > chunks, > > and let the endpoints deal with re-assembling them. > > > > Another approach would be to have the focus force the endpoints to use > > > a cpim envelope. However, there may be times where the identity that > > the focus wants to insert may be different than the identity that the > > endpoint inserts. > > > > Therefore, I propose we add a new optional header called > > Contributor-ID, which can carry a name-addr. Normal endpoints would > > never insert this, but a conference focus could insert this header on > a > > per-chunk basis, and avoid the buffering requirement mentioned above. > > > > What do others think? Am I completely off base? > > > > Thanks! > > > > Ben. > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 11 19:13:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29511; Wed, 11 Aug 2004 19:13:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv2Mr-0006Qa-DC; Wed, 11 Aug 2004 19:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv2E4-0005dL-FR; Wed, 11 Aug 2004 19:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv2Ag-0004iY-9D for simple@megatron.ietf.org; Wed, 11 Aug 2004 19:06:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29190 for ; Wed, 11 Aug 2004 19:06:11 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv2FV-0006J9-1Z for simple@ietf.org; Wed, 11 Aug 2004 19:11:14 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 11 Aug 2004 16:05:34 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 16:05:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 11 Aug 2004 16:05:44 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcR/75h1ppYSdUPYRAWxwb7inDOwTQAA2z5w From: "Orit Levin" To: "Aki Niemi" X-OriginalArrivalTime: 11 Aug 2004 23:05:37.0089 (UTC) FILETIME=[B6A14B10:01C47FF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable XCON is an application protocol to control conferences and (indirectly) "mixers". I am not advocating discussing (and supporting) XCON or any other advanced conferencing design as a part of MSRP :-) Not at all! I am saying that MSRP must have the basic hooks (as all other media protocols have today) for allowing various conferencing designs to happen and without requiring participants to support special extensions in order to be invited to or dial-into a conference. This is the basic SIPPING conferencing requirements which are possible with all other media. We could say that all MSRP clients MUST always be prepared to receive CPIM as a part of the core MSRP. That is even when no end-to-end security is being used. I think that it is a complete misuse of CPIM. When you need or willing to use the end-to-end security, in addition to using CPIM - you will do many other security related steps. Binding it with simple conferencing under the claim that it makes the implementations/architecture easer - doesn't sound reasonable to me. I am afraid it is exactly the opposite: Focus/mixer and end-to-end security don't live very well together and using the same header for both - is a certain recipe for big troubles. In some scenarios foci and GWs will have the dilemma of double wrapping the data vs. aggregating the CPIM information: one as being received from a participant and the other for e-to-e security purposes... and this is just the tip of the iceberg. Orit. -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 Sent: Wednesday, August 11, 2004 3:05 PM To: Orit Levin Cc: ext Ben Campbell; SIMPLE WG Subject: RE: [Simple] MSRP: Contributor ID On Wed, 2004-08-11 at 20:10, ext Orit Levin wrote: > BTW the "whisper" functionality, according to XCON design, is being > achieved very differently from what Aki envisions. The message is > supposed to be "routed" based on the media policy kept in the media > policy server - not as a result of a participant inserting the "final > destination" information in one of the headers of a media/data stream. Uh... This has been discussed at length in the past, and I do wonder why people insist on this idea of requiring media policy manipulation in order to do a simple thing like send a private message. In any case, media policy alone still wouldn't solve the whole problem. How would the recipient know that the received message was private and not sent to all of the participants? Anyway, I thought what I described *was* the XCON design - at least that's what the conclusion we arrived somewhere around Seoul was. I agree there is some configuration present in the media policy that then allows temporary changes to happen in the mixing of an IM conference. But those changes would be brought upon by something signaled in-band in the media stream, e.g., using the CPIM To header. Cheers, Aki > Cheers, > Orit. >=20 >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Aki Niemi > Sent: Wednesday, August 11, 2004 8:34 AM > To: ext Ben Campbell > Cc: SIMPLE WG > Subject: Re: [Simple] MSRP: Contributor ID >=20 > Hi, >=20 > IMO, there are two things CPIM is needed for in a conferencing scenario: >=20 > 1 - In your use case below, for a focus-inserted "asserted" identity > identifying the sender of the message >=20 > 2 - For routing purposes, in order to route messages based on who the > messages were addressed to. This is to enable whispering within a > conference (i.e., sending a certain message not to the entire > conference, but to one or a few of the participants). This has been > discussed before at length. >=20 > Clearly, CPIM (ugly as it may be) can be made to handle both of these > needs. Contributor-ID will only cover the first one - unless of course > we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted > by the client, to cover the second need. >=20 > Cheers, > Aki=20 >=20 >=20 > On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote: > > Hi, > >=20 > > In last week's SIMPLE meeting, Orit brought up an issue about how we > > planned to identify contributors when MSRP is used with a conference > > focus. Previously, we had discussed using message/cpim wrappers for=20 > > this purpose. > >=20 > > After thinking through the use case, I think Orit may be correct that=20 > > cpim is unwieldy for this purpose. > >=20 > > The use case I think we have in mind is, you have a text conference=20 > > where each participant has an independent MSRP session with the=20 > > conference focus. The focus acts as a reflector, forwarding messages > > that come in on one participant session to each of the other=20 > > participants. It needs a way to tell the receiving parties which=20 > > participant sent the message. _How_ it determines what contributor ID=20 > > to attach to a given message is out of scope for MSRP--that problem=20 > > belongs to XCON. > >=20 > > We had previously assumed the focus would simply wrap the inbound=20 > > message in a message/cpim document, and use the CPIM "from" field for=20 > > this purpose. This, however, is problematic for chunked messages, as > > the focus would need to buffer the message until it had received all > > the chunks, wrap the completed message in the cpim document, and then=20 > > send that message out to the other participants, possibly re-chunking=20 > > in the process. This does seem to me to be burdensome on the focus; it >=20 > > would be nicer if the focus could simply forward the individual > chunks,=20 > > and let the endpoints deal with re-assembling them. > >=20 > > Another approach would be to have the focus force the endpoints to use >=20 > > a cpim envelope. However, there may be times where the identity that > > the focus wants to insert may be different than the identity that the=20 > > endpoint inserts. > >=20 > > Therefore, I propose we add a new optional header called=20 > > Contributor-ID, which can carry a name-addr. Normal endpoints would=20 > > never insert this, but a conference focus could insert this header on > a=20 > > per-chunk basis, and avoid the buffering requirement mentioned above. > >=20 > > What do others think? Am I completely off base? > >=20 > > Thanks! > >=20 > > Ben.=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 10:00:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02550; Thu, 12 Aug 2004 10:00:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvGD4-0004Th-Mw; Thu, 12 Aug 2004 10:05:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG4k-0004FR-K5; Thu, 12 Aug 2004 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFkp-0000lR-If for simple@megatron.ietf.org; Thu, 12 Aug 2004 09:36:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01390 for ; Thu, 12 Aug 2004 09:36:25 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvFpk-000441-6k for simple@ietf.org; Thu, 12 Aug 2004 09:41:35 -0400 Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id D7F5F154009 for ; Thu, 12 Aug 2004 13:36:21 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Message-ID: <20040812133605.10496.59603.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Thu, 12 Aug 2004 14:36:05 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Simple] XCAP as general configuration protocol. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi folks, I'm a little confused by XCAP's purpose - is it aimed at providing a configuration protocol specifically for the needs of SIMPLE's protocol suite, or is it aimed at providing generalized configuration access? It may help to know that I'm looking at it from the perspective of someone who's operationally deployed ACAP in production environments, but given the lack of support, if XCAP takes off, then I might have to switch. I appreciate this is an unusual perspective. :-) It may also help to know I know next to nothing about XML Schemas, which is unfortunate, but I note this draft is heading quickly towards last call, so I wanted to find out exactly what it's doing as quickly as possible. Things I'm particularly confused about: 1) How do vendor-specific extensions work? (Say, if an addressbook or bookmark collection were stored in XCAP, how would an application add its own data to it?) Is this handled purely by namespaces, or does that interfere with the Schemas defined? 2) Given the degree of validation effort possible to request from the server, is it within the specification to have an AUID that doesn't do any validation? (Obviously it'd have to do XML-well-formedness.) I'm quite concerned that XCAP appears to be a substantial resource-hog - performing referential integrity checks on XML can't be the fastest thing in the world (I could be wrong, but it's certainly going to be slower than a purely syntactic validation). Does anyone have any information on how fast (or slow) an XCAP server is? 3) As I understand it, the only method of searching is via the reduced XPath used in the URI. Is there any reason why a redefinition of a reduced XPath has been used rather than simply using XPath in the URI? (I can't see anyone choosing to handle these URIs in any way other than using an XPath library). 4) Given that, in general, applications will wish to use a substanital block of configuration data, and maintain it as current as reasonably possible, how does an application obtain a list of changes since a certain time (or ETag)? The only method I can see is by polling the entire block, which, if changed, will produce a substantial amount of output. Alternately, an application could try an If-None-Match HTTP request against every node - the problem then being that, naturally, the entire document will not match the stored ETag, hence reducing to a full poll. This strikes me as quite a serious problem, so I'd like to be assured that I'm missing something obvious. (Ideally, XCAP would have push notifications like ACAP has, but given the HTTP basis, that is of course impossible.) Of course, I don't care about any of the above if XCAP isn't really intended for the same general target as ACAP is - in which case I'll keep my eye out for some other, more suitable, replacement. (A shame, since ACAP is perfectly suited to my needs.) And I apologise in advance if this has already been done to death on the mailing list - Google can't find much about it all. Whichever, I would thoroughly appreciate a mail if anyone has a test implementation of an XCAP server and/or client I could try. Dave. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 11:03:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07244; Thu, 12 Aug 2004 11:03:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvHBm-0005Zd-2e; Thu, 12 Aug 2004 11:08:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvH06-0005V2-5h; Thu, 12 Aug 2004 10:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvGnf-0002qB-03 for simple@megatron.ietf.org; Thu, 12 Aug 2004 10:43:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06164 for ; Thu, 12 Aug 2004 10:43:25 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvGsb-0005C5-SS for simple@ietf.org; Thu, 12 Aug 2004 10:48:36 -0400 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7CEgn4l013577; Thu, 12 Aug 2004 07:42:50 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn5-209.cisco.com [10.21.88.209]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ARI93646; Thu, 12 Aug 2004 07:42:48 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Wed, 11 Aug 2004 17:55:25 -0700 Subject: Re: [Simple] MSRP: Contributor ID From: Cullen Jennings To: Ben Campbell , Hisham khartabil , Orit Levin , Rohan Mahy , Chris Boulton , Adam Roach , Robert Sparks , Paul H Kyzivat Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Sounds like a reasonable idea to me. I think we would want to add that if the user had requested Privacy either via the privacy header or setting From to Anonymous then the contributor id should not be revealed here. Even if the user authenticated via pins or something, the identity should not be revealed here if the original call was private. On 8/9/04 11:27 AM, "Ben Campbell" wrote: > Hi, > > In last week's SIMPLE meeting, Orit brought up an issue about how we > planned to identify contributors when MSRP is used with a conference > focus. Previously, we had discussed using message/cpim wrappers for > this purpose. > > After thinking through the use case, I think Orit may be correct that > cpim is unwieldy for this purpose. > > The use case I think we have in mind is, you have a text conference > where each participant has an independent MSRP session with the > conference focus. The focus acts as a reflector, forwarding messages > that come in on one participant session to each of the other > participants. It needs a way to tell the receiving parties which > participant sent the message. _How_ it determines what contributor ID > to attach to a given message is out of scope for MSRP--that problem > belongs to XCON. > > We had previously assumed the focus would simply wrap the inbound > message in a message/cpim document, and use the CPIM "from" field for > this purpose. This, however, is problematic for chunked messages, as > the focus would need to buffer the message until it had received all > the chunks, wrap the completed message in the cpim document, and then > send that message out to the other participants, possibly re-chunking > in the process. This does seem to me to be burdensome on the focus; it > would be nicer if the focus could simply forward the individual chunks, > and let the endpoints deal with re-assembling them. > > Another approach would be to have the focus force the endpoints to use > a cpim envelope. However, there may be times where the identity that > the focus wants to insert may be different than the identity that the > endpoint inserts. > > Therefore, I propose we add a new optional header called > Contributor-ID, which can carry a name-addr. Normal endpoints would > never insert this, but a conference focus could insert this header on a > per-chunk basis, and avoid the buffering requirement mentioned above. > > What do others think? Am I completely off base? > > Thanks! > > Ben. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 11:09:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07863; Thu, 12 Aug 2004 11:09:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvHI5-0005kr-Hg; Thu, 12 Aug 2004 11:14:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvH26-0005vY-Gr; Thu, 12 Aug 2004 10:58:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvGxJ-0004dV-8I for simple@megatron.ietf.org; Thu, 12 Aug 2004 10:53:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06643 for ; Thu, 12 Aug 2004 10:53:22 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvH2E-0005MF-Gj for simple@ietf.org; Thu, 12 Aug 2004 10:58:33 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CEpjB12511; Thu, 12 Aug 2004 17:51:45 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 17:51:33 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7CEpXcj001018; Thu, 12 Aug 2004 17:51:33 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00giZj5d; Thu, 12 Aug 2004 17:51:31 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CEpPu23507; Thu, 12 Aug 2004 17:51:25 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 17:51:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] MSRP: Contributor ID Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2004 17:51:16 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEC15@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSAes4Z7eYb/OzcTGKEL835BSIJzQAAPL6g To: , , , , , , , X-OriginalArrivalTime: 12 Aug 2004 14:51:17.0520 (UTC) FILETIME=[D28FF900:01C4807B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable That's definitely conference policy and is outside the scope of MSRP. /Hisham > -----Original Message----- > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 12.August.2004 03:55 > To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki);=20 > Orit Levin; > Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP: Contributor ID >=20 >=20 >=20 > Sounds like a reasonable idea to me. I think we would want to=20 > add that if > the user had requested Privacy either via the privacy header=20 > or setting From > to Anonymous then the contributor id should not be revealed=20 > here. Even if > the user authenticated via pins or something, the identity=20 > should not be > revealed here if the original call was private. >=20 >=20 > On 8/9/04 11:27 AM, "Ben Campbell" wrote: >=20 > > Hi, > >=20 > > In last week's SIMPLE meeting, Orit brought up an issue about how we > > planned to identify contributors when MSRP is used with a conference > > focus. Previously, we had discussed using message/cpim wrappers for > > this purpose. > >=20 > > After thinking through the use case, I think Orit may be=20 > correct that > > cpim is unwieldy for this purpose. > >=20 > > The use case I think we have in mind is, you have a text conference > > where each participant has an independent MSRP session with the > > conference focus. The focus acts as a reflector, forwarding messages > > that come in on one participant session to each of the other > > participants. It needs a way to tell the receiving parties which > > participant sent the message. _How_ it determines what=20 > contributor ID > > to attach to a given message is out of scope for MSRP--that problem > > belongs to XCON. > >=20 > > We had previously assumed the focus would simply wrap the inbound > > message in a message/cpim document, and use the CPIM "from"=20 > field for > > this purpose. This, however, is problematic for chunked messages, as > > the focus would need to buffer the message until it had received all > > the chunks, wrap the completed message in the cpim=20 > document, and then > > send that message out to the other participants, possibly=20 > re-chunking > > in the process. This does seem to me to be burdensome on=20 > the focus; it > > would be nicer if the focus could simply forward the=20 > individual chunks, > > and let the endpoints deal with re-assembling them. > >=20 > > Another approach would be to have the focus force the=20 > endpoints to use > > a cpim envelope. However, there may be times where the identity that > > the focus wants to insert may be different than the=20 > identity that the > > endpoint inserts. > >=20 > > Therefore, I propose we add a new optional header called > > Contributor-ID, which can carry a name-addr. Normal endpoints would > > never insert this, but a conference focus could insert this=20 > header on a > > per-chunk basis, and avoid the buffering requirement=20 > mentioned above. > >=20 > > What do others think? Am I completely off base? > >=20 > > Thanks! > >=20 > > Ben.=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 12:36:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13435; Thu, 12 Aug 2004 12:36:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIeC-0007Op-Rl; Thu, 12 Aug 2004 12:41:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvINr-0001V7-R7; Thu, 12 Aug 2004 12:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIDm-00076Q-IS for simple@megatron.ietf.org; Thu, 12 Aug 2004 12:14:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11479 for ; Thu, 12 Aug 2004 12:14:28 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIIk-0006tM-VC for simple@ietf.org; Thu, 12 Aug 2004 12:19:40 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CGEQ319156 for ; Thu, 12 Aug 2004 19:14:27 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 19:13:58 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7CGDwPF017602 for ; Thu, 12 Aug 2004 19:13:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00AZfyDV; Thu, 12 Aug 2004 19:13:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CGDpn05693 for ; Thu, 12 Aug 2004 19:13:51 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 19:13:50 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by kusti.research.nokia.com (Postfix) with ESMTP id 2256193B75 for ; Thu, 12 Aug 2004 19:13:50 +0300 (EEST) Received: from agni.research.nokia.com (news.netsonic.fi [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7CGDotR017182 for ; Thu, 12 Aug 2004 19:13:50 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7CGDol2017181; Thu, 12 Aug 2004 19:13:50 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Thu, 12 Aug 2004 19:13:49 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 12 Aug 2004 16:13:50.0352 (UTC) FILETIME=[5AAE2900:01C48087] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Simple] message-session-07: why responses? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello all, The current MSRP draft now includes extensive REPORT facilities. I wonder why we still keep the responses in the spec? During the discussion between Orit and rest of the world last spring AFAIR the most compelling reason for hop-by-hop responses is that they provide explicit keepalive functionality. When using responses, relays have to buffer transactions only until they receive application-level confirmation. Without response, relays could not get any indication when the next-hop connection failed. Could we simply use explicit keepalive messages, say, single-hop SEND without body with Report-Success: yes (or PING/PONG a'la IRC or HELLO or KEEPALIVE)? An MSRP entity could send such a keepalive request any time, and it would know that all the messages sent before keepalive were actually received when it receives the suitable keepalive reply request. Instead of error responses (like 401), we could use REPORT with appropriate Status. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 13:01:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15355; Thu, 12 Aug 2004 13:01:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvJ2l-0007zb-5d; Thu, 12 Aug 2004 13:07:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIhP-0005s7-CC; Thu, 12 Aug 2004 12:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvISQ-0002Qy-WE for simple@megatron.ietf.org; Thu, 12 Aug 2004 12:29:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12959 for ; Thu, 12 Aug 2004 12:29:36 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIXN-0007I1-FG for simple@ietf.org; Thu, 12 Aug 2004 12:34:48 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CGTXj07091 for ; Thu, 12 Aug 2004 19:29:33 +0300 (EET DST) X-Scanned: Thu, 12 Aug 2004 19:29:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7CGTKlJ031277 for ; Thu, 12 Aug 2004 19:29:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ect5kk; Thu, 12 Aug 2004 19:28:55 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7CGSsn21992 for ; Thu, 12 Aug 2004 19:28:54 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 12 Aug 2004 19:28:12 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by kusti.research.nokia.com (Postfix) with ESMTP id A726F93B75 for ; Thu, 12 Aug 2004 19:28:12 +0300 (EEST) Received: from agni.research.nokia.com (news.netsonic.fi [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7CFrLmI017011 for ; Thu, 12 Aug 2004 18:53:21 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7CFrKpO017010; Thu, 12 Aug 2004 18:53:20 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Thu, 12 Aug 2004 18:53:20 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 12 Aug 2004 16:28:12.0889 (UTC) FILETIME=[5CCADC90:01C48089] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Simple] msrp-relay-01: How to apply backpressure? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hello all, Neither the message-session-07 nor the msrp-relay-01 address any way the flow control issues. There is no limit on the data a msrp endpoint can push to the network nor there is no way of relays to indicate that their internal queues are becoming full. Should we consider adding mechanisms for flow control in MSRP? A response or REPORT could indicate the available window size. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 15:01:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23191; Thu, 12 Aug 2004 15:01:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvKu7-00020M-Tb; Thu, 12 Aug 2004 15:06:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKke-0003yw-1i; Thu, 12 Aug 2004 14:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKfM-0008BP-6z for simple@megatron.ietf.org; Thu, 12 Aug 2004 14:51:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22435 for ; Thu, 12 Aug 2004 14:51:06 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvKkM-0001jB-2Q for simple@ietf.org; Thu, 12 Aug 2004 14:56:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2004 11:54:39 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CInJCL021832; Thu, 12 Aug 2004 11:49:21 -0700 (PDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU61381; Thu, 12 Aug 2004 14:50:27 -0400 (EDT) Message-ID: <411BBBF4.40807@cisco.com> Date: Thu, 12 Aug 2004 14:50:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi Subject: Re: [Simple] msrp-relay-01: How to apply backpressure? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit We tried to solve that and had so many problems we gave up for now. Consider it a topic for future work. (Something had to give, or we were going to end up with no solution at all.) Paul Pekka Pessi wrote: > Hello all, > > Neither the message-session-07 nor the msrp-relay-01 address any > way the flow control issues. There is no limit on the data a > msrp endpoint can push to the network nor there is no way of > relays to indicate that their internal queues are becoming full. > > Should we consider adding mechanisms for flow control in MSRP? A > response or REPORT could indicate the available window size. > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 16:54:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06798; Thu, 12 Aug 2004 16:54:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvMfY-0006IP-LR; Thu, 12 Aug 2004 16:59:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvMQJ-0004Mc-L2; Thu, 12 Aug 2004 16:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvLqx-0003U8-5y for simple@megatron.ietf.org; Thu, 12 Aug 2004 16:07:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29509 for ; Thu, 12 Aug 2004 16:07:09 -0400 (EDT) Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvLvx-0003n8-Pp for simple@ietf.org; Thu, 12 Aug 2004 16:12:23 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i7CK6cLp030222 for ; Thu, 12 Aug 2004 15:06:38 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1092341131.2459.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 12 Aug 2004 15:05:31 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Simple] Please comment: Do we want to take on partial publication? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Folks - If you haven't already read it, please take a moment and skim http://www.ietf.org/internet-drafts/draft-lonnfors-simple-partial-publish-01.txt We've had _very_ light list discussion on this draft. We talked about it briefly at the interim in Boston, but it wasn't clear that there was sufficient interest even in that room. The primary question in that meeting was whether or not we could meet the requirements this draft intends without doing any additional standardization work (by having endpoints that want to publish pieces act as one publisher per piece). So speak up. Do you think this is a place SIMPLE needs to take on more work? Who thinks we have a good enough solution for this already? Who, in addition to the authors of this draft, is willing to spend time working on this problem? Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 17:01:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07541; Thu, 12 Aug 2004 17:01:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvMm7-0006Wt-L7; Thu, 12 Aug 2004 17:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvMZB-00081E-DI; Thu, 12 Aug 2004 16:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bug3C-0007cv-PE for simple@megatron.ietf.org; Tue, 10 Aug 2004 19:29:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16718 for ; Tue, 10 Aug 2004 19:28:59 -0400 (EDT) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bug7p-0001V5-Ag for simple@ietf.org; Tue, 10 Aug 2004 19:33:50 -0400 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 11 Aug 2004 09:38:29 +1000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7ANSD1q007798; Wed, 11 Aug 2004 09:28:14 +1000 (EST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWC13655; Tue, 10 Aug 2004 16:27:03 -0700 (PDT) In-Reply-To: <4117D1E2.8060406@cisco.com> References: <4117C6CD.8060508@cisco.com> <4117D1E2.8060406@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <381D0596-EB25-11D8-A01A-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] MSRP: Contributor ID Date: Tue, 10 Aug 2004 16:30:09 -0700 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Aug 2004 16:52:52 -0400 Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: 7bit Paul, I am not arguing for using CPIM. I actually feel its kind of ugly, but in the interest of describing what you need to do to use CPIM, I think you missed a few cases. I believe there are 2 axes here (signature, and crypto) 1. Unsigned 2. Signed by the participant 3. Signed by the focus 4. Signed by both the participant and the focus A. Unencrypted B. Encrypted with a group key to whole conference C. Encrypted to Focus, Re-encrypted to Target Participant On the signature axis, the focus just needs to add a new message/cpim envelope, and can do this in all 4 cases. 1. Unsigned BEFORE ... Content-Type: text/plain Hi -------foo$ AFTER ... Content-Type: message/cpim From: Content-Type: text/plain Hi -------foo$ 2. Signed by Participant BEFORE ... Content-Type: multipart/signed;boudary=bar --bar Content-Type: text/plain Hi --bar Content-Type: application/pkcs7-mime --bar -------foo$ AFTER ... Content-Type: message/cpim From: Alice Content-Type: multipart/signed;boudary=bar --bar Content-Type: text/plain Hi --bar Content-Type: application/pkcs7-mime --bar -------foo$ 3. Signed by Focus BEFORE ... Content-Type: text/plain Hi -------foo$ AFTER ... Content-Type: multipart/signed;boundary=bar --bar Content-Type: message/cpim From: Alice Content-Type: text/plain Hi --bar Content-Type: application/pkcs7-mime --bar -------foo$ 4. Signed by Both BEFORE ... Content-Type: multipart/signed;boudary=bar --bar Content-Type: text/plain Hi --bar Content-Type: application/pkcs7-mime --bar -------foo$ AFTER ... Content-Type: multipart/signed;boundary=focus-bound --focus-bound Content-Type: message/cpim From: Alice Content-Type: multipart/signed;boundary=godzilla --godzilla Content-Type: text/plain Hi --godzilla Content-Type: application/pkcs7-mime --godzilla --focus-bound Content-Type: application/pkcs7-mime --focus-bound -------foo$ None of the signature combos requires the whole message. You insert some stuff at the top, and and the end. you need to keep a running hash going in the middle to generate or verify the signature at the end, but you don't need the whole message to start writing. For the encryption axis, obviously all the signature examples were unencrypted and work fine. If a message is encrypted for a group, the focus just treats this like any other type of body and slaps a message/cpim envelope around it to assert who it thinks the From is (**). The only time the focus needs to grab the whole message, is when it is encrypted for the focus and nobody else has the key. Obviously here, you need the whole message anyway, so CPIM is hardly the limiting factor. (**) example: B. Encrypted with group key BEFORE ... Content-Type: application/pkcs7mime ***********ciphertext********* -------foo$ AFTER ... Content-Type: message/cpim From: Alice Content-Type: application/pkcs7mime ***********ciphertext********* -------foo$ thanks. -rohan On Aug 9, 2004, at 12:34 PM, Paul Kyzivat wrote: > > > Ben Campbell wrote: >> On Aug 9, 2004, at 1:47 PM, Paul Kyzivat wrote: >>> comments inline. >>> >>> Paul >>> >>> Ben Campbell wrote: >>> >>>> Hi, >>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>> we planned to identify contributors when MSRP is used with a >>>> conference focus. Previously, we had discussed using message/cpim >>>> wrappers for this purpose. >>>> After thinking through the use case, I think Orit may be correct >>>> that cpim is unwieldy for this purpose. >>>> The use case I think we have in mind is, you have a text conference >>>> where each participant has an independent MSRP session with the >>>> conference focus. The focus acts as a reflector, forwarding >>>> messages that come in on one participant session to each of the >>>> other participants. It needs a way to tell the receiving parties >>>> which participant sent the message. _How_ it determines what >>>> contributor ID to attach to a given message is out of scope for >>>> MSRP--that problem belongs to XCON. >>>> We had previously assumed the focus would simply wrap the inbound >>>> message in a message/cpim document, and use the CPIM "from" field >>>> for this purpose. This, however, is problematic for chunked >>>> messages, as the focus would need to buffer the message until it >>>> had received all the chunks, wrap the completed message in the cpim >>>> document, and then send that message out to the other participants, >>>> possibly re-chunking in the process. This does seem to me to be >>>> burdensome on the focus; it would be nicer if the focus could >>>> simply forward the individual chunks, and let the endpoints deal >>>> with re-assembling them. >>> >>> >>> I haven't thought this thru carefully, but I think it should be >>> possible to wrap the message in a CPIM wrapper without reassembling >>> it first. It is just a matter of inserting some bytes for the >>> wrapper in the first chunk. If that pushes the first chunk over 2k >>> then it might have to be sent as two chunks, then so be it. If the >>> actual length of the message was provided, then it would need to be >>> changed. And then each other chunk of the message would need to have >>> its byte range adjusted. Then, when the last chunk is found, it >>> needs to have a suffix appended to it to wrap out the CPIM wrapper. >>> (Actually I don't recall the details of CPIM to know if that is >>> needed.) >>> >>> So, it takes a bit of work, but not a huge amount. >>> >> I agree this is true, assuming the use of cpim is always that simple. >> Do we run into any problem if the chunk contained signed or encrypted >> data? Will the focus ever need to sign or encrypt the data itself? > > Well, what are the cases? > - the message arriving at the mixer could be signed, encrypted, both, > neither - by the sender. > - the outgoing message from the mixer could any signing/encryping of > the incoming message alone, or could remove one or the other. > - the outgoing message from the mixer could be signed, encrypted, both > or neither - by the mixer. > > I'm not sure how many of those combinations are meaningful - not very > many I think. > > If the message is encrypted, and the mixer needs to remove that > encryption, then it cannot escape buffering the whole message. > > If the message is not encrypted, but it is signed with > multipart/signed, then it should be possible to remove the signature > on the fly. > > If the message is to be signed and/or encrypted by the mixer, then > given a suitable algorith, I think it is possible to do it on the fly, > with the restriction that any out-of-order chunks will need to be > buffered until their turn arrives. All the stuff that wraps the actual > encrypted text can still be inserted at the beginning or end. > > I'm not sure of this - would need to study the encoding more carefully > to be sure, but I think this should work. > > Note that all of this is independent of whether a CPIM wrapper is > being added or not. > >>> I think the two approaches aren't different enough in the work >>> required that they should be judged based on that. >>> >>> Its probably more important to get the semantics right. Suppose we >>> were to go with this new header. And then suppose we had conference >>> participants sending CPIM wrapped messages that contain a From >>> header. What identity should the recipient display? >> It seems to me that this is a matter for the conference policy to >> solve, and is not significantly different than if you have a voice >> conference, and a caller has a different identity in the credentials >> for a SIP dialog than in the conference policy. > > Certainly it *can*. But as long as the endpoint can receive identity > information in two ways there will always be more confusion that if > there is only one way. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 12 17:01:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07610; Thu, 12 Aug 2004 17:01:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvMmn-0006YN-2h; Thu, 12 Aug 2004 17:06:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvMZC-00081t-1n; Thu, 12 Aug 2004 16:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvDr7-0000he-H3 for simple@megatron.ietf.org; Thu, 12 Aug 2004 07:34:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24390 for ; Thu, 12 Aug 2004 07:34:48 -0400 (EDT) Received: from mail.followap.com ([194.90.168.100] helo=MHAIFA.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvDw3-0001jy-0a for simple@ietf.org; Thu, 12 Aug 2004 07:39:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Aug 2004 14:31:02 +0300 Message-ID: <8993B20049600A40B0AEAFD6F736C9DFC12E6C@MHAIFA.followap.com> X-MS-Has-Attach: yes Thread-Topic: MSRP-07 Comments Thread-Index: AcSAXxFN37gsyMCoQTqAaV9ObyKusQ== From: "Sharon Fridman" To: "Ben Campbell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f X-Mailman-Approved-At: Thu, 12 Aug 2004 16:52:52 -0400 Cc: simple@ietf.org Subject: [Simple] MSRP-07 Comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1314694801==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f This is a multi-part message in MIME format. --===============1314694801== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C4805F.D8DE0F3C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4805F.D8DE0F3C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4805F.D8DE0F3C" ------_=_NextPart_002_01C4805F.D8DE0F3C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! =20 Some nits and minor comments:=20 =20 Section 11.1 Diagram misaligned in numbering with the following steps in text. Step 5 does not include a CRLF after the headers as indicated in Section 9. =20 Section 11.3 Does not include a CRLF after the headers as indicated in Section 9. =20 Section 11.4 (3rd step, above Section 11.5) Shouldn't it be a REPORT method and not SEND? =20 Section 11.5 REGISTER CSeq does not relate to the response CSeq. =20 Thanks, Fridy (Sharon Fridman) / Followap =20 ------_=_NextPart_002_01C4805F.D8DE0F3C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

Some nits and minor comments: =

 

Section 11.1

Diagram misaligned in numbering with the following = steps in text.

Step 5 does not include a CRLF after the headers as indicated in Section 9.

 

Section 11.3

Does not include a CRLF after the headers as = indicated in Section 9.

 

Section 11.4

(3rd step, above Section 11.5) = Shouldn’t it be a REPORT method and not SEND?

 

Section 11.5

REGISTER CSeq does not relate to the response = CSeq.

 

Thanks,

Fridy (Sharon = Fridman) / Followap

 

------_=_NextPart_002_01C4805F.D8DE0F3C-- ------_=_NextPart_001_01C4805F.D8DE0F3C Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhDwAPAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAY AAAADG1zT1BNU09GRklDRTkuMERuJlAzACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIC AQEGiroUzgAh+QQBAAABACwAAAAADwAPAIb/99jAwMD/0BP/1Cf/2Dv/32IAAABSUf94eP+Mi/+f nv/Fxf//8LD/88QFBP8sK///9MT/+Nj/77D/88X/6In/8LH/2tr/v7//sbH/o6P/h4f/eXn/1zv/ 4GL/z8//s7P/pqb/mJf/xMT/qKf/mpr/jIz/cXD/YmL/ra3/kZL/hIP/dXb/Wlr/TEz/oqL/hob/ eHf/amr/Tk7/QUD/lpb/enr/bW3/Xl//0BSfn//Gxf95d/+Li///6Ir/54l5eP94d/9SUv8sKv8r K/8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMHh4ABgoOEhYaCBoeDAgMcBQYUFQ0AhjgDBB0GPgyThowEj5sQEZ6XjxQSE6SF lqCQnJQBNDU2N5YcmT0SnQEuLzAxMjMODwYHCDw5OgEoKSorLC0OQsZACQoLASIjJCUmJ9PGCNfZ Hh8gIQbq6+wGFhcYGRobDkPGP9fLhsQGQTs82BQFSFQoEAA7 ------_=_NextPart_001_01C4805F.D8DE0F3C-- --===============1314694801== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1314694801==-- From simple-bounces@ietf.org Thu Aug 12 17:03:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07835; Thu, 12 Aug 2004 17:03:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvMoZ-0006cA-IT; Thu, 12 Aug 2004 17:08:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvMZt-0000jB-8P; Thu, 12 Aug 2004 16:53:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvMP4-0003UR-A7 for simple@megatron.ietf.org; Thu, 12 Aug 2004 16:42:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05791 for ; Thu, 12 Aug 2004 16:42:24 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvMU6-0005v9-4F for simple@ietf.org; Thu, 12 Aug 2004 16:47:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2004 13:45:04 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CKeeCL028369; Thu, 12 Aug 2004 13:40:43 -0700 (PDT) Received: from [128.107.170.218] ([128.107.170.218]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ARJ29100; Thu, 12 Aug 2004 13:41:47 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Thu, 12 Aug 2004 13:41:51 -0700 Subject: Re: [Simple] MSRP: Contributor ID From: Cullen Jennings To: , , Orit Levin , , , Adam Roach , Robert Sparks , Paul H Kyzivat Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEC15@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Uh, I don't think we should make this about XCON or conferencing. The use case for this is that some time the message comes from a different person than sent it - sure xcon is one example of that. This field allows a way to specify who it originally came from. I would suspect that to pass IESG security review the security section better be really clear on how this name fields deals with issues of privacy, spoofing of identity, and who is asserting it. My text was clearly inadequate but I look forward to reading the security section around this. Saying the security portion of this is somebody else's problem, in a different working groups, seems inadequate. On 8/12/04 7:51 AM, "hisham.khartabil@nokia.com" wrote: > That's definitely conference policy and is outside the scope of MSRP. > > /Hisham > >> -----Original Message----- >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 12.August.2004 03:55 >> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >> Orit Levin; >> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat >> Cc: simple@ietf.org >> Subject: Re: [Simple] MSRP: Contributor ID >> >> >> >> Sounds like a reasonable idea to me. I think we would want to >> add that if >> the user had requested Privacy either via the privacy header >> or setting From >> to Anonymous then the contributor id should not be revealed >> here. Even if >> the user authenticated via pins or something, the identity >> should not be >> revealed here if the original call was private. >> >> >> On 8/9/04 11:27 AM, "Ben Campbell" wrote: >> >>> Hi, >>> >>> In last week's SIMPLE meeting, Orit brought up an issue about how we >>> planned to identify contributors when MSRP is used with a conference >>> focus. Previously, we had discussed using message/cpim wrappers for >>> this purpose. >>> >>> After thinking through the use case, I think Orit may be >> correct that >>> cpim is unwieldy for this purpose. >>> >>> The use case I think we have in mind is, you have a text conference >>> where each participant has an independent MSRP session with the >>> conference focus. The focus acts as a reflector, forwarding messages >>> that come in on one participant session to each of the other >>> participants. It needs a way to tell the receiving parties which >>> participant sent the message. _How_ it determines what >> contributor ID >>> to attach to a given message is out of scope for MSRP--that problem >>> belongs to XCON. >>> >>> We had previously assumed the focus would simply wrap the inbound >>> message in a message/cpim document, and use the CPIM "from" >> field for >>> this purpose. This, however, is problematic for chunked messages, as >>> the focus would need to buffer the message until it had received all >>> the chunks, wrap the completed message in the cpim >> document, and then >>> send that message out to the other participants, possibly >> re-chunking >>> in the process. This does seem to me to be burdensome on >> the focus; it >>> would be nicer if the focus could simply forward the >> individual chunks, >>> and let the endpoints deal with re-assembling them. >>> >>> Another approach would be to have the focus force the >> endpoints to use >>> a cpim envelope. However, there may be times where the identity that >>> the focus wants to insert may be different than the >> identity that the >>> endpoint inserts. >>> >>> Therefore, I propose we add a new optional header called >>> Contributor-ID, which can carry a name-addr. Normal endpoints would >>> never insert this, but a conference focus could insert this >> header on a >>> per-chunk basis, and avoid the buffering requirement >> mentioned above. >>> >>> What do others think? Am I completely off base? >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 04:41:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27834; Fri, 13 Aug 2004 04:41:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvXhn-0001Q9-FK; Fri, 13 Aug 2004 04:46:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvXae-0004qt-ED; Fri, 13 Aug 2004 04:39:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvXWq-00042o-9h for simple@megatron.ietf.org; Fri, 13 Aug 2004 04:35:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27478 for ; Fri, 13 Aug 2004 04:35:10 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvXbx-0001Ic-IS for simple@ietf.org; Fri, 13 Aug 2004 04:40:30 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7D8Z8307065 for ; Fri, 13 Aug 2004 11:35:08 +0300 (EET DST) X-Scanned: Fri, 13 Aug 2004 11:35:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7D8Z67O013531 for ; Fri, 13 Aug 2004 11:35:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00WCw3mh; Fri, 13 Aug 2004 11:35:05 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7D8Z4n15672 for ; Fri, 13 Aug 2004 11:35:04 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 13 Aug 2004 11:35:03 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 13 Aug 2004 11:35:04 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEC1A@esebe019.ntc.nokia.com> Thread-Topic: IETF 60 SIMPLE WG Proceedings thread-index: AcSBEG2zvf20bdgXRJG6kMPe7VQFow== To: X-OriginalArrivalTime: 13 Aug 2004 08:35:03.0569 (UTC) FILETIME=[6DDA2810:01C48110] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: quoted-printable Subject: [Simple] IETF 60 SIMPLE WG Proceedings X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable You can find the proceedings at: http://www.softarmor.com/simple/meets/ietf60/proceedings/ Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 05:57:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01932; Fri, 13 Aug 2004 05:57:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvYts-0002hn-Fa; Fri, 13 Aug 2004 06:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvYiU-00075d-Lu; Fri, 13 Aug 2004 05:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvYgw-0006dQ-Bi for simple@megatron.ietf.org; Fri, 13 Aug 2004 05:49:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01331 for ; Fri, 13 Aug 2004 05:49:39 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvYm1-0002Wf-Pr for simple@ietf.org; Fri, 13 Aug 2004 05:55:01 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i7D9nX0T032223; Fri, 13 Aug 2004 11:49:34 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i7D9mwNW016912; Fri, 13 Aug 2004 11:49:08 +0200 Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i7D9mlU9018735; Fri, 13 Aug 2004 11:48:58 +0200 Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 13 Aug 2004 11:48:46 +0200 Message-ID: From: Schmidt Christian To: "'Robert Sparks'" , simple@ietf.org Subject: AW: [Simple] Please comment: Do we want to take on partial public ation? Date: Fri, 13 Aug 2004 11:48:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: "'aki.niemi@nokia.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Hi Robert,=20 mobile networks are always interested in increasing efficiency. = Requirements for Presence Service in 3GPP Wireless Systems = (draft-kiss-simple-presence-wireless-reqs-03) contains: PUBL-REQ2: Partial publishing The publish mechanism must allow a PUA to change only part of the = presentity's presence information. For example, a PUA must be = able to publish one single element of the presentity's PIDF = document, while the document contains several elements. So, in general, I am interested in this work. Nevertheless, some = information, concerning the possible increase in efficiency could be = helpful for motivation. Two short comments to the current version of the draft. Section 4.2. ".. the PUA MUST NOT change the content type between full and partial = event state publications." is somehow in contradiction to Section 4.3. exceptional cases: "In case = the PUA changes the content type..." In Section 4.2 it is mentioned: "When a presence user agent decides to use the partial publication = machanism.." What could be the basis for this decision? Keep in mind, that in case, = the PA do not support partial publication, this decision could even = decrease efficiency (fallback to full publication). Best Regards, Christian Schmidt -----Urspr=FCngliche Nachricht----- Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im = Auftrag von Robert Sparks Gesendet: Donnerstag, 12. August 2004 22:06 An: simple@ietf.org Betreff: [Simple] Please comment: Do we want to take on partial = publication? Folks - If you haven't already read it, please take a moment and skim http://www.ietf.org/internet-drafts/draft-lonnfors-simple-partial-publis= h-01.txt We've had _very_ light list discussion on this draft. We talked about it briefly at the interim in Boston, but it wasn't clear that there was sufficient interest even in that room. The primary question in that meeting was whether or not we could meet the requirements this draft intends without doing any additional standardization work (by having endpoints that want to publish pieces act as one publisher per piece). So speak up. Do you think this is a place SIMPLE needs to take on more work? Who thinks we have a good enough solution for this already? Who, in addition to the authors of this draft, is willing to spend time working on this problem? Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 10:07:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17467; Fri, 13 Aug 2004 10:07:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvcnC-0007Mv-L1; Fri, 13 Aug 2004 10:12:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvcg3-0003ks-Qi; Fri, 13 Aug 2004 10:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvcd6-0001dV-3A for simple@megatron.ietf.org; Fri, 13 Aug 2004 10:02:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16829 for ; Fri, 13 Aug 2004 10:01:57 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvciG-0007Go-0K for simple@ietf.org; Fri, 13 Aug 2004 10:07:21 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DE1uB28295 for ; Fri, 13 Aug 2004 17:01:56 +0300 (EET DST) X-Scanned: Fri, 13 Aug 2004 17:01:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7DE1W75005518 for ; Fri, 13 Aug 2004 17:01:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Am7L3h; Fri, 13 Aug 2004 17:01:30 EEST Received: from [172.21.40.110] (xitami.research.nokia.com [172.21.40.110]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7DE1Uu08116 for ; Fri, 13 Aug 2004 17:01:30 +0300 (EET DST) From: Jari Urpalainen To: simple@ietf.org Content-Type: text/plain Message-Id: <1092405632.3325.43.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 13 Aug 2004 17:00:32 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Simple] [XCAP] partial append and ETag X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi ! While there was an agreement to send the document ETag in the response body of partial delete there's still an annoying (to me at least) thing in the partial append that you may loose sync there too when multiple clients edit the same document. As you can't do a conditional append/insert I'll propose that the server would return the document ETag before the append in the body of 201 response. With this information the client will know whether the resource has been changed by another request. As in partial delete the client would send the Accept:-header. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 14:32:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03674; Fri, 13 Aug 2004 14:32:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvgwW-0003gW-Ue; Fri, 13 Aug 2004 14:38:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvgnp-0005Pi-4y; Fri, 13 Aug 2004 14:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvgdV-0003g5-4N for simple@megatron.ietf.org; Fri, 13 Aug 2004 14:18:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02981 for ; Fri, 13 Aug 2004 14:18:39 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvgih-0003RF-Br for simple@ietf.org; Fri, 13 Aug 2004 14:24:05 -0400 Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i7DIINeE014469; Fri, 13 Aug 2004 14:18:24 -0400 (EDT) Message-ID: <411D05D4.1070104@dynamicsoft.com> Date: Fri, 13 Aug 2004 14:17:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] XCAP URI Scheme? References: <1092231389.7335.92.camel@hed039-226.research.nokia.com> In-Reply-To: <1092231389.7335.92.camel@hed039-226.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit I do not think we should define a different URI scheme for XCAP. An XCAP resource *is* an HTTP resource. If you got an HTTP URI in a context in which you didnt understand what to do with it, performing a GET does the right thing - it gets the content. The problem you are worried about is that there is context above HTTP, in knowing that the resource you are getting has some specific meaning - its a buddy list, or a CPCP document. You have this kind of issue with any http content that is processed by an automata, as opposed to a human. I think that, generally, the context is provided by the application that passes around the URI. That is, if a phone has a configuration profile that tells it to follow a certain URI to get its buddy list, then the fact that the URI is coming from a specific field in the configuration provides the context. -Jonathan R. Aki Niemi wrote: > Hi All, > > This came up in the past in terms of whether or not XCAP is a new > protocol based on HTTP or not. I think we are clearly talking about > HTTP, but there is I think another aspect to this. > > Where a new xcap URI scheme would be very beneficial would be in guiding > a non-XCAP application in deciding which application to dispatch for the > URI. For example, if included in a web page, or email message, with an > xcap URI the client could be configured to dispatch an XCAP client > instead of the default for http, which is usually just a web browser. > GETs would still (kind of) work without an xcap URI, but in order to do > anything more elaborate, the client really needs to understand XCAP. (in > fact, there would need to be even a second level of dispatch based on > AUID, but that's a separate issue.) > > The schema really would be just for this purpose of dispatching, and > abstract in a sense, since the XCAP client would handle the URI simply > by replacing the "xcap:" with "http:". > > Having said that, I don't know how well such a thing would merit > defining a new URI scheme. It also seems that the process for defining > new URI schemes is not the most straight forward - even though in this > case the actual definition would be a trivial one. > > Thoughts? > > Cheers, > AKi > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 14:37:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03999; Fri, 13 Aug 2004 14:37:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvh0U-0003lR-9n; Fri, 13 Aug 2004 14:42:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvgoV-0005c8-Ah; Fri, 13 Aug 2004 14:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvghs-00045a-5p for simple@megatron.ietf.org; Fri, 13 Aug 2004 14:23:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03278 for ; Fri, 13 Aug 2004 14:23:10 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvgn3-0003XR-FM for simple@ietf.org; Fri, 13 Aug 2004 14:28:36 -0400 Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7DIMv17089188 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 Aug 2004 13:22:58 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Fri, 13 Aug 2004 13:23:02 -0500 To: "Orit Levin" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit Cc: Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: 7bit On Aug 11, 2004, at 6:05 PM, Orit Levin wrote: > XCON is an application protocol to control conferences and (indirectly) > "mixers". I am not advocating discussing (and supporting) XCON or any > other advanced conferencing design as a part of MSRP :-) Not at all! > > I am saying that MSRP must have the basic hooks (as all other media > protocols have today) for allowing various conferencing designs to > happen and without requiring participants to support special extensions > in order to be invited to or dial-into a conference. This is the basic > SIPPING conferencing requirements which are possible with all other > media. > > We could say that all MSRP clients MUST always be prepared to receive > CPIM as a part of the core MSRP. That is even when no end-to-end > security is being used. I think that it is a complete misuse of CPIM. > We already have a MUST SUPPORT requirement for CPIM, to allow interoperability with other cpim compliant IM protocols. For the same reason, we also have a mechanism that allows an endpoint to require the peer to always use CPIM. > When you need or willing to use the end-to-end security, in addition to > using CPIM - you will do many other security related steps. Binding it > with simple conferencing under the claim that it makes the > implementations/architecture easer - doesn't sound reasonable to me. I > am afraid it is exactly the opposite: > > Focus/mixer and end-to-end security don't live very well together and > using the same header for both - is a certain recipe for big troubles. > > In some scenarios foci and GWs will have the dilemma of double wrapping > the data vs. aggregating the CPIM information: one as being received > from a participant and the other for e-to-e security purposes... and > this is just the tip of the iceberg. > Although the primary motivation behind cpim is to allow end-to-end security, it also works well for delivering identity information. I think this is a good thing, as it fits with the IETF philosopy of coming up with a few primatives on which many applications can be built, rather than a separate mechanism for each application. (Consider why SIP has a REFER method, rather than a TRANSFER method.) I am not convinced that the double identity assertion problem does not exist even without the use of a cpim gateway, and therefore will also exist with a source identity header. > Orit. > > > > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Wednesday, August 11, 2004 3:05 PM > To: Orit Levin > Cc: ext Ben Campbell; SIMPLE WG > Subject: RE: [Simple] MSRP: Contributor ID > > On Wed, 2004-08-11 at 20:10, ext Orit Levin wrote: >> BTW the "whisper" functionality, according to XCON design, is being >> achieved very differently from what Aki envisions. The message is >> supposed to be "routed" based on the media policy kept in the media >> policy server - not as a result of a participant inserting the "final >> destination" information in one of the headers of a media/data stream. > > Uh... This has been discussed at length in the past, and I do wonder > why > people insist on this idea of requiring media policy manipulation in > order to do a simple thing like send a private message. > > In any case, media policy alone still wouldn't solve the whole problem. > How would the recipient know that the received message was private and > not sent to all of the participants? > > Anyway, I thought what I described *was* the XCON design - at least > that's what the conclusion we arrived somewhere around Seoul was. I > agree there is some configuration present in the media policy that then > allows temporary changes to happen in the mixing of an IM conference. > But those changes would be brought upon by something signaled in-band > in > the media stream, e.g., using the CPIM To header. > > Cheers, > Aki > >> Cheers, >> Orit. >> >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf >> Of Aki Niemi >> Sent: Wednesday, August 11, 2004 8:34 AM >> To: ext Ben Campbell >> Cc: SIMPLE WG >> Subject: Re: [Simple] MSRP: Contributor ID >> >> Hi, >> >> IMO, there are two things CPIM is needed for in a conferencing > scenario: >> >> 1 - In your use case below, for a focus-inserted "asserted" identity >> identifying the sender of the message >> >> 2 - For routing purposes, in order to route messages based on who the >> messages were addressed to. This is to enable whispering within a >> conference (i.e., sending a certain message not to the entire >> conference, but to one or a few of the participants). This has been >> discussed before at length. >> >> Clearly, CPIM (ugly as it may be) can be made to handle both of these >> needs. Contributor-ID will only cover the first one - unless of course >> we also add "Recipient-ID" and "Recipient-of-Carbon-Copy-ID", inserted >> by the client, to cover the second need. >> >> Cheers, >> Aki >> >> >> On Mon, 2004-08-09 at 18:27, ext Ben Campbell wrote: >>> Hi, >>> >>> In last week's SIMPLE meeting, Orit brought up an issue about how we > >>> planned to identify contributors when MSRP is used with a conference > >>> focus. Previously, we had discussed using message/cpim wrappers for >>> this purpose. >>> >>> After thinking through the use case, I think Orit may be correct > that >>> cpim is unwieldy for this purpose. >>> >>> The use case I think we have in mind is, you have a text conference >>> where each participant has an independent MSRP session with the >>> conference focus. The focus acts as a reflector, forwarding messages > >>> that come in on one participant session to each of the other >>> participants. It needs a way to tell the receiving parties which >>> participant sent the message. _How_ it determines what contributor > ID >>> to attach to a given message is out of scope for MSRP--that problem >>> belongs to XCON. >>> >>> We had previously assumed the focus would simply wrap the inbound >>> message in a message/cpim document, and use the CPIM "from" field > for >>> this purpose. This, however, is problematic for chunked messages, as > >>> the focus would need to buffer the message until it had received all > >>> the chunks, wrap the completed message in the cpim document, and > then >>> send that message out to the other participants, possibly > re-chunking >>> in the process. This does seem to me to be burdensome on the focus; > it >> >>> would be nicer if the focus could simply forward the individual >> chunks, >>> and let the endpoints deal with re-assembling them. >>> >>> Another approach would be to have the focus force the endpoints to > use >> >>> a cpim envelope. However, there may be times where the identity that > >>> the focus wants to insert may be different than the identity that > the >>> endpoint inserts. >>> >>> Therefore, I propose we add a new optional header called >>> Contributor-ID, which can carry a name-addr. Normal endpoints would >>> never insert this, but a conference focus could insert this header > on >> a >>> per-chunk basis, and avoid the buffering requirement mentioned > above. >>> >>> What do others think? Am I completely off base? >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 14:53:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05057; Fri, 13 Aug 2004 14:53:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvhG6-00046C-Fk; Fri, 13 Aug 2004 14:58:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvgyS-0007Uk-6W; Fri, 13 Aug 2004 14:40:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvgv9-0006dL-7o for simple@megatron.ietf.org; Fri, 13 Aug 2004 14:36:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03994 for ; Fri, 13 Aug 2004 14:36:53 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvh0J-0003kq-Fm for simple@ietf.org; Fri, 13 Aug 2004 14:42:19 -0400 Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7DIYS9Y090140 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 Aug 2004 13:34:29 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7023EEC15@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7023EEC15@esebe019.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6C721C52-ED57-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Fri, 13 Aug 2004 13:34:34 -0500 To: X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, rohan@cisco.com, oritl@microsoft.com, adam@dynamicsoft.com, rsparks@dynamicsoft.com, pkyzivat@cisco.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit It does not seem like we are converging on a consensus here. Let me back up a level: I think we have one high-level decision to make before we can decide on the details. That is, how much effort do we intend to put into making sure that the MSRP core spec can support all likely conference scenarios? The working group's previous consensus was to simply say that, if you need to carry this sort of information, use CPIM. We did not discuss questions about whether the sender uses cpim, or a focus wraps received messages in cpim before sending them out, etc. We did not discuss situations where different nodes have different ideas about what identity should be used. The opposite extreme would be to make an effort to define all the conferencing use-cases we care about, and choose the mechanism that best fits. Now, this may be a good thing to do, but it would once again be a case of delaying the completion of MSRP because we decided to add significant new requirements at the last minute. A middle ground would be to consider one or two very simple use cases, such as a single-focus, and maybe a single-focus where at least participant is crossing a cpim gateway from another protocol. So, can we reach a consensus about which of these three approaches to take? Personally, I think lack of consensus on this point means we do nothing. Do the chairs have an opinion? On Aug 12, 2004, at 9:51 AM, wrote: > That's definitely conference policy and is outside the scope of MSRP. > > /Hisham > >> -----Original Message----- >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 12.August.2004 03:55 >> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >> Orit Levin; >> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat >> Cc: simple@ietf.org >> Subject: Re: [Simple] MSRP: Contributor ID >> >> >> >> Sounds like a reasonable idea to me. I think we would want to >> add that if >> the user had requested Privacy either via the privacy header >> or setting From >> to Anonymous then the contributor id should not be revealed >> here. Even if >> the user authenticated via pins or something, the identity >> should not be >> revealed here if the original call was private. >> >> >> On 8/9/04 11:27 AM, "Ben Campbell" wrote: >> >>> Hi, >>> >>> In last week's SIMPLE meeting, Orit brought up an issue about how we >>> planned to identify contributors when MSRP is used with a conference >>> focus. Previously, we had discussed using message/cpim wrappers for >>> this purpose. >>> >>> After thinking through the use case, I think Orit may be >> correct that >>> cpim is unwieldy for this purpose. >>> >>> The use case I think we have in mind is, you have a text conference >>> where each participant has an independent MSRP session with the >>> conference focus. The focus acts as a reflector, forwarding messages >>> that come in on one participant session to each of the other >>> participants. It needs a way to tell the receiving parties which >>> participant sent the message. _How_ it determines what >> contributor ID >>> to attach to a given message is out of scope for MSRP--that problem >>> belongs to XCON. >>> >>> We had previously assumed the focus would simply wrap the inbound >>> message in a message/cpim document, and use the CPIM "from" >> field for >>> this purpose. This, however, is problematic for chunked messages, as >>> the focus would need to buffer the message until it had received all >>> the chunks, wrap the completed message in the cpim >> document, and then >>> send that message out to the other participants, possibly >> re-chunking >>> in the process. This does seem to me to be burdensome on >> the focus; it >>> would be nicer if the focus could simply forward the >> individual chunks, >>> and let the endpoints deal with re-assembling them. >>> >>> Another approach would be to have the focus force the >> endpoints to use >>> a cpim envelope. However, there may be times where the identity that >>> the focus wants to insert may be different than the >> identity that the >>> endpoint inserts. >>> >>> Therefore, I propose we add a new optional header called >>> Contributor-ID, which can carry a name-addr. Normal endpoints would >>> never insert this, but a conference focus could insert this >> header on a >>> per-chunk basis, and avoid the buffering requirement >> mentioned above. >>> >>> What do others think? Am I completely off base? >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 17:17:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18725; Fri, 13 Aug 2004 17:17:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvjVP-0008I1-Ba; Fri, 13 Aug 2004 17:22:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvjOm-0000ZU-IM; Fri, 13 Aug 2004 17:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvjJN-0007ld-O2 for simple@megatron.ietf.org; Fri, 13 Aug 2004 17:10:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18409 for ; Fri, 13 Aug 2004 17:10:02 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvjOb-0008Bt-IG for simple@ietf.org; Fri, 13 Aug 2004 17:15:31 -0400 Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 6C380154009; Fri, 13 Aug 2004 21:10:01 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Jonathan Rosenberg Subject: Re: [Simple] XCAP URI Scheme? References: <1092231389.7335.92.camel@hed039-226.research.nokia.com> <411D05D4.1070104@dynamicsoft.com> In-Reply-To: <411D05D4.1070104@dynamicsoft.com> Message-ID: <20040813210942.16884.91673.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 13 Aug 2004 22:09:42 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Fri Aug 13 19:17:56 2004, Jonathan Rosenberg wrote: > I do not think we should define a different URI scheme for XCAP. > > An XCAP resource *is* an HTTP resource. If you got an HTTP URI in a > context in which you didnt understand what to do with it, > performing a GET does the right thing - it gets the content. > > I agree with you in as much as an XCAP resource "is a" HTTP resource, in as much as that usage is in agreement with the usual OO terminology. It's not in doubt, either - it's the reverse that isn't true, and is a problem. This is starting to become a pressing problem - it's already impossible for me to take a "web folder" (ie, WebDAV) URI and drop it in an email, expecting the user's MUA to dispatch it to the right application. It'll pick the wrong one, a web browser, usually. I was under the distinct impression this was the point of URIs. With XCAP, I entirely understand that the URI is unlikely to be used in this way except by between knowledgable users, given its limited scope. Creating new URI schemes isn't really the answer, I think - we need some other additional, backwards compatible, method for indicating it's XCAP (Or WebDAV, or any of the 37,576 protocols now built on top of HTTP). For XCAP, document fragment identifiers would work, given that they're not used for XCAP. In general, an illegal fragment identifier might be best - #? for instance. I've no idea what current applications might do with a double fragment identifier, though. Dave, _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 17:50:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20031; Fri, 13 Aug 2004 17:50:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvk1d-0000J4-D3; Fri, 13 Aug 2004 17:55:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvjuC-0006cQ-2l; Fri, 13 Aug 2004 17:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvjrq-0005rH-5P for simple@megatron.ietf.org; Fri, 13 Aug 2004 17:45:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19862 for ; Fri, 13 Aug 2004 17:45:39 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvjx4-0000Eo-K7 for simple@ietf.org; Fri, 13 Aug 2004 17:51:08 -0400 Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7DLg9f8006276 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 Aug 2004 16:42:10 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Fri, 13 Aug 2004 16:42:15 -0500 To: Hisham khartabil , Rohan Mahy , Chris Boulton , Adam Roach , Cullen Jennings , Robert Sparks X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] MSRP: Content-Type position X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit The base spec says Content-Type must be the last header. Hisham asked if we can put in some text to justify that. I am having trouble thinking of a good reason. So, can we remove that assertion completely? If not, can someone justify it? Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 18:09:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21410; Fri, 13 Aug 2004 18:09:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkKZ-0000aa-KN; Fri, 13 Aug 2004 18:15:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvk9e-0003Fl-Nk; Fri, 13 Aug 2004 18:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvk6P-0000U8-GU for simple@megatron.ietf.org; Fri, 13 Aug 2004 18:00:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20497 for ; Fri, 13 Aug 2004 18:00:42 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkBe-0000Sl-MX for simple@ietf.org; Fri, 13 Aug 2004 18:06:11 -0400 Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id B52BB154009; Fri, 13 Aug 2004 22:00:43 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: "Joel M. Halpern" Subject: Re: [Simple] XCAP as general configuration protocol. References: <5.1.0.14.0.20040812101048.0237b450@localhost> In-Reply-To: <5.1.0.14.0.20040812101048.0237b450@localhost> Message-ID: <20040813220024.21163.56634.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Fri, 13 Aug 2004 23:00:24 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Brought back on list with author's permission, uncut. This was the only reply I received, on or off list. On Thu Aug 12 15:17:42 2004, Joel M. Halpern wrote: > We are using XCAP to configure a charging and service control > device. Said device does not care about buddy lists, resource > lists, or any other SIMPLE properties. But it does use XCAP. It > uses a different AUID. > > We do full validation of configuration. In my view, accepting > configuration changes and not validating them is a mistake. The > performance impact is tiny. > > The performance impact appears to be potentially substantial - referential integrity checks aren't cheap, as far as I'm aware. My personal view is entirely in agreement with yours, I just disagree about where the validation should take place. (On the client when receiving the data, as it surely must do anyway.) But I can happily agree to disagree on this point. > We did not use an XPATH library. We used an off the shelf HTTP > server, and then wrote our own path parsing logic. (That is in > part because our underlying data representation is not XML.) > > I don't think anyone has looked very hard at whether XCAP could be > used for the problem ACAP was trying to address. At the surface, > it does look suitable. > > No, I get the impression by the huge difference between ACAP and XCAP that nobody at all before me has considered this, yet it says that the aims are largely similar in the introduction section, which is why I'm more than a little confused. I expected based on that to find a reasonable replacement. > With regard to your specific questions: > 1) Extensibility depends upon the schema of the application. If > the application schema does not allow for extensions, then there > are no vendor extensions. If every element of the scheme has an > any tag permitted, then you can do anything you want. > > Presumably that applies to standardized extensions, too - a new version of a particular AU would require an entirely new AUID? (Since, if there's no extensibility space available, replacement would be the only solution.) That suggests that clients and servers will become increasingly more complex, or else will lose interoperability. Forgive my ignorance about XML Schemas... I'm really hoping to be utterly wrong on this point. Please, somebody shoot this line of reasoning down. > 2) Each application can specify the validation (beyond schema > validation) that it chooses to perform. Some apps will have very > general schemas and no additional requirements. Some will be very > specific. > > Excellent, so I can effectively turn it off. > 3) XCAP is not designed for searching in a real sense. It is > designed for selecting elements based on known identifiers. It is > not intended as a general XML Database access methodology. > > I see - that's quite a limitation for a generalized configuration access protocol, isn't it? (Certainly IMSP appeared to suggest that personal configuration data can become very large, so retrieving the whole lot in order to search is going to be expensive, hence, as I understand it, many of the features of ACAP.) > 4) It is not expected that you can get detailed change reporting as > part of the XCAP base. However, an application could use the > xml-diff mechanism and have a tree with progressive diffs available > if that was desired. You can also subscribe for notification of > changes as they occur, if the server supports such notifications. > > Sorry, I'm desperately unfamiliar with any form of notifications across HTTP - to tell the truth, I was firmly of the belief there were no such mechanisms. It does seem worrying that reconnection, resync, etc - all operations performed quite frequently by potential clients such as MUAs, and I assume the kinds of clients SIMPLE deals with - has no solution inherent in the standard, nor, as far as I'm able to tell, an alternative method mentioned in the specification. I'm thinking particularly of, for instance, storing bookmarks in XCAP, which would require some method to track which bookmarks had been visited recently - in other words, every bookmark usage would then invalidate the entire document. That's truly terrifying. Is the quantity of personal data required for SIMPLE's use particularly small and static? > Just my personal take, > Joel > > I have to admit, at the moment, this doesn't look like an XML Configuration Access Protocol, but more like an XML validating editor running over HTTP, which seems to me to be a bit different. Useful, possibly, for SIMPLE's needs, interesting, certainly, but very limited as a general configuration access protocol. I'd be delighted to be proven wrong, as this appears to be the only replacement/successor to ACAP on the cards at the moment. Dave. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 18:13:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21970; Fri, 13 Aug 2004 18:13:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkOF-0000g1-Eh; Fri, 13 Aug 2004 18:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkGS-0006jt-4i; Fri, 13 Aug 2004 18:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkBg-00046i-6v for simple@megatron.ietf.org; Fri, 13 Aug 2004 18:06:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20944 for ; Fri, 13 Aug 2004 18:06:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkGu-0000WA-SO for simple@ietf.org; Fri, 13 Aug 2004 18:11:38 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2004 15:10:00 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7DM5ZTK018260; Fri, 13 Aug 2004 15:05:36 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWF04285; Fri, 13 Aug 2004 15:04:25 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2F4D1A20-ED75-11D8-A01A-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 13 Aug 2004 15:07:36 -0700 To: Ben Campbell X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Adam Roach , Robert Sparks , Chris Boulton , Simple WG Subject: [Simple] Re: MSRP: Content-Type position X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit I'll provide some motivational text. thx, -r On Aug 13, 2004, at 2:42 PM, Ben Campbell wrote: > The base spec says Content-Type must be the last header. Hisham asked > if we can put in some text to justify that. I am having trouble > thinking of a good reason. > > So, can we remove that assertion completely? If not, can someone > justify it? > > Thanks! > > Ben. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 18:27:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23077; Fri, 13 Aug 2004 18:27:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvkbs-0000t4-AH; Fri, 13 Aug 2004 18:33:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkV1-0004gK-9a; Fri, 13 Aug 2004 18:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkTa-0004Ma-78 for simple@megatron.ietf.org; Fri, 13 Aug 2004 18:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23001 for ; Fri, 13 Aug 2004 18:24:38 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkYo-0000rE-6E for simple@ietf.org; Fri, 13 Aug 2004 18:30:08 -0400 Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7DMNY2F009381 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 Aug 2004 17:24:29 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8E4CE61E-ED77-11D8-BB7E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP-07 ABNF issues Date: Fri, 13 Aug 2004 17:24:35 -0500 To: Pekka Pessi X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Hi, I think I have fixed 1-6. Can you point out the specific occurrences of the problem for 7? Thanks! On Aug 9, 2004, at 8:48 AM, Pekka Pessi wrote: > Hello all, > > There are a few issues related to ABNF and the text in MSRP-07. > Most of them are just nits, but.. > > 1) The protocol token and method name defintions must have explicit > base character 'x' after the '%' sign. I think this is correct > form: > > pMSRP = %x4D.53.52.50 ; MSRP in caps > > 2) There is no definition for UPALPHA or DIGIT or HT or SP or... I > presume: > > CRLF = %x0D.0A > HT = %x09 > SP = %x20 > UPALPHA = %x41-5A > LOWALPHA = %x61-7A > DIGIT = %x30-39 > ALPHANUM = LOWALPHA / UPALPHA / DIGIT > > 3) The 'header' can expand to Mime-Header. Mime-Header is not > defined anywhere. Left-over from earlier days? > > 4) The text discusses about "none" as value to Report-Failure. > However, ABNF values are "yes", "no" or "partial". > > 5) "Token" has no closing parenthesis in its expansion. > > Token definition is again different from everything else. For > example, RFC 2045 and sdp-new define "token" like this: > > token = 1*(%x21 / %xx23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / > %x5E-7E) > > 6) Speaking of token, I don't think it is a good idea to have > "token" in the MSRP URL. Using "%", for instance, is very very > confusing. Instead, transport could be defined separately as a > subset of token and unreserved: > > transport = "tcp" / ttoken > ttoken = 1*( ALPHANUM / "-" / "_" / "." / "!" / "~" / "*" / "'" ) > > 7) Only the first two examples are valid according to the ABNF. > There are extra quotation marks or whitespace is missing. > Curiously, the examples have data with a CRLF in the beginning > (two empty lines after headers) but not at the end (no empty line > before end-line). Leftover from message/cpim? > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 18:31:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23174; Fri, 13 Aug 2004 18:31:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvkf2-0000vK-GI; Fri, 13 Aug 2004 18:36:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkXs-0005Eg-OO; Fri, 13 Aug 2004 18:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkWA-0004qM-LP for simple@megatron.ietf.org; Fri, 13 Aug 2004 18:27:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23066 for ; Fri, 13 Aug 2004 18:27:19 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkbQ-0000sW-Dh for simple@ietf.org; Fri, 13 Aug 2004 18:32:48 -0400 Received: from [192.168.1.105] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7DMR7kd009668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 Aug 2004 17:27:08 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <8993B20049600A40B0AEAFD6F736C9DFC12E6C@MHAIFA.followap.com> References: <8993B20049600A40B0AEAFD6F736C9DFC12E6C@MHAIFA.followap.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Ben Campbell Subject: Re: [Simple] MSRP-07 Comments Date: Fri, 13 Aug 2004 17:27:13 -0500 To: "Sharon Fridman" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, Ben Campbell X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Thanks! I think I have these fixed. Please check the next version to=20 make sure what you saw has gone away! Thanks! Ben. On Aug 12, 2004, at 6:31 AM, Sharon Fridman wrote: > Hi! > > =A0 > > Some nits and minor comments: > > =A0 > > Section 11.1 > > Diagram misaligned in numbering with the following steps in text. > > Step 5 does not include a CRLF after the headers as indicated in=20 > Section 9. > > =A0 > > Section 11.3 > > Does not include a CRLF after the headers as indicated in Section 9. > > =A0 > > Section 11.4 > > (3rd step, above Section 11.5) Shouldn=92t it be a REPORT method and = not=20 > SEND? > > =A0 > > Section 11.5 > > REGISTER CSeq does not relate to the response CSeq. > > =A0 > > Thanks, > > Fridy (Sharon Fridman) / Followap > > =A0 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 18:44:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23845; Fri, 13 Aug 2004 18:44:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvksM-00016S-Iq; Fri, 13 Aug 2004 18:50:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvklb-0007AK-E5; Fri, 13 Aug 2004 18:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkZv-0005dU-9r for simple@megatron.ietf.org; Fri, 13 Aug 2004 18:31:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23194 for ; Fri, 13 Aug 2004 18:31:12 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvkf8-0000ux-3T for simple@ietf.org; Fri, 13 Aug 2004 18:36:41 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 13 Aug 2004 15:33:56 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7DMUVTK008799; Fri, 13 Aug 2004 15:30:31 -0700 (PDT) Received: from cisco.com ([161.44.79.234]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKV50541; Fri, 13 Aug 2004 18:30:30 -0400 (EDT) Message-ID: <411D4106.6030905@cisco.com> Date: Fri, 13 Aug 2004 18:30:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] Re: MSRP: Content-Type position References: <2F4D1A20-ED75-11D8-A01A-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > I'll provide some motivational text. > > On Aug 13, 2004, at 2:42 PM, Ben Campbell wrote: > >> The base spec says Content-Type must be the last header. Hisham asked >> if we can put in some text to justify that. I am having trouble >> thinking of a good reason. >> >> So, can we remove that assertion completely? If not, can someone >> justify it? >> >> Thanks! What is the goal here? To have the message parser stop parsing when it gets to a mime header, so you can switch to using a separate mime header parser there? If so, maybe we should allow for other mime headers as well. Maybe it would be better to have some more overt delimiter that says everything following is mime. In the case of SIP, my conceptual model is that the entire sip message is a mime entity, consisting of mime headers and extension headers (from mime point of view). Then the order doesn't matter. But to take advantage of that model you need a sip parser and a mime parser that share a representation. It would be simpler if the two parsers could be independent. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 21:43:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01390; Fri, 13 Aug 2004 21:43:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvnfk-0003UM-TT; Fri, 13 Aug 2004 21:49:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvnYf-0001GI-5H; Fri, 13 Aug 2004 21:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvnXr-000185-Bu for simple@megatron.ietf.org; Fri, 13 Aug 2004 21:41:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01058 for ; Fri, 13 Aug 2004 21:41:17 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvnd7-0003OA-QN for simple@ietf.org; Fri, 13 Aug 2004 21:46:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 13 Aug 2004 18:44:08 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7E1egep020895; Fri, 13 Aug 2004 18:40:42 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWF19250; Fri, 13 Aug 2004 18:39:32 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3C43BF1D-ED93-11D8-A01A-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] message-session-07: why responses? Date: Fri, 13 Aug 2004 18:42:43 -0700 To: Pekka Pessi X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Hi Pekka, A few things: - Certain types of errors are more appropriate to inform the requester about using a response (for example, a 403). - Responses to SEND requests are hop-by-hop instead of end-to-end like REPORT requests. This is actually used by different combinations of the current Report-Success / Report-Failure headers. - Responses to AUTH are end-to-end. We need to use responses to carry the Use-Path information in a response to an AUTH back to the MSRP Client that sent the AUTH request. Because the way the authorization works, you can't carry this information in a REPORT. You would need to send a REPORT request to a URI that the client didn't know about yet. hope this helps. thanks, -rohan On Aug 12, 2004, at 9:13 AM, Pekka Pessi wrote: > Hello all, > > The current MSRP draft now includes extensive REPORT facilities. I > wonder why we still keep the responses in the spec? > > During the discussion between Orit and rest of the world last > spring AFAIR the most compelling reason for hop-by-hop responses > is that they provide explicit keepalive functionality. When using > responses, relays have to buffer transactions only until they > receive application-level confirmation. Without response, relays > could not get any indication when the next-hop connection failed. > > Could we simply use explicit keepalive messages, say, single-hop > SEND without body with Report-Success: yes (or PING/PONG a'la IRC > or HELLO or KEEPALIVE)? An MSRP entity could send such a keepalive > request any time, and it would know that all the messages sent > before keepalive were actually received when it receives the > suitable keepalive reply request. > > Instead of error responses (like 401), we could use REPORT with > appropriate Status. > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 21:58:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01973; Fri, 13 Aug 2004 21:58:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvntZ-0003gZ-Ei; Fri, 13 Aug 2004 22:03:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvngG-0002U6-N4; Fri, 13 Aug 2004 21:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvncV-0001sP-Rh for simple@megatron.ietf.org; Fri, 13 Aug 2004 21:46:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01557 for ; Fri, 13 Aug 2004 21:46:05 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvnhl-0003WL-H1 for simple@ietf.org; Fri, 13 Aug 2004 21:51:35 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2004 18:49:56 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7E1jUep024204; Fri, 13 Aug 2004 18:45:30 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWF19461; Fri, 13 Aug 2004 18:44:21 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] MSRP-07 ABNF issues Date: Fri, 13 Aug 2004 18:47:32 -0700 To: Pekka Pessi X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit On Aug 9, 2004, at 6:48 AM, Pekka Pessi wrote: > Hello all, > > There are a few issues related to ABNF and the text in MSRP-07. > Most of them are just nits, but.. > > 1) The protocol token and method name defintions must have explicit > base character 'x' after the '%' sign. I think this is correct > form: > > pMSRP = %x4D.53.52.50 ; MSRP in caps good catch > 2) There is no definition for UPALPHA or DIGIT or HT or SP or... I > presume: > > CRLF = %x0D.0A > HT = %x09 > SP = %x20 > UPALPHA = %x41-5A > LOWALPHA = %x61-7A > DIGIT = %x30-39 > ALPHANUM = LOWALPHA / UPALPHA / DIGIT These productions are defined in the RFC that defines ABNF. We could add them for clarity, but I think They are pretty well understood. I could go either way. > 3) The 'header' can expand to Mime-Header. Mime-Header is not > defined anywhere. Left-over from earlier days? oops > 4) The text discusses about "none" as value to Report-Failure. > However, ABNF values are "yes", "no" or "partial". will make these consistent (none/no) > 5) "Token" has no closing parenthesis in its expansion. > > Token definition is again different from everything else. For > example, RFC 2045 and sdp-new define "token" like this: > > token = 1*(%x21 / %xx23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / > %x5E-7E) > > 6) Speaking of token, I don't think it is a good idea to have > "token" in the MSRP URL. Using "%", for instance, is very very > confusing. Instead, transport could be defined separately as a > subset of token and unreserved: > > transport = "tcp" / ttoken > ttoken = 1*( ALPHANUM / "-" / "_" / "." / "!" / "~" / "*" / "'" ) > > 7) Only the first two examples are valid according to the ABNF. > There are extra quotation marks or whitespace is missing. > Curiously, the examples have data with a CRLF in the beginning > (two empty lines after headers) but not at the end (no empty line > before end-line). Leftover from message/cpim? good reading. thx, -r > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 13 22:01:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02134; Fri, 13 Aug 2004 22:01:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvnx3-0003jn-8f; Fri, 13 Aug 2004 22:07:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvngH-0002UD-AE; Fri, 13 Aug 2004 21:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvndj-0001vJ-IG for simple@megatron.ietf.org; Fri, 13 Aug 2004 21:47:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01592 for ; Fri, 13 Aug 2004 21:47:21 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvnj1-0003XW-75 for simple@ietf.org; Fri, 13 Aug 2004 21:52:51 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2004 18:51:14 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7E1kfep025219; Fri, 13 Aug 2004 18:46:48 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWF19317; Fri, 13 Aug 2004 18:41:21 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7DA1959A-ED93-11D8-A01A-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] MSRP-07 and charsets Date: Fri, 13 Aug 2004 18:44:33 -0700 To: Pekka Pessi X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Hi, SIP uses the UTF-8 charset exclusively. Since all expected usages of MSRP in the foreseeable future will be signaled via SIP, I don't see requiring UTF-8 for MSRP to be a hardship. thanks, -rohan On Aug 9, 2004, at 6:41 AM, Pekka Pessi wrote: > Hello all, > > There is no mention about charsets in MSRP except for the SDP > attributes used by session setup. I think the MSRP spec was > supposed to declare UTF-8 as the default charset. A message > without a charset parameter in Content-Type would default to > UTF-8, and all the endpoints should accept messages using UTF-8. > > However, I'm afraid it will take some time before UTF-8 will be > universally available, so it might be worthwhile to negotiate the > charsets for the MSRP session. > > HTTP uses Accept-Charset header for that purpose. We could define > a accept-charset attribute. Here is a proposal based on > cut'n'paste from RFC 2616. > > --Pekka > > ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--- > > X.X.X The accept-charset attribute > > The accept-charset attribute can be used to indicate what > character sets are acceptable for the endpoint. The attribute > allows endpoints capable of understanding more special-purpose > character sets to announce their capabilities. > > accept-charset = accept-charset-label ":" charset-list > accept-charset-label = "accept-charset" > charset-list = chatset-entry *( SP charset-entry) > chatset-entry = token | "*" > > Character set values are described in [17]. > > An example is > > a=accept-charset:iso-8859-15,iso-8859-1,utf-8 > > The special value "*", if present in the accept-charset attribute, > matches every character set. Even if no "*" is present > in an accept-charset attribute, the endpoint is required to accept > UTF-8 encoded text. > > OPEN ISSUE: is this reasonable requirement? Unicode fonts may > be an overkill for very simple devices with text-only display. > > If no accept-charset attribute is present in SDP sent by the > endpoint, the default is that any character set is acceptable. If > an accept-charset attribute is present, and if the other endpoint > cannot send messages which are acceptable according to the > accept-charset attribute, then the endpoint may reject the > session. Alternatively, if the endpoint accepts the session and if > the session is set up with SIP, the endpoint may issue Warning > code 305. > > --->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--- > > ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--- > > 15.3.5 Accept Charsets > > Attribute-name: accept-charsets > Long-form Attribute Name: MSRP Charsets > Type: Media level > Subject to Charset Attribute: No > Purpose and Appropriate Values: See Section X.X.X > > --->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--- > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Aug 14 12:48:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21722; Sat, 14 Aug 2004 12:48:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bw1nc-0007Py-Jb; Sat, 14 Aug 2004 12:54:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw1gN-0006X8-Rt; Sat, 14 Aug 2004 12:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw1eg-0006Bn-To for simple@megatron.ietf.org; Sat, 14 Aug 2004 12:45:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21607 for ; Sat, 14 Aug 2004 12:45:16 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bw1k5-0007Lc-QZ for simple@ietf.org; Sat, 14 Aug 2004 12:50:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2004 12:44:46 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7EGiiCf021863; Sat, 14 Aug 2004 12:44:44 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-2-145.cisco.com [10.86.242.145]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKV70104; Sat, 14 Aug 2004 12:44:42 -0400 (EDT) Message-ID: <411E417A.1050404@cisco.com> Date: Sat, 14 Aug 2004 12:44:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] MSRP-07 ABNF issues References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > >> 2) There is no definition for UPALPHA or DIGIT or HT or SP or... I >> presume: >> >> CRLF = %x0D.0A >> HT = %x09 >> SP = %x20 >> UPALPHA = %x41-5A >> LOWALPHA = %x61-7A >> DIGIT = %x30-39 >> ALPHANUM = LOWALPHA / UPALPHA / DIGIT > > These productions are defined in the RFC that defines ABNF. We could > add them for clarity, but I think They are pretty well understood. I > could go either way. I have looked at that, and while it isn't clear to me, I think the definitions there are simply examples, as well as being used in the syntax of ABNF itself. So I think such things should be copied into other syntaxes that need them. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Aug 14 14:43:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25458; Sat, 14 Aug 2004 14:43:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bw3a3-0000Qo-Ea; Sat, 14 Aug 2004 14:48:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw3TS-0003Dk-SQ; Sat, 14 Aug 2004 14:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw3SX-00034p-7Z for simple@megatron.ietf.org; Sat, 14 Aug 2004 14:40:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25412 for ; Sat, 14 Aug 2004 14:40:51 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bw3Xx-0000On-Ul for simple@ietf.org; Sat, 14 Aug 2004 14:46:30 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sat, 14 Aug 2004 11:39:53 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Aug 2004 11:40:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Sat, 14 Aug 2004 11:40:21 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSBZIXFbxaXIgzjTZClQ8rAtI+i3QAx6NRw From: "Orit Levin" To: "Ben Campbell" , X-OriginalArrivalTime: 14 Aug 2004 18:40:45.0776 (UTC) FILETIME=[35E89D00:01C4822E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, rohan@cisco.com, adam@dynamicsoft.com, rsparks@dynamicsoft.com, pkyzivat@cisco.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Just to a add to Ben's summary, There is additional the simplest and the best (in my mind) approach: By including a "SourceID" header into MSRP, we allow for any type of conferencing architecture (and other possible applications) to handle MSRP sessions in the same way it chooses to handle RTP/RTCP sessions WITHOUT requiring MSRP specs to discuss conferencing in any details. Orit. -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Friday, August 13, 2004 11:35 AM To: hisham.khartabil@nokia.com Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; simple@ietf.org; adam@dynamicsoft.com Subject: Re: [Simple] MSRP: Contributor ID It does not seem like we are converging on a consensus here. Let me=20 back up a level: I think we have one high-level decision to make before we can decide on=20 the details. That is, how much effort do we intend to put into making=20 sure that the MSRP core spec can support all likely conference=20 scenarios? The working group's previous consensus was to simply say that, if you=20 need to carry this sort of information, use CPIM. We did not discuss=20 questions about whether the sender uses cpim, or a focus wraps received=20 messages in cpim before sending them out, etc. We did not discuss=20 situations where different nodes have different ideas about what=20 identity should be used. The opposite extreme would be to make an effort to define all the=20 conferencing use-cases we care about, and choose the mechanism that=20 best fits. Now, this may be a good thing to do, but it would once again=20 be a case of delaying the completion of MSRP because we decided to add=20 significant new requirements at the last minute. A middle ground would be to consider one or two very simple use cases,=20 such as a single-focus, and maybe a single-focus where at least=20 participant is crossing a cpim gateway from another protocol. So, can we reach a consensus about which of these three approaches to=20 take? Personally, I think lack of consensus on this point means we do=20 nothing. Do the chairs have an opinion? On Aug 12, 2004, at 9:51 AM, wrote: > That's definitely conference policy and is outside the scope of MSRP. > > /Hisham > >> -----Original Message----- >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 12.August.2004 03:55 >> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >> Orit Levin; >> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat >> Cc: simple@ietf.org >> Subject: Re: [Simple] MSRP: Contributor ID >> >> >> >> Sounds like a reasonable idea to me. I think we would want to >> add that if >> the user had requested Privacy either via the privacy header >> or setting From >> to Anonymous then the contributor id should not be revealed >> here. Even if >> the user authenticated via pins or something, the identity >> should not be >> revealed here if the original call was private. >> >> >> On 8/9/04 11:27 AM, "Ben Campbell" wrote: >> >>> Hi, >>> >>> In last week's SIMPLE meeting, Orit brought up an issue about how we >>> planned to identify contributors when MSRP is used with a conference >>> focus. Previously, we had discussed using message/cpim wrappers for >>> this purpose. >>> >>> After thinking through the use case, I think Orit may be >> correct that >>> cpim is unwieldy for this purpose. >>> >>> The use case I think we have in mind is, you have a text conference >>> where each participant has an independent MSRP session with the >>> conference focus. The focus acts as a reflector, forwarding messages >>> that come in on one participant session to each of the other >>> participants. It needs a way to tell the receiving parties which >>> participant sent the message. _How_ it determines what >> contributor ID >>> to attach to a given message is out of scope for MSRP--that problem >>> belongs to XCON. >>> >>> We had previously assumed the focus would simply wrap the inbound >>> message in a message/cpim document, and use the CPIM "from" >> field for >>> this purpose. This, however, is problematic for chunked messages, as >>> the focus would need to buffer the message until it had received all >>> the chunks, wrap the completed message in the cpim >> document, and then >>> send that message out to the other participants, possibly >> re-chunking >>> in the process. This does seem to me to be burdensome on >> the focus; it >>> would be nicer if the focus could simply forward the >> individual chunks, >>> and let the endpoints deal with re-assembling them. >>> >>> Another approach would be to have the focus force the >> endpoints to use >>> a cpim envelope. However, there may be times where the identity that >>> the focus wants to insert may be different than the >> identity that the >>> endpoint inserts. >>> >>> Therefore, I propose we add a new optional header called >>> Contributor-ID, which can carry a name-addr. Normal endpoints would >>> never insert this, but a conference focus could insert this >> header on a >>> per-chunk basis, and avoid the buffering requirement >> mentioned above. >>> >>> What do others think? Am I completely off base? >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 04:09:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16038; Mon, 16 Aug 2004 04:09:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwcdx-0004DG-CJ; Mon, 16 Aug 2004 04:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwcSP-0002Uc-5w; Mon, 16 Aug 2004 04:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwcLx-0001gv-9W for simple@megatron.ietf.org; Mon, 16 Aug 2004 03:56:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15345 for ; Mon, 16 Aug 2004 03:56:22 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwcRg-00040i-5U for simple@ietf.org; Mon, 16 Aug 2004 04:02:21 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7G7uCv14249; Mon, 16 Aug 2004 10:56:12 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 10:55:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7G7tqXM016260; Mon, 16 Aug 2004 10:55:52 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00oiHTDx; Mon, 16 Aug 2004 10:55:50 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7G7tju24586; Mon, 16 Aug 2004 10:55:45 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 10:55:32 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 16 Aug 2004 10:55:25 +0300 Subject: Re: [Simple] XCAP URI Scheme? From: Aki Niemi To: ext Jonathan Rosenberg In-Reply-To: <411D05D4.1070104@dynamicsoft.com> References: <1092231389.7335.92.camel@hed039-226.research.nokia.com> <411D05D4.1070104@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092642924.19721.12.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 16 Aug 2004 10:55:25 +0300 X-OriginalArrivalTime: 16 Aug 2004 07:55:32.0831 (UTC) FILETIME=[68057EF0:01C48366] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit On Fri, 2004-08-13 at 21:17, ext Jonathan Rosenberg wrote: > I do not think we should define a different URI scheme for XCAP. > > An XCAP resource *is* an HTTP resource. If you got an HTTP URI in a > context in which you didnt understand what to do with it, performing a > GET does the right thing - it gets the content. > > The problem you are worried about is that there is context above HTTP, > in knowing that the resource you are getting has some specific meaning - > its a buddy list, or a CPCP document. You have this kind of issue with > any http content that is processed by an automata, as opposed to a > human. I think that, generally, the context is provided by the > application that passes around the URI. That is, if a phone has a > configuration profile that tells it to follow a certain URI to get its > buddy list, then the fact that the URI is coming from a specific field > in the configuration provides the context. Yes, this is fine as long as the URI comes with a specific context, as in part of configuration information. For many XCAP AUs (like the buddy list) this is the norm, but imagine a web page that contains information about a conference bridge. Standard HTML markup like this: Conference Policy will not give enough of a context for the browser to do the right thing were a user to click this link. Conference Policy" then again would. It could dispatch an XCAP client instead of just displaying the XML file that a GET to this link would return. Cheers, Aki > -Jonathan R. > > > > Aki Niemi wrote: > > > Hi All, > > > > This came up in the past in terms of whether or not XCAP is a new > > protocol based on HTTP or not. I think we are clearly talking about > > HTTP, but there is I think another aspect to this. > > > > Where a new xcap URI scheme would be very beneficial would be in guiding > > a non-XCAP application in deciding which application to dispatch for the > > URI. For example, if included in a web page, or email message, with an > > xcap URI the client could be configured to dispatch an XCAP client > > instead of the default for http, which is usually just a web browser. > > GETs would still (kind of) work without an xcap URI, but in order to do > > anything more elaborate, the client really needs to understand XCAP. (in > > fact, there would need to be even a second level of dispatch based on > > AUID, but that's a separate issue.) > > > > The schema really would be just for this purpose of dispatching, and > > abstract in a sense, since the XCAP client would handle the URI simply > > by replacing the "xcap:" with "http:". > > > > Having said that, I don't know how well such a thing would merit > > defining a new URI scheme. It also seems that the process for defining > > new URI schemes is not the most straight forward - even though in this > > case the actual definition would be a trivial one. > > > > Thoughts? > > > > Cheers, > > AKi > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 05:47:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22113; Mon, 16 Aug 2004 05:47:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BweB9-00066R-C8; Mon, 16 Aug 2004 05:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwdqd-0000PZ-95; Mon, 16 Aug 2004 05:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwdjj-0005SJ-Jg for simple@megatron.ietf.org; Mon, 16 Aug 2004 05:25:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20940 for ; Mon, 16 Aug 2004 05:25:01 -0400 (EDT) From: mikko.lonnfors@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwdpR-0005hr-Pq for simple@ietf.org; Mon, 16 Aug 2004 05:31:01 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7G9OY313364; Mon, 16 Aug 2004 12:24:34 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 12:24:08 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7G9O8XW011612; Mon, 16 Aug 2004 12:24:08 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 004tljac; Mon, 16 Aug 2004 12:24:07 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7G9O2u22412; Mon, 16 Aug 2004 12:24:02 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 12:23:48 +0300 Received: from esebe051.NOE.Nokia.com ([172.21.138.215]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 12:23:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Please comment: Do we want to take on partial publication? Date: Mon, 16 Aug 2004 12:23:37 +0300 Message-ID: Thread-Topic: [Simple] Please comment: Do we want to take on partial publication? Thread-Index: AcSBHa5wLOB7NqVFQV2vGIQNwYGYUQAQB3vw To: , , X-OriginalArrivalTime: 16 Aug 2004 09:23:39.0015 (UTC) FILETIME=[B6D52970:01C48372] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: aki.niemi@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Hi, Inline: >=20 > Hi Robert, >=20 > mobile networks are always interested in increasing > efficiency. Requirements for Presence Service in 3GPP=20 > Wireless Systems=20 > (draft-kiss-simple-presence-wireless-reqs-03) contains: > PUBL-REQ2: Partial publishing > The publish mechanism must allow a PUA to change only part of=20 > the presentity's presence information. For example, a =20 > PUA must be able to publish one single element of the=20 > presentity's PIDF document, while the document contains=20 > several elements. >=20 > So, in general, I am interested in this work. Nevertheless, > some information, concerning the possible increase in=20 > efficiency could be helpful for motivation. >=20 > Two short comments to the current version of the draft. >=20 > Section 4.2. > ".. the PUA MUST NOT change the content type between full and > partial event state publications." >=20 > is somehow in contradiction to Section 4.3. exceptional > cases: "In case the PUA changes the content type..." The intention in section 4.2 is to say that if PUA wants to send a = partial event state it must provide full event state using = 'application/pidf-partial+xml' before it can send partial state. This = will be fixed if we decide to move this work forward. =20 >=20 > In Section 4.2 it is mentioned: > "When a presence user agent decides to use the partial > publication machanism.." What could be the basis for this=20 > decision? Keep in mind, that in case, the PA do not support=20 > partial publication, this decision could even decrease=20 > efficiency (fallback to full publication). One option is to use OPTIONS. Decision can be based on local policy or = device configuration. I don't think that loss of one request is really a = problem here because it should happen only once before device knows that = PA doesn't support partial publications. - Mikko =20 > Best Regards, > Christian Schmidt >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > Im Auftrag von Robert Sparks > Gesendet: Donnerstag, 12. August 2004 22:06 > An: simple@ietf.org > Betreff: [Simple] Please comment: Do we want to take on=20 > partial publication? >=20 >=20 > Folks - >=20 > If you haven't already read it, please take a moment and > skim > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part ial-publish-01.txt We've had _very_ light list discussion on this draft. We talked about it = briefly at the interim in Boston, but it wasn't clear that there was = sufficient interest even in that room. The primary question in that meeting was whether or not we could meet = the requirements this draft intends without doing any additional = standardization work (by having endpoints that want to publish pieces = act as one publisher per piece). So speak up. Do you think this is a place SIMPLE needs to take on more = work? Who thinks we have a good enough solution for this already? Who, = in addition to the authors of this draft, is willing to spend time = working on this problem? Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 09:53:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04456; Mon, 16 Aug 2004 09:53:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwi0u-0001fy-3f; Mon, 16 Aug 2004 09:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwhuL-0000H6-DP; Mon, 16 Aug 2004 09:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwhqI-00082M-FF for simple@megatron.ietf.org; Mon, 16 Aug 2004 09:48:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04194 for ; Mon, 16 Aug 2004 09:48:04 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwhw2-0001b5-AT for simple@ietf.org; Mon, 16 Aug 2004 09:54:06 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GDlu328207; Mon, 16 Aug 2004 16:47:56 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 16:47:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7GDlWJE021801; Mon, 16 Aug 2004 16:47:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00nFxSq0; Mon, 16 Aug 2004 16:47:32 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GDlWu07386; Mon, 16 Aug 2004 16:47:32 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 16:26:40 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 16:26:39 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 16 Aug 2004 16:26:39 +0300 Subject: Re: [Simple] XCAP URI Scheme? From: Aki Niemi To: ext Dave Cridland In-Reply-To: <20040813210942.16884.91673.polymer@peirce.gestalt.entity.net> References: <1092231389.7335.92.camel@hed039-226.research.nokia.com> <411D05D4.1070104@dynamicsoft.com> <20040813210942.16884.91673.polymer@peirce.gestalt.entity.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092662798.26829.43.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 16 Aug 2004 16:26:38 +0300 X-OriginalArrivalTime: 16 Aug 2004 13:26:39.0475 (UTC) FILETIME=[A976CC30:01C48394] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit On Sat, 2004-08-14 at 00:09, ext Dave Cridland wrote: > Creating new URI schemes isn't really the answer, I think - we need > some other additional, backwards compatible, method for indicating > it's XCAP (Or WebDAV, or any of the 37,576 protocols now built on top > of HTTP). For XCAP, document fragment identifiers would work, given > that they're not used for XCAP. In general, an illegal fragment > identifier might be best - #? for instance. I've no idea what current > applications might do with a double fragment identifier, though. Perhaps you're right about the new URI scheme - I'm open to any solution that works. However, I don't think fragment identifiers would work, since AFAIK, they are supposed to be interpreted only *after* document retrieval, which is already too late. Of course the MIME type of the XCAP resource (e.g., application/resource-list+xml) already serves as an identifier, but there is no guarantee that in the absence of a configured helper application for such a MIME type, the browser wouldn't simply render the XML to the user. In fact, I think it even SHOULD. Compared to not doing anything at all when a user clicks the link, I think this would be worse user experience. Not by far, but still... Cheers, Aki > Dave, > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 11:13:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10130; Mon, 16 Aug 2004 11:13:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwjGi-0002zL-KK; Mon, 16 Aug 2004 11:19:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwj4Q-0000t5-03; Mon, 16 Aug 2004 11:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwj10-0000O7-51 for simple@megatron.ietf.org; Mon, 16 Aug 2004 11:03:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09352 for ; Mon, 16 Aug 2004 11:03:09 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwj6k-0002p9-Ux for simple@ietf.org; Mon, 16 Aug 2004 11:09:12 -0400 Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id D2B2D154009; Mon, 16 Aug 2004 15:03:05 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Aki Niemi Subject: Re: [Simple] XCAP URI Scheme? References: <1092231389.7335.92.camel@hed039-226.research.nokia.com> <411D05D4.1070104@dynamicsoft.com> <20040813210942.16884.91673.polymer@peirce.gestalt.entity.net> <1092662798.26829.43.camel@hed039-226.research.nokia.com> In-Reply-To: <1092662798.26829.43.camel@hed039-226.research.nokia.com> Message-ID: <20040816150240.21703.98411.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Mon, 16 Aug 2004 16:02:40 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Jonathan Rosenberg , SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 On Mon Aug 16 14:26:38 2004, Aki Niemi wrote: > On Sat, 2004-08-14 at 00:09, ext Dave Cridland wrote: > > Creating new URI schemes isn't really the answer, I think - we > need > some other additional, backwards compatible, method for > indicating > it's XCAP (Or WebDAV, or any of the 37,576 protocols > now built on top > of HTTP). For XCAP, document fragment > identifiers would work, given > that they're not used for XCAP. In > general, an illegal fragment > identifier might be best - #? for > instance. I've no idea what current > applications might do with a > double fragment identifier, though. > > Perhaps you're right about the new URI scheme - I'm open to any > solution > that works. However, I don't think fragment identifiers would work, > since AFAIK, they are supposed to be interpreted only *after* > document > retrieval, which is already too late. > > Emphasis on "supposed to be". The nice thing about fragment identifiers is that they're not sent to the HTTP server, so they'd remain backwards compatible. The nasty thing is that it's an unashamed hack. FWIW, those clients I've tested ignore a double-fragment, so it's a technically feasable hack with few ill-effects. > Of course the MIME type of the XCAP resource (e.g., > application/resource-list+xml) already serves as an identifier, but > there is no guarantee that in the absence of a configured helper > application for such a MIME type, the browser wouldn't simply > render the > XML to the user. In fact, I think it even SHOULD. Compared to not > doing > anything at all when a user clicks the link, I think this would be > worse > user experience. Not by far, but still... > > I agree, but: a) A useful property of protocols based on HTTP is that they behave like HTTP, because they are. Pretend, for a moment, that XCAP could be used to handle configuration such as bookmarks. [I'm not yet convinced it's suitable, but it makes for a nice example.] It'd be possible, and quite fun, to have an XCAP URI (Or rather, 'http' scheme URI to an XCAP server), which returned the XML fragment containing bookmark data, with a stylesheet PI directing a typical web browser to render the XML fragment as a web page with links, as in a typical "links" page. b) By the time you've got the MIME type, that's also too late to do anything useful with an XCAP server, since the more useful property for dispatching is the URI, not the data you get back. Therefore a dispatch must operate on the URI rather than the MIME type returned. Whatever the case, I do think that this problem does exist, and is also outside the scope of this WG. It's purely a problem created by the heavy overloading that HTTP has received. Dave. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 12:02:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12831; Mon, 16 Aug 2004 12:02:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwk1t-0003n3-UJ; Mon, 16 Aug 2004 12:08:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwjtf-0008CC-80; Mon, 16 Aug 2004 11:59:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwjs9-0007yJ-8A for simple@megatron.ietf.org; Mon, 16 Aug 2004 11:58:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12656 for ; Mon, 16 Aug 2004 11:58:06 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwjxy-0003jx-GK for simple@ietf.org; Mon, 16 Aug 2004 12:04:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2004 12:07:16 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7GFvYCf026184; Mon, 16 Aug 2004 11:57:34 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-2-145.cisco.com [10.86.242.145]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKW21068; Mon, 16 Aug 2004 11:57:32 -0400 (EDT) Message-ID: <4120D96C.20605@cisco.com> Date: Mon, 16 Aug 2004 11:57:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin Subject: Re: [Simple] MSRP: Contributor ID References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, adam@dynamicsoft.com, rsparks@dynamicsoft.com, rohan@cisco.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Orit Levin wrote: > Just to a add to Ben's summary, > There is additional the simplest and the best (in my mind) approach: > > By including a "SourceID" header into MSRP, we allow for any type of > conferencing architecture (and other possible applications) to handle > MSRP sessions in the same way it chooses to handle RTP/RTCP sessions > WITHOUT requiring MSRP specs to discuss conferencing in any details. To pursue that philosophy, the "SourceID" should be as semantically similar as possible to that of RTP/RTCP. That would mean it should not be signed, or end to end secure, and should be be able to accomodate multiple values. I'm inclined to think we would like to do something different than that, but need to do work with the conference team to figure out what. Is there really any problem is waiting for them to figure out what they need, and then add it? Paul > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Friday, August 13, 2004 11:35 AM > To: hisham.khartabil@nokia.com > Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; > rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; > simple@ietf.org; adam@dynamicsoft.com > Subject: Re: [Simple] MSRP: Contributor ID > > It does not seem like we are converging on a consensus here. Let me > back up a level: > > I think we have one high-level decision to make before we can decide on > the details. That is, how much effort do we intend to put into making > sure that the MSRP core spec can support all likely conference > scenarios? > > The working group's previous consensus was to simply say that, if you > need to carry this sort of information, use CPIM. We did not discuss > questions about whether the sender uses cpim, or a focus wraps received > messages in cpim before sending them out, etc. We did not discuss > situations where different nodes have different ideas about what > identity should be used. > > The opposite extreme would be to make an effort to define all the > conferencing use-cases we care about, and choose the mechanism that > best fits. Now, this may be a good thing to do, but it would once again > be a case of delaying the completion of MSRP because we decided to add > significant new requirements at the last minute. > > A middle ground would be to consider one or two very simple use cases, > such as a single-focus, and maybe a single-focus where at least > participant is crossing a cpim gateway from another protocol. > > So, can we reach a consensus about which of these three approaches to > take? Personally, I think lack of consensus on this point means we do > nothing. Do the chairs have an opinion? > > > On Aug 12, 2004, at 9:51 AM, wrote: > > >>That's definitely conference policy and is outside the scope of MSRP. >> >>/Hisham >> >> >>>-----Original Message----- >>>From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>Sent: 12.August.2004 03:55 >>>To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>>Orit Levin; >>>Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat >>>Cc: simple@ietf.org >>>Subject: Re: [Simple] MSRP: Contributor ID >>> >>> >>> >>>Sounds like a reasonable idea to me. I think we would want to >>>add that if >>>the user had requested Privacy either via the privacy header >>>or setting From >>>to Anonymous then the contributor id should not be revealed >>>here. Even if >>>the user authenticated via pins or something, the identity >>>should not be >>>revealed here if the original call was private. >>> >>> >>>On 8/9/04 11:27 AM, "Ben Campbell" wrote: >>> >>> >>>>Hi, >>>> >>>>In last week's SIMPLE meeting, Orit brought up an issue about how we >>>>planned to identify contributors when MSRP is used with a conference >>>>focus. Previously, we had discussed using message/cpim wrappers for >>>>this purpose. >>>> >>>>After thinking through the use case, I think Orit may be >>> >>>correct that >>> >>>>cpim is unwieldy for this purpose. >>>> >>>>The use case I think we have in mind is, you have a text conference >>>>where each participant has an independent MSRP session with the >>>>conference focus. The focus acts as a reflector, forwarding messages >>>>that come in on one participant session to each of the other >>>>participants. It needs a way to tell the receiving parties which >>>>participant sent the message. _How_ it determines what >>> >>>contributor ID >>> >>>>to attach to a given message is out of scope for MSRP--that problem >>>>belongs to XCON. >>>> >>>>We had previously assumed the focus would simply wrap the inbound >>>>message in a message/cpim document, and use the CPIM "from" >>> >>>field for >>> >>>>this purpose. This, however, is problematic for chunked messages, as >>>>the focus would need to buffer the message until it had received all >>>>the chunks, wrap the completed message in the cpim >>> >>>document, and then >>> >>>>send that message out to the other participants, possibly >>> >>>re-chunking >>> >>>>in the process. This does seem to me to be burdensome on >>> >>>the focus; it >>> >>>>would be nicer if the focus could simply forward the >>> >>>individual chunks, >>> >>>>and let the endpoints deal with re-assembling them. >>>> >>>>Another approach would be to have the focus force the >>> >>>endpoints to use >>> >>>>a cpim envelope. However, there may be times where the identity that >>>>the focus wants to insert may be different than the >>> >>>identity that the >>> >>>>endpoint inserts. >>>> >>>>Therefore, I propose we add a new optional header called >>>>Contributor-ID, which can carry a name-addr. Normal endpoints would >>>>never insert this, but a conference focus could insert this >>> >>>header on a >>> >>>>per-chunk basis, and avoid the buffering requirement >>> >>>mentioned above. >>> >>>>What do others think? Am I completely off base? >>>> >>>>Thanks! >>>> >>>>Ben. >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 12:22:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13829; Mon, 16 Aug 2004 12:22:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwkM0-00046q-2A; Mon, 16 Aug 2004 12:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwkEr-00040b-JN; Mon, 16 Aug 2004 12:21:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwk0G-0000Yi-Cr for simple@megatron.ietf.org; Mon, 16 Aug 2004 12:06:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13076 for ; Mon, 16 Aug 2004 12:06:30 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwk65-0003rG-DP for simple@ietf.org; Mon, 16 Aug 2004 12:12:34 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7GG4fru086503 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 16 Aug 2004 11:04:42 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4120D96C.20605@cisco.com> References: <4120D96C.20605@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Mon, 16 Aug 2004 11:04:35 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, rohan@cisco.com, Orit Levin , adam@dynamicsoft.com, rsparks@dynamicsoft.com, cboulton@ubiquity.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: 7bit On Aug 16, 2004, at 10:57 AM, Paul Kyzivat wrote: > > > Orit Levin wrote: >> Just to a add to Ben's summary, >> There is additional the simplest and the best (in my mind) approach: >> By including a "SourceID" header into MSRP, we allow for any type of >> conferencing architecture (and other possible applications) to handle >> MSRP sessions in the same way it chooses to handle RTP/RTCP sessions >> WITHOUT requiring MSRP specs to discuss conferencing in any details. > > To pursue that philosophy, the "SourceID" should be as semantically > similar as possible to that of RTP/RTCP. That would mean it should not > be signed, or end to end secure, and should be be able to accomodate > multiple values. > > I'm inclined to think we would like to do something different than > that, but need to do work with the conference team to figure out what. > Is there really any problem is waiting for them to figure out what > they need, and then add it? > If that means blocking completion on the MSRP base spec, I think we are trying to meet some deadlines from external liason groups. The chairs can probably clarify. > Paul > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] Sent: Friday, August 13, >> 2004 11:35 AM >> To: hisham.khartabil@nokia.com >> Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; >> rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; >> simple@ietf.org; adam@dynamicsoft.com >> Subject: Re: [Simple] MSRP: Contributor ID >> It does not seem like we are converging on a consensus here. Let me >> back up a level: >> I think we have one high-level decision to make before we can decide >> on the details. That is, how much effort do we intend to put into >> making sure that the MSRP core spec can support all likely conference >> scenarios? >> The working group's previous consensus was to simply say that, if you >> need to carry this sort of information, use CPIM. We did not discuss >> questions about whether the sender uses cpim, or a focus wraps >> received messages in cpim before sending them out, etc. We did not >> discuss situations where different nodes have different ideas about >> what identity should be used. >> The opposite extreme would be to make an effort to define all the >> conferencing use-cases we care about, and choose the mechanism that >> best fits. Now, this may be a good thing to do, but it would once >> again be a case of delaying the completion of MSRP because we decided >> to add significant new requirements at the last minute. >> A middle ground would be to consider one or two very simple use >> cases, such as a single-focus, and maybe a single-focus where at >> least participant is crossing a cpim gateway from another protocol. >> So, can we reach a consensus about which of these three approaches to >> take? Personally, I think lack of consensus on this point means we do >> nothing. Do the chairs have an opinion? >> On Aug 12, 2004, at 9:51 AM, wrote: >>> That's definitely conference policy and is outside the scope of MSRP. >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>> Sent: 12.August.2004 03:55 >>>> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>>> Orit Levin; >>>> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat >>>> Cc: simple@ietf.org >>>> Subject: Re: [Simple] MSRP: Contributor ID >>>> >>>> >>>> >>>> Sounds like a reasonable idea to me. I think we would want to >>>> add that if >>>> the user had requested Privacy either via the privacy header >>>> or setting From >>>> to Anonymous then the contributor id should not be revealed >>>> here. Even if >>>> the user authenticated via pins or something, the identity >>>> should not be >>>> revealed here if the original call was private. >>>> >>>> >>>> On 8/9/04 11:27 AM, "Ben Campbell" wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>> we >>>>> planned to identify contributors when MSRP is used with a >>>>> conference >>>>> focus. Previously, we had discussed using message/cpim wrappers for >>>>> this purpose. >>>>> >>>>> After thinking through the use case, I think Orit may be >>>> >>>> correct that >>>> >>>>> cpim is unwieldy for this purpose. >>>>> >>>>> The use case I think we have in mind is, you have a text conference >>>>> where each participant has an independent MSRP session with the >>>>> conference focus. The focus acts as a reflector, forwarding >>>>> messages >>>>> that come in on one participant session to each of the other >>>>> participants. It needs a way to tell the receiving parties which >>>>> participant sent the message. _How_ it determines what >>>> >>>> contributor ID >>>> >>>>> to attach to a given message is out of scope for MSRP--that problem >>>>> belongs to XCON. >>>>> >>>>> We had previously assumed the focus would simply wrap the inbound >>>>> message in a message/cpim document, and use the CPIM "from" >>>> >>>> field for >>>> >>>>> this purpose. This, however, is problematic for chunked messages, >>>>> as >>>>> the focus would need to buffer the message until it had received >>>>> all >>>>> the chunks, wrap the completed message in the cpim >>>> >>>> document, and then >>>> >>>>> send that message out to the other participants, possibly >>>> >>>> re-chunking >>>> >>>>> in the process. This does seem to me to be burdensome on >>>> >>>> the focus; it >>>> >>>>> would be nicer if the focus could simply forward the >>>> >>>> individual chunks, >>>> >>>>> and let the endpoints deal with re-assembling them. >>>>> >>>>> Another approach would be to have the focus force the >>>> >>>> endpoints to use >>>> >>>>> a cpim envelope. However, there may be times where the identity >>>>> that >>>>> the focus wants to insert may be different than the >>>> >>>> identity that the >>>> >>>>> endpoint inserts. >>>>> >>>>> Therefore, I propose we add a new optional header called >>>>> Contributor-ID, which can carry a name-addr. Normal endpoints would >>>>> never insert this, but a conference focus could insert this >>>> >>>> header on a >>>> >>>>> per-chunk basis, and avoid the buffering requirement >>>> >>>> mentioned above. >>>> >>>>> What do others think? Am I completely off base? >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 13:56:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18092; Mon, 16 Aug 2004 13:56:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwlox-0005cw-NZ; Mon, 16 Aug 2004 14:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwlZk-00078O-46; Mon, 16 Aug 2004 13:47:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwlQZ-0005Oi-Fa for simple@megatron.ietf.org; Mon, 16 Aug 2004 13:37:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16929 for ; Mon, 16 Aug 2004 13:37:46 -0400 (EDT) Received: from fw.cdotb.ernet.in ([202.41.72.207] helo=ws9.cdotb.ernet.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwlWJ-0005DX-Sk for simple@ietf.org; Mon, 16 Aug 2004 13:43:50 -0400 Received: from cdotb.ernet.in ([192.168.51.203]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id WAA06238 for ; Mon, 16 Aug 2004 22:34:56 +0500 (GMT+0500) Message-ID: <4120F680.8090505@cdotb.ernet.in> Date: Mon, 16 Aug 2004 23:31:36 +0530 From: Biplab Chattopadhyay Organization: C-DOT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Simple] When to create transaction in server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: biplab@cdotb.ernet.in List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi folks, I have one doubt. In Txn Server side, should I create a transaction immediately after getting a request from the client or should I pass it to the UA without creating a transaction and wait for the UA to accept the request and send a response and then create the transaction. RFC 3261 (Section 17.2.1) seems to be telling the first case, where as the second case may save some kinds of spurious attacks. Biplab. -- ---------------------------------------------------------------------------- Biplab Chattopadhyay Research Engineer CDOT-Bangalore email: biplab@cdotb.ernet.in biplab_1979@rediffmail.com Phone# Office: 2263399, ext 255 2383951 (direct) Mobile: 9845378867 ---------------------------------------------------------------------------- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 14:46:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21569; Mon, 16 Aug 2004 14:46:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwmau-0006hF-Cs; Mon, 16 Aug 2004 14:52:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmTo-0007zn-VC; Mon, 16 Aug 2004 14:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmKf-0006mJ-77 for simple@megatron.ietf.org; Mon, 16 Aug 2004 14:35:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20933 for ; Mon, 16 Aug 2004 14:35:43 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwmQU-0006V0-QW for simple@ietf.org; Mon, 16 Aug 2004 14:41:48 -0400 Received: from [192.168.0.106] (adsl-209-30-32-144.dsl.rcsntx.swbell.net [209.30.32.144]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7GIZXeC099131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2004 13:35:35 -0500 (CDT) (envelope-from adam@dynamicsoft.com) Message-ID: <4120FE2C.1060008@dynamicsoft.com> Date: Mon, 16 Aug 2004 13:34:20 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schmidt Christian Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: "'aki.niemi@nokia.com'" , "'Robert Sparks'" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Schmidt Christian wrote: >mobile networks are always interested in increasing efficiency. Requirements for Presence Service in 3GPP Wireless Systems (draft-kiss-simple-presence-wireless-reqs-03) contains: >PUBL-REQ2: Partial publishing >The publish mechanism must allow a PUA to change only part of the presentity's presence information. For example, a PUA must be able to publish one single element of the presentity's PIDF document, while the document contains several elements. > > I think Robert's question wasn't whether efficiency is important for wireless networks -- we all agree that it is -- but whether the existing mechanisms provided by the publication framework are sufficient. I argue that they are. In particular, the requirement that you cite *is* already satisfied by the Etag handling in the base PUBLISH specification. Publication of a tuple without an indicated Etag generates a new stream of publications that can be composited by the presence server in any way it sees fit. So, one can trivially set up a system that accepts a new publication stream which represents a single tuple within a larger presence document; it is then possible to update that tuple and only that tuple without having to upload the entire presence document. This is all completely possible and expected with the current PUBLISH draft. Personally, I have rather strong feelings that the partial publication work imposes substantial complexity on the system while providing an insignificant improvement in overall system efficiency. I believe that our efforts are best spent elsewhere. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 16:53:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08901; Mon, 16 Aug 2004 16:53:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwoaI-0003PR-B5; Mon, 16 Aug 2004 17:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwoH2-00022X-BR; Mon, 16 Aug 2004 16:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwnuG-0004YQ-0a for simple@megatron.ietf.org; Mon, 16 Aug 2004 16:16:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03586 for ; Mon, 16 Aug 2004 16:16:34 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwo06-0001oh-GV for simple@ietf.org; Mon, 16 Aug 2004 16:22:39 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7GKGNP0007763 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 16 Aug 2004 15:16:24 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4120FE2C.1060008@dynamicsoft.com> References: <4120FE2C.1060008@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2243C492-EFC1-11D8-8B27-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? Date: Mon, 16 Aug 2004 15:16:19 -0500 To: Adam Roach X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , "'Robert Sparks'" , simple@ietf.org, "'aki.niemi@nokia.com'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Aug 16, 2004, at 1:34 PM, Adam Roach wrote: [...] > Personally, I have rather strong feelings that the partial publication > work imposes substantial complexity on the system while providing an > insignificant improvement in overall system efficiency. I believe that > our efforts are best spent elsewhere. > > At the risk of making a "me to" posting, I share Adam's concern about the complexity introduced by partial publication. Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 17:21:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10804; Mon, 16 Aug 2004 17:21:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwp0a-0003yd-0o; Mon, 16 Aug 2004 17:27:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwosc-0003AW-LA; Mon, 16 Aug 2004 17:18:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwoeu-0001Fi-UH for simple@megatron.ietf.org; Mon, 16 Aug 2004 17:04:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09816 for ; Mon, 16 Aug 2004 17:04:46 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwokm-0003hK-Kx for simple@ietf.org; Mon, 16 Aug 2004 17:10:53 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Aug 2004 14:08:08 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7GL46bq007448; Mon, 16 Aug 2004 14:04:13 -0700 (PDT) Received: from [128.107.171.33] ([128.107.171.33]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ARL33900; Mon, 16 Aug 2004 14:02:49 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Mon, 16 Aug 2004 14:02:53 -0700 Subject: Re: [Simple] MSRP: Contributor ID From: Cullen Jennings To: Ben Campbell , Paul H Kyzivat Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit Cc: rohan@cisco.com, Orit Levin , Adam Roach , Robert Sparks , cboulton@ubiquity.com, "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit This is starting to look like .... 1) CPIM would work 2) we could define something else later if we wanted without breaking current stuff This makes me think it is a separable problem and should be separated from the MSRP base. On 8/16/04 9:04 AM, "Ben Campbell" wrote: > > On Aug 16, 2004, at 10:57 AM, Paul Kyzivat wrote: > >> >> >> Orit Levin wrote: >>> Just to a add to Ben's summary, >>> There is additional the simplest and the best (in my mind) approach: >>> By including a "SourceID" header into MSRP, we allow for any type of >>> conferencing architecture (and other possible applications) to handle >>> MSRP sessions in the same way it chooses to handle RTP/RTCP sessions >>> WITHOUT requiring MSRP specs to discuss conferencing in any details. >> >> To pursue that philosophy, the "SourceID" should be as semantically >> similar as possible to that of RTP/RTCP. That would mean it should not >> be signed, or end to end secure, and should be be able to accomodate >> multiple values. >> >> I'm inclined to think we would like to do something different than >> that, but need to do work with the conference team to figure out what. >> Is there really any problem is waiting for them to figure out what >> they need, and then add it? >> > > If that means blocking completion on the MSRP base spec, I think we are > trying to meet some deadlines from external liason groups. The chairs > can probably clarify. > > >> Paul >> >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] Sent: Friday, August 13, >>> 2004 11:35 AM >>> To: hisham.khartabil@nokia.com >>> Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; >>> rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; >>> simple@ietf.org; adam@dynamicsoft.com >>> Subject: Re: [Simple] MSRP: Contributor ID >>> It does not seem like we are converging on a consensus here. Let me >>> back up a level: >>> I think we have one high-level decision to make before we can decide >>> on the details. That is, how much effort do we intend to put into >>> making sure that the MSRP core spec can support all likely conference >>> scenarios? >>> The working group's previous consensus was to simply say that, if you >>> need to carry this sort of information, use CPIM. We did not discuss >>> questions about whether the sender uses cpim, or a focus wraps >>> received messages in cpim before sending them out, etc. We did not >>> discuss situations where different nodes have different ideas about >>> what identity should be used. >>> The opposite extreme would be to make an effort to define all the >>> conferencing use-cases we care about, and choose the mechanism that >>> best fits. Now, this may be a good thing to do, but it would once >>> again be a case of delaying the completion of MSRP because we decided >>> to add significant new requirements at the last minute. >>> A middle ground would be to consider one or two very simple use >>> cases, such as a single-focus, and maybe a single-focus where at >>> least participant is crossing a cpim gateway from another protocol. >>> So, can we reach a consensus about which of these three approaches to >>> take? Personally, I think lack of consensus on this point means we do >>> nothing. Do the chairs have an opinion? >>> On Aug 12, 2004, at 9:51 AM, wrote: >>>> That's definitely conference policy and is outside the scope of MSRP. >>>> >>>> /Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>>> Sent: 12.August.2004 03:55 >>>>> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>>>> Orit Levin; >>>>> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat >>>>> Cc: simple@ietf.org >>>>> Subject: Re: [Simple] MSRP: Contributor ID >>>>> >>>>> >>>>> >>>>> Sounds like a reasonable idea to me. I think we would want to >>>>> add that if >>>>> the user had requested Privacy either via the privacy header >>>>> or setting From >>>>> to Anonymous then the contributor id should not be revealed >>>>> here. Even if >>>>> the user authenticated via pins or something, the identity >>>>> should not be >>>>> revealed here if the original call was private. >>>>> >>>>> >>>>> On 8/9/04 11:27 AM, "Ben Campbell" wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>>> we >>>>>> planned to identify contributors when MSRP is used with a >>>>>> conference >>>>>> focus. Previously, we had discussed using message/cpim wrappers for >>>>>> this purpose. >>>>>> >>>>>> After thinking through the use case, I think Orit may be >>>>> >>>>> correct that >>>>> >>>>>> cpim is unwieldy for this purpose. >>>>>> >>>>>> The use case I think we have in mind is, you have a text conference >>>>>> where each participant has an independent MSRP session with the >>>>>> conference focus. The focus acts as a reflector, forwarding >>>>>> messages >>>>>> that come in on one participant session to each of the other >>>>>> participants. It needs a way to tell the receiving parties which >>>>>> participant sent the message. _How_ it determines what >>>>> >>>>> contributor ID >>>>> >>>>>> to attach to a given message is out of scope for MSRP--that problem >>>>>> belongs to XCON. >>>>>> >>>>>> We had previously assumed the focus would simply wrap the inbound >>>>>> message in a message/cpim document, and use the CPIM "from" >>>>> >>>>> field for >>>>> >>>>>> this purpose. This, however, is problematic for chunked messages, >>>>>> as >>>>>> the focus would need to buffer the message until it had received >>>>>> all >>>>>> the chunks, wrap the completed message in the cpim >>>>> >>>>> document, and then >>>>> >>>>>> send that message out to the other participants, possibly >>>>> >>>>> re-chunking >>>>> >>>>>> in the process. This does seem to me to be burdensome on >>>>> >>>>> the focus; it >>>>> >>>>>> would be nicer if the focus could simply forward the >>>>> >>>>> individual chunks, >>>>> >>>>>> and let the endpoints deal with re-assembling them. >>>>>> >>>>>> Another approach would be to have the focus force the >>>>> >>>>> endpoints to use >>>>> >>>>>> a cpim envelope. However, there may be times where the identity >>>>>> that >>>>>> the focus wants to insert may be different than the >>>>> >>>>> identity that the >>>>> >>>>>> endpoint inserts. >>>>>> >>>>>> Therefore, I propose we add a new optional header called >>>>>> Contributor-ID, which can carry a name-addr. Normal endpoints would >>>>>> never insert this, but a conference focus could insert this >>>>> >>>>> header on a >>>>> >>>>>> per-chunk basis, and avoid the buffering requirement >>>>> >>>>> mentioned above. >>>>> >>>>>> What do others think? Am I completely off base? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Ben. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 17:37:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11835; Mon, 16 Aug 2004 17:37:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwpGC-0004Ki-Pn; Mon, 16 Aug 2004 17:43:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwou2-000654-Oa; Mon, 16 Aug 2004 17:20:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwohJ-0001U4-I6 for simple@megatron.ietf.org; Mon, 16 Aug 2004 17:07:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09945 for ; Mon, 16 Aug 2004 17:07:15 -0400 (EDT) Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwonB-0003jy-Dc for simple@ietf.org; Mon, 16 Aug 2004 17:13:21 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i7GL4MLp015178; Mon, 16 Aug 2004 16:04:22 -0500 Subject: Re: [Simple] MSRP: Contributor ID From: Robert Sparks To: Ben Campbell In-Reply-To: References: <4120D96C.20605@cisco.com> Content-Type: text/plain Message-Id: <1092690181.10426.242.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 16 Aug 2004 16:03:01 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, Rohan Mahy , Adam Roach , simple@ietf.org, Paul Kyzivat , cboulton@ubiquity.com, Orit Levin X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit My 2-cents an individual contributor: I expect that we have many different ideas of what this identifier means and what it should be used for. Because of that, it's not clear to me where there needs to be _protocol_ to solve the problem. If we are going to pursue adding MSRP syntax, then we will have, in this forum, to talk about the impact of the behavior of that syntax, agree on the security properties we want around that behavior, and build the mechanism to meet those properties. If we're looking for anything more than a "because I said so" token like CSRC or P-Asserted-Identity in other spaces, we've got a lot to talk about. We have the option of leaving that conversation to the application using MSRP. The original proposal of using cpim is an existence proof that apps can achieve much more than "because I said so" without additional MSRP mechanics. As an individual contributor, I think this is something we can leave to the application, by way of doing "stuff" in the body (doesn't _have_ to be CPIM wrapping if that tastes so bad). We can point to something like CPIM wrapping as evidence that we aren't making it impossible, and leave the long-hard discussion we'd otherwise have to have for the conferencing work. RjS On Mon, 2004-08-16 at 11:04, Ben Campbell wrote: > On Aug 16, 2004, at 10:57 AM, Paul Kyzivat wrote: > > > > > > > Orit Levin wrote: > >> Just to a add to Ben's summary, > >> There is additional the simplest and the best (in my mind) approach: > >> By including a "SourceID" header into MSRP, we allow for any type of > >> conferencing architecture (and other possible applications) to handle > >> MSRP sessions in the same way it chooses to handle RTP/RTCP sessions > >> WITHOUT requiring MSRP specs to discuss conferencing in any details. > > > > To pursue that philosophy, the "SourceID" should be as semantically > > similar as possible to that of RTP/RTCP. That would mean it should not > > be signed, or end to end secure, and should be be able to accomodate > > multiple values. > > > > I'm inclined to think we would like to do something different than > > that, but need to do work with the conference team to figure out what. > > Is there really any problem is waiting for them to figure out what > > they need, and then add it? > > > > If that means blocking completion on the MSRP base spec, I think we are > trying to meet some deadlines from external liason groups. The chairs > can probably clarify. > > > > Paul > > > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] Sent: Friday, August 13, > >> 2004 11:35 AM > >> To: hisham.khartabil@nokia.com > >> Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; > >> rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; > >> simple@ietf.org; adam@dynamicsoft.com > >> Subject: Re: [Simple] MSRP: Contributor ID > >> It does not seem like we are converging on a consensus here. Let me > >> back up a level: > >> I think we have one high-level decision to make before we can decide > >> on the details. That is, how much effort do we intend to put into > >> making sure that the MSRP core spec can support all likely conference > >> scenarios? > >> The working group's previous consensus was to simply say that, if you > >> need to carry this sort of information, use CPIM. We did not discuss > >> questions about whether the sender uses cpim, or a focus wraps > >> received messages in cpim before sending them out, etc. We did not > >> discuss situations where different nodes have different ideas about > >> what identity should be used. > >> The opposite extreme would be to make an effort to define all the > >> conferencing use-cases we care about, and choose the mechanism that > >> best fits. Now, this may be a good thing to do, but it would once > >> again be a case of delaying the completion of MSRP because we decided > >> to add significant new requirements at the last minute. > >> A middle ground would be to consider one or two very simple use > >> cases, such as a single-focus, and maybe a single-focus where at > >> least participant is crossing a cpim gateway from another protocol. > >> So, can we reach a consensus about which of these three approaches to > >> take? Personally, I think lack of consensus on this point means we do > >> nothing. Do the chairs have an opinion? > >> On Aug 12, 2004, at 9:51 AM, wrote: > >>> That's definitely conference policy and is outside the scope of MSRP. > >>> > >>> /Hisham > >>> > >>> > >>>> -----Original Message----- > >>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] > >>>> Sent: 12.August.2004 03:55 > >>>> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > >>>> Orit Levin; > >>>> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H Kyzivat > >>>> Cc: simple@ietf.org > >>>> Subject: Re: [Simple] MSRP: Contributor ID > >>>> > >>>> > >>>> > >>>> Sounds like a reasonable idea to me. I think we would want to > >>>> add that if > >>>> the user had requested Privacy either via the privacy header > >>>> or setting From > >>>> to Anonymous then the contributor id should not be revealed > >>>> here. Even if > >>>> the user authenticated via pins or something, the identity > >>>> should not be > >>>> revealed here if the original call was private. > >>>> > >>>> > >>>> On 8/9/04 11:27 AM, "Ben Campbell" wrote: > >>>> > >>>> > >>>>> Hi, > >>>>> > >>>>> In last week's SIMPLE meeting, Orit brought up an issue about how > >>>>> we > >>>>> planned to identify contributors when MSRP is used with a > >>>>> conference > >>>>> focus. Previously, we had discussed using message/cpim wrappers for > >>>>> this purpose. > >>>>> > >>>>> After thinking through the use case, I think Orit may be > >>>> > >>>> correct that > >>>> > >>>>> cpim is unwieldy for this purpose. > >>>>> > >>>>> The use case I think we have in mind is, you have a text conference > >>>>> where each participant has an independent MSRP session with the > >>>>> conference focus. The focus acts as a reflector, forwarding > >>>>> messages > >>>>> that come in on one participant session to each of the other > >>>>> participants. It needs a way to tell the receiving parties which > >>>>> participant sent the message. _How_ it determines what > >>>> > >>>> contributor ID > >>>> > >>>>> to attach to a given message is out of scope for MSRP--that problem > >>>>> belongs to XCON. > >>>>> > >>>>> We had previously assumed the focus would simply wrap the inbound > >>>>> message in a message/cpim document, and use the CPIM "from" > >>>> > >>>> field for > >>>> > >>>>> this purpose. This, however, is problematic for chunked messages, > >>>>> as > >>>>> the focus would need to buffer the message until it had received > >>>>> all > >>>>> the chunks, wrap the completed message in the cpim > >>>> > >>>> document, and then > >>>> > >>>>> send that message out to the other participants, possibly > >>>> > >>>> re-chunking > >>>> > >>>>> in the process. This does seem to me to be burdensome on > >>>> > >>>> the focus; it > >>>> > >>>>> would be nicer if the focus could simply forward the > >>>> > >>>> individual chunks, > >>>> > >>>>> and let the endpoints deal with re-assembling them. > >>>>> > >>>>> Another approach would be to have the focus force the > >>>> > >>>> endpoints to use > >>>> > >>>>> a cpim envelope. However, there may be times where the identity > >>>>> that > >>>>> the focus wants to insert may be different than the > >>>> > >>>> identity that the > >>>> > >>>>> endpoint inserts. > >>>>> > >>>>> Therefore, I propose we add a new optional header called > >>>>> Contributor-ID, which can carry a name-addr. Normal endpoints would > >>>>> never insert this, but a conference focus could insert this > >>>> > >>>> header on a > >>>> > >>>>> per-chunk basis, and avoid the buffering requirement > >>>> > >>>> mentioned above. > >>>> > >>>>> What do others think? Am I completely off base? > >>>>> > >>>>> Thanks! > >>>>> > >>>>> Ben. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Simple mailing list > >>>>> Simple@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>> > >>>> > >>>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 17:39:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12183; Mon, 16 Aug 2004 17:39:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwpII-0004Ql-KR; Mon, 16 Aug 2004 17:45:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwou9-0006An-JD; Mon, 16 Aug 2004 17:20:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwosI-00030g-D6 for simple@megatron.ietf.org; Mon, 16 Aug 2004 17:18:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10602 for ; Mon, 16 Aug 2004 17:18:36 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwoyA-0003uZ-3w for simple@ietf.org; Mon, 16 Aug 2004 17:24:42 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7GLGeRg012344 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 16 Aug 2004 16:16:40 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D8B5ABD-EFC9-11D8-8B27-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Mon, 16 Aug 2004 16:16:34 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit Cc: rohan@cisco.com, Orit Levin , Adam Roach , Robert Sparks , Paul H Kyzivat , cboulton@ubiquity.com, "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit On Aug 16, 2004, at 4:02 PM, Cullen Jennings wrote: > > This is starting to look like .... > > 1) CPIM would work > 2) we could define something else later if we wanted without breaking > current stuff > > This makes me think it is a separable problem and should be separated > from > the MSRP base. > > I agree, assuming we don't _later_ decide we need to add a new header. If that happens, since we don't have an extension negotiation mechanism, then many clients would not be able to participate in the conferencing solution. However, if we stick to using something in the body for this, we at least have some mechanism for negotiating body content-types. Furthermore, if we can make it work with cpim, we have mandatory support for that. So, after much flipping of opinions, I think I am back to thinking that we do not need to do anything in the base protocol definition. > > On 8/16/04 9:04 AM, "Ben Campbell" wrote: > >> >> On Aug 16, 2004, at 10:57 AM, Paul Kyzivat wrote: >> >>> >>> >>> Orit Levin wrote: >>>> Just to a add to Ben's summary, >>>> There is additional the simplest and the best (in my mind) approach: >>>> By including a "SourceID" header into MSRP, we allow for any type of >>>> conferencing architecture (and other possible applications) to >>>> handle >>>> MSRP sessions in the same way it chooses to handle RTP/RTCP sessions >>>> WITHOUT requiring MSRP specs to discuss conferencing in any details. >>> >>> To pursue that philosophy, the "SourceID" should be as semantically >>> similar as possible to that of RTP/RTCP. That would mean it should >>> not >>> be signed, or end to end secure, and should be be able to accomodate >>> multiple values. >>> >>> I'm inclined to think we would like to do something different than >>> that, but need to do work with the conference team to figure out >>> what. >>> Is there really any problem is waiting for them to figure out what >>> they need, and then add it? >>> >> >> If that means blocking completion on the MSRP base spec, I think we >> are >> trying to meet some deadlines from external liason groups. The chairs >> can probably clarify. >> >> >>> Paul >>> >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] Sent: Friday, August 13, >>>> 2004 11:35 AM >>>> To: hisham.khartabil@nokia.com >>>> Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; >>>> rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; >>>> simple@ietf.org; adam@dynamicsoft.com >>>> Subject: Re: [Simple] MSRP: Contributor ID >>>> It does not seem like we are converging on a consensus here. Let me >>>> back up a level: >>>> I think we have one high-level decision to make before we can decide >>>> on the details. That is, how much effort do we intend to put into >>>> making sure that the MSRP core spec can support all likely >>>> conference >>>> scenarios? >>>> The working group's previous consensus was to simply say that, if >>>> you >>>> need to carry this sort of information, use CPIM. We did not discuss >>>> questions about whether the sender uses cpim, or a focus wraps >>>> received messages in cpim before sending them out, etc. We did not >>>> discuss situations where different nodes have different ideas about >>>> what identity should be used. >>>> The opposite extreme would be to make an effort to define all the >>>> conferencing use-cases we care about, and choose the mechanism that >>>> best fits. Now, this may be a good thing to do, but it would once >>>> again be a case of delaying the completion of MSRP because we >>>> decided >>>> to add significant new requirements at the last minute. >>>> A middle ground would be to consider one or two very simple use >>>> cases, such as a single-focus, and maybe a single-focus where at >>>> least participant is crossing a cpim gateway from another protocol. >>>> So, can we reach a consensus about which of these three approaches >>>> to >>>> take? Personally, I think lack of consensus on this point means we >>>> do >>>> nothing. Do the chairs have an opinion? >>>> On Aug 12, 2004, at 9:51 AM, wrote: >>>>> That's definitely conference policy and is outside the scope of >>>>> MSRP. >>>>> >>>>> /Hisham >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>>>> Sent: 12.August.2004 03:55 >>>>>> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>>>>> Orit Levin; >>>>>> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H >>>>>> Kyzivat >>>>>> Cc: simple@ietf.org >>>>>> Subject: Re: [Simple] MSRP: Contributor ID >>>>>> >>>>>> >>>>>> >>>>>> Sounds like a reasonable idea to me. I think we would want to >>>>>> add that if >>>>>> the user had requested Privacy either via the privacy header >>>>>> or setting From >>>>>> to Anonymous then the contributor id should not be revealed >>>>>> here. Even if >>>>>> the user authenticated via pins or something, the identity >>>>>> should not be >>>>>> revealed here if the original call was private. >>>>>> >>>>>> >>>>>> On 8/9/04 11:27 AM, "Ben Campbell" wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>>>> we >>>>>>> planned to identify contributors when MSRP is used with a >>>>>>> conference >>>>>>> focus. Previously, we had discussed using message/cpim wrappers >>>>>>> for >>>>>>> this purpose. >>>>>>> >>>>>>> After thinking through the use case, I think Orit may be >>>>>> >>>>>> correct that >>>>>> >>>>>>> cpim is unwieldy for this purpose. >>>>>>> >>>>>>> The use case I think we have in mind is, you have a text >>>>>>> conference >>>>>>> where each participant has an independent MSRP session with the >>>>>>> conference focus. The focus acts as a reflector, forwarding >>>>>>> messages >>>>>>> that come in on one participant session to each of the other >>>>>>> participants. It needs a way to tell the receiving parties which >>>>>>> participant sent the message. _How_ it determines what >>>>>> >>>>>> contributor ID >>>>>> >>>>>>> to attach to a given message is out of scope for MSRP--that >>>>>>> problem >>>>>>> belongs to XCON. >>>>>>> >>>>>>> We had previously assumed the focus would simply wrap the inbound >>>>>>> message in a message/cpim document, and use the CPIM "from" >>>>>> >>>>>> field for >>>>>> >>>>>>> this purpose. This, however, is problematic for chunked messages, >>>>>>> as >>>>>>> the focus would need to buffer the message until it had received >>>>>>> all >>>>>>> the chunks, wrap the completed message in the cpim >>>>>> >>>>>> document, and then >>>>>> >>>>>>> send that message out to the other participants, possibly >>>>>> >>>>>> re-chunking >>>>>> >>>>>>> in the process. This does seem to me to be burdensome on >>>>>> >>>>>> the focus; it >>>>>> >>>>>>> would be nicer if the focus could simply forward the >>>>>> >>>>>> individual chunks, >>>>>> >>>>>>> and let the endpoints deal with re-assembling them. >>>>>>> >>>>>>> Another approach would be to have the focus force the >>>>>> >>>>>> endpoints to use >>>>>> >>>>>>> a cpim envelope. However, there may be times where the identity >>>>>>> that >>>>>>> the focus wants to insert may be different than the >>>>>> >>>>>> identity that the >>>>>> >>>>>>> endpoint inserts. >>>>>>> >>>>>>> Therefore, I propose we add a new optional header called >>>>>>> Contributor-ID, which can carry a name-addr. Normal endpoints >>>>>>> would >>>>>>> never insert this, but a conference focus could insert this >>>>>> >>>>>> header on a >>>>>> >>>>>>> per-chunk basis, and avoid the buffering requirement >>>>>> >>>>>> mentioned above. >>>>>> >>>>>>> What do others think? Am I completely off base? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Ben. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> >>>>>> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 17:57:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13518; Mon, 16 Aug 2004 17:57:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwpZt-0004tO-BK; Mon, 16 Aug 2004 18:03:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwpCI-0001jA-2k; Mon, 16 Aug 2004 17:39:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwou8-00068K-4s for simple@megatron.ietf.org; Mon, 16 Aug 2004 17:20:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10775 for ; Mon, 16 Aug 2004 17:20:29 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwozz-0003xp-K3 for simple@ietf.org; Mon, 16 Aug 2004 17:26:36 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7GLItKY012588 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 16 Aug 2004 16:18:56 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <1092690181.10426.242.camel@localhost.localdomain> References: <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Mon, 16 Aug 2004 16:18:50 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, Rohan Mahy , Orit Levin , Adam Roach , simple@ietf.org, Paul Kyzivat , cboulton@ubiquity.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Content-Transfer-Encoding: 7bit Just to be precise, I think you are proposing that we do not add anything new to the base protocol for this purpose, correct? That is, leave things as they are? On Aug 16, 2004, at 4:03 PM, Robert Sparks wrote: > My 2-cents an individual contributor: > > I expect that we have many different ideas of what this > identifier means and what it should be used for. Because > of that, it's not clear to me where there needs to be > _protocol_ to solve the problem. > > If we are going to pursue adding MSRP syntax, then we > will have, in this forum, to talk about the impact of > the behavior of that syntax, agree on the security > properties we want around that behavior, and build the > mechanism to meet those properties. If we're looking > for anything more than a "because I said so" token > like CSRC or P-Asserted-Identity in other spaces, > we've got a lot to talk about. > > We have the option of leaving that conversation to > the application using MSRP. The original proposal > of using cpim is an existence proof that apps > can achieve much more than "because I said so" without > additional MSRP mechanics. As an individual contributor, > I think this is something we can leave to the application, > by way of doing "stuff" in the body (doesn't _have_ to > be CPIM wrapping if that tastes so bad). We can point to > something like CPIM wrapping as evidence that we aren't > making it impossible, and leave the long-hard discussion > we'd otherwise have to have for the conferencing work. > > RjS > > > On Mon, 2004-08-16 at 11:04, Ben Campbell wrote: >> On Aug 16, 2004, at 10:57 AM, Paul Kyzivat wrote: >> >>> >>> >>> Orit Levin wrote: >>>> Just to a add to Ben's summary, >>>> There is additional the simplest and the best (in my mind) approach: >>>> By including a "SourceID" header into MSRP, we allow for any type of >>>> conferencing architecture (and other possible applications) to >>>> handle >>>> MSRP sessions in the same way it chooses to handle RTP/RTCP sessions >>>> WITHOUT requiring MSRP specs to discuss conferencing in any details. >>> >>> To pursue that philosophy, the "SourceID" should be as semantically >>> similar as possible to that of RTP/RTCP. That would mean it should >>> not >>> be signed, or end to end secure, and should be be able to accomodate >>> multiple values. >>> >>> I'm inclined to think we would like to do something different than >>> that, but need to do work with the conference team to figure out >>> what. >>> Is there really any problem is waiting for them to figure out what >>> they need, and then add it? >>> >> >> If that means blocking completion on the MSRP base spec, I think we >> are >> trying to meet some deadlines from external liason groups. The chairs >> can probably clarify. >> >> >>> Paul >>> >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] Sent: Friday, August 13, >>>> 2004 11:35 AM >>>> To: hisham.khartabil@nokia.com >>>> Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; >>>> rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; >>>> simple@ietf.org; adam@dynamicsoft.com >>>> Subject: Re: [Simple] MSRP: Contributor ID >>>> It does not seem like we are converging on a consensus here. Let me >>>> back up a level: >>>> I think we have one high-level decision to make before we can decide >>>> on the details. That is, how much effort do we intend to put into >>>> making sure that the MSRP core spec can support all likely >>>> conference >>>> scenarios? >>>> The working group's previous consensus was to simply say that, if >>>> you >>>> need to carry this sort of information, use CPIM. We did not discuss >>>> questions about whether the sender uses cpim, or a focus wraps >>>> received messages in cpim before sending them out, etc. We did not >>>> discuss situations where different nodes have different ideas about >>>> what identity should be used. >>>> The opposite extreme would be to make an effort to define all the >>>> conferencing use-cases we care about, and choose the mechanism that >>>> best fits. Now, this may be a good thing to do, but it would once >>>> again be a case of delaying the completion of MSRP because we >>>> decided >>>> to add significant new requirements at the last minute. >>>> A middle ground would be to consider one or two very simple use >>>> cases, such as a single-focus, and maybe a single-focus where at >>>> least participant is crossing a cpim gateway from another protocol. >>>> So, can we reach a consensus about which of these three approaches >>>> to >>>> take? Personally, I think lack of consensus on this point means we >>>> do >>>> nothing. Do the chairs have an opinion? >>>> On Aug 12, 2004, at 9:51 AM, wrote: >>>>> That's definitely conference policy and is outside the scope of >>>>> MSRP. >>>>> >>>>> /Hisham >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>>>> Sent: 12.August.2004 03:55 >>>>>> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); >>>>>> Orit Levin; >>>>>> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H >>>>>> Kyzivat >>>>>> Cc: simple@ietf.org >>>>>> Subject: Re: [Simple] MSRP: Contributor ID >>>>>> >>>>>> >>>>>> >>>>>> Sounds like a reasonable idea to me. I think we would want to >>>>>> add that if >>>>>> the user had requested Privacy either via the privacy header >>>>>> or setting From >>>>>> to Anonymous then the contributor id should not be revealed >>>>>> here. Even if >>>>>> the user authenticated via pins or something, the identity >>>>>> should not be >>>>>> revealed here if the original call was private. >>>>>> >>>>>> >>>>>> On 8/9/04 11:27 AM, "Ben Campbell" wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> In last week's SIMPLE meeting, Orit brought up an issue about how >>>>>>> we >>>>>>> planned to identify contributors when MSRP is used with a >>>>>>> conference >>>>>>> focus. Previously, we had discussed using message/cpim wrappers >>>>>>> for >>>>>>> this purpose. >>>>>>> >>>>>>> After thinking through the use case, I think Orit may be >>>>>> >>>>>> correct that >>>>>> >>>>>>> cpim is unwieldy for this purpose. >>>>>>> >>>>>>> The use case I think we have in mind is, you have a text >>>>>>> conference >>>>>>> where each participant has an independent MSRP session with the >>>>>>> conference focus. The focus acts as a reflector, forwarding >>>>>>> messages >>>>>>> that come in on one participant session to each of the other >>>>>>> participants. It needs a way to tell the receiving parties which >>>>>>> participant sent the message. _How_ it determines what >>>>>> >>>>>> contributor ID >>>>>> >>>>>>> to attach to a given message is out of scope for MSRP--that >>>>>>> problem >>>>>>> belongs to XCON. >>>>>>> >>>>>>> We had previously assumed the focus would simply wrap the inbound >>>>>>> message in a message/cpim document, and use the CPIM "from" >>>>>> >>>>>> field for >>>>>> >>>>>>> this purpose. This, however, is problematic for chunked messages, >>>>>>> as >>>>>>> the focus would need to buffer the message until it had received >>>>>>> all >>>>>>> the chunks, wrap the completed message in the cpim >>>>>> >>>>>> document, and then >>>>>> >>>>>>> send that message out to the other participants, possibly >>>>>> >>>>>> re-chunking >>>>>> >>>>>>> in the process. This does seem to me to be burdensome on >>>>>> >>>>>> the focus; it >>>>>> >>>>>>> would be nicer if the focus could simply forward the >>>>>> >>>>>> individual chunks, >>>>>> >>>>>>> and let the endpoints deal with re-assembling them. >>>>>>> >>>>>>> Another approach would be to have the focus force the >>>>>> >>>>>> endpoints to use >>>>>> >>>>>>> a cpim envelope. However, there may be times where the identity >>>>>>> that >>>>>>> the focus wants to insert may be different than the >>>>>> >>>>>> identity that the >>>>>> >>>>>>> endpoint inserts. >>>>>>> >>>>>>> Therefore, I propose we add a new optional header called >>>>>>> Contributor-ID, which can carry a name-addr. Normal endpoints >>>>>>> would >>>>>>> never insert this, but a conference focus could insert this >>>>>> >>>>>> header on a >>>>>> >>>>>>> per-chunk basis, and avoid the buffering requirement >>>>>> >>>>>> mentioned above. >>>>>> >>>>>>> What do others think? Am I completely off base? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Ben. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>> >>>>>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 18:12:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15724; Mon, 16 Aug 2004 18:12:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwpoX-0005OI-3W; Mon, 16 Aug 2004 18:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwpcB-0002g5-0c; Mon, 16 Aug 2004 18:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwpPU-0005Km-VB for simple@megatron.ietf.org; Mon, 16 Aug 2004 17:52:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13182 for ; Mon, 16 Aug 2004 17:52:54 -0400 (EDT) Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwpVN-0004kg-6t for simple@ietf.org; Mon, 16 Aug 2004 17:59:01 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i7GLowLp015391; Mon, 16 Aug 2004 16:50:58 -0500 Subject: Re: [Simple] MSRP: Contributor ID From: Robert Sparks To: Ben Campbell In-Reply-To: References: <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1092692976.10426.251.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 16 Aug 2004 16:49:36 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, Rohan Mahy , Orit Levin , Adam Roach , simple@ietf.org, Paul Kyzivat , cboulton@ubiquity.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: 7bit Yes, with the possible addition of some forward looking text capturing that we thought about the problem and expect to be able to solve it without needing to change the MSRP protocol itself. RjS On Mon, 2004-08-16 at 16:18, Ben Campbell wrote: > Just to be precise, I think you are proposing that we do not add > anything new to the base protocol for this purpose, correct? That is, > leave things as they are? > > On Aug 16, 2004, at 4:03 PM, Robert Sparks wrote: > > > My 2-cents an individual contributor: > > > > I expect that we have many different ideas of what this > > identifier means and what it should be used for. Because > > of that, it's not clear to me where there needs to be > > _protocol_ to solve the problem. > > > > If we are going to pursue adding MSRP syntax, then we > > will have, in this forum, to talk about the impact of > > the behavior of that syntax, agree on the security > > properties we want around that behavior, and build the > > mechanism to meet those properties. If we're looking > > for anything more than a "because I said so" token > > like CSRC or P-Asserted-Identity in other spaces, > > we've got a lot to talk about. > > > > We have the option of leaving that conversation to > > the application using MSRP. The original proposal > > of using cpim is an existence proof that apps > > can achieve much more than "because I said so" without > > additional MSRP mechanics. As an individual contributor, > > I think this is something we can leave to the application, > > by way of doing "stuff" in the body (doesn't _have_ to > > be CPIM wrapping if that tastes so bad). We can point to > > something like CPIM wrapping as evidence that we aren't > > making it impossible, and leave the long-hard discussion > > we'd otherwise have to have for the conferencing work. > > > > RjS > > > > > > On Mon, 2004-08-16 at 11:04, Ben Campbell wrote: > >> On Aug 16, 2004, at 10:57 AM, Paul Kyzivat wrote: > >> > >>> > >>> > >>> Orit Levin wrote: > >>>> Just to a add to Ben's summary, > >>>> There is additional the simplest and the best (in my mind) approach: > >>>> By including a "SourceID" header into MSRP, we allow for any type of > >>>> conferencing architecture (and other possible applications) to > >>>> handle > >>>> MSRP sessions in the same way it chooses to handle RTP/RTCP sessions > >>>> WITHOUT requiring MSRP specs to discuss conferencing in any details. > >>> > >>> To pursue that philosophy, the "SourceID" should be as semantically > >>> similar as possible to that of RTP/RTCP. That would mean it should > >>> not > >>> be signed, or end to end secure, and should be be able to accomodate > >>> multiple values. > >>> > >>> I'm inclined to think we would like to do something different than > >>> that, but need to do work with the conference team to figure out > >>> what. > >>> Is there really any problem is waiting for them to figure out what > >>> they need, and then add it? > >>> > >> > >> If that means blocking completion on the MSRP base spec, I think we > >> are > >> trying to meet some deadlines from external liason groups. The chairs > >> can probably clarify. > >> > >> > >>> Paul > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ben Campbell [mailto:ben@nostrum.com] Sent: Friday, August 13, > >>>> 2004 11:35 AM > >>>> To: hisham.khartabil@nokia.com > >>>> Cc: rsparks@dynamicsoft.com; fluffy@cisco.com; Orit Levin; > >>>> rohan@cisco.com; cboulton@ubiquity.com; pkyzivat@cisco.com; > >>>> simple@ietf.org; adam@dynamicsoft.com > >>>> Subject: Re: [Simple] MSRP: Contributor ID > >>>> It does not seem like we are converging on a consensus here. Let me > >>>> back up a level: > >>>> I think we have one high-level decision to make before we can decide > >>>> on the details. That is, how much effort do we intend to put into > >>>> making sure that the MSRP core spec can support all likely > >>>> conference > >>>> scenarios? > >>>> The working group's previous consensus was to simply say that, if > >>>> you > >>>> need to carry this sort of information, use CPIM. We did not discuss > >>>> questions about whether the sender uses cpim, or a focus wraps > >>>> received messages in cpim before sending them out, etc. We did not > >>>> discuss situations where different nodes have different ideas about > >>>> what identity should be used. > >>>> The opposite extreme would be to make an effort to define all the > >>>> conferencing use-cases we care about, and choose the mechanism that > >>>> best fits. Now, this may be a good thing to do, but it would once > >>>> again be a case of delaying the completion of MSRP because we > >>>> decided > >>>> to add significant new requirements at the last minute. > >>>> A middle ground would be to consider one or two very simple use > >>>> cases, such as a single-focus, and maybe a single-focus where at > >>>> least participant is crossing a cpim gateway from another protocol. > >>>> So, can we reach a consensus about which of these three approaches > >>>> to > >>>> take? Personally, I think lack of consensus on this point means we > >>>> do > >>>> nothing. Do the chairs have an opinion? > >>>> On Aug 12, 2004, at 9:51 AM, wrote: > >>>>> That's definitely conference policy and is outside the scope of > >>>>> MSRP. > >>>>> > >>>>> /Hisham > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>> Sent: 12.August.2004 03:55 > >>>>>> To: Ben Campbell; Khartabil Hisham (Nokia-TP-MSW/Helsinki); > >>>>>> Orit Levin; > >>>>>> Rohan Mahy; Chris Boulton; Adam Roach; Robert Sparks; Paul H > >>>>>> Kyzivat > >>>>>> Cc: simple@ietf.org > >>>>>> Subject: Re: [Simple] MSRP: Contributor ID > >>>>>> > >>>>>> > >>>>>> > >>>>>> Sounds like a reasonable idea to me. I think we would want to > >>>>>> add that if > >>>>>> the user had requested Privacy either via the privacy header > >>>>>> or setting From > >>>>>> to Anonymous then the contributor id should not be revealed > >>>>>> here. Even if > >>>>>> the user authenticated via pins or something, the identity > >>>>>> should not be > >>>>>> revealed here if the original call was private. > >>>>>> > >>>>>> > >>>>>> On 8/9/04 11:27 AM, "Ben Campbell" wrote: > >>>>>> > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> In last week's SIMPLE meeting, Orit brought up an issue about how > >>>>>>> we > >>>>>>> planned to identify contributors when MSRP is used with a > >>>>>>> conference > >>>>>>> focus. Previously, we had discussed using message/cpim wrappers > >>>>>>> for > >>>>>>> this purpose. > >>>>>>> > >>>>>>> After thinking through the use case, I think Orit may be > >>>>>> > >>>>>> correct that > >>>>>> > >>>>>>> cpim is unwieldy for this purpose. > >>>>>>> > >>>>>>> The use case I think we have in mind is, you have a text > >>>>>>> conference > >>>>>>> where each participant has an independent MSRP session with the > >>>>>>> conference focus. The focus acts as a reflector, forwarding > >>>>>>> messages > >>>>>>> that come in on one participant session to each of the other > >>>>>>> participants. It needs a way to tell the receiving parties which > >>>>>>> participant sent the message. _How_ it determines what > >>>>>> > >>>>>> contributor ID > >>>>>> > >>>>>>> to attach to a given message is out of scope for MSRP--that > >>>>>>> problem > >>>>>>> belongs to XCON. > >>>>>>> > >>>>>>> We had previously assumed the focus would simply wrap the inbound > >>>>>>> message in a message/cpim document, and use the CPIM "from" > >>>>>> > >>>>>> field for > >>>>>> > >>>>>>> this purpose. This, however, is problematic for chunked messages, > >>>>>>> as > >>>>>>> the focus would need to buffer the message until it had received > >>>>>>> all > >>>>>>> the chunks, wrap the completed message in the cpim > >>>>>> > >>>>>> document, and then > >>>>>> > >>>>>>> send that message out to the other participants, possibly > >>>>>> > >>>>>> re-chunking > >>>>>> > >>>>>>> in the process. This does seem to me to be burdensome on > >>>>>> > >>>>>> the focus; it > >>>>>> > >>>>>>> would be nicer if the focus could simply forward the > >>>>>> > >>>>>> individual chunks, > >>>>>> > >>>>>>> and let the endpoints deal with re-assembling them. > >>>>>>> > >>>>>>> Another approach would be to have the focus force the > >>>>>> > >>>>>> endpoints to use > >>>>>> > >>>>>>> a cpim envelope. However, there may be times where the identity > >>>>>>> that > >>>>>>> the focus wants to insert may be different than the > >>>>>> > >>>>>> identity that the > >>>>>> > >>>>>>> endpoint inserts. > >>>>>>> > >>>>>>> Therefore, I propose we add a new optional header called > >>>>>>> Contributor-ID, which can carry a name-addr. Normal endpoints > >>>>>>> would > >>>>>>> never insert this, but a conference focus could insert this > >>>>>> > >>>>>> header on a > >>>>>> > >>>>>>> per-chunk basis, and avoid the buffering requirement > >>>>>> > >>>>>> mentioned above. > >>>>>> > >>>>>>> What do others think? Am I completely off base? > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> Ben. > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Simple mailing list > >>>>>>> Simple@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>>> > >>>>>> > >>>>>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 16 18:36:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18342; Mon, 16 Aug 2004 18:36:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwqBi-00063N-CE; Mon, 16 Aug 2004 18:42:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwq0X-0006W6-9O; Mon, 16 Aug 2004 18:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwpuz-0004aK-RA for simple@megatron.ietf.org; Mon, 16 Aug 2004 18:25:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17545 for ; Mon, 16 Aug 2004 18:25:27 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwq0r-0005l8-Gy for simple@ietf.org; Mon, 16 Aug 2004 18:31:34 -0400 Received: from [192.168.0.106] (adsl-209-30-32-144.dsl.rcsntx.swbell.net [209.30.32.144]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7GMPJl2018531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Aug 2004 17:25:21 -0500 (CDT) (envelope-from adam@dynamicsoft.com) Message-ID: <41213424.9080800@dynamicsoft.com> Date: Mon, 16 Aug 2004 17:24:36 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] MSRP: Contributor ID References: <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> In-Reply-To: <1092692976.10426.251.camel@localhost.localdomain> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit At the cost of putting in a "me too" post, I agree with Robert and Ben that there is no good reason to change the solution which we agreed to in Ottawa. The properties of identity in CPIM are well defined and clearly specified. They can clearly be leveraged solve the problem at hand. It seems obvious that arguments like "it won't work" would be a valid reason to re-visit consensus. At this late stage in the process, I think that anything *short* of "it won't work" shouldn't be entertained. (Just from a practical perspective, allowing substantial changes to consensus around a valid functional solution months after that consensus has been reached gives detractors the opportunity to derail any effort at a whim. I take no position about whether such is occurring in this case, but worry about precedent if this topic is allowed to slow completion of MSRP. Chairs?). /a Robert Sparks wrote: >Yes, with the possible addition of some forward looking text capturing >that we thought about the problem and expect to be able >to solve it without needing to change the MSRP protocol itself. > >RjS > >On Mon, 2004-08-16 at 16:18, Ben Campbell wrote: > > >>Just to be precise, I think you are proposing that we do not add >>anything new to the base protocol for this purpose, correct? That is, >>leave things as they are? >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 09:57:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15753; Tue, 17 Aug 2004 09:57:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4Ye-0004RR-FR; Tue, 17 Aug 2004 10:03:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4O6-0002tD-QC; Tue, 17 Aug 2004 09:52:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4K6-00022U-8m for simple@megatron.ietf.org; Tue, 17 Aug 2004 09:48:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15183 for ; Tue, 17 Aug 2004 09:48:20 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4Q4-0004Fu-98 for simple@ietf.org; Tue, 17 Aug 2004 09:54:35 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDm2306013; Tue, 17 Aug 2004 16:48:02 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 16:47:17 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7HDlHjj025117; Tue, 17 Aug 2004 16:47:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00i0VoRb; Tue, 17 Aug 2004 16:47:16 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDlAn24245; Tue, 17 Aug 2004 16:47:10 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 16:46:47 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id 5415493B75; Tue, 17 Aug 2004 16:46:47 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7HDklpZ019499; Tue, 17 Aug 2004 16:46:47 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7HDkkK3019498; Tue, 17 Aug 2004 16:46:46 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Subject: Re: [Simple] MSRP-07 ABNF issues X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <8E4CE61E-ED77-11D8-BB7E-000D93B0AE1A@nostrum.com> (Ben Campbell's message of "Fri, 13 Aug 2004 17:24:35 -0500") References: <8E4CE61E-ED77-11D8-BB7E-000D93B0AE1A@nostrum.com> Date: Tue, 17 Aug 2004 16:46:46 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 17 Aug 2004 13:46:47.0411 (UTC) FILETIME=[A3DCF430:01C48460] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Yet another nit in ABNF: 8) Status things are not defined. I think they are as follows: namespace = 3DIGIT short-status = status-code text-reason = phrase A bit bigger issue: 9) To-Path and From-Path seem to be pretty mandatory in requests and responses. Should we update the language in section 6.1 and the ABNF so that they are normatively required, for example: headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) header = ( Message-ID / Report-Success / Report-Failure / Byte-Range / Status / ext-header ) Another nit: 10) UTF-8 definition is not correct (it looks like it has been lifted from RFC 3261). My proposal which weeds out fishy things from ASCII range masquerading as UTF-8: utf8text = *(HT / %x20-7E / UTF8-NONASCII) UTF8-NONASCII = %xC2-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT UTF8-CONT = %x80-BF RFC 3629 definition (which weeds out even more fishy things): UTF8-octets = *( UTF8-char ) UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 = %x00-7F UTF8-2 = %xC2-DF UTF8-tail UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail ) UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail ) UTF8-tail = %x80-BF A problem for 3GPP: 11) The RFC 2396 explicitly disallows IPv6 addresses in hostport. Should we use hostport from RFC 3261 instead? hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6reference = "[" IPv6address "]" IPv6address = hexpart [ ":" IPv4address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT HEXDIG = %x30-39 / %x41-46 / %x61-66 --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 10:01:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16025; Tue, 17 Aug 2004 10:01:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4cc-0004Wj-2P; Tue, 17 Aug 2004 10:07:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4O7-0002tI-8X; Tue, 17 Aug 2004 09:52:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4L0-00023s-Vh for simple@megatron.ietf.org; Tue, 17 Aug 2004 09:49:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15193 for ; Tue, 17 Aug 2004 09:49:17 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4R0-0004GO-LB for simple@ietf.org; Tue, 17 Aug 2004 09:55:32 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDn6B25470; Tue, 17 Aug 2004 16:49:06 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 16:48:56 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7HDmugV010176; Tue, 17 Aug 2004 16:48:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00DTfWaI; Tue, 17 Aug 2004 16:48:54 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HDmsu08112; Tue, 17 Aug 2004 16:48:54 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 16:48:54 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id 43C2793B6A; Tue, 17 Aug 2004 16:48:54 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7HDmspZ019506; Tue, 17 Aug 2004 16:48:54 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7HDmsYv019505; Tue, 17 Aug 2004 16:48:54 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Subject: Re: [Simple] MSRP-07 ABNF issues X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <8E4CE61E-ED77-11D8-BB7E-000D93B0AE1A@nostrum.com> (Ben Campbell's message of "Fri, 13 Aug 2004 17:24:35 -0500") References: <8E4CE61E-ED77-11D8-BB7E-000D93B0AE1A@nostrum.com> Date: Tue, 17 Aug 2004 16:48:53 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 17 Aug 2004 13:48:54.0666 (UTC) FILETIME=[EFB686A0:01C48460] X-Spam-Score: 0.8 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Ben Campbell writes: >> 7) Only the first two examples are valid according to the ABNF. >> There are extra quotation marks or whitespace is missing. >> Curiously, the examples have data with a CRLF in the beginning >> (two empty lines after headers) but not at the end (no empty line >> before end-line). Leftover from message/cpim? >Can you point out the specific occurrences of the problem for 7? OK. Here we go for the examples (only including versions where I have fixed errors): Page 7 (extra CRLF in the beginning of message): MSRP a786hjs2 SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp Message-ID: 87652 Content-Type: text/plain Hey Bob, are you there? -------a786hjs2$ Page 9 (extra quotes, extra CRLF in the beginning of message): MSRP dkei38sd SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp Message-ID: 456 Byte-Range: 1-4/8 Content-Type: text/plain abcd -------dkei38sd+ MSRP dkei38ia SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp Message-ID: 456 Byte-Range: 5-8/8 Content-Type: text/plain EFGH -------dkei38ia$ Page 35 (whitespace, empty line missing): MSRP d93kswow SEND To-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Content-Type: text/plain Hi, I'm Alice! -------d93kswow$ MSRP d93kswow 200 OK To-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7777/iau39;tcp -------d93kswow$ MSRP dkei38sd SEND To-Path: msrp://alice.example.com:7777/iau39;tcp From-Path: msrp://bob.example.com:8888/9di4ea;tcp Message-ID: 456 Content-Type: text/plain Hi, Alice! I'm Bob! -------dkei38sd$ MSRP dkei38sd 200 OK To-Path: msrp://alice.example.com:7777/iau39;tcp From-Path: msrp://bob.example.com:8888/9di4ea;tcp -------dkei38sd$ Page 36 (whitespace, empty line missing, now torturing with case): Sysadmin->Alice (MSRP): MSRP vZohU+P4 SEND to-path: MSRP://ALICEPC.EXAMPLE.COM:8888/5qWX;TCP from-path: MSRP://EXAMPLE.COM:7777/Cwix;TCP message-id: Z0lHBnF1wDett0nsMfLIvQ report-failure: NO report-success: NO content-type: Text/Plain The system is going down in 5 minutes -------vZohU+P4$ Page 37 (whitespace, SEND instead of REPORT): Alice->Bob (MSRP): MSRP H21vs6Wy SEND To-Path: msrp://bob.example.com:8888/cvDWt3ui;tcp From-Path: msrp://alicepc.example.com:7777/fVTFIykn;tcp Message-ID: 0zt9FDMj+KTE8jGj Report-Success: yes Content-Type: text/html

Here is that important link... foobar

-------H21vs6Wy$ Bob->Alice (MSRP): MSRP H21vs6Wy 200 OK To-Path: msrp://alicepc.example.com:7777/fVTFIykn;tcp From-Path: msrp://bob.example.com:8888/cvDWt3ui;tcp -------H21vs6Wy$ Bob->Alice (MSRP): MSRP Dzu2ddLJ REPORT To-Path: msrp://alicepc.example.com:7777/fVTFIykn;tcp From-Path: msrp://bob.example.com:8888/cvDWt3ui;tcp Message-ID: 0zt9FDMj+KTE8jGj Status: 000 200 OK -------Dzu2ddLJ$ --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 10:16:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17901; Tue, 17 Aug 2004 10:16:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4rA-0004pA-7V; Tue, 17 Aug 2004 10:22:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4go-0001Py-JQ; Tue, 17 Aug 2004 10:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4eU-0000aW-9O for simple@megatron.ietf.org; Tue, 17 Aug 2004 10:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17119 for ; Tue, 17 Aug 2004 10:09:24 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4kS-0004iY-Fz for simple@ietf.org; Tue, 17 Aug 2004 10:15:39 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HE5Sj16893; Tue, 17 Aug 2004 17:05:29 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 17:05:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7HE54cS029095; Tue, 17 Aug 2004 17:05:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00FgTEQi; Tue, 17 Aug 2004 17:05:02 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HE51n11317; Tue, 17 Aug 2004 17:05:01 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 17:04:57 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id A244393B77; Tue, 17 Aug 2004 17:04:57 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7HE4vpZ019667; Tue, 17 Aug 2004 17:04:57 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7HE4tuV019666; Tue, 17 Aug 2004 17:04:55 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Paul Kyzivat Subject: Re: [Simple] Re: MSRP: Content-Type position X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <411D4106.6030905@cisco.com> (Paul Kyzivat's message of "Fri, 13 Aug 2004 18:30:30 -0400") References: <2F4D1A20-ED75-11D8-A01A-0003938AF740@cisco.com> <411D4106.6030905@cisco.com> Date: Tue, 17 Aug 2004 17:04:54 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 17 Aug 2004 14:04:58.0038 (UTC) FILETIME=[2DED6D60:01C48463] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Cullen Jennings , Rohan Mahy , Adam Roach , Robert Sparks , Chris Boulton , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Paul Kyzivat writes: >>> The base spec says Content-Type must be the last header. Hisham asked if >>> we can put in some text to justify that. I am having trouble thinking of >>> a good reason. >>> So, can we remove that assertion completely? If not, can someone justify >>> it? >What is the goal here? I think the syntax makes sure that there is a Content-Type header if and only if there is some actual content. >To have the message parser stop parsing when it gets >to a mime header, so you can switch to using a separate mime header parser >there? Currently, the other MIME headers are before Content-Type: content-stuff = *(Other-Mime-Header CRLF) Content-Type 2CRLF data CRLF If we would like to switch to MIME header parser, we should have content-stuff = Content-Type CRLF *(Other-Mime-Header CRLF) CRLF data CRLF --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 12:33:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27220; Tue, 17 Aug 2004 12:33:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx6zr-0007RO-U9; Tue, 17 Aug 2004 12:39:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx6mb-0000ad-63; Tue, 17 Aug 2004 12:25:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx6Wr-0004Fv-Dw for simple@megatron.ietf.org; Tue, 17 Aug 2004 12:09:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25601 for ; Tue, 17 Aug 2004 12:09:38 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx6cs-0006wj-KU for simple@ietf.org; Tue, 17 Aug 2004 12:15:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HG88B23193; Tue, 17 Aug 2004 19:08:08 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 19:08:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7HG80ix006184; Tue, 17 Aug 2004 19:08:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00WeR24S; Tue, 17 Aug 2004 19:07:57 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HG7un02498; Tue, 17 Aug 2004 19:07:56 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 19:07:55 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id DE71293B6A; Tue, 17 Aug 2004 19:07:54 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7HG7spZ021491; Tue, 17 Aug 2004 19:07:54 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7HG7saK021490; Tue, 17 Aug 2004 19:07:54 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Rohan Mahy Subject: Re: [Simple] message-session-07: why responses? X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3C43BF1D-ED93-11D8-A01A-0003938AF740@cisco.com> (Rohan Mahy's message of "Fri, 13 Aug 2004 18:42:43 -0700") References: <3C43BF1D-ED93-11D8-A01A-0003938AF740@cisco.com> Date: Tue, 17 Aug 2004 19:07:54 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 17 Aug 2004 16:07:55.0699 (UTC) FILETIME=[5B5B2830:01C48474] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi Rohan, >A few things: >- Certain types of errors are more appropriate to inform the requester about >using a response (for example, a 403). >- Responses to SEND requests are hop-by-hop instead of end-to-end like >REPORT requests. This is actually used by different combinations of the >current Report-Success / Report-Failure headers. >- Responses to AUTH are end-to-end. That is actually my main problem, some requests don't generate responses (REPORT, anything with Report-Failure: partial/no), some requests generate hop-by-hop responses, others end-to-end. It looks like things get *interesting* when there is large payload in a REPORT or AUTH or extension request (chunk or not to chunk...). The world would be happier place if an element could always just send a REPORT, syntax would be simpler, there would be less messages, protocol would be more symmetric, no conversion from response to REPORT would be needed etc. etc. Of course, a hop-by-hop REPORT is also *interesting*, like, it probaly has to include either the transact-id or Byte-Range from request it reports. However, the Report-Range (or something) is probably needed by msrp-relay-01++, too, as it introduces the REPORTs that are sent after each received chunk. >We need to use responses to carry the Use-Path information in a >response to an AUTH back to the MSRP Client that sent the AUTH >request. Because the way the authorization works, you can't carry >this information in a REPORT. You would need to send a REPORT >request to a URI that the client didn't know about yet. I don't see any reason why the challenge and/or credential headers or Use-Path could not be transmitted in a special request. For example, it is possible to use AUTH in both directions. An added bonus is that a relay could authenticate itself with the client. Of course, some of these issues must already have been discusssed, but I'll try to catch up with the last 4 months of SIMPLE... --Pekka >On Aug 12, 2004, at 9:13 AM, Pekka Pessi wrote: >> Hello all, >> The current MSRP draft now includes extensive REPORT facilities. I >> wonder why we still keep the responses in the spec? >> During the discussion between Orit and rest of the world last >> spring AFAIR the most compelling reason for hop-by-hop responses >> is that they provide explicit keepalive functionality. When using >> responses, relays have to buffer transactions only until they >> receive application-level confirmation. Without response, relays >> could not get any indication when the next-hop connection failed. >> Could we simply use explicit keepalive messages, say, single-hop >> SEND without body with Report-Success: yes (or PING/PONG a'la IRC >> or HELLO or KEEPALIVE)? An MSRP entity could send such a keepalive >> request any time, and it would know that all the messages sent >> before keepalive were actually received when it receives the >> suitable keepalive reply request. >> Instead of error responses (like 401), we could use REPORT with >> appropriate Status. >> --Pekka >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 12:42:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28188; Tue, 17 Aug 2004 12:42:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx79B-0007j3-24; Tue, 17 Aug 2004 12:49:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx6nB-0000pb-US; Tue, 17 Aug 2004 12:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx6er-0007IE-Eu for simple@megatron.ietf.org; Tue, 17 Aug 2004 12:17:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26117 for ; Tue, 17 Aug 2004 12:17:54 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx6kt-000760-OC for simple@ietf.org; Tue, 17 Aug 2004 12:24:12 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HGHjB05824; Tue, 17 Aug 2004 19:17:45 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 19:16:57 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7HGGvrg018525; Tue, 17 Aug 2004 19:16:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 007kWtUt; Tue, 17 Aug 2004 19:16:49 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HGGiu19521; Tue, 17 Aug 2004 19:16:44 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 19:16:44 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 19:16:44 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 17 Aug 2004 19:16:42 +0300 Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? From: Aki Niemi To: ext Adam Roach In-Reply-To: <4120FE2C.1060008@dynamicsoft.com> References: <4120FE2C.1060008@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092759402.4284.199.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 17 Aug 2004 19:16:42 +0300 X-OriginalArrivalTime: 17 Aug 2004 16:16:44.0241 (UTC) FILETIME=[96644410:01C48475] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , "'Robert Sparks'" , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit On Mon, 2004-08-16 at 21:34, ext Adam Roach wrote: > Schmidt Christian wrote: > > >mobile networks are always interested in increasing efficiency. > Requirements for Presence Service in 3GPP Wireless Systems > (draft-kiss-simple-presence-wireless-reqs-03) contains: > >PUBL-REQ2: Partial publishing > >The publish mechanism must allow a PUA to change only part of the > presentity's presence information. For example, a PUA must be > able to publish one single element of the presentity's PIDF > document, while the document contains several elements. > > > > > > I think Robert's question wasn't whether efficiency is important for > wireless networks -- we all agree that it is -- but whether the existing > mechanisms provided by the publication framework are sufficient. I argue > that they are. > > In particular, the requirement that you cite *is* already satisfied by > the Etag handling in the base PUBLISH specification. Publication of a > tuple without an indicated Etag generates a new stream of publications > that can be composited by the presence server in any way it sees fit. > So, one can trivially set up a system that accepts a new publication > stream which represents a single tuple within a larger presence > document; it is then possible to update that tuple and only that tuple > without having to upload the entire presence document. This is all > completely possible and expected with the current PUBLISH draft. Sure, of course you need to take into account the need to refresh each of the per-tuple publications individually (and the overhead that generates), plus the extra state required to handle those publications and their etags. Just to say that there are costs in all optimisations, generally. > Personally, I have rather strong feelings that the partial publication > work imposes substantial complexity on the system while providing an > insignificant improvement in overall system efficiency. I believe that > our efforts are best spent elsewhere. Our efforts? While I agree with the complexity argument (seems like an inevitable side-effect of optimisation), I have a hard time understanding the reluctance to adopt or progress not only this but many of the "optimisations", including partial-notify, event-filter, and event throttle to name some of them. After all, these are all optional features and no-one is required to implement them. Since these drafts all have authors willing to work on them, it would seem most of the concerns about scarce WG efforts spent on them are already go away. They also seem to have community support (especially in the mobile domain), so why not let them be progressed and get them over with. We could even progress them as experimental to reflect the fact that the community had concerns about the cost vs. benefit of the mechanism? Cheers, AKi > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 12:49:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28811; Tue, 17 Aug 2004 12:49:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7FT-0007uf-QT; Tue, 17 Aug 2004 12:55:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx750-000554-7c; Tue, 17 Aug 2004 12:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx70U-0003Oc-6K for simple@megatron.ietf.org; Tue, 17 Aug 2004 12:40:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27932 for ; Tue, 17 Aug 2004 12:40:15 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx76U-0007dS-HB for simple@ietf.org; Tue, 17 Aug 2004 12:46:33 -0400 Received: from [63.110.3.172] ([63.110.3.172]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7HGe6tB098784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2004 11:40:07 -0500 (CDT) (envelope-from adam@dynamicsoft.com) Message-ID: <412234D7.9090201@dynamicsoft.com> Date: Tue, 17 Aug 2004 11:39:51 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? References: <4120FE2C.1060008@dynamicsoft.com> <1092759402.4284.199.camel@hed039-226.research.nokia.com> In-Reply-To: <1092759402.4284.199.camel@hed039-226.research.nokia.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , "'Robert Sparks'" , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Aki Niemi wrote: >Our efforts? While I agree with the complexity argument (seems like an >inevitable side-effect of optimisation), I have a hard time >understanding the reluctance to adopt or progress not only this but many >of the "optimisations", including partial-notify, event-filter, and >event throttle to name some of them. After all, these are all optional >features and no-one is required to implement them. > >Since these drafts all have authors willing to work on them, it would >seem most of the concerns about scarce WG efforts spent on them are >already go away. They also seem to have community support (especially in >the mobile domain), so why not let them be progressed and get them over >with. > > These arguments could equally be applied to previous efforts to define a PHONECTRL verb (for IR remote control of phones), a TRANSFER verb (for a very limited subset of what REFER allows), an "Also" header for use with BYE (for a very limited subset of what TRANSFER would have allowed), a PING verb (which probably wouldn't have worked for its intended purpose), a DO verb (which would have allowed you to turn on and off your lamp, even if it roams onto another network -- because everyone knows that rendezvous is an important feature if you don't know where your appliances might end up), several different binary encodings for SIP, and a host of other ill-conceived ideas. My point is that "people are willing to work on it" is a necessary condition for any work item, but it is far from sufficient. The work item must also represent a good idea that fits with the precepts of the protocol -- such as "generality over efficiency" (cf. TRANSFER). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 12:57:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29310; Tue, 17 Aug 2004 12:57:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7Mk-00083x-DV; Tue, 17 Aug 2004 13:03:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7AP-0006IO-FO; Tue, 17 Aug 2004 12:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx79z-00063u-Pv for simple@megatron.ietf.org; Tue, 17 Aug 2004 12:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28850 for ; Tue, 17 Aug 2004 12:50:04 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7G2-0007un-A8 for simple@ietf.org; Tue, 17 Aug 2004 12:56:22 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Aug 2004 09:53:06 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7HGnXo4014280; Tue, 17 Aug 2004 09:49:34 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWH32909; Tue, 17 Aug 2004 09:48:22 -0700 (PDT) In-Reply-To: References: <3C43BF1D-ED93-11D8-A01A-0003938AF740@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] message-session-07: why responses? Date: Tue, 17 Aug 2004 09:51:37 -0700 To: Pekka Pessi X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Hi Pekka, On Aug 17, 2004, at 9:07 AM, Pekka Pessi wrote: > Hi Rohan, > >> A few things: > >> - Certain types of errors are more appropriate to inform the >> requester about >> using a response (for example, a 403). > >> - Responses to SEND requests are hop-by-hop instead of end-to-end like >> REPORT requests. This is actually used by different combinations of >> the >> current Report-Success / Report-Failure headers. > >> - Responses to AUTH are end-to-end. > > That is actually my main problem, some requests don't generate > responses (REPORT, anything with Report-Failure: partial/no), some > requests generate hop-by-hop responses, others end-to-end. It > looks like things get *interesting* when there is large payload in > a REPORT or AUTH or extension request (chunk or not to chunk...). The spec forbids sending contents larger than 2k in anything other than a SEND request. You MUST NOT chunk a REPORT or AUTH request. > The world would be happier place if an element could always just > send a REPORT, syntax would be simpler, there would be less > messages, protocol would be more symmetric, no conversion from > response to REPORT would be needed etc. etc. Because of chunking, some intermediate relays need to keep a little bit of state. Without hop-by-hop responses, these relays cannot clean up. If you banned response codes completely, you would still need something to carry the hop-by-hop status of send requests. You could call this a RESPONSE request if you liked. You could also try to combine this with the existing semantics of REPORT, but then you would need to add additional headers that the client would have to look at to figure out what the REPORT was about, and relays would still need to *convert* between one type of REPORT and another. I don't see any benefit there. > Of course, a hop-by-hop REPORT is also *interesting*, like, it > probaly has to include either the transact-id or Byte-Range from > request it reports. However, the Report-Range (or something) is > probably needed by msrp-relay-01++, too, as it introduces the > REPORTs that are sent after each received chunk. Probably I should have mentioned the separation of semantics between responses and REPORTs. I'm sorry I did not bring it up as it may help illustrate why these can be cleanly separated. Responses carry information about the status of a *transaction*. REPORT requests carry information about the delivery of a *complete message*. The REPORT always contains the Message ID. (The transaction ID of the last hop is meaningless to the original sender in an environment with any relays). I can already say in a REPORT that the message was abandoned at byte-range position 573,482. The Byte-Range header is just carried in the report. >> We need to use responses to carry the Use-Path information in a >> response to an AUTH back to the MSRP Client that sent the AUTH >> request. Because the way the authorization works, you can't carry >> this information in a REPORT. You would need to send a REPORT >> request to a URI that the client didn't know about yet. > > I don't see any reason why the challenge and/or credential headers > or Use-Path could not be transmitted in a special request. I don't see any *benefit* to using a separate request either. You still need to send the request over the same path over which you received it. You now need an *additional* header to carry the transaction-id of the original request. All the same restrictions and requirements are there. Congratulations, you just added zero value to the protocol and you had to carry around an additional now meaningless psuedo-random identifier. Furthermore, the semantics are that the transaction succeeded or failed. That's what responses are for. > For > example, it is possible to use AUTH in both directions. An added > bonus is that a relay could authenticate itself with the client. It does not make sense to use AUTH in both directions. The relay already authenticates to the client by providing a certificate in the initial TLS exchange. The semantics of the AUTH request is that a client is requesting authorization of a URL on the relay. thanks, -rohan > Of course, some of these issues must already have been discusssed, > but I'll try to catch up with the last 4 months of SIMPLE... > > --Pekka > >> On Aug 12, 2004, at 9:13 AM, Pekka Pessi wrote: > >>> Hello all, > >>> The current MSRP draft now includes extensive REPORT facilities. I >>> wonder why we still keep the responses in the spec? > >>> During the discussion between Orit and rest of the world last >>> spring AFAIR the most compelling reason for hop-by-hop responses >>> is that they provide explicit keepalive functionality. When using >>> responses, relays have to buffer transactions only until they >>> receive application-level confirmation. Without response, relays >>> could not get any indication when the next-hop connection failed. > >>> Could we simply use explicit keepalive messages, say, single-hop >>> SEND without body with Report-Success: yes (or PING/PONG a'la IRC >>> or HELLO or KEEPALIVE)? An MSRP entity could send such a keepalive >>> request any time, and it would know that all the messages sent >>> before keepalive were actually received when it receives the >>> suitable keepalive reply request. > >>> Instead of error responses (like 401), we could use REPORT with >>> appropriate Status. > >>> --Pekka > >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 13:13:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00413; Tue, 17 Aug 2004 13:13:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7d7-0008QY-UK; Tue, 17 Aug 2004 13:20:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Tl-00012j-Ba; Tue, 17 Aug 2004 13:10:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7ME-0008CF-D5 for simple@megatron.ietf.org; Tue, 17 Aug 2004 13:02:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29664 for ; Tue, 17 Aug 2004 13:02:43 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7SG-0008Ap-4D for simple@ietf.org; Tue, 17 Aug 2004 13:09:01 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HH2d304217; Tue, 17 Aug 2004 20:02:39 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 20:02:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7HH2DIC003532; Tue, 17 Aug 2004 20:02:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00WRV2nV; Tue, 17 Aug 2004 20:02:11 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HH2An17685; Tue, 17 Aug 2004 20:02:10 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 20:02:07 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 17 Aug 2004 20:02:06 +0300 Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? From: Aki Niemi To: ext Adam Roach In-Reply-To: <412234D7.9090201@dynamicsoft.com> References: <4120FE2C.1060008@dynamicsoft.com> <1092759402.4284.199.camel@hed039-226.research.nokia.com> <412234D7.9090201@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092762126.4284.301.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 17 Aug 2004 20:02:06 +0300 X-OriginalArrivalTime: 17 Aug 2004 17:02:07.0650 (UTC) FILETIME=[EDAB8020:01C4847B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , "'Robert Sparks'" , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Tue, 2004-08-17 at 19:39, ext Adam Roach wrote: > These arguments could equally be applied to previous efforts to define a > PHONECTRL verb (for IR remote control of phones), a TRANSFER verb (for a > very limited subset of what REFER allows), an "Also" header for use with > BYE (for a very limited subset of what TRANSFER would have allowed), a > PING verb (which probably wouldn't have worked for its intended > purpose), a DO verb (which would have allowed you to turn on and off > your lamp, even if it roams onto another network -- because everyone > knows that rendezvous is an important feature if you don't know where > your appliances might end up), several different binary encodings for > SIP, and a host of other ill-conceived ideas. Each of which can demonstratively be shown to either be broken, or have a more general solution. You have not shown either in this case. Yes, partial-publish adds complexity, but is not broken. Per-tuple publication is no more general (still presence-specific) - just different. > My point is that "people are willing to work on it" is a necessary > condition for any work item, but it is far from sufficient. The work > item must also represent a good idea that fits with the precepts of the > protocol -- such as "generality over efficiency" (cf. TRANSFER). With the exception of course that there is no solution available that would be more general, except the obvious one. (Personally, partial *should* have been part of PIDF from the very beginning but that's too late now...) Cheers, Aki > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 13:16:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00723; Tue, 17 Aug 2004 13:16:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7fv-0008VL-77; Tue, 17 Aug 2004 13:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Tr-00014q-Oz; Tue, 17 Aug 2004 13:10:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Og-0000B7-7A for simple@megatron.ietf.org; Tue, 17 Aug 2004 13:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29847 for ; Tue, 17 Aug 2004 13:05:15 -0400 (EDT) Received: from mail.mis.stn.net ([216.191.62.13] helo=fortuna.stn.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7Ui-0008Ep-0t for simple@ietf.org; Tue, 17 Aug 2004 13:11:33 -0400 Received: from [216.191.63.209] (helo=jedi) by fortuna.stn.net with esmtp (Exim 4.20) id 1Bx7Oc-0001mL-H0 for simple@ietf.org; Tue, 17 Aug 2004 13:05:15 -0400 From: "Peter Ridler" To: Date: Tue, 17 Aug 2004 13:05:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSEfFcH3YNVebp7RCOLjdR4aLAxdg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP when used with SIP/SDP inconsistent with RFC2327 ABNF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hi all, In the draft-ietf-simple-messages-sessions-07.txt Section 7.1 uses "accept-types" in the attribute-fields (the a= line) where RFC2327 defines attribute as: attribute-fields = *("a=" attribute CRLF) attribute = (att-field ":" att-value) / att-field att-field = 1*(alpha-numeric) att-value = byte-string Note that "att-field" only allows for alpha-numeric field names which would make "accept-types" illegal. Maybe the name should be changed to "AcceptTypes" or something to conform. Also, Why is the path attribute used and not the media-field (m= line) used as described in the RFC2327 standard? I see that the path can have multiple urls defined but I don't see no more then one ever being used! SIP controls the call/session information between the endpoints, MSRP should not have to resolve the communication paths again. Peter Ridler _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 13:17:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00794; Tue, 17 Aug 2004 13:17:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7gz-000056-8P; Tue, 17 Aug 2004 13:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Ts-00014v-Ak; Tue, 17 Aug 2004 13:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Og-0000B9-BG for simple@megatron.ietf.org; Tue, 17 Aug 2004 13:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29849 for ; Tue, 17 Aug 2004 13:05:15 -0400 (EDT) Received: from mail.mis.stn.net ([216.191.62.13] helo=fortuna.stn.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7Uj-0008Eu-1x for simple@ietf.org; Tue, 17 Aug 2004 13:11:33 -0400 Received: from [216.191.63.209] (helo=jedi) by fortuna.stn.net with esmtp (Exim 4.20) id 1Bx7Od-0001mL-MB for simple@ietf.org; Tue, 17 Aug 2004 13:05:16 -0400 From: "Peter Ridler" To: Date: Tue, 17 Aug 2004 13:05:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSEfE6TOuLKlRS7SSSBAxN5SpvApQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP - ABNF corrections and changes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Hi all, I have come in late to the group, so please forgive me in stating something that has already be addressed and resolved before. I am building this code into my test apps and have focused on the ABNF. I know there has been some discussion on this already. I have run it through my ABNF parser and found some of the syntax errors already discussed. I have also found other problems relating to references to other RFC's. I have made many changes/corrections (nits) but have some real comments to follow: In the draft-ietf-simple-messages-sessions-07.txt Section 5 "MSRP URLs" refers to sections from RFC RFC2396. RFC2396 has syntax/logic errors so I recommend we define the MSRP-url in our own ABNF (of course following other RFC standards as much as possible) as what was done in SIP(RFC3261). My attachment contains that ABNF code. Note that RFC2396 (as well RFC3261) has logic errors in its hostname/domainlabel/toplabel definitions -- I used the logic from RFC1035 (converted to ABNF). Another reason for imbedding the URL ABNF is that MSRP does not allow escaping where the other RFC's do. I also removed the ":" from the userinfo (RFC2396) as this is the password lead-in char and "a userinfo part MUST NOT contain password information" in the MSRP-url. .-.-.-.-.-.-.-.-.-.-.-.-.- I completed some ABNF code defining namespace, short-status, and text-reason for the definition of "Status". .-.-.-.-.-.-.-.-.-.-.-.-.- Three syntax lines of interest: msrp-request = req-start headers [content-stuff] end-line content-stuff = *(Other-Mime-Header CRLF) Content-Type 2CRLF data CRLF data = *OCTET The definition of "data" states ZERO to INFINITY, and assuming that we have defined a MSRP message limit, then data will eat up all the bytes of information AND the CRLF of "content-stuff" as well as the "end-line" message as well. "data" must have some bounds defined for it! Also content-stuff is OPTIONAL, therefore, "Content-Type" is also OPTIONAL. >From my point of view I see a need of a little change to the message. Consider the following: Put all message control portions in a message header and the payload strictly data. This way when the message is received via TCP the message header can be easily found in the stream (the double CRLF sequences) and used to define the size/type of the data following (if any). msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-start headers CRLF [ data ] msrp-response = resp-start headers CRLF "Content-Type" and "Continuation-Flag" should be in the "headers" definition ADD "Content-Length" to the "headers" to state the length of the message payload and MUST be in every MSRP message. Although "headers" are optional in the ABNF syntax -- enforcement of the headers within the different messages can be specified in the RFC requirements for message validation. This would simplify the parsing of the message. .-.-.-.-.-.-.-.-.-.-.-.-.- Peter Ridler _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 13:25:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01457; Tue, 17 Aug 2004 13:25:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7oi-0000Fs-4i; Tue, 17 Aug 2004 13:32:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Wb-0001fv-An; Tue, 17 Aug 2004 13:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Sx-0000qm-8d for simple@megatron.ietf.org; Tue, 17 Aug 2004 13:09:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00121 for ; Tue, 17 Aug 2004 13:09:40 -0400 (EDT) Received: from mail.mis.stn.net ([216.191.62.13] helo=fortuna.stn.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7Yz-0008LD-2i for simple@ietf.org; Tue, 17 Aug 2004 13:15:58 -0400 Received: from [216.191.63.209] (helo=jedi) by fortuna.stn.net with esmtp (Exim 4.20) id 1Bx7Ss-0005dC-ST for simple@ietf.org; Tue, 17 Aug 2004 13:09:39 -0400 From: "Peter Ridler" To: Date: Tue, 17 Aug 2004 13:09:41 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C4845B.75AC1A00" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSEfPdpmZLFGpnnRAW9ucrL1IY9jg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Subject: [Simple] MSRP - ABNF corrections and changes -- Attachment X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4845B.75AC1A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry -- forgot attachment! Hi all, I have come in late to the group, so please forgive me in stating something that has already be addressed and resolved before. I am building this code into my test apps and have focused on the ABNF. I know there has been some discussion on this already. I have run it through my ABNF parser and found some of the syntax errors already discussed. I have also found other problems relating to references to other RFC's. I have made many changes/corrections (nits) but have some real comments to follow: In the draft-ietf-simple-messages-sessions-07.txt Section 5 "MSRP URLs" refers to sections from RFC RFC2396. RFC2396 has syntax/logic errors so I recommend we define the MSRP-url in our own ABNF (of course following other RFC standards as much as possible) as what was done in SIP(RFC3261). My attachment contains that ABNF code. Note that RFC2396 (as well RFC3261) has logic errors in its hostname/domainlabel/toplabel definitions -- I used the logic from RFC1035 (converted to ABNF). Another reason for imbedding the URL ABNF is that MSRP does not allow escaping where the other RFC's do. I also removed the ":" from the userinfo (RFC2396) as this is the password lead-in char and "a userinfo part MUST NOT contain password information" in the MSRP-url. .-.-.-.-.-.-.-.-.-.-.-.-.- I completed some ABNF code defining namespace, short-status, and text-reason for the definition of "Status". .-.-.-.-.-.-.-.-.-.-.-.-.- Three syntax lines of interest: msrp-request = req-start headers [content-stuff] end-line content-stuff = *(Other-Mime-Header CRLF) Content-Type 2CRLF data CRLF data = *OCTET The definition of "data" states ZERO to INFINITY, and assuming that we have defined a MSRP message limit, then data will eat up all the bytes of information AND the CRLF of "content-stuff" as well as the "end-line" message as well. "data" must have some bounds defined for it! Also content-stuff is OPTIONAL, therefore, "Content-Type" is also OPTIONAL. >From my point of view I see a need of a little change to the message. Consider the following: Put all message control portions in a message header and the payload strictly data. This way when the message is received via TCP the message header can be easily found in the stream (the double CRLF sequences) and used to define the size/type of the data following (if any). msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-start headers CRLF [ data ] msrp-response = resp-start headers CRLF "Content-Type" and "Continuation-Flag" should be in the "headers" definition ADD "Content-Length" to the "headers" to state the length of the message payload and MUST be in every MSRP message. Although "headers" are optional in the ABNF syntax -- enforcement of the headers within the different messages can be specified in the RFC requirements for message validation. This would simplify the parsing of the message. .-.-.-.-.-.-.-.-.-.-.-.-.- Peter Ridler ------=_NextPart_000_0000_01C4845B.75AC1A00 Content-Type: application/octet-stream; name="MsrpParser.bnf" Content-Disposition: attachment; filename="MsrpParser.bnf" Content-Transfer-Encoding: quoted-printable %start msrp-req-or-resp %import Rfc2183 %% alphanum =3D ALPHA / DIGIT UPALPHA =3D %x41-5A MSRP-url =3D msrp-scheme "://" [userinfo "@"] hostport ["/" resource] = ";" transport msrp-scheme =3D "msrp" / "msrps" resource =3D 1*unreserved transport =3D "tcp" / token hostport =3D host [ ":" port ] host =3D hostname / IPv4address hostname =3D label *( "." label ) ; defined as in RFC1035 label =3D ALPHA *ldh-str ldh-str =3D let-dig / let-dig-hyp let-dig let-dig-hyp =3D let-dig / "-" let-dig =3D ALPHA / DIGIT IPv4address =3D 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT port =3D 1*DIGIT userinfo =3D 1*( unreserved / ";" / "&" / "=3D" / "+" / "$" / "," ) unreserved =3D alphanum / "-" / "_" / "." / "!" / "~" / "*" / "'" / = "(" / ")" msrp-req-or-resp =3D msrp-request / msrp-response msrp-request =3D req-start headers [content-stuff] end-line msrp-response =3D resp-start headers end-line req-start =3D pMSRP SP transact-id SP method CRLF resp-start =3D pMSRP SP transact-id SP status-code [SP phrase] CRLF phrase =3D utf8text pMSRP =3D %x4d.53.52.50 ; MSRP in caps transact-id =3D ident method =3D mSEND / mREPORT / other-method mSEND =3D %x53.45.4e.44 ; SEND in caps mREPORT =3D %x52.45.50.4f.52.54; REPORT in caps other-method =3D 1*UPALPHA status-code =3D 3DIGIT headers =3D 1*( header CRLF ) header =3D To-Path / From-Path / Message-ID / Report-Success / Report-Failure / Byte-Range / Status / entity-headers ; defined in RFC 2045 (Mime-Header) / ext-header To-Path =3D "To-Path:" SP MSRP-url *( SP MSRP-url ) From-Path =3D "From-Path:" SP MSRP-url *( SP MSRP-url ) Message-ID =3D "Message-ID:" SP ident Report-Success =3D "Report-Success:" SP ("yes" / "no" ) Report-Failure =3D "Report-Failure:" SP ("yes" / "no" / "partial" ) Byte-Range =3D "Byte-Range:" SP range-start "-" range-end "/" total range-start =3D 1*DIGIT range-end =3D 1*DIGIT / "*" total =3D 1*DIGIT / "*" Status =3D "Status:" SP namespace SP short-status [SP text-reason] namespace =3D "000" short-status =3D "200" ; OK / "400" ; Bad Request / "403" ; Forbidden / "415" ; Unsupported Media Type / "426" ; Request is only allowed over TLS / "481" ; Session Does Not Exist / "506" ; Request already bound on another connection text-reason =3D *(VCHAR / WSP) ; All visible charcters / SP / HTAB = (defined in RFC2234 core) ident =3D alphanum 3*31ident-char ident-char =3D alphanum / "." / "-" / "+" / "%" / "=3D" content-stuff =3D *(Other-Mime-Header CRLF) Content-Type 2CRLF data CRLF Content-Type =3D "Content-Type:" SP media-type media-type =3D type "/" subtype *( ";" gen-param ) type =3D token subtype =3D token gen-param =3D pname [ "=3D" pval ] pname =3D token pval =3D token / quoted-string token =3D 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+") quoted-string =3D DQUOTE *(qdtext / qd-esc) DQUOTE qdtext =3D SP / HTAB / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII qd-esc =3D (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) BACKSLASH =3D "\" Other-Mime-Header =3D id ; Content-ID defined in = RFC2045 / description ; Content-Description defined = in RFC2045 / disposition ; Content-Disposition defined = in RFC2183 / MIME-extension-field ; defined in RFC2045 data =3D *OCTET end-line =3D "-------" transact-id continuation-flag CRLF continuation-flag =3D "+" / "$" ext-header =3D hname ":" SP hval CRLF hname =3D ALPHA *token hval =3D utf8text utf8text =3D *(HTAB / %x20-7E / UTF8-NONASCII) UTF8-NONASCII =3D %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT =3D %x80-BF ------=_NextPart_000_0000_01C4845B.75AC1A00 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=_NextPart_000_0000_01C4845B.75AC1A00-- From simple-bounces@ietf.org Tue Aug 17 13:31:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01753; Tue, 17 Aug 2004 13:31:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7ti-0000MK-09; Tue, 17 Aug 2004 13:37:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7gk-0003Mp-8O; Tue, 17 Aug 2004 13:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx7Vu-0001Y1-RE for simple@megatron.ietf.org; Tue, 17 Aug 2004 13:12:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00287 for ; Tue, 17 Aug 2004 13:12:43 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx7bw-0008Os-KF for simple@ietf.org; Tue, 17 Aug 2004 13:19:02 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HHACj27545; Tue, 17 Aug 2004 20:10:13 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 20:09:53 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7HH9rtB032624; Tue, 17 Aug 2004 20:09:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00vbJiQw; Tue, 17 Aug 2004 20:09:50 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7HH9nn24610; Tue, 17 Aug 2004 20:09:49 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 20:09:48 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 17 Aug 2004 20:09:47 +0300 Subject: Re: [Simple] message-session-07: why responses? From: Aki Niemi To: ext Rohan Mahy In-Reply-To: References: <3C43BF1D-ED93-11D8-A01A-0003938AF740@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092762587.4284.308.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 17 Aug 2004 20:09:47 +0300 X-OriginalArrivalTime: 17 Aug 2004 17:09:48.0734 (UTC) FILETIME=[007F55E0:01C4847D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Tue, 2004-08-17 at 19:51, ext Rohan Mahy wrote: snip--- > > The world would be happier place if an element could always just > > send a REPORT, syntax would be simpler, there would be less > > messages, protocol would be more symmetric, no conversion from > > response to REPORT would be needed etc. etc. > > Because of chunking, some intermediate relays need to keep a little bit > of state. Without hop-by-hop responses, these relays cannot clean up. Keep this state for what? For being able to retransmit, over TCP? Can't the upstream node at least push back with a 4xx response, or is 2xx the only one ever coming back? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 14:00:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03825; Tue, 17 Aug 2004 14:00:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx8Lt-0000yE-AH; Tue, 17 Aug 2004 14:06:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx8Bw-0001A3-Qi; Tue, 17 Aug 2004 13:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx86q-0000Tz-NO for simple@megatron.ietf.org; Tue, 17 Aug 2004 13:50:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03094 for ; Tue, 17 Aug 2004 13:50:55 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx8Cr-0000mz-JZ for simple@ietf.org; Tue, 17 Aug 2004 13:57:12 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Aug 2004 10:53:53 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7HHoKs9017119; Tue, 17 Aug 2004 10:50:20 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AWH40597; Tue, 17 Aug 2004 10:49:08 -0700 (PDT) In-Reply-To: <1092762587.4284.308.camel@hed039-226.research.nokia.com> References: <3C43BF1D-ED93-11D8-A01A-0003938AF740@cisco.com> <1092762587.4284.308.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <31BAA8AC-F076-11D8-A776-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] message-session-07: why responses? Date: Tue, 17 Aug 2004 10:52:23 -0700 To: Aki Niemi X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.3 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , Rohan Mahy , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On Aug 17, 2004, at 10:09 AM, Aki Niemi wrote: > On Tue, 2004-08-17 at 19:51, ext Rohan Mahy wrote: > snip--- >>> The world would be happier place if an element could always just >>> send a REPORT, syntax would be simpler, there would be less >>> messages, protocol would be more symmetric, no conversion from >>> response to REPORT would be needed etc. etc. >> >> Because of chunking, some intermediate relays need to keep a little >> bit >> of state. Without hop-by-hop responses, these relays cannot clean up. > > Keep this state for what? For being able to retransmit, over TCP? Can't > the upstream node at least push back with a 4xx response, or is 2xx the > only one ever coming back? There are two categories of state. For a relay just forwarding requests, but offering Report-Failure: yes, the relay needs to keep track of the sending URL for a specific message-id. If the relay receives a negative response on a specific message-id, it needs to generate a REPORT back to the originator. When rechunking, the relay also needs to buffer the incoming message, keep track of which byte-ranges have been received and which have not, deal with out-of-order chunks. The relay needs the hop-by-hop positive responses to figure out when it can flush various parts of its buffers. thanks, -rohan > Cheers, > Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 17 14:48:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06858; Tue, 17 Aug 2004 14:48:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx96s-0001uq-Fg; Tue, 17 Aug 2004 14:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx8xk-0001Bu-82; Tue, 17 Aug 2004 14:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx8tz-0000FI-Qw for simple@megatron.ietf.org; Tue, 17 Aug 2004 14:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06544 for ; Tue, 17 Aug 2004 14:41:42 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx902-0001n0-FM for simple@ietf.org; Tue, 17 Aug 2004 14:47:59 -0400 Received: from [63.110.3.172] ([63.110.3.172]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7HIfXmW008794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2004 13:41:33 -0500 (CDT) (envelope-from adam@dynamicsoft.com) Message-ID: <4122514C.9050109@dynamicsoft.com> Date: Tue, 17 Aug 2004 13:41:16 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? References: <4120FE2C.1060008@dynamicsoft.com> <1092759402.4284.199.camel@hed039-226.research.nokia.com> <412234D7.9090201@dynamicsoft.com> <1092762126.4284.301.camel@hed039-226.research.nokia.com> In-Reply-To: <1092762126.4284.301.camel@hed039-226.research.nokia.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , "'Robert Sparks'" , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Aki Niemi wrote: >On Tue, 2004-08-17 at 19:39, ext Adam Roach wrote: > > >>These arguments could equally be applied to previous efforts to define a >>PHONECTRL verb (for IR remote control of phones), a TRANSFER verb (for a >>very limited subset of what REFER allows), an "Also" header for use with >>BYE (for a very limited subset of what TRANSFER would have allowed), a >>PING verb (which probably wouldn't have worked for its intended >>purpose), a DO verb (which would have allowed you to turn on and off >>your lamp, even if it roams onto another network -- because everyone >>knows that rendezvous is an important feature if you don't know where >>your appliances might end up), several different binary encodings for >>SIP, and a host of other ill-conceived ideas. >> >> > >Each of which can demonstratively be shown to either be broken, or have >a more general solution. You have not shown either in this case. > My argument is *precisely* that multiple publication streams for a resource is a more general solution that allows publication of part of a presence document. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 18 05:31:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21112; Wed, 18 Aug 2004 05:31:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxMtK-0000MU-KY; Wed, 18 Aug 2004 05:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxMeM-0002sX-3u; Wed, 18 Aug 2004 05:22:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxMYK-0001hl-6d for simple@megatron.ietf.org; Wed, 18 Aug 2004 05:16:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20137 for ; Wed, 18 Aug 2004 05:16:14 -0400 (EDT) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxMeU-0008Vo-Mu for simple@ietf.org; Wed, 18 Aug 2004 05:22:40 -0400 Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for simple@ietf.org; Wed, 18 Aug 2004 11:15:41 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 11:15:41 +0200 Message-Id: <32BCBA960C20EB408F4BE7658522620D05B77670@G9JJX.mgb01.telekom.de> From: "Alexeitsev, D" To: simple@ietf.org Date: Wed, 18 Aug 2004 11:15:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Simple] Policies and Events X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hello All Was it considered to unify the policy XML document with the related state event XML document (for example watcher auth)? In such scenario a presentity would receive event XML document in a NOTIFY, change the state to "accepted" and upload it as a policy document or a fragment. In the current situation where policy and event documents are separated there is an additional need to define transitions between the states depending on the values in the policy document. Or is it considered obvious? Greetings, Denis Alexeitsev _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 18 05:36:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21331; Wed, 18 Aug 2004 05:36:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxMy7-0000SS-0y; Wed, 18 Aug 2004 05:42:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxMnv-0004Nx-0H; Wed, 18 Aug 2004 05:32:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxMiF-0003Ql-B0 for simple@megatron.ietf.org; Wed, 18 Aug 2004 05:26:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20884 for ; Wed, 18 Aug 2004 05:26:29 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxMoQ-0000HZ-09 for simple@ietf.org; Wed, 18 Aug 2004 05:32:55 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I9Phj10065; Wed, 18 Aug 2004 12:25:48 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 12:24:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7I9OLJo029105; Wed, 18 Aug 2004 12:24:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00KtuV5J; Wed, 18 Aug 2004 12:24:19 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I9OIn20944; Wed, 18 Aug 2004 12:24:18 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 12:24:15 +0300 Received: esebe013.ntc.nokia.com 172.21.138.52 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by esebe013.ntc.nokia.com; 18 Aug 2004 12:24:15 +0300 Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? From: Aki Niemi To: ext Adam Roach In-Reply-To: <4122514C.9050109@dynamicsoft.com> References: <4120FE2C.1060008@dynamicsoft.com> <1092759402.4284.199.camel@hed039-226.research.nokia.com> <412234D7.9090201@dynamicsoft.com> <1092762126.4284.301.camel@hed039-226.research.nokia.com> <4122514C.9050109@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092821055.11480.28.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 18 Aug 2004 12:24:15 +0300 X-OriginalArrivalTime: 18 Aug 2004 09:24:15.0540 (UTC) FILETIME=[216DEF40:01C48505] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , "'Robert Sparks'" , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit On Tue, 2004-08-17 at 21:41, ext Adam Roach wrote: > My argument is *precisely* that multiple publication streams for a > resource is a more general solution that allows publication of part of a > presence document. And my argument is that it is no more general - just different. Even worse, it makes things complicated. Consider those presence elements that are siblings of - does each PUA need to include them all, or just one of them? How can the composer tell apart presence-level attributes from completely different sources? Each front-end PUA also needs to refresh its segment individually - even if some other tuple has been updated in the mean time. Also, the PUBLISH specification contains the notion of a PUA being an entity, which is responsible for publication of all state it is aware of. This property is confused by artificially creating a number of PUAs. In practice, tuple-ids are no longer useful for identification, since they are only supposed to be unique within a single PIDF document. This complicates things for the composer. None of these problems exist for the partial-publish, and in some sense partial-publish is the more general solution, since it reuses the MIME type and semantics of partial-notify. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 18 17:18:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19135; Wed, 18 Aug 2004 17:18:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxXvc-0002MH-7h; Wed, 18 Aug 2004 17:25:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxXGY-0002vR-QW; Wed, 18 Aug 2004 16:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxWFB-0008AA-SS for simple@megatron.ietf.org; Wed, 18 Aug 2004 15:37:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01876 for ; Wed, 18 Aug 2004 15:36:28 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxWKo-0004Qv-VP for simple@ietf.org; Wed, 18 Aug 2004 15:42:59 -0400 Received: from [192.168.0.100] (adsl-209-30-32-144.dsl.rcsntx.swbell.net [209.30.32.144]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7IJaHkl024693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2004 14:36:19 -0500 (CDT) (envelope-from adam@dynamicsoft.com) Message-ID: <4123AFA3.5060606@dynamicsoft.com> Date: Wed, 18 Aug 2004 14:36:03 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: AW: [Simple] Please comment: Do we want to take on partial public ation? References: <4120FE2C.1060008@dynamicsoft.com> <1092759402.4284.199.camel@hed039-226.research.nokia.com> <412234D7.9090201@dynamicsoft.com> <1092762126.4284.301.camel@hed039-226.research.nokia.com> <4122514C.9050109@dynamicsoft.com> <1092821055.11480.28.camel@hed039-226.research.nokia.com> In-Reply-To: <1092821055.11480.28.camel@hed039-226.research.nokia.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , "'Robert Sparks'" , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Aki Niemi wrote: >On Tue, 2004-08-17 at 21:41, ext Adam Roach wrote: > > >>My argument is *precisely* that multiple publication streams for a >>resource is a more general solution that allows publication of part of a >>presence document. >> >> > >And my argument is that it is no more general - just different. Even >worse, it makes things complicated. Consider those presence elements >that are siblings of - does each PUA need to include them all, >or just one of them? > These are general questions about presence publication that we're finally getting some traction on in the presence team. They're certainly not specific to the problem at hand. > How can the composer tell apart presence-level >attributes from completely different sources? > > Isn't this part of the reason that we're moving towards having device identifiers in presence documents? >None of these problems exist for the partial-publish, and in some sense >partial-publish is the more general solution, since it reuses the MIME >type and semantics of partial-notify. > > I guess I haven't been particularly clear in my logic in asserting *why* the existing solution is more general purpose. What you are proposing is specific to presence documents. If someone wanted to come up with some way to do the same thing for alternate event packages, they'd have to do a whole new partial publish specification for it. On the other hand, using the existing PUBLISH framework, contributing multiple streams of state for a single resource is built-in to the protocol. Exactly how these streams are composed into a single event state is the job of the notifier, and is completely a matter of local policy. This is precisely where different implementations can differentiate themselves. So, in short, what's already specified for PUBLISH works for all event packages, both existing and future. The partial publication work you propose works for precisely one event package. The comparative generalities should be fairly obvious. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 19 03:19:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07962; Thu, 19 Aug 2004 03:19:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxhJL-0005Dq-Dl; Thu, 19 Aug 2004 03:26:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxhBg-0007C2-0H; Thu, 19 Aug 2004 03:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxhAx-00077U-Qq for simple@megatron.ietf.org; Thu, 19 Aug 2004 03:17:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07815 for ; Thu, 19 Aug 2004 03:17:30 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxhHL-0005BA-8P for simple@ietf.org; Thu, 19 Aug 2004 03:24:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7J7Fnv22494; Thu, 19 Aug 2004 10:16:19 +0300 (EET DST) X-Scanned: Thu, 19 Aug 2004 10:14:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7J7EUXo004716; Thu, 19 Aug 2004 10:14:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003WSRTi; Thu, 19 Aug 2004 10:14:28 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7J7EMu23710; Thu, 19 Aug 2004 10:14:22 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 19 Aug 2004 10:14:00 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 19 Aug 2004 10:13:59 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.39.226 172.21.39.226 via HTTP with MS-WebStorage 6.0.6249 Received: from hed039-226.research.nokia.com by ESEBE054.NOE.Nokia.com; 19 Aug 2004 10:13:58 +0300 Subject: Re: AW: [Simple] Please comment: Do we want to take on partial publication? From: Aki Niemi To: ext Adam Roach In-Reply-To: <4123AFA3.5060606@dynamicsoft.com> References: <4123AFA3.5060606@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092899316.19953.43.camel@hed039-226.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 Aug 2004 10:13:58 +0300 X-OriginalArrivalTime: 19 Aug 2004 07:13:59.0233 (UTC) FILETIME=[18F5E310:01C485BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Schmidt Christian , Robert Sparks , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit On Wed, 2004-08-18 at 22:36, ext Adam Roach wrote: <> > I guess I haven't been particularly clear in my logic in asserting > *why* > the existing solution is more general purpose. What you are proposing > is > specific to presence documents. If someone wanted to come up with some > way to do the same thing for alternate event packages, they'd have to > do > a whole new partial publish specification for it. Are we talking about the same problem here? I want partial updates, which PIDF doesn't support, unfortunately. Watcherinfo, for example, already has that feature and it's built in to the document format, and specified by the event package specs. And I would imagine any future event package that needs partial updates would do the exact same thing. > On the other hand, > using the existing PUBLISH framework, contributing multiple streams of > state for a single resource is built-in to the protocol. Exactly how > these streams are composed into a single event state is the job of the > notifier, and is completely a matter of local policy. This is > precisely > where different implementations can differentiate themselves. I'm not disagreeing with you in that multiple streams are part of the publish framework. But if you "misuse" that feature to accomplish something akin to partial updates for presence, then I have a problem. IMHO, it's a hack that certainly doesn't avoid the complexity partial-publish is said to introduce - it merely pushes it into the composer. > So, in short, what's already specified for PUBLISH works for all event > packages, both existing and future. The partial publication work you > propose works for precisely one event package. The comparative > generalities should be fairly obvious. As I said above, the problem at hand is partial updates *specifically* in presence. In perfect 20-20 hindsight, this problem would've best been solved in PIDF already, by making it support partial state updates. There is no need to look for generalities, since any future event package need not make the same mistake. Cheers, Aki > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 19 08:35:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27249; Thu, 19 Aug 2004 08:35:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxmFP-00036j-Pz; Thu, 19 Aug 2004 08:42:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxm4w-00021X-5x; Thu, 19 Aug 2004 08:31:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxltF-0008Gv-Jp for simple@megatron.ietf.org; Thu, 19 Aug 2004 08:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25964 for ; Thu, 19 Aug 2004 08:19:32 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxlze-0002i0-Pk for simple@ietf.org; Thu, 19 Aug 2004 08:26:12 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7JCJS103482; Thu, 19 Aug 2004 15:19:28 +0300 (EET DST) X-Scanned: Thu, 19 Aug 2004 15:19:25 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7JCJPGE009952; Thu, 19 Aug 2004 15:19:25 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00myP80Z; Thu, 19 Aug 2004 15:19:24 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7JCJIn07865; Thu, 19 Aug 2004 15:19:18 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 19 Aug 2004 15:19:19 +0300 Received: from agni.research.nokia.com (hed040-218.research.nokia.com [172.21.40.218]) by kusti.research.nokia.com (Postfix) with ESMTP id 20C4393B6A; Thu, 19 Aug 2004 15:19:18 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7JCJHax008539; Thu, 19 Aug 2004 15:19:17 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7JCJFj9008538; Thu, 19 Aug 2004 15:19:16 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Peter Ridler Subject: Re: [Simple] MSRP when used with SIP/SDP inconsistent with RFC2327 ABNF X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Peter Ridler's message of "Tue, 17 Aug 2004 13:05:15 -0400") References: Date: Thu, 19 Aug 2004 15:19:14 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 19 Aug 2004 12:19:19.0238 (UTC) FILETIME=[C088CE60:01C485E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Peter Ridler writes: >In the draft-ietf-simple-messages-sessions-07.txt Section 7.1 uses >"accept-types" in the attribute-fields (the a= line) where RFC2327 defines >attribute as: ... >Note that "att-field" only allows for alpha-numeric field names which would >make "accept-types" illegal. Maybe the name should be changed to >"AcceptTypes" or something to conform. RFC 2327 syntax is outdated and it contradicts with the examples and actual usage (like, it does not allow RTP/AVP as a transport protocol for media.) I think the problem lies with message-session-07 reference [2], [2] should refer to draft-ietf-mmusic-sdp-new-XX. >Also, Why is the path attribute used and not the media-field (m= line) used >as described in the RFC2327 standard? I see that the path can have multiple >urls defined but I don't see no more then one ever being used! SIP controls >the call/session information between the endpoints, MSRP should not have to >resolve the communication paths again. Please see . Traversing through firewalls by using relays is MSRP's raison d'etre. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 19 10:16:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04781; Thu, 19 Aug 2004 10:16:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxnoX-0005GP-PF; Thu, 19 Aug 2004 10:22:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxncO-0003u2-Eh; Thu, 19 Aug 2004 10:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxnX0-0001j9-Nf for simple@megatron.ietf.org; Thu, 19 Aug 2004 10:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03284 for ; Thu, 19 Aug 2004 10:04:41 -0400 (EDT) Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxndR-0004xC-2y for simple@ietf.org; Thu, 19 Aug 2004 10:11:22 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.12.10/8.12.10) with ESMTP id i7JE4ALp023297 for ; Thu, 19 Aug 2004 09:04:10 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: multipart/mixed; boundary="=-WLZ5VtMNU5n4y36aMrf4" Message-Id: <1092924161.1986.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 19 Aug 2004 09:02:41 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: aec2475b197ed9c8908117d8fbf9ee2e Subject: [Simple] Minutes/proceedings - IETF60 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a --=-WLZ5VtMNU5n4y36aMrf4 Content-Type: text/plain Content-Transfer-Encoding: 7bit The slides from San Diego are on softarmor at http://www.softarmor.com/simple/meets/ietf60/slides/ and in the draft proceedings at http://www.ietf.org/proceedings/04aug/index.html Draft minutes are attached. Please provide feedback/correction no later than 8/31. Thanks, RjS --=-WLZ5VtMNU5n4y36aMrf4 Content-Disposition: attachment; filename=minutes Content-Type: text/plain; name=minutes; charset=UTF-8 X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id i7JE4ALp023297 Content-Transfer-Encoding: quoted-printable SIMPLE Working Group Minutes - IETF 60 August 2, 2004 1300 and August 3, 2004 0900 Chairs: Robert Sparks, Hisham Khartabil Notetakers: Dean Willis, Spencer Dawkins, Chris Boulton Summary - - The core SIMPLE documents are finally in AUTH48 - The group reviewed the agressive project plan it is working against to complete many of its current work items - The MSRP base spec was rewritten for clarity. The number of open issues is going down. Several will be closed based on discussion from this meeting. (See the detailed notes for specifics on each issue.) - The MSRP relay spec is being revised to track the base spec. It will help the editors if group members start reporting inconsistencies to the list. - The XCAP discussions during this meeting focused mostly on remaining issues in xcap-base and list. - XCAP Package is being reconciled with the configuration framework. The resulting components may meet the requirements for a directory.=20 - The room expressed an interest in addressing the topic in draft-peterson-pidf-ice-00.txt as a SIMPLE WG effort. - The room expressed support for the data model expressed in draft-rosenberg-simple-presence-data-model. ---------------------------------------------------------------------- Detailed Notes: (We were fortunate to have two notetakers for each session) Session One: recorded by Dean Willis. Topic: Chairs Report -------------------- Core SIMPLE docs in Auth 48 and should complete soon. Project plan presented. Topic: MSRP Base, Ben Campbell ------------------------------ Slides presented. Discussion of Status and Changes follows. Reports changes: Discussion: There is no minimum size of an MSRP message. Can a report get chunked by a relay? Ans: No. Reports don't get chunked. Framing: No discussion apart from changed reviewed in slides. Chunking: Changes reviewed in slides. Noted that recent email suggested that draft should note that S/MIME must be applied before by chunking. Also, guidance received that chunking be imposed at 2kB boundar= y. VISIT: Removed from spec, replaced with a utilization of SEND, which could be empty. No further discussion in meeting. Transport and Protection: No discussion. Max-Size: No discussion. Discussion of Open Issues follows. Issue: Terminating long-message transmissions without accidental rendering of incomplete message: Possibility of "abort" flag on the transmission raised. There seems to be a consensus to adopt this approach. Issue: Range header: Proposed: if you think there is any chance that a message might be interrupted (over 2k) go ahead then the last field in the byte range header should be set to "*". There seems to be a consensus to use this approach in conjunction with the "abort" flag. Issue: MSRPS vs MSRP. Is this justifiable due to DNS-cert matching resolution requirements and/or NAPTR options? Rough conensus seems to be that the usage is justified. Issue: Report Handling. Discussion of whether report headers can be present in a REPORT request -- answer is no, they are not allowed. There may be an error in the spec or examples that needs to be corrected. These headers only apply to SEND. Issue: Extensibility. Do we need versioning? Proposed that a URL parameter for version be added. This relates to whether we wish to develop an innate extension negotiation mechanism as per SIP, use completely new protocol definitions and negotiate with SDP. This could fall back to making a SIP option tage for understanding the version option. Action item: Document the selected extension approach as part of the MSRP spec. Issue: What does max-size mean? How does it apply to body parts inside of multipart? Proposed that it apply to any matching body part, regardless of encapsulation. For example, if a multipart has text, html, and text parts, then these qualify as three individual parts. Suggested that we have a max-size apply across the whole set of multiparts. Ensuing discussion indicates a lack of clear requirements. Proposed: We seem to have sufficient annecdotal evidence that justifies a max-size parameter that applies to all body parts. We should adopt this now, and unless someone comes up with a good justification for part-by-part sizing, we drop that requirement. There seems to be consensus for this approach. Proposed approach is a new a-line entry "max-size". Discussion: Is this data "a hint" or normative behavior for the sender? There seems to be consensus that it is a hint. Issue: Page vs. session mode. Should there be a discussion of when to use each mode? Proposed that this belongs in a SIMPLE architecture document, not in MSRP. There seems to be consensus not to discuss this in the MSRP spec. Issue: DSN. Now that we have have status information in a report, what does DSN do for us? Is there a reason to keep it? Seems to be consensus that we do not need DSN body parts any more. Proposed: Change from SHOULD send DSN to MAY send DSN, and to deprecate body preparation to be free-form text. Alternate proposal: Drop DNS discussion from draft entirely. Question: Do we allow bodies on REPORT? Proposed: No. Counterproposed: Yes, up to 2k, negotiated as an SDP option. Message-context header discussed as a possibility. Suggested that this needs to be handled as part of the alleged SIMPLE architecture document. Further discussion: Do we need guidance on resource starvation and utilization, like weighting algorithms and discard and stuff? Discussion was inconclusive. Issue: being able to put information like a "From" header in the MSRP request that identifies the source so that intermediaries like mixers can relay this on. This might be applicable to an MSRP conferencing model. Even though the focus knows who is talking, how does it pass this on to the other recipients so that utterances can be associated with sources? Clarifying question: Given that the focus might be multiprotocol, should the utterance identifier be a protocol-indicating URI? Question -- Would this identifier be mandatory, or optional? Comment: The source can present its identity in CPIM. Issue: If this is an "anonymous" identity, how does this correlate to the roster? We would need some way for the focus to transmit the focus-assigned anonymous identity value to the user agent for inclusion in the CPIM wrapper. Thought: Wow, this is just like the proxy identity-rewrite problem in SIP, isn't it? Comment: Something we did in SIP that was a mistake was the failure to distinguish between identity-targeted headers vs. end-to-end significance. The CPIM-wrapper method is clearly end-to-end, and may as a result be better than the SIP approach. Conclusion: Author will attempt to document use of CPIM with focus-provided identifier valuesd to addresses anonymous-conference requirements. Topic: MSRP Relays, Rohan Mahy ------------------------------ Slides presented. Status: Document is known to still contain inconsistencies. Poll on reading of base draft: about 10% of room. About 3% indicated that they have read the relay draft. Changes summarized. Issue: Refreshing AUTHs. Proposal that client periodically send new AUTH requests, targeted to a specific URI in the To-Path. Consequently, a full refresh would do a "full telescope" but not necessarily in order of traversal. Discussion: This conflcts with refresh approach chosen in Canada interim meeting two years ago. This might have been related to the n-way timer negotiation as envisioned during the Ottawa meeting. Since the new model is one of one-to-one relationships between clients and relays, the proposed approach seems to work better. Noted: Editor requests that people start sending inconsistencies between relay and base drafts. Discussion: The time-limiting aspect of authentication nees to be clarified. Session One : recorded by Spencer Dawkins 13:00-13:05 Agenda Bashing, Chairs Report o IMPP documents are in AUTH-48 =E2=80=93 should be published rea= lly soon o Filter has been through WGLC, please send comments o XCAP base draft and PIDF manipulation draft in WGLC now o Want to send MSRP base and relay drafts to IESG back-to-back 13:05-14:15 MSRP Base (Ben Campbell) o Version 07 is major re-write of this document o Going for readability and fixing =E2=80=9Ccut-and-paste-itis=E2= =80=9D o Changes are report handling, framing, chunk handling, eliminating VISIT method, transport and TLS, and adding max-size to media o Two headers for report selection (Report-Success and Report-Failure) =E2=80=93 Report-Failure needed to accommodate relay oper= ation o Chunking very intrinsic to MSRP, so promoted to a Byte-Range header o Recommended chunking at 2KB boundaries o VISIT semantics became almost identical to SEND, so replaced with an initial SEND request o Transport parameter added (TCP is only defined value, but would accommodate TLS in future) o Max-Size refers to complete message content =E2=80=93 entire me= ssage body o Chunking =E2=80=93 Adam proposed two flags on the list =E2=80=93= allow an additional flag that says =E2=80=9Clast chunk, I=E2=80=99m abandoning thi= s message=E2=80=9D? =E2=80=93 OK o If you have real numbers in byte range numbers, header should reflect this =E2=80=93 but there=E2=80=99s an issue with interrupting str= eaming media =E2=80=93 require =E2=80=9Cstars=E2=80=9D as last byte in byte-range header if the = message is bigger than 2KB? - OK o What certificate identities do you present for TLS? Relay draft doesn=E2=80=99t have quite the same language as HTTP-S =E2=80=93 sh= ould copy that language exactly. Cullen =E2=80=93 should match what we did with SIP-S. J= on =E2=80=93 does the SRV record match the URI? That=E2=80=99s the important part. o Open issues o Transaction responses are tied to error reports - should they be separated? Proposal =E2=80=93 leave tied together =E2=80=93 o Extensibility =E2=80=93 we=E2=80=99re not going to have a versi= on number, we need to document our decision not to have version numbers =E2=80=93 non-b= ackward compatible extensions become new protocols instead o Max-size will refer to all media types, not per-media type o Page mode vs session mode =E2=80=93 need to give guidance, but = not in this document. SIMPLE architecture? Where? o How to slow down packet rates? No other way than slowing down request rates. o Is DSN still required? We can send reports, don=E2=80=99t need human-readable DSNs. Still allowed =E2=80=93 it=E2=80=99s a body part - b= ut what=E2=80=99s the guidance here? Is anything required beyond what people can Accept: today? o Need to map MSRP headers to SIP headers to avoid confusion. o Need to make sure that focus won=E2=80=99t be inserting identit= ies =E2=80=93 we rejected this previously, and it=E2=80=99s creeping back in =E2=80=93 = this doesn=E2=80=99t work for anonymous participants =E2=80=93 but can=E2=80=99t they provide = their own anonymous identities? Need to map what they provide to a participant roster, though. Need to take this offline, with two concrete proposals. o Need to be clear about headers that are end-to-end vs hop-by-hop =E2=80=93 we blew this in HTTP and inherited the problem into = SIP =E2=80=93 can we be smarter? o Ready for WGLC of next draft, in a week or so? Please send open issues ASAP. 14:15-15:00 MSRP Relay (Rohan Mahy, Cullen Jennings) o Last-nanosecond editing pass doesn=E2=80=99t quite align with t= he base spec (which is now complete enough for the relay functions) =E2=80=93 nee= d one more pass to complete this. o SEND and AUTH responses are end-to-end o Client which needs multiple relays sends AUTH to each one, inside out, and relay uses complete path to authorize requests o Relay to Relay is always TLS with mutual authentication, client to its relay is always TLC with Digest, foreign relay to client can be either TCP or TLS. o Relays can re-chunk, and must be able to interrupt chunks bigger than 2 KB. o Refreshing AUTHs =E2=80=93 suggesting periodic new AUTHs, but n= eed to work out details =E2=80=93 but WG chose not to go this way, a long time a= go =E2=80=93 can we remember why? Maybe because that was end-to-end and this is relay-to-relay. Maybe OK. o Need to catch up with base protocol, make document self-consistent. What other changes are needed? Rohan =E2=80=93 how to do AUTHs that aren=E2=80=99t one-AUTH-per-session? o This is like base GRUUs =E2=80=93 if people know my relay MSRP = URI, they can pass out that URI to their friends and I=E2=80=99ll relay anythi= ng they send using that URI. o Talking with Ted about security aspects of this =E2=80=93 suffi= ciently complicated to require security assistance in getting this right. o What does =E2=80=9Cpassing out=E2=80=9D mean? Does it matter if= eavesdroppers hear the URI? o Does =E2=80=9Ctime-limited=E2=80=9D help? The URI doesn=E2=80=99= t last forever. Session Two: recorded by Dean Willis Topic: XCAP -- Jonathan Rosenberg --------------------------------- Slides presented. Changes since last rev reviewed. Changes were discussed also on list. No questions or comments raised in meeting. Issue: DELETE idempotency. Discussion: Could we do away with the positional syntax and use a ".next" style iterator? Discussion followed. Initial Conclusion: Will add text to spec that describes URI constructor constraints for delete idempotency. This led to extended discussion -- is idempotency really required here? Key issue: What happens when you have issued a command and lose network access before the response is returned? If the request is not processed idempotently, there is no way to just reissue it. Heated debate followed. Comment: In choosing to use HTTP with DELETE as done. we have chosen to use the entire implied infrastructure, including HTTP proxies. HTTP proxies can retry these commands on your behalf, without your knowledge or consent, and if the requests are not idempotent, this will break the application. Restatement of proposal: Soften the requirement of a server to enforce idempotency to only enforce it in the presence of an ETag in an If-Match header. Issue: XPath Namespace Context. Extended discussion followed, with no conclusions. Author will research and bring up on list. Issue: ETag and DELETE. When a resource is deleted, it doesn't exist. But some servers return the ETag of the deleted element. Several options proposed in slides. Meeting proposed fourth option: DELETE response contain a body that references some related resource, presumably the parent. The third proposal, the "MODIFY TO EMPTY" approach, was universally recognized as "crap". Comment: Unless we are introducing transactions across multiple requests, we are simply going to have this problem. Final Proposal: XCAP will have normative ref to xcap-diff format and will state that if a DELETE request includes an accept header for that MIME type then the server SHOULD return a diff body that indicates the etag of the resource following the DELETE operation. Issue: Caching. Proposal: Add discussion of caching issues to XCAP document. Topic: XCAP List, Jonathan Rosenberg ------------------------------------ Slides presented. Four issues to be discussed. Question on whether indirection URI in a rls-service document has to point to XCAP or can point to other destination -- author will consider. Topic: Resource List Document, Jonathan Rosenberg ------------------------------------------------- Issue: Embedded vs external lists. Proposed: retain as is. Poll on readership: about twenty people indicated they had read it. No objection to proposal. Issue: Simpler structure. Proposed retain as is. No objections. Issue: Membercode attribute proposed by Hiller draft. Problem: Schema doesn't allow attribute extensibility. Proposal: Add attribute extensibility. Comment: We need to go through the extensibility discussion for everything. Question: Can the membercode be done as an element instead of an attribute? This needs to be reviewed in the Hiller draft. (probably not, as it seems to be used with XCAP selection). Question: How can we develop extensibility guidelines for consistency? Discussion followed. Topic: XCAP Package/DIFF, Jonathan Rosenberg -------------------------------------------- Slides presented. Document is radically changed, including a great deal of reconciliation with Config Framework. Changes reviewed in presentation. Question: Is the providing of a starting point ETag in addition to a diff helpful? Yes, otherwise you don't know whether an intermediate change was missed that would make the sequence of changes not add up. Issue: Relationship to directory. Proposed that this restructure makes a seperate directory unneeded. Poll indicates that about twentyfive people in meeting had read the document. Further list discussion on proposal is appropriate. Topic: XCAP Directory, Miguel-Angel Garcia Martin ------------------------------------------------- Comment: The heirarchicalization is inconsistent with XCAP. Comment: The size is going to be hard to compute. Discussion: The functionality seems to be needed. The question is how to implement. Is rls-services adequate? Need to evaluate rls-services against this requirements raised in this document. comment: The config framework truly does what this does -- give me all the servcies related to me. The rls-services document is a related thing, that provides an index of the documents related to me, in a linkage tree. As there may be unreferenced documents, rls-services may not get everything. Author is to vet requirements against rls and config work. Topic: PIDF-ICE, Jon Peterson ----------------------------- Slides presented. Idea is to get the information that one would request from ICE through presence, allowing evaluation of probability as to whether a real-time multimedia session establishment might succeed. This could be of use to users making contact decisions. Discussion: This seems to have value as a presence accuracy enhancer, and some would like to see it move forward. There seems to be a general consensus to follow this work in SIMPLE. Topic: Presence Data Model, Jonathan Rosenberg ---------------------------------------------- Slides presented. Goal is to establish a common understanding of what opresence documents mean in order to achieve interoperability. Issue: One vs. many Presentity. Model allows one presentity per document. Proposal to handle conflicts at attribute level. No comments from meeting. Issue: Devices or Not. We now have a definition of device clear enough to understand what we are debating, but not clear enough for a final definition. Open issues remain around distributed devices. Comment: We need to simplify the use-purpose of the device tuple. This probably includes some kind of device identifier that allows the UI to display an appropriate icon. If one doesn't actually use this description to guess device properties, the information is useful. Discussion: There is a useful correlation property, when a user can see that a specific device offers multiple services. Debate continued on whether the device classification (like PDA, mobile phone) implies enough about the utilization characteristics. Further discussion deferred. Comment: It seems like the presnetity being modeled is seen as a collection of devices, and this doesn't really give the correct picture. Discussion: We are modeling the user, its services, and the devices forming the context on which those services execute. Issue: Resources and capabilities. Design team believes that association of resources nad capabilitiesare not useful as part of "device" and are probably mroe useful as part of "service". Issue: Correlation. Design team conclusion is that the state of a given service cannot in general be inferred from knowledge of the state of other services executing on the same device. Comment: This relates to the use of user-supplied identfiers, e.g. cellphone vs mobile. The key thing is that services are identified by URIs, and these URIs can be mapped to devices under applicaton control. Question: Do we have in mind that certain elements will be used only with certain tuple types? Proposed: Go through RPID, and for each thing, describe where it can be and what the limitations are. Issue: Idle. Discussion on restricting the amount of information going to the watcher. Counterpoint that this needs to not be restricted, but well-defined. Comment: Less is better to display, in most cases. Discussion on whether this work will delay anything. We are not anticipating changes that would restructure any of the related documents. Comment: Restricting presence to people is speciesism. Discussion: The idea is to model things that have human-like properties, as opposed to places or organizations. This discussion proceeded to devolve into pseudoreligiosity and was deferred to the list. Poll: Do we believe, as a group, that this model is the one that we want to pursue, at least in a directional basis? None opposed noted. Session Two: recorded by Chris Boulton XCAP Base Document - No questions on initial resolved open issues slide. DELETE Idempotency - Cullen - proposed removal positional insertion - JR Conclusion -Add text to draft regarding URI construction for deletio= n. - Is there a requirement for idempotency checking? - Ted - Suggested that not using would be choosing a different protocol f= rom HTTP - JR to add text to cover 2 scenarios for idempotency checking that rejec= ts the request if there wasn't an "if-match" header and allows if present= . Consensus agreed. XPATH Namespace Context - Rohan questions the need for this feature. - JR to consider options and propose to the list ETag and DELETE - What is the meaning as the resource doesn't exist - Ted Proposal to add a resource body to signify entity tag status o This could be the XCAP diff format - Empty Content proposal discarded - Concrete proposal for entity body in response to delete to signify enti= ty tag status - No objections Caching Add discussions of caching XCAP List Usage document - List of resolved issues reviewed - Issues since WGLC reviewed XCAP Package/Diff - Radical change - aligned with Config framework - Now just a format that can be used with the config package XCAP Directory - Do we need functionality? - Miguel to check config package to cross ref= erence functionality. PIDF-ICE - Is this useful - Consensus seems to be it is. Presence Data Model - Need a resolution of "What is a Tuple" discussion for interoperable sys= tems. - JR provided update on Design team discussions - Still confusion regarding "device" definition - Group feedback required on discussion/conclusion - Discussion needs to take place on the list - Poll to see if the group is happy with direction of this model - consen= sus was "Yes" --=-WLZ5VtMNU5n4y36aMrf4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=-WLZ5VtMNU5n4y36aMrf4-- From simple-bounces@ietf.org Thu Aug 19 17:55:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13228; Thu, 19 Aug 2004 17:55:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxuyg-0008Mv-Od; Thu, 19 Aug 2004 18:01:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxuce-0001E8-U6; Thu, 19 Aug 2004 17:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxuPO-000643-7D for simple@megatron.ietf.org; Thu, 19 Aug 2004 17:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10811 for ; Thu, 19 Aug 2004 17:25:16 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxuVp-0007YY-HI for simple@ietf.org; Thu, 19 Aug 2004 17:32:01 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i7JLP3eE017370; Thu, 19 Aug 2004 17:25:03 -0400 (EDT) Message-ID: <41251A96.5090105@dynamicsoft.com> Date: Thu, 19 Aug 2004 17:24:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" Subject: Re: [Simple] Policies and Events References: <32BCBA960C20EB408F4BE7658522620D05B77670@G9JJX.mgb01.telekom.de> In-Reply-To: <32BCBA960C20EB408F4BE7658522620D05B77670@G9JJX.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Alexeitsev, D wrote: > Hello All > > Was it considered to unify the policy XML document with the related > state event XML document (for example watcher auth)? > > In such scenario a presentity would receive event XML document in a > NOTIFY, change the state to "accepted" and upload it as a policy > document or a fragment. That is not how it works, no. The watcherinfo states do not contain policy document fragments that would be uploaded. > > In the current situation where policy and event documents are > separated there is an additional need to define transitions between > the states depending on the values in the policy document. Or is it > considered obvious? I don't see the problem here. There is a transition in the subscription states (and thus the watcherinfo states) based on policy changes. Perhaps you are asking for there to be a clear definition of the state changes in the subscription states when policy documents are uploaded? I think that is a reasonable request, and I can make that more explicit than it is today. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 20 08:28:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09075; Fri, 20 Aug 2004 08:28:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By8cX-0006N8-Am; Fri, 20 Aug 2004 08:35:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By86R-00075l-K9; Fri, 20 Aug 2004 08:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7sW-0004EA-0A for simple@megatron.ietf.org; Fri, 20 Aug 2004 07:48:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06692 for ; Fri, 20 Aug 2004 07:48:09 -0400 (EDT) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7z2-0005Si-Uj for simple@ietf.org; Fri, 20 Aug 2004 07:55:02 -0400 Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 20 Aug 2004 13:47:37 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Aug 2004 13:47:37 +0200 Message-Id: <32BCBA960C20EB408F4BE7658522620D05B7767F@G9JJX.mgb01.telekom.de> From: "Alexeitsev, D" To: jdrosen@dynamicsoft.com Subject: AW: [Simple] Policies and Events Date: Fri, 20 Aug 2004 13:47:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hello Jonathan Thanks for the clarifications, a short summup inline. >I don't see the problem here. There is a transition in the subscription >states (and thus the watcherinfo states) based on policy changes. >Perhaps you are asking for there to be a clear definition of the state >changes in the subscription states when policy documents are uploaded? This is exactly the case, if the watcherinfo states would contain policy document fragments then the subscription state transition would be implicitly included in the policy documents. I don't see a problem with the current solution where states and policies are separated as long as their relations are defined. My question was what is the main benefit of this separation apart from "That is how it works" ? :-) Greetings, Denis Alexeitsev _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 23 10:55:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14020; Mon, 23 Aug 2004 10:55:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzGEU-0006bU-HS; Mon, 23 Aug 2004 10:55:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFui-00073x-Gp; Mon, 23 Aug 2004 10:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFeD-0002Vf-JP for simple@megatron.ietf.org; Mon, 23 Aug 2004 10:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10794 for ; Mon, 23 Aug 2004 10:18:02 -0400 (EDT) Received: from 202-39-210-32.sipit.net ([202.39.210.32] helo=agni.research.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFeR-0005vl-Sn for simple@ietf.org; Mon, 23 Aug 2004 10:18:24 -0400 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7K8Diax025350; Fri, 20 Aug 2004 11:13:44 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7K8Din8025349; Fri, 20 Aug 2004 11:13:44 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Peter Ridler Subject: Re: [Simple] MSRP - ABNF corrections and changes -- Attachment X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Peter Ridler's message of "Tue, 17 Aug 2004 13:09:41 -0400") References: Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) Date: Fri, 20 Aug 2004 11:13:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi Peter, Peter Ridler writes: ... >RFC2396 has syntax/logic errors so I recommend we define the >MSRP-url in our own ABNF (of course following other RFC standards >as much as possible) as what was done in SIP(RFC3261). My >attachment contains that ABNF code. Note that RFC2396 (as well >RFC3261) has logic errors in its hostname/domainlabel/toplabel >definitions -- I used the logic from RFC1035 (converted to ABNF). I think one "logic error" is there because domain names are nowadays used more freely than originally specified by RFC1035. Here is my more liberal proposal making people from 3com.com (not to speak about 2600.org) happy: hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum *label-string label-string = alphanum / "-" alphanum toplabel = ALPHA *label-string The last dot (from RFC 3261) is a problem, I admit. I think most popular browsers don't like it at all (they consider http://foo.bar./baz/ different from http://foo.bar/baz/). >The definition of "data" states ZERO to INFINITY, and assuming that we have >defined a MSRP message limit, then data will eat up all the bytes of >information AND the CRLF of "content-stuff" as well as the "end-line" >message as well. "data" must have some bounds defined for it! The CRLF end-line bounds data. I don't think ABNF can express that kind of bounds, rather the there could be a comment to the effect: data = *OCTET ; data MUST NOT contain end-line or even data = *OCTET ; data MUST NOT contain "-------" followed by transact-id ... >Put all message control portions in a message header and the payload >strictly data. This way when the message is received via TCP the message >header can be easily found in the stream (the double CRLF sequences) and >used to define the size/type of the data following (if any). I'd just move CRLF (coming after data) from content-stuff to end-line, so that we had. content-stuff = *(Other-Mime-Header CRLF) Content-Type 2CRLF data end-line = CRLF "-------" transact-id continuation-flag CRLF All the messages would then have the double CRLF after headers. On the other hand, current syntax make sure that if you have data, you must have MIME type for it (Content-Type header is mandatory). ... >Although "headers" are optional in the ABNF syntax -- enforcement >of the headers within the different messages can be specified in >the RFC requirements for message validation. This would simplify >the parsing of the message. I agree. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 23 10:55:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14053; Mon, 23 Aug 2004 10:55:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzGF5-0006cW-FN; Mon, 23 Aug 2004 10:56:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFuh-00073e-Tt; Mon, 23 Aug 2004 10:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFe1-0002Tj-EH for simple@megatron.ietf.org; Mon, 23 Aug 2004 10:17:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10758 for ; Mon, 23 Aug 2004 10:17:50 -0400 (EDT) Received: from 202-39-210-32.sipit.net ([202.39.210.32] helo=agni.research.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFeC-0005vl-Qh for simple@ietf.org; Mon, 23 Aug 2004 10:18:12 -0400 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7K8BUax025340; Fri, 20 Aug 2004 11:11:30 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7K8BT2Y025339; Fri, 20 Aug 2004 11:11:29 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Peter Ridler Subject: Re: [Simple] MSRP - ABNF corrections and changes -- Attachment X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Peter Ridler's message of "Tue, 17 Aug 2004 13:09:41 -0400") References: Date: Fri, 20 Aug 2004 11:11:28 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi Peter, Peter Ridler writes: ... >RFC2396 has syntax/logic errors so I recommend we define the >MSRP-url in our own ABNF (of course following other RFC standards >as much as possible) as what was done in SIP(RFC3261). My >attachment contains that ABNF code. Note that RFC2396 (as well >RFC3261) has logic errors in its hostname/domainlabel/toplabel >definitions -- I used the logic from RFC1035 (converted to ABNF). I think one "logic error" is there because domain names are nowadays used more freely than originally specified by RFC1035. Here is my more liberal proposal making people from 3com.com (not to speak about 2600.org) happy: hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum *label-string label-string = alphanum / "-" alphanum toplabel = ALPHA *label-string The last dot (from RFC 3261) is a problem, I admit. I think most popular browsers don't like it at all (they consider http://foo.bar./baz/ different from http://foo.bar/baz/). >The definition of "data" states ZERO to INFINITY, and assuming that we have >defined a MSRP message limit, then data will eat up all the bytes of >information AND the CRLF of "content-stuff" as well as the "end-line" >message as well. "data" must have some bounds defined for it! The CRLF end-line bounds data. I don't think ABNF can express that kind of bounds, rather the there could be a comment to the effect: data = *OCTET ; data MUST NOT contain end-line or even data = *OCTET ; data MUST NOT contain "-------" followed by transact-id ... >Put all message control portions in a message header and the payload >strictly data. This way when the message is received via TCP the message >header can be easily found in the stream (the double CRLF sequences) and >used to define the size/type of the data following (if any). I'd just move CRLF (coming after data) from content-stuff to end-line, so that we had. content-stuff = *(Other-Mime-Header CRLF) Content-Type 2CRLF data end-line = CRLF "-------" transact-id continuation-flag CRLF All the messages would then have the double CRLF after headers. On the other hand, current syntax make sure that if you have data, you must have MIME type for it (Content-Type header is mandatory). ... >Although "headers" are optional in the ABNF syntax -- enforcement >of the headers within the different messages can be specified in >the RFC requirements for message validation. This would simplify >the parsing of the message. I agree. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 23 14:00:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26722; Mon, 23 Aug 2004 14:00:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzJ8C-0001vl-Bc; Mon, 23 Aug 2004 14:01:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIlL-0006xF-6G; Mon, 23 Aug 2004 13:37:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIV1-0005Dp-TO for simple@megatron.ietf.org; Mon, 23 Aug 2004 13:20:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24312 for ; Mon, 23 Aug 2004 13:20:43 -0400 (EDT) Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzIVG-0001EL-Kv for simple@ietf.org; Mon, 23 Aug 2004 13:21:09 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0I2W0081YTHB2B@firewall.mci.com> for simple@ietf.org; Mon, 23 Aug 2004 17:19:59 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I2W00E01THBIA@pmismtp01.mcilink.com>; Mon, 23 Aug 2004 17:19:59 +0000 (GMT) Received: from XS578V7033521.mci.com ([131.146.40.85]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I2W00E39TH9EQ@pmismtp01.mcilink.com>; Mon, 23 Aug 2004 17:19:59 +0000 (GMT) Date: Mon, 23 Aug 2004 12:19:56 -0500 From: Alan Johnston Subject: Re: [Simple] MSRP: Contributor ID In-reply-to: <41213424.9080800@dynamicsoft.com> X-Sender: Alan.Johnston@pop.mcilink.com To: Adam Roach , simple@ietf.org Message-id: <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <1092692976.10426.251.camel@localhost.localdomain> <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 At 05:24 PM 8/16/2004 -0500, Adam Roach wrote: >At the cost of putting in a "me too" post, I agree with Robert and Ben >that there is no good reason to change the solution which we agreed to in >Ottawa. The properties of identity in CPIM are well defined and clearly >specified. They can clearly be leveraged solve the problem at hand. > >It seems obvious that arguments like "it won't work" would be a valid >reason to re-visit consensus. (Joining this discussion late, so my apologies.) I suspect "it won't work". MSRP must define in the base specification source identification and how mixing is done without loosing source identification. Otherwise, MSRP will be dumber than RTP, and will be a 2nd class citizen in conferencing, unable to meet the basic requirements in the SIPPING conferencing framework. MSRP can not be dumber than RTP. The worst result possible would be for a conference unaware user agent in an MSRP conference to have all the participants messages be attributed to the focus because we left out basic source identification. At a minimum, it would need to be attribute different messages to different participants without knowing who they are (this is the XCON problem). Any acceptable proposal must rule out this possibility - I don't see how an optional CPIM encoding solves this problem. Thanks, Alan sip:alan@sipstation.com >At this late stage in the process, I think that anything *short* of "it >won't work" shouldn't be entertained. > >(Just from a practical perspective, allowing substantial changes to >consensus around a valid functional solution months after that consensus >has been reached gives detractors the opportunity to derail any effort at >a whim. I take no position about whether such is occurring in this case, >but worry about precedent if this topic is allowed to slow completion of >MSRP. Chairs?). > >/a > >Robert Sparks wrote: > >>Yes, with the possible addition of some forward looking text capturing >>that we thought about the problem and expect to be able >>to solve it without needing to change the MSRP protocol itself. >> >>RjS >> >>On Mon, 2004-08-16 at 16:18, Ben Campbell wrote: >> >> >>>Just to be precise, I think you are proposing that we do not add >>>anything new to the base protocol for this purpose, correct? That is, >>>leave things as they are? >>> > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 23 15:24:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03879; Mon, 23 Aug 2004 15:24:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzKQc-0003b3-Jb; Mon, 23 Aug 2004 15:24:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzK0m-0001ra-VT; Mon, 23 Aug 2004 14:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzJgA-0006i0-MG for simple@megatron.ietf.org; Mon, 23 Aug 2004 14:36:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29653 for ; Mon, 23 Aug 2004 14:36:20 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzJgQ-0002i1-W9 for simple@ietf.org; Mon, 23 Aug 2004 14:36:44 -0400 Received: from [63.110.3.154] ([63.110.3.154]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7NIaH4J034870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2004 13:36:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <412A3913.6010302@nostrum.com> Date: Mon, 23 Aug 2004 13:36:03 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [Simple] MSRP: Contributor ID References: <1092692976.10426.251.camel@localhost.localdomain> <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> In-Reply-To: <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Alan Johnston wrote: > At 05:24 PM 8/16/2004 -0500, Adam Roach wrote: > >> At the cost of putting in a "me too" post, I agree with Robert and >> Ben that there is no good reason to change the solution which we >> agreed to in Ottawa. The properties of identity in CPIM are well >> defined and clearly specified. They can clearly be leveraged solve >> the problem at hand. >> >> It seems obvious that arguments like "it won't work" would be a valid >> reason to re-visit consensus. > > > (Joining this discussion late, so my apologies.) > > I suspect "it won't work". MSRP must define in the base specification > source identification and how mixing is done without loosing source > identification. Source identification can be performed by correlation between the initial "From-Path" header element and the session establishment. There isn't really mixing per se involved, simply message switching -- so all we need is a mechanism to identify (a) who originated the message (get this from CPIM), and (b) the "mixer" that sent it to you (get this from "From-Path.") Does that address your concern, or did I misunderstand? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 23 18:17:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21929; Mon, 23 Aug 2004 18:17:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzN8s-0000hy-3F; Mon, 23 Aug 2004 18:18:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzMTh-0004oM-Af; Mon, 23 Aug 2004 17:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzKg2-0003XG-Kx for simple@megatron.ietf.org; Mon, 23 Aug 2004 15:40:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05316 for ; Mon, 23 Aug 2004 15:40:15 -0400 (EDT) Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzKgB-00040H-Vy for simple@ietf.org; Mon, 23 Aug 2004 15:40:41 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0I2W0088ZZDF60@firewall.mci.com> for simple@ietf.org; Mon, 23 Aug 2004 19:27:15 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I2W00601ZD23N@pmismtp02.mcilink.com>; Mon, 23 Aug 2004 19:27:14 +0000 (GMT) Received: from XS578V7033521.mci.com ([131.146.40.85]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I2W005FLZD6MY@pmismtp02.mcilink.com>; Mon, 23 Aug 2004 19:27:12 +0000 (GMT) Date: Mon, 23 Aug 2004 14:27:03 -0500 From: Alan Johnston Subject: Re: [Simple] MSRP: Contributor ID In-reply-to: <412A3913.6010302@nostrum.com> X-Sender: Alan.Johnston@pop.mcilink.com To: Adam Roach Message-id: <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <1092692976.10426.251.camel@localhost.localdomain> <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 At 01:36 PM 8/23/2004 -0500, Adam Roach wrote: >Alan Johnston wrote: > >>At 05:24 PM 8/16/2004 -0500, Adam Roach wrote: >> >>>At the cost of putting in a "me too" post, I agree with Robert and Ben >>>that there is no good reason to change the solution which we agreed to >>>in Ottawa. The properties of identity in CPIM are well defined and >>>clearly specified. They can clearly be leveraged solve the problem at hand. >>> >>>It seems obvious that arguments like "it won't work" would be a valid >>>reason to re-visit consensus. >> >> >>(Joining this discussion late, so my apologies.) >> >>I suspect "it won't work". MSRP must define in the base specification >>source identification and how mixing is done without loosing source >>identification. > > >Source identification can be performed by correlation between the initial >"From-Path" header element and the session establishment. There isn't >really mixing per se involved, simply message switching -- so all we need >is a mechanism to identify (a) who originated the message (get this from >CPIM), and (b) the "mixer" that sent it to you (get this from "From-Path.") > >Does that address your concern, or did I misunderstand? I thought CPIM use was optional. If so, this proposal seems to break. Remember, the SSRC is RTP is not optional - it is a MUST in the spec. MSRP needs similar strength or interoperability problems will result. Thanks, Alan sip:alan@sipstation.com >/a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 23 18:25:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22532; Mon, 23 Aug 2004 18:25:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzNGj-0000qL-II; Mon, 23 Aug 2004 18:26:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzMVr-0005LS-4F; Mon, 23 Aug 2004 17:37:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzKpJ-0005BF-Jx for simple@megatron.ietf.org; Mon, 23 Aug 2004 15:49:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05995 for ; Mon, 23 Aug 2004 15:49:50 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzKpa-0004EK-MQ for simple@ietf.org; Mon, 23 Aug 2004 15:50:16 -0400 Received: from [63.110.3.154] ([63.110.3.154]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7NJnnvd041521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2004 14:49:49 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <412A4A52.4060608@nostrum.com> Date: Mon, 23 Aug 2004 14:49:39 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [Simple] MSRP: Contributor ID References: <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <1092692976.10426.251.camel@localhost.localdomain> <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> In-Reply-To: <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Alan Johnston wrote: > At 01:36 PM 8/23/2004 -0500, Adam Roach wrote: > >> >> Source identification can be performed by correlation between the >> initial "From-Path" header element and the session establishment. >> There isn't really mixing per se involved, simply message switching >> -- so all we need is a mechanism to identify (a) who originated the >> message (get this from CPIM), and (b) the "mixer" that sent it to you >> (get this from "From-Path.") >> >> Does that address your concern, or did I misunderstand? > > > I thought CPIM use was optional. If so, this proposal seems to > break. Remember, the SSRC is RTP is not optional - it is a MUST in > the spec. MSRP needs similar strength or interoperability problems > will result. I agree. SSRC is mandatory in the same way that From-Path is mandatory. Semantically, they identify the same element. CSRC is optional in the same way that CPIM is optional. Semantically, they identify the same element. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 24 14:13:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29673; Tue, 24 Aug 2004 14:13:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzfnr-0006BT-Sd; Tue, 24 Aug 2004 14:13:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzfO4-0005ls-61; Tue, 24 Aug 2004 13:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzfDX-00037T-V8 for simple@megatron.ietf.org; Tue, 24 Aug 2004 13:36:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26710 for ; Tue, 24 Aug 2004 13:36:13 -0400 (EDT) Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzfE1-0005Qa-P8 for simple@ietf.org; Tue, 24 Aug 2004 13:36:50 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0I2Y00F8LOTH2P@firewall.mci.com> for simple@ietf.org; Tue, 24 Aug 2004 17:34:29 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I2Y00F01OQAAN@pmismtp01.mcilink.com>; Tue, 24 Aug 2004 17:34:29 +0000 (GMT) Received: from XS578V7033521.mci.com ([131.146.1.91]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I2Y00F5TOSIAD@pmismtp01.mcilink.com>; Tue, 24 Aug 2004 17:33:55 +0000 (GMT) Date: Tue, 24 Aug 2004 12:33:53 -0500 From: Alan Johnston Subject: Re: [Simple] MSRP: Contributor ID In-reply-to: <412A4A52.4060608@nostrum.com> X-Sender: Alan.Johnston@pop.mcilink.com To: Adam Roach Message-id: <5.2.1.1.0.20040824122654.04658e88@pop.mcilink.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <1092692976.10426.251.camel@localhost.localdomain> <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 At 02:49 PM 8/23/2004 -0500, Adam Roach wrote: >Alan Johnston wrote: > >>At 01:36 PM 8/23/2004 -0500, Adam Roach wrote: >> >>> >>>Source identification can be performed by correlation between the >>>initial "From-Path" header element and the session establishment. There >>>isn't really mixing per se involved, simply message switching -- so all >>>we need is a mechanism to identify (a) who originated the message (get >>>this from CPIM), and (b) the "mixer" that sent it to you (get this from >>>"From-Path.") >>> >>>Does that address your concern, or did I misunderstand? >> >> >>I thought CPIM use was optional. If so, this proposal seems to >>break. Remember, the SSRC is RTP is not optional - it is a MUST in the >>spec. MSRP needs similar strength or interoperability problems will result. > > >I agree. > >SSRC is mandatory in the same way that From-Path is mandatory. >Semantically, they identify the same element. > >CSRC is optional in the same way that CPIM is optional. Semantically, they >identify the same element. Well, CSRC is optional in RTP, which might explain why no one implements it today - not a good outcome that we wish to repeat. It is not critical because with voice or video media, we can do the identification by sound or sight, so we get by. For text, this is not possible, so I think the semantic equivalent of CSRC must not be optional, and must be fully defined in the base spec of MSRP. Otherwise, in a few months, XCON will send SIMPLE a requirement to extend MSRP in order for text chat rooms and sessions to work properly. We know the requirements - why not just do it now and be done with it? 'd rather not leave a big mess for XCON to have to clean up. Also, even though CSRC is optional, it is fully specified in the base RTP specification - we need the same thing here in MSRP. If CPIM is the right way (not clear to me, but I don't follow SIMPLE closely), the use of CPIM for CSRC needs to be mandated and fully specified in the base MSRP specification. Thanks, Alan sip:alan@sipstation.com >/a > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 24 14:30:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00933; Tue, 24 Aug 2004 14:30:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzg4h-0006VT-1G; Tue, 24 Aug 2004 14:31:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzfmk-0003Vq-VR; Tue, 24 Aug 2004 14:12:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzfUj-0006e6-ME for simple@megatron.ietf.org; Tue, 24 Aug 2004 13:54:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28060 for ; Tue, 24 Aug 2004 13:53:59 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzfV5-0005mG-4D for simple@ietf.org; Tue, 24 Aug 2004 13:54:36 -0400 Received: from [63.110.3.154] ([63.110.3.154]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7OHqPol037904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 12:52:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <412B8045.1070209@nostrum.com> Date: Tue, 24 Aug 2004 12:52:05 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [Simple] MSRP: Contributor ID References: <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <1092692976.10426.251.camel@localhost.localdomain> <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> <5.2.1.1.0.20040824122654.04658e88@pop.mcilink.com> In-Reply-To: <5.2.1.1.0.20040824122654.04658e88@pop.mcilink.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Alan Johnston wrote: > > If CPIM is the right way (not clear to me, but I don't follow SIMPLE > closely), the use of CPIM for CSRC needs to be mandated and fully > specified in the base MSRP specification. I think we may actually be in agreement on this, but I need to poke at it a little bit. What I think is reasonable is provisions that you MUST be able to receive CPIM, and you MUST be able to send CPIM if the remote side requests that you do so. I do _not_ think that _mandating_ that every message use CPIM is reasonable. If you're sending MSRP point-to-point between two endpoints that want to do so without wrapping each message in CPIM, I think they should be allowed to do so. Is that what you're arguing for, or do you want to force the use of CPIM in all cases? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 24 15:15:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04643; Tue, 24 Aug 2004 15:15:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzgmM-0007Ju-HD; Tue, 24 Aug 2004 15:16:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzgXl-0006Bm-TA; Tue, 24 Aug 2004 15:01:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzg84-0008Q5-1w for simple@megatron.ietf.org; Tue, 24 Aug 2004 14:34:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01408 for ; Tue, 24 Aug 2004 14:34:37 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzg8X-0006ak-HS for simple@ietf.org; Tue, 24 Aug 2004 14:35:14 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2004 11:38:59 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7OIY1We026495; Tue, 24 Aug 2004 11:34:02 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-145.cisco.com [10.86.242.145]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB30627; Tue, 24 Aug 2004 14:34:00 -0400 (EDT) Message-ID: <412B8A18.6000205@cisco.com> Date: Tue, 24 Aug 2004 14:34:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [Simple] MSRP: Contributor ID References: <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <1092692976.10426.251.camel@localhost.localdomain> <4120D96C.20605@cisco.com> <1092690181.10426.242.camel@localhost.localdomain> <1092692976.10426.251.camel@localhost.localdomain> <5.2.1.1.0.20040823120555.04645c38@pop.mcilink.com> <5.2.1.1.0.20040823142435.04639ec0@pop.mcilink.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Alan Johnston wrote: > >> Source identification can be performed by correlation between the >> initial "From-Path" header element and the session establishment. >> There isn't really mixing per se involved, simply message switching -- >> so all we need is a mechanism to identify (a) who originated the >> message (get this from CPIM), and (b) the "mixer" that sent it to you >> (get this from "From-Path.") >> >> Does that address your concern, or did I misunderstand? > > I thought CPIM use was optional. If so, this proposal seems to break. > Remember, the SSRC is RTP is not optional - it is a MUST in the spec. > MSRP needs similar strength or interoperability problems will result. Support of CPIM is necessary for interop, but use isn't necessary. If it is required in some context, e.g. in inputs to a conference mixer, then it is simple to negotiate a requirement for a CPIM wrapper on every message. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 24 20:35:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27444; Tue, 24 Aug 2004 20:35:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzllL-0004fh-Mx; Tue, 24 Aug 2004 20:35:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzlOG-0001AD-GK; Tue, 24 Aug 2004 20:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzl5l-0005YR-06 for simple@megatron.ietf.org; Tue, 24 Aug 2004 19:52:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24584 for ; Tue, 24 Aug 2004 19:52:34 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzl6H-0003o4-3t for simple@ietf.org; Tue, 24 Aug 2004 19:53:14 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 24 Aug 2004 16:52:05 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 16:52:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Tue, 24 Aug 2004 16:52:07 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSKEKMgxwdU15q9Q/qdWZelELUiLwACoK6A From: "Orit Levin" To: "Paul Kyzivat" , "Alan Johnston" X-OriginalArrivalTime: 24 Aug 2004 23:52:02.0235 (UTC) FILETIME=[5A1398B0:01C48A35] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable I am back from my one week vacation :-) I can see at least two independent major problems when using CPIM wrapper for MSRP conferencing: 1. Let's assume that CPIM support is mandatory but CPIM use is optional as per Paul. If the sender is a conference-unaware participant, there is no way to "negotiate" or to request the sender to wrap the MSRP message (unless we add "something" mandatory to the core MSRP). This contradicts "draft-ietf-sipping-conferencing-requirements": =20 3.4.1 Participation of a Conference-unaware User Agent REQ -1: Focus MUST be able to invite and disconnect an RFC 3261 compliant only SIP user agent to and from a SIP conference.=20 REQ -2: RFC 3261 compliant only SIP user agent MUST be able to dial-in a particular SIP conference. In this case, only the human knows that he/she is connected to the conference.=20 2. Let's assume that the sender is a conference-aware participant who also wants to convey its private identity in an encrypted CPIM header to its peer(s). This is the original purpose for using CPIM and it must be possible to convey the identity without letting any intermediate, including the focus, to learn it. The collison problem here is that=20 - the CPIM content is the peer-to-peer application information and, as such, is transport independent and can be encrypted - the missing from MSRP "Source ID" is the transport protocol identity and can't be encrypted in order to be used by intermediates Any focus (e.g. operated by XCON) must be able to include some well-defined user identity in its (XCON, conferencing package) communications with the participants. This well-defined identity must be visible to the focus and must also be attached to the MSRP messages sent from the focus. As a result, two CPIM headers will be needed in this scenario to resolve the collision (one in clear and the other encrypted). The mechanism TBD in the core MSRP needs to address these two scenarios. Orit.=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, August 24, 2004 11:34 AM > To: Alan Johnston > Cc: Adam Roach; simple@ietf.org > Subject: Re: [Simple] MSRP: Contributor ID >=20 >=20 >=20 > Alan Johnston wrote: > >=20 > >> Source identification can be performed by correlation between the=20 > >> initial "From-Path" header element and the session establishment. > >> There isn't really mixing per se involved, simply message=20 > switching=20 > >> -- so all we need is a mechanism to identify (a) who=20 > originated the=20 > >> message (get this from CPIM), and (b) the "mixer" that=20 > sent it to you=20 > >> (get this from "From-Path.") > >> > >> Does that address your concern, or did I misunderstand? > >=20 > > I thought CPIM use was optional. If so, this proposal=20 > seems to break. =20 > > Remember, the SSRC is RTP is not optional - it is a MUST in=20 > the spec. =20 > > MSRP needs similar strength or interoperability problems=20 > will result. >=20 > Support of CPIM is necessary for interop, but use isn't necessary. >=20 > If it is required in some context, e.g. in inputs to a=20 > conference mixer, then it is simple to negotiate a=20 > requirement for a CPIM wrapper on every message. >=20 > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 25 01:33:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16006; Wed, 25 Aug 2004 01:33:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzqPy-0001lt-IT; Wed, 25 Aug 2004 01:33:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzq67-0006wd-Kj; Wed, 25 Aug 2004 01:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzpu1-0004t9-K9 for simple@megatron.ietf.org; Wed, 25 Aug 2004 01:00:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14538 for ; Wed, 25 Aug 2004 01:00:48 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzpua-0001Hy-I1 for simple@ietf.org; Wed, 25 Aug 2004 01:01:30 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7P50S107153; Wed, 25 Aug 2004 08:00:29 +0300 (EET DST) X-Scanned: Wed, 25 Aug 2004 08:00:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7P50Cwc005740; Wed, 25 Aug 2004 08:00:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00OhV0FW; Wed, 25 Aug 2004 08:00:12 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7P50Bn25956; Wed, 25 Aug 2004 08:00:11 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Aug 2004 08:00:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 25 Aug 2004 08:00:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7023EEC9B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSKCt1eUXRAfqReR7asfUPraO/nAAAVQ7UQ To: , X-OriginalArrivalTime: 25 Aug 2004 05:00:08.0894 (UTC) FILETIME=[64FBE5E0:01C48A60] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable I don't agree that the base MSRP spec needs to fully specify the = behaviour for a conference. It is not the place to do so. There will be = a separate internet draft describing the behaviour when MSRP is used in = a conference, which is not an MSRP core protocol specification. The = behaviour of a client or conference server in an MSRP session does not = alter MSRP as a protocol and therefore does not need to be described in = the base spec. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Alan Johnston > Sent: 24.August.2004 20:34 > To: Adam Roach > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP: Contributor ID >=20 >=20 > At 02:49 PM 8/23/2004 -0500, Adam Roach wrote: > >Alan Johnston wrote: > > > >>At 01:36 PM 8/23/2004 -0500, Adam Roach wrote: > >> > >>> > >>>Source identification can be performed by correlation between the=20 > >>>initial "From-Path" header element and the session=20 > establishment. There=20 > >>>isn't really mixing per se involved, simply message=20 > switching -- so all=20 > >>>we need is a mechanism to identify (a) who originated the=20 > message (get=20 > >>>this from CPIM), and (b) the "mixer" that sent it to you=20 > (get this from=20 > >>>"From-Path.") > >>> > >>>Does that address your concern, or did I misunderstand? > >> > >> > >>I thought CPIM use was optional. If so, this proposal seems to=20 > >>break. Remember, the SSRC is RTP is not optional - it is a=20 > MUST in the=20 > >>spec. MSRP needs similar strength or interoperability=20 > problems will result. > > > > > >I agree. > > > >SSRC is mandatory in the same way that From-Path is mandatory.=20 > >Semantically, they identify the same element. > > > >CSRC is optional in the same way that CPIM is optional.=20 > Semantically, they=20 > >identify the same element. >=20 > Well, CSRC is optional in RTP, which might explain why no one=20 > implements it=20 > today - not a good outcome that we wish to repeat. It is not=20 > critical=20 > because with voice or video media, we can do the=20 > identification by sound or=20 > sight, so we get by. >=20 > For text, this is not possible, so I think the semantic=20 > equivalent of CSRC=20 > must not be optional, and must be fully defined in the base spec of=20 > MSRP. Otherwise, in a few months, XCON will send SIMPLE a=20 > requirement to=20 > extend MSRP in order for text chat rooms and sessions to work=20 > properly. We=20 > know the requirements - why not just do it now and be done=20 > with it? 'd=20 > rather not leave a big mess for XCON to have to clean up. >=20 > Also, even though CSRC is optional, it is fully specified in=20 > the base RTP=20 > specification - we need the same thing here in MSRP. >=20 > If CPIM is the right way (not clear to me, but I don't follow SIMPLE=20 > closely), the use of CPIM for CSRC needs to be mandated and=20 > fully specified=20 > in the base MSRP specification. >=20 > Thanks, > Alan > sip:alan@sipstation.com >=20 > >/a > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 25 09:56:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15743; Wed, 25 Aug 2004 09:56:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzyHM-0002Mn-Ap; Wed, 25 Aug 2004 09:57:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzy2T-0007Ht-0V; Wed, 25 Aug 2004 09:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzxtb-0005Ll-Nf for simple@megatron.ietf.org; Wed, 25 Aug 2004 09:32:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13951 for ; Wed, 25 Aug 2004 09:32:53 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzxuD-0001u9-3y for simple@ietf.org; Wed, 25 Aug 2004 09:33:40 -0400 Received: from [192.168.0.102] (adsl-209-30-32-144.dsl.rcsntx.swbell.net [209.30.32.144]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7PDVCVS025266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2004 08:31:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <412C94A4.3050402@nostrum.com> Date: Wed, 25 Aug 2004 08:31:16 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin Subject: Re: [Simple] MSRP: Contributor ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Alan Johnston , Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Orit Levin wrote: >I am back from my one week vacation :-) >I can see at least two independent major problems when using CPIM >wrapper for MSRP conferencing: > >1. Let's assume that CPIM support is mandatory but CPIM use is optional >as per Paul. If the sender is a conference-unaware participant, there is >no way to "negotiate" or to request the sender to wrap the MSRP message > > Yes, there is. In the SDP, you can indicate that the only unwrapped type that you accept is CPIM. This forces the remote endpoint to always send CPIM-wrapped messages. >2. Let's assume that the sender is a conference-aware participant who >also wants to convey its private identity in an encrypted CPIM header to >its peer(s). This is the original purpose for using CPIM and it must be >possible to convey the identity without letting any intermediate, >including the focus, to learn it. The collison problem here is that >- the CPIM content is the peer-to-peer application information and, as >such, is transport independent and can be encrypted >- the missing from MSRP "Source ID" is the transport protocol identity >and can't be encrypted in order to be used by intermediates >Any focus (e.g. operated by XCON) must be able to include some >well-defined user identity in its (XCON, conferencing package) >communications with the participants. > This correlation is provided by the first element in the From-Path. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 25 14:18:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06560; Wed, 25 Aug 2004 14:18:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C02N2-0007H8-Js; Wed, 25 Aug 2004 14:19:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01uY-0007p3-Vk; Wed, 25 Aug 2004 13:50:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01kC-0005rd-ES for simple@megatron.ietf.org; Wed, 25 Aug 2004 13:39:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03901 for ; Wed, 25 Aug 2004 13:39:26 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C01kq-0006Yu-8z for simple@ietf.org; Wed, 25 Aug 2004 13:40:15 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7PHcl13045902 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 Aug 2004 12:38:47 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP when used with SIP/SDP inconsistent with RFC2327 ABNF Date: Wed, 25 Aug 2004 12:38:52 -0500 To: Pekka Pessi X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Sorry for answering so late; I somehow missed this thread until now. Comments inline. On Aug 19, 2004, at 7:19 AM, Pekka Pessi wrote: > Peter Ridler writes: >> In the draft-ietf-simple-messages-sessions-07.txt Section 7.1 uses >> "accept-types" in the attribute-fields (the a= line) where RFC2327 >> defines >> attribute as: > ... >> Note that "att-field" only allows for alpha-numeric field names which >> would >> make "accept-types" illegal. Maybe the name should be changed to >> "AcceptTypes" or something to conform. > > RFC 2327 syntax is outdated and it contradicts with the examples > and actual usage (like, it does not allow RTP/AVP as a transport > protocol for media.) I think the problem lies with > message-session-07 reference [2], [2] should refer to > draft-ietf-mmusic-sdp-new-XX. Hmm. I'm not sure how to handle this one; a normative reference to a non-rfc will likely delay publication for some time, but we do need to reference the right thing. Can the chairs offer a comment? > >> Also, Why is the path attribute used and not the media-field (m= >> line) used >> as described in the RFC2327 standard? I see that the path can have >> multiple >> urls defined but I don't see no more then one ever being used! SIP >> controls >> the call/session information between the endpoints, MSRP should not >> have to >> resolve the communication paths again. > > Please see . Traversing > through firewalls by using relays is MSRP's raison d'etre. I assume you mean draft-ietf-simple-msrp-relays-01.txt. > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 25 14:25:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07121; Wed, 25 Aug 2004 14:25:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C02T7-0007Nn-LL; Wed, 25 Aug 2004 14:25:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C02B6-0001MF-W0; Wed, 25 Aug 2004 14:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01r8-0007Hl-F6 for simple@megatron.ietf.org; Wed, 25 Aug 2004 13:46:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04458 for ; Wed, 25 Aug 2004 13:46:36 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C01rp-0006i7-8H for simple@ietf.org; Wed, 25 Aug 2004 13:47:25 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 25 Aug 2004 10:46:04 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 10:46:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 25 Aug 2004 10:45:56 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSKqAjAU2E4zw3/QASHYnLbbS233wAH9Ghg From: "Orit Levin" To: "Adam Roach" X-OriginalArrivalTime: 25 Aug 2004 17:46:05.0213 (UTC) FILETIME=[6515ACD0:01C48ACB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: Alan Johnston , Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Inline.=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Wednesday, August 25, 2004 6:31 AM > To: Orit Levin > Cc: Paul Kyzivat; Alan Johnston; simple@ietf.org > Subject: Re: [Simple] MSRP: Contributor ID >=20 > Orit Levin wrote: >=20 > >I am back from my one week vacation :-) I can see at least two=20 > >independent major problems when using CPIM wrapper for MSRP=20 > >conferencing: > > > >1. Let's assume that CPIM support is mandatory but CPIM use=20 > is optional=20 > >as per Paul. If the sender is a conference-unaware=20 > participant, there=20 > >is no way to "negotiate" or to request the sender to wrap the MSRP=20 > >message > > =20 > > >=20 > Yes, there is. In the SDP, you can indicate that the only=20 > unwrapped type that you accept is CPIM. This forces the=20 > remote endpoint to always send CPIM-wrapped messages. >=20 I understand. This case will work if a focus will always request for (and insist on) CPIM wrap for both dial-in and dial-out calls. This assumption needs to be explicitly stated in the core MSRP if we stick to CPIM. I still have privacy concerns with this scenario, but they depend on the solution to the second "problem" below. > >2. Let's assume that the sender is a conference-aware=20 > participant who=20 > >also wants to convey its private identity in an encrypted=20 > CPIM header=20 > >to its peer(s). This is the original purpose for using CPIM=20 > and it must=20 > >be possible to convey the identity without letting any intermediate,=20 > >including the focus, to learn it. The collison problem here is that > >- the CPIM content is the peer-to-peer application=20 > information and, as=20 > >such, is transport independent and can be encrypted > >- the missing from MSRP "Source ID" is the transport=20 > protocol identity=20 > >and can't be encrypted in order to be used by intermediates=20 > Any focus=20 > >(e.g. operated by XCON) must be able to include some=20 > well-defined user=20 > >identity in its (XCON, conferencing package) communications with the=20 > >participants. > > >=20 > This correlation is provided by the first element in the From-Path. > I hope I don't understand your answer. Do you envision that for each real source a different From-Path value will be generated by the focus? (a-la SSRC by mixer) What is the perceived "dialog-id" or "session-id" for MSRP and how many MSRP "dialogs" or "sessions" do you see being established (by SDP) and maintained between a focus and its single participant? > /a >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 25 16:12:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16151; Wed, 25 Aug 2004 16:12:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C048m-0001Jq-52; Wed, 25 Aug 2004 16:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C03sm-0003Gb-GP; Wed, 25 Aug 2004 15:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C03bv-00005Z-Bj for simple@megatron.ietf.org; Wed, 25 Aug 2004 15:39:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13000 for ; Wed, 25 Aug 2004 15:39:00 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C03cb-0000Cr-0O for simple@ietf.org; Wed, 25 Aug 2004 15:39:51 -0400 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7PJalHS055709 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 Aug 2004 14:36:48 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1DB13457-F6CE-11D8-A6E0-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP: Contributor ID Date: Wed, 25 Aug 2004 14:36:52 -0500 To: "Orit Levin" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: Alan Johnston , Paul Kyzivat , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit On Aug 25, 2004, at 12:45 PM, Orit Levin wrote: > Inline. > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Wednesday, August 25, 2004 6:31 AM >> To: Orit Levin >> Cc: Paul Kyzivat; Alan Johnston; simple@ietf.org >> Subject: Re: [Simple] MSRP: Contributor ID >> >> Orit Levin wrote: >> >>> I am back from my one week vacation :-) I can see at least two >>> independent major problems when using CPIM wrapper for MSRP >>> conferencing: >>> >>> 1. Let's assume that CPIM support is mandatory but CPIM use >> is optional >>> as per Paul. If the sender is a conference-unaware >> participant, there >>> is no way to "negotiate" or to request the sender to wrap the MSRP >>> message >>> >>> >> >> Yes, there is. In the SDP, you can indicate that the only >> unwrapped type that you accept is CPIM. This forces the >> remote endpoint to always send CPIM-wrapped messages. >> > I understand. This case will work if a focus will always request for > (and insist on) CPIM wrap for both dial-in and dial-out calls. This > assumption needs to be explicitly stated in the core MSRP if we stick > to > CPIM. I still have privacy concerns with this scenario, but they depend > on the solution to the second "problem" below. > >>> 2. Let's assume that the sender is a conference-aware >> participant who >>> also wants to convey its private identity in an encrypted >> CPIM header >>> to its peer(s). This is the original purpose for using CPIM >> and it must >>> be possible to convey the identity without letting any intermediate, >>> including the focus, to learn it. The collison problem here is that >>> - the CPIM content is the peer-to-peer application >> information and, as >>> such, is transport independent and can be encrypted >>> - the missing from MSRP "Source ID" is the transport >> protocol identity >>> and can't be encrypted in order to be used by intermediates >> Any focus >>> (e.g. operated by XCON) must be able to include some >> well-defined user >>> identity in its (XCON, conferencing package) communications with the >>> participants. >>> >> >> This correlation is provided by the first element in the From-Path. >> > I hope I don't understand your answer. > Do you envision that for each real source a different From-Path value > will be generated by the focus? (a-la SSRC by mixer) > I think Adam's point was, if the focus needs to know who sent a particular message, it can compare the From-Path value with the values used in the initial session creation, and infer the sender's identity. > What is the perceived "dialog-id" or "session-id" for MSRP and how many > MSRP "dialogs" or "sessions" do you see being established (by SDP) and > maintained between a focus and its single participant? There is likely one MSRP session, and one SIP dialog between the focus and a given participant. Clearly that does not _have_ to be the case, but it will be the common case. I think there are two basic models of focus operation we need to deal with, and your problem statement appears to be rooted in the second of them. 1) The focus tells each participant to identify themselves. The focus requires all messages to be wrapped in CPIM using the wrapped-types mechanism. 2) The focus says, no _I_ will identify you. The focus determines the identity from the session parameters, and inserts something attributing the message to a sender. This could be a header, or it could add its on CPIM wrapper. If the message already had a cpim wrapper, then the focus could choose to leave it alone, or put it inside yet another wrapper. (You can have nested cpim wrappers.) >> /a >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 25 18:38:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03650; Wed, 25 Aug 2004 18:38:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C06Qo-0006N0-P0; Wed, 25 Aug 2004 18:39:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C06If-0003aw-63; Wed, 25 Aug 2004 18:31:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C051x-0000Rx-9N for simple@megatron.ietf.org; Wed, 25 Aug 2004 17:10:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22020 for ; Wed, 25 Aug 2004 17:09:58 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C052g-00030h-Hp for simple@ietf.org; Wed, 25 Aug 2004 17:10:51 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 25 Aug 2004 14:09:30 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 14:09:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 25 Aug 2004 14:09:45 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSK2zH2pmqUz67mRCalHWiAtc9pjAABddSg From: "Orit Levin" To: "Ben Campbell" X-OriginalArrivalTime: 25 Aug 2004 21:09:29.0408 (UTC) FILETIME=[CF5A0C00:01C48AE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: Alan Johnston , Paul Kyzivat , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable =20 Inline. > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Wednesday, August 25, 2004 12:37 PM > To: Orit Levin > Cc: Adam Roach; Alan Johnston; simple@ietf.org; Paul Kyzivat > Subject: Re: [Simple] MSRP: Contributor ID >=20 >=20 > On Aug 25, 2004, at 12:45 PM, Orit Levin wrote: >=20 > > Inline. > > > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com] > >> Sent: Wednesday, August 25, 2004 6:31 AM > >> To: Orit Levin > >> Cc: Paul Kyzivat; Alan Johnston; simple@ietf.org > >> Subject: Re: [Simple] MSRP: Contributor ID > >> > >> Orit Levin wrote: > >> > >>> I am back from my one week vacation :-) I can see at least two=20 > >>> independent major problems when using CPIM wrapper for MSRP > >>> conferencing: > >>> > >>> 1. Let's assume that CPIM support is mandatory but CPIM use > >> is optional > >>> as per Paul. If the sender is a conference-unaware > >> participant, there > >>> is no way to "negotiate" or to request the sender to wrap=20 > the MSRP=20 > >>> message > >>> > >>> > >> > >> Yes, there is. In the SDP, you can indicate that the only=20 > unwrapped=20 > >> type that you accept is CPIM. This forces the remote endpoint to=20 > >> always send CPIM-wrapped messages. > >> > > I understand. This case will work if a focus will always=20 > request for=20 > > (and insist on) CPIM wrap for both dial-in and dial-out calls. This=20 > > assumption needs to be explicitly stated in the core MSRP=20 > if we stick=20 > > to CPIM. I still have privacy concerns with this scenario, but they=20 > > depend on the solution to the second "problem" below. > > > >>> 2. Let's assume that the sender is a conference-aware > >> participant who > >>> also wants to convey its private identity in an encrypted > >> CPIM header > >>> to its peer(s). This is the original purpose for using CPIM > >> and it must > >>> be possible to convey the identity without letting any=20 > intermediate,=20 > >>> including the focus, to learn it. The collison problem=20 > here is that > >>> - the CPIM content is the peer-to-peer application > >> information and, as > >>> such, is transport independent and can be encrypted > >>> - the missing from MSRP "Source ID" is the transport > >> protocol identity > >>> and can't be encrypted in order to be used by intermediates > >> Any focus > >>> (e.g. operated by XCON) must be able to include some > >> well-defined user > >>> identity in its (XCON, conferencing package)=20 > communications with the=20 > >>> participants. > >>> > >> > >> This correlation is provided by the first element in the From-Path. > >> > > I hope I don't understand your answer. > > Do you envision that for each real source a different=20 > From-Path value=20 > > will be generated by the focus? (a-la SSRC by mixer) > > >=20 > I think Adam's point was, if the focus needs to know who sent=20 > a particular message, it can compare the From-Path value with=20 > the values used in the initial session creation, and infer=20 > the sender's identity. >=20 I am glad to hear that. Hope you are right in your interpretation. >=20 > > What is the perceived "dialog-id" or "session-id" for MSRP and how=20 > > many MSRP "dialogs" or "sessions" do you see being established (by=20 > > SDP) and maintained between a focus and its single participant? >=20 > There is likely one MSRP session, and one SIP dialog between=20 > the focus and a given participant. Clearly that does not=20 > _have_ to be the case, but it will be the common case. >=20 I agree 100%. > I think there are two basic models of focus operation we need=20 > to deal with, and your problem statement appears to be rooted=20 > in the second of them. >=20 > 1) The focus tells each participant to identify themselves.=20 > The focus requires all messages to be wrapped in CPIM using=20 > the wrapped-types mechanism. >=20 > 2) The focus says, no _I_ will identify you. The focus=20 > determines the identity from the session parameters, and=20 > inserts something attributing the message to a sender. This=20 > could be a header, or it could add its on CPIM wrapper. =20 Again, I agree with your presentation of the possible cases. > If=20 > the message already had a cpim wrapper, then the focus could=20 > choose to leave it alone, or put it inside yet another wrapper.=20 > (You can have nested cpim wrappers.) > To accommodate the end-to-end encrypted CPIM, it will need to be something like: If the message already had a cpim wrapper and the destination is conference-aware, then the focus puts it inside yet another clear wrapper (that is in order to provide mapping to conferencing extensions). If the message already had a cpim wrapper and the destination is conference-unaware (e.g. doesn't use XCON) leave it alone (that is in order to not confuse the receiving client with conferencing information vs. peer-to-peer information). This is VERY DIFFERENT from the existing today conferencing architecture where the focus logic is NOT dependant on the participant's ability to understand or actively support conferencing extensions and protocols. Yet "MY MAJOR PROBLEM" with using CPIM wrapper for conferencing/focus can be summarised as following: There is no (well-defined simple) way in the CPIM header to distinguish whether a particular CPIM is being used for intermediate (e.g. focus, GW) vs. for peer-to-peer needs. A user may have very different privacy policies regarding each. In the case of conference-unaware user - the UA will not even have the ability to distinguish between the two cases. Which identity will the user put in the requested CPIM header? The private (for peer-to-peer) or the public for the focus use? How the receiving participant (which can be conference unaware as well) will undertsand what kind of identity he is looking at? Just to add to it, in many systems GW functionality is achived by MCUs that are responsible for "bridging" among different protocols. This clearly illustrates that the privacy and security requirements for using MCUs are similar to those for GWs: i.e. the end-to-end privacy, for which CPIM techniques have been introdiced in the first place, is required to be addressed when working through MCUs. Orit. > >> /a > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 26 15:06:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27958; Thu, 26 Aug 2004 15:06:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0PaQ-0003eJ-6g; Thu, 26 Aug 2004 15:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0PX4-00008C-Mq; Thu, 26 Aug 2004 15:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0PUH-0005Jo-4z for simple@megatron.ietf.org; Thu, 26 Aug 2004 15:00:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27583 for ; Thu, 26 Aug 2004 15:00:39 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0PVF-0003Zt-L8 for simple@ietf.org; Thu, 26 Aug 2004 15:01:42 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 26 Aug 2004 15:11:35 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7QI055g010043; Thu, 26 Aug 2004 14:00:05 -0400 (EDT) Received: from cisco.com (che-vpn-cluster-1-120.cisco.com [10.86.240.120]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALC86163; Thu, 26 Aug 2004 15:00:04 -0400 (EDT) Message-ID: <412E3334.90809@cisco.com> Date: Thu, 26 Aug 2004 15:00:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin Subject: Re: [Simple] MSRP: Contributor ID References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Alan Johnston , Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Orit Levin wrote: > >>If >>the message already had a cpim wrapper, then the focus could >>choose to leave it alone, or put it inside yet another wrapper. >>(You can have nested cpim wrappers.) >> > > To accommodate the end-to-end encrypted CPIM, it will need to be > something like: > If the message already had a cpim wrapper and the destination is > conference-aware, then the focus puts it inside yet another clear > wrapper (that is in order to provide mapping to conferencing > extensions). > If the message already had a cpim wrapper and the destination is > conference-unaware (e.g. doesn't use XCON) leave it alone (that is in > order to not confuse the receiving client with conferencing information > vs. peer-to-peer information). > > This is VERY DIFFERENT from the existing today conferencing architecture > where the focus logic is NOT dependant on the participant's ability to > understand or actively support conferencing extensions and protocols. I don't understand why you are splitting out different behaviors for conference aware and unaware participants. If the focus wants to ensure that messages are properly identified as to source, then it will either have to add a CPIM wrapper, or else inspect and approve one that is already present. If the message is encrypted e2e so that the focus can't decrypt, then it doesn't matter whether the encrypted body is CPIM or not. Either way the focus will have to wrap the encrypted body in a new CPIM wrapper. It can only avoid this if it doesn't feel it is necessary to identify the message sender. It will be up to the conference arch to decide about that. Maybe it will depend on whether the recipient is conference aware, maybe not. > Yet "MY MAJOR PROBLEM" with using CPIM wrapper for conferencing/focus > can be summarised as following: > There is no (well-defined simple) way in the CPIM header to distinguish > whether a particular CPIM is being used for intermediate (e.g. focus, > GW) vs. for peer-to-peer needs. A user may have very different privacy > policies regarding each. In the case of conference-unaware user - the UA > will not even have the ability to distinguish between the two cases. Why should there be? there isn't any way to do this for RTP/RTCP. There isn't any ability to have both kinds. And it is up to the mixer whether it preserves the IDs provided by the sender or puts in artificial ones. The recipient can't tell which is the case. > Which identity will the user put in the requested CPIM header? The > private (for peer-to-peer) or the public for the focus use? How the > receiving participant (which can be conference unaware as well) will > undertsand what kind of identity he is looking at? If there are multiple unsigned and unencrypted identities, then the recipient should probably display them all, or maybe none of them if it is untrusting. If some or all of the identities are signed, then it could choose to only display ones signed by somebody it trusts. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 26 16:19:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07447; Thu, 26 Aug 2004 16:19:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0QjY-0006YH-Q3; Thu, 26 Aug 2004 16:20:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Q2C-00088b-B2; Thu, 26 Aug 2004 15:35:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Q1K-0007hN-CA; Thu, 26 Aug 2004 15:34:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00896; Thu, 26 Aug 2004 15:34:48 -0400 (EDT) Message-Id: <200408261934.PAA00896@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 26 Aug 2004 15:34:48 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-08.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-08.txt Pages : 49 Date : 2004-8-26 This document describes the Message Session Relay Protocol (MSRP), a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when setup via a rendezvous or session setup protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-26150730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-26150730.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Aug 26 19:18:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23714; Thu, 26 Aug 2004 19:18:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0TX4-0002Lr-EA; Thu, 26 Aug 2004 19:19:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0TS5-0006hR-Nt; Thu, 26 Aug 2004 19:14:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0TN8-0005x9-G3 for simple@megatron.ietf.org; Thu, 26 Aug 2004 19:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23225 for ; Thu, 26 Aug 2004 19:09:31 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0TO8-0002BK-Si for simple@ietf.org; Thu, 26 Aug 2004 19:10:38 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Thu, 26 Aug 2004 16:09:00 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 16:08:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Thu, 26 Aug 2004 16:08:59 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSLnu6q5lMPHfU5QnK2n8BL3QchEwAFj21w From: "Orit Levin" To: "Paul Kyzivat" X-OriginalArrivalTime: 26 Aug 2004 23:08:58.0000 (UTC) FILETIME=[AA942100:01C48BC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Paul, The answer to "why" in each of the cases relates to the fact that different cases belong to same architecture/possible deployment. Even when you see a solution to one case - you are unintentionally missing another unless you go through the exercise of defining the full conferencing architecture. Instead, if we step back and try to look at the problem from the top, CPIM is a simple means for peer-to-peer private communications with non-trusted intermediates (e.g. GW, MCUs) potentially present in the middle. Using CPIM for communications between users and the intermediates themselves (and still being able to use CPIM for what it had been designed for) without defining standard ubiquitous means for distinguishing between the cases - is close to impossible. On the RTP note, RTP is different from MSRP in many aspects: - RTP doesn't use CPIM and as a result doesn't have this problem to start from :-) - SSRC is used as a stream identifier only. In the core RTP, there is no multiplexing inside the UDP connection (which is 1-to-1 with the RTP session). In MSRP, the from-path value is used as the part of the "MSRP session identifier" for multiplexing inside a TCP tunnel. - in addition to the RTP "mixer" mode being implemented today, RTP also defines the "translator" mode - which is much closer to what happening in IM conferencing case. It this mode, the original SSRC is PRESERVED by translators (and the CSRC list is not created because it doesn't have any meaning at all). As it was stated earlier, voice and video conferencing vendors got away with it only because the user can guess the source by his/her voice or video. This doesn't work for IM unless an advanced conferencing protocol (e.g. XCON) is being used by ALL participants. Orit. =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, August 26, 2004 12:00 PM > To: Orit Levin > Cc: Ben Campbell; Adam Roach; Alan Johnston; simple@ietf.org > Subject: Re: [Simple] MSRP: Contributor ID >=20 >=20 >=20 > Orit Levin wrote: > > =20 > >>If > >>the message already had a cpim wrapper, then the focus=20 > could choose to=20 > >>leave it alone, or put it inside yet another wrapper. > >>(You can have nested cpim wrappers.) > >> > >=20 > > To accommodate the end-to-end encrypted CPIM, it will need to be=20 > > something like: > > If the message already had a cpim wrapper and the destination is=20 > > conference-aware, then the focus puts it inside yet another clear=20 > > wrapper (that is in order to provide mapping to conferencing=20 > > extensions). > > If the message already had a cpim wrapper and the destination is=20 > > conference-unaware (e.g. doesn't use XCON) leave it alone=20 > (that is in=20 > > order to not confuse the receiving client with conferencing=20 > > information vs. peer-to-peer information). > > > > This is VERY DIFFERENT from the existing today conferencing=20 > > architecture where the focus logic is NOT dependant on the=20 > > participant's ability to understand or actively support=20 > conferencing extensions and protocols. >=20 > I don't understand why you are splitting out different=20 > behaviors for conference aware and unaware participants. >=20 > If the focus wants to ensure that messages are properly=20 > identified as to source, then it will either have to add a=20 > CPIM wrapper, or else inspect and approve one that is already=20 > present. If the message is encrypted e2e so that the focus=20 > can't decrypt, then it doesn't matter whether the encrypted=20 > body is CPIM or not. Either way the focus will have to wrap=20 > the encrypted body in a new CPIM wrapper. >=20 > It can only avoid this if it doesn't feel it is necessary to=20 > identify the message sender. It will be up to the conference=20 > arch to decide about that. Maybe it will depend on whether=20 > the recipient is conference aware, maybe not. >=20 > > Yet "MY MAJOR PROBLEM" with using CPIM wrapper for=20 > conferencing/focus=20 > > can be summarised as following: > > There is no (well-defined simple) way in the CPIM header to=20 > > distinguish whether a particular CPIM is being used for=20 > intermediate=20 > > (e.g. focus, > > GW) vs. for peer-to-peer needs. A user may have very=20 > different privacy=20 > > policies regarding each. In the case of conference-unaware=20 > user - the=20 > > UA will not even have the ability to distinguish between=20 > the two cases. >=20 > Why should there be? there isn't any way to do this for=20 > RTP/RTCP. There isn't any ability to have both kinds. And it=20 > is up to the mixer whether it preserves the IDs provided by=20 > the sender or puts in artificial ones.=20 > The recipient can't tell which is the case. >=20 > > Which identity will the user put in the requested CPIM header? The=20 > > private (for peer-to-peer) or the public for the focus use? How the=20 > > receiving participant (which can be conference unaware as=20 > well) will=20 > > undertsand what kind of identity he is looking at? >=20 > If there are multiple unsigned and unencrypted identities,=20 > then the recipient should probably display them all, or maybe=20 > none of them if it is untrusting. If some or all of the=20 > identities are signed, then it could choose to only display=20 > ones signed by somebody it trusts. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 27 00:11:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10235; Fri, 27 Aug 2004 00:11:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0Y6E-0007bD-8h; Fri, 27 Aug 2004 00:12:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Y3O-0003Y9-HK; Fri, 27 Aug 2004 00:09:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Y2f-0003Oa-Rv for simple@megatron.ietf.org; Fri, 27 Aug 2004 00:08:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10089 for ; Fri, 27 Aug 2004 00:08:42 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0Y3g-0007XS-IS for simple@ietf.org; Fri, 27 Aug 2004 00:09:52 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7R48TCY007280 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 26 Aug 2004 23:08:30 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) To: Simple WG Message-Id: <6DC69E11-F7A3-11D8-B5FD-000D93B0AE1A@nostrum.com> From: Ben Campbell Subject: Fwd: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-08.txt Date: Thu, 26 Aug 2004 16:03:49 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.7 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1029047298==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 --===============1029047298== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--717086848; protocol="application/pkcs7-signature" --Apple-Mail-11--717086848 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit This draft should take care of all previous open issues I am aware of, or at least that I remembered, except for the following: 1) The source ID issue, which is still under discussion. 2) The normative reference to the SDP RFC. It has been pointed out that the RFC does not allow the hyphens in some of our a line attributes, but that draft updating SDP does. We need to decide whether to have a normative reference to a work-in-progress, or fix our syntax to match the RFC. There was a lot of feedback on the previous revision, so if I missed anything or failed to incorporate someone's feedback, please let me know. Thanks! Ben. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: August 26, 2004 2:34:48 PM CDT > To: i-d-announce@ietf.org > Cc: simple@ietf.org > Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-08.txt > > 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 : The Message Session Relay Protocol > Author(s) : B. Campbell, et al. > Filename : draft-ietf-simple-message-sessions-08.txt > Pages : 49 > Date : 2004-8-26 > > This document describes the Message Session Relay Protocol (MSRP), a > protocol for transmitting a series of related instant messages in > the > context of a session. Message sessions are treated like any other > media stream when setup via a rendezvous or session setup protocol > such as the Session Initiation Protocol (SIP). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-message- > sessions-08.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-simple-message-sessions-08.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-message-sessions-08.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. > Content-Type: text/plain > Content-ID: <2004-8-26150730.I-D@ietf.org> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --Apple-Mail-11--717086848 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAwwdSDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMjA0NTUyWhcNMDUwNDEyMjA0NTUyWjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFv8c1i8a9NXiEohMEryzypOcyz39k8PN WxTS4F45JSYwQ0/RAZ4vaemHCyJaUc7tc5DN3o7zl2oaqQuOIrvnjk79ILGJVfRgwt+uGDIGyaSM YmBeKXSdawFiJdk5jGtMzlgF8tzJzc4do5Mzl5YS39AR8mj8PF4zEgIlYYkKXBByHQ2jPA0qVfm/ Aj71RdYZyDAD4P7TyW9jKvZCl7KCfajar1llEQVj+kWMvt/3AE6mwAHXfkU7nL9XzLvGSnMUJvYx hq3UDju4IacXsYFw2oLb4LQdvwP4Lbg6qdp08h59+TkHlV6WNdt3ggM9C/cGQTDCa0CVJsr+76Dm mPorAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAApFAg5tsI2OhByoUglTZ+ip3M/1xfWDsCNsDB4+HtnH9fZfKkrkGp4e JQyuvl5VhvW67qYU6wEPMD0EKoWDU3v7l1huzR7Cpkf7n21y4LLG+VxldYiA3SEkv7RBPhhVhdMl sHwNZAYyVXFCdnvuVjfeytdAeXK6vzcaUvo9EwkHMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMHUgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDQwODI2MjEwMzUwWjAjBgkqhkiG9w0BCQQxFgQUch3X439+fAKBGS/G jjzy4xEcUmAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwwdSDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMHUgwDQYJKoZIhvcNAQEBBQAEggEAU5eBu1M4uOfkOHtU KmhQoty5Ep2btxz942XEE1LguFCElYdex/qx8JMeenrT+Jn/ZsFx+Umopc4CF1y0ziAVwd47pud3 W9hbJZyhoVlwJSBW/AA+yKzojjozxicDkLJEuZjVgkZ3b9K/VZUW1d3CHNaWVNkb3pYYlaex8G7H 6NwtpxRUB8FsMXC1HZPw7/F7WpwiuPjPRzLEx+K6Bc1GE7vnYmiVKotPFnKbD2PLdGjs7j+Gcyav LqqnRbgdXDy/DOPVeTekLzgPa3n4GbqtN/2XolbdKRyL22nVnI1BaP0Ic7tRNwLo7L2W6xdmdTjd +ZOV5NFCjk/H7cn41p9PVgAAAAAAAA== --Apple-Mail-11--717086848-- --===============1029047298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1029047298==-- From simple-bounces@ietf.org Fri Aug 27 09:03:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26843; Fri, 27 Aug 2004 09:03:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gPb-0000lH-A2; Fri, 27 Aug 2004 09:04:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gCZ-0000am-Qk; Fri, 27 Aug 2004 08:51:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0g8t-00085f-7j for simple@megatron.ietf.org; Fri, 27 Aug 2004 08:47:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26109 for ; Fri, 27 Aug 2004 08:47:41 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gA2-0000Uj-6S for simple@ietf.org; Fri, 27 Aug 2004 08:48:54 -0400 Received: from dynamicsoft.com ([63.113.46.31]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i7RClDeE022983; Fri, 27 Aug 2004 08:47:13 -0400 (EDT) Message-ID: <412F2D3B.5000609@dynamicsoft.com> Date: Fri, 27 Aug 2004 08:46:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland Subject: Re: [Simple] XCAP as general configuration protocol. References: <20040812133605.10496.59603.polymer@peirce.gestalt.entity.net> In-Reply-To: <20040812133605.10496.59603.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit Dave, Apologies for the long delay in responding. Answers inline. Dave Cridland wrote: > Hi folks, > > I'm a little confused by XCAP's purpose - is it aimed at providing a > configuration protocol specifically for the needs of SIMPLE's > protocol suite, or is it aimed at providing generalized configuration > access? > > It may help to know that I'm looking at it from the perspective of > someone who's operationally deployed ACAP in production environments, > but given the lack of support, if XCAP takes off, then I might have > to switch. I appreciate this is an unusual perspective. :-) > > It may also help to know I know next to nothing about XML Schemas, > which is unfortunate, but I note this draft is heading quickly > towards last call, so I wanted to find out exactly what it's doing as > quickly as possible. > > Things I'm particularly confused about: > > 1) How do vendor-specific extensions work? (Say, if an addressbook or > bookmark collection were stored in XCAP, how would an application > add its own data to it?) Is this handled purely by namespaces, or > does that interfere with the Schemas defined? Each of the schemas in an application usage defines points where extensions can add additional information. That additional information would come from a different namespace. > > 2) Given the degree of validation effort possible to request from the > server, is it within the specification to have an AUID that doesn't > do any validation? Yes. Indeed, extensions to existing application usages, which are not understood by the server, will have no validation beyond XML well formedness. > (Obviously it'd have to do XML-well-formedness.) I'm > quite concerned that XCAP appears to be a substantial resource-hog - > performing referential integrity checks on XML can't be the fastest > thing in the world XCAP servers don't do referential integrity checks. This is explicitly called out somewhere. >(I could be wrong, but it's certainly going to be > slower than a purely syntactic validation). Does anyone have any > information on how fast (or slow) an XCAP server is? I don't have performance figures. I suspect they depend on the app usage. > > 3) As I understand it, the only method of searching is via the > reduced XPath used in the URI. Is there any reason why a redefinition > of a reduced XPath has been used rather than simply using XPath in > the URI? (I can't see anyone choosing to handle these URIs in any way > other than using an XPath library). There was a LOOONG debate on this. XPath does a lot of stuff we really don't need or want, as it would introduce a lot of complexity into the server and client for no net benefit. Thus, our approach was to use a strict subset. > > 4) Given that, in general, applications will wish to use a > substanital block of configuration data, and maintain it as current > as reasonably possible, how does an application obtain a list of > changes since a certain time (or ETag)? The only method I can see is > by polling the entire block, which, if changed, will produce a > substantial amount of output. The following spec defines a format for differences in documents: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-02.txt These documents would get delivered in notifications, using a SIP event package: http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-04.txt > > Alternately, an application could try an If-None-Match HTTP request > against every node - the problem then being that, naturally, the > entire document will not match the stored ETag, hence reducing to a > full poll. > > This strikes me as quite a serious problem, so I'd like to be assured > that I'm missing something obvious. (Ideally, XCAP would have push > notifications like ACAP has, but given the HTTP basis, that is of > course impossible.) Right, thats why we use a SIP event package for pushing diffs. > > > Of course, I don't care about any of the above if XCAP isn't really > intended for the same general target as ACAP is - in which case I'll > keep my eye out for some other, more suitable, replacement. (A > shame, since ACAP is perfectly suited to my needs.) TO be clear, it is NOT the objective of XCAP to be a feature for feature equivalent replacement to ACAP. The group looked at acap as the basis of its work: http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.txt but decided not to use acap. As such, XCAP is "inspired" by ACAP, but not designed to be a replacement. I suspect it meets many of the needs of any existing ACAP users (though I admit I didnt know there were any!), but I am sure it doesnt meet them all. In particular, we purposefully rejected features like inheritance and built in ACL support, which are present in ACAP, but were not needed for our applications. Answering some of your follow up questions from Joel's response: >> With regard to your specific questions: 1) Extensibility depends >> upon the schema of the application. If the application schema does >> not allow for extensions, then there are no vendor extensions. If >> every element of the scheme has an any tag permitted, then you can >> do anything you want. >> >> > Presumably that applies to standardized extensions, too - a new > version of a particular AU would require an entirely new AUID? No. The AUID remains unchanged. Standardized extensions all have built-in extensibility. > (Since, if there's no extensibility space available, replacement > would be the only solution.) > > That suggests that clients and servers will become increasingly more > complex, or else will lose interoperability. Unknown information in the XML document (so long as it is in a place where extensibility is allowed) is just ignored. >> 3) XCAP is not designed for searching in a real sense. It is >> designed for selecting elements based on known identifiers. It is >> not intended as a general XML Database access methodology. >> >> > I see - that's quite a limitation for a generalized configuration > access protocol, isn't it? (Certainly IMSP appeared to suggest that > personal configuration data can become very large, so retrieving the > whole lot in order to search is going to be expensive, hence, as I > understand it, many of the features of ACAP.) XCAP provides a form of searching, where you know specific fields from the data you want. If I have a list of config parameters, each with a specific name, I can find the one with that name. It does not provide a fully flexible, regexp style search - no. Again, the objective was NOT to be a general purpose config protocol for any app, but to meet the needs of our existing usages and some likely future ones. Future extensions to xcap would likely increase its capabilities for selection operations. Indeed, this is one such proposed extension, still under discussion: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-xcap-multiple-00.txt this would allow you to ask for all entries with attribute "color" equal to "blue" within a parent and get back the list of all such entries. > It does seem worrying that reconnection, resync, etc - all operations > performed quite frequently by potential clients such as MUAs, and I > assume the kinds of clients SIMPLE deals with - has no solution > inherent in the standard, nor, as far as I'm able to tell, an > alternative method mentioned in the specification. Resync after reconnect is handled by the above SIP event package and diff format. You would subscribe, indicate your current version (etag) and the diff would come with the changes since then. Its possible that the server doesnt remember the version you had, in which case you'd get the full dump. > > I'm thinking particularly of, for instance, storing bookmarks in > XCAP, which would require some method to track which bookmarks had > been visited recently - in other words, every bookmark usage would > then invalidate the entire document. That's truly terrifying. I don't follow what you intend to store in the server. The bookmark URL and some kind of indication of when it was last visited? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Aug 27 11:27:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09500; Fri, 27 Aug 2004 11:27:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0if1-0004CK-Mf; Fri, 27 Aug 2004 11:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0iRC-0000t3-3W; Fri, 27 Aug 2004 11:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0iNS-0006qq-MH for simple@megatron.ietf.org; Fri, 27 Aug 2004 11:10:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07927 for ; Fri, 27 Aug 2004 11:10:51 -0400 (EDT) Received: from mail.mis.stn.net ([216.191.62.13] helo=fortuna.stn.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0iOc-0003l5-P0 for simple@ietf.org; Fri, 27 Aug 2004 11:12:07 -0400 Received: from nas5-ip-199.mis.stn.net ([216.191.63.199] helo=jedi) by fortuna.stn.net with esmtp (Exim 4.20) id 1C0iNN-0007YQ-5H; Fri, 27 Aug 2004 11:10:49 -0400 From: "Peter Ridler" To: Date: Fri, 27 Aug 2004 11:10:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSMR6VoMPs29C7+RcGiR7jhEy+Ijg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Subject: [Simple] ABNF Issues in draft-ietf-simple-message-sessions-08.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Hi all, I still see a lot of issues in the new draft-ietf-simple-message-sessions-08.txt for ABNF Syntax. My ABNF Compiler throws out a lot of errors still. Here is may list (going from top down)..... 1) Missing x on "mSend" and "mREPORT" rules (should be) mSEND = %x53.45.4e.44 ; SEND in caps mREPORT = %x52.45.50.4f.52.54; REPORT in caps 2) Grouping not required on "headers" rule (nit) 3) Section 5 defines the MSRP URL with ABNF but not present in Section 8 (shown here with corrections) ; "userinfo", "hostport", and "unreserved" are detailed in RFC2396 MSRP-url = msrp-scheme "://" [userinfo "@"] hostport ["/" resource] ";" transport msrp-scheme = "msrp" / "msrps" resource = 1*unreserved transport = "tcp" / ALPHANUM 4) "To-Path" and "From-Path" use "URL" should be "MSRP-url" as follows To-Path = "To-Path:" SP MSRP-url *( SP MSRP-url ) From-Path = "From-Path:" SP MSRP-url *( SP MSRP-url ) 5)"namespace", "short-status" and "text-reason" are undefined could be... namespace = "000" short-status = "200" ; OK / "400" ; Bad Request / "403" ; Forbidden / "415" ; Unsupported Media Type / "426" ; Request is only allowed over TLS / "481" ; Session Does Not Exist / "506" ; Request already bound on another connection text-reason = *(VCHAR / WSP) ; All visible charcters / SP / HTAB (defined in RFC2234 CORE) 6) Rule "DUmMy" should maybe labled "Status" ! Status = "Status:" SP namespace SP short-status [SP text-reason] 7) "alphanum" on rule "ident-char" should be "ALPHANUM" (nit) ident-char = ALPHANUM / "." / "-" / "+" / "%" / "=" 8) Double x on second range on rule "token" token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E) 9) "HT" is defined in RFC2234 CORE as "HTAB" qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII 10) "DQUOTE", "CRLF" , "HT" as "HTAB", "SP", "DIGIT" are defined in RFC2234 CORE. Should NOT redefine them. 11) "LOWALPH" not really used, "ALPHAHUM" can be defined as: (nit) ALPHAHUM = ALPHA / DIGIT 12) "Content-ID" and "Content-Description" NOT defined in RFC2045 "Content-Disposition" NOT defined in RFC2183 "mime-extension-field" should be defined as "MIME-extension-field" for RFC2045 (nit) Other-Mime-Header = id ; Content-ID defined in RFC2045 / description ; Content-Description defined in RFC2045 / disposition ; Content-Disposition defined in RFC2183 / MIME-extension-field ; defined in RFC2045 13) On rule "hname", "alpha" should in uppercase (nit) hname = ALPHA *token 14) On rule "utf8text" should use "HTAB" insead of "HT" (RFC2234 CORE) utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) 15) The definition of "data" states ZERO to INFINITY, and assuming that we have defined a MSRP message limit, then data will eat up all the bytes of information AND the CRLF of "content-stuff" as well as the "end-line" message as well. "data" must have some bounds defined for it! Here is a suggestion to make "data" more clear (and conform to ABNF RFC2234 logic rules) a) You could use "text" as defined in RFC2822 (because of MSRP->RFC2183->RFC2045->RFC2822) data = *text ; defined in RFC2822 ---- OR ------ b) You could use "ptext" as defined in RFC2045. This allows for escaped bytes using "=" (hex-octet) data = *ptext ; defined in RFC2045 ---- OR ------ c) Just define our own type (similar to text in RFC2822) data = *(%x01-09 / %x0B-0C / %x0E-7F) ; Characters excluding CR and LF --------------- I like point #b, but could live with any of them..... ---Peter _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 30 10:46:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29147; Mon, 30 Aug 2004 10:46:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nSV-0005o3-Nw; Mon, 30 Aug 2004 10:48:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nOR-0002o7-Lr; Mon, 30 Aug 2004 10:44:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1nKD-00028D-Rw for simple@megatron.ietf.org; Mon, 30 Aug 2004 10:40:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28668 for ; Mon, 30 Aug 2004 10:39:59 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1nM0-0005g5-GT for simple@ietf.org; Mon, 30 Aug 2004 10:41:52 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UEduT13625; Mon, 30 Aug 2004 17:39:57 +0300 (EET DST) X-Scanned: Mon, 30 Aug 2004 17:39:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7UEdqpD021259; Mon, 30 Aug 2004 17:39:52 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00cAn9VL; Mon, 30 Aug 2004 17:35:02 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UEZ2B23926; Mon, 30 Aug 2004 17:35:02 +0300 (EET DST) Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 17:35:01 +0300 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 17:35:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Please comment: Do we want to take on partial publication? Date: Mon, 30 Aug 2004 17:34:59 +0300 Message-ID: Thread-Topic: [Simple] Please comment: Do we want to take on partial publication? Thread-Index: AcSArrPq42ruu7J3SvOfgD2L9QqO8AN7Za2Q To: , X-OriginalArrivalTime: 30 Aug 2004 14:35:00.0769 (UTC) FILETIME=[87CF1910:01C48E9E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Hi, It seems that there are a few individuals who are strongly opposed to = accepting this as a WG item. I'm not totally sure why people are so = worried about this kind of optional-to-implement extension. If they = don't think it's useful, they can just ignore it (of course provided = that it does not introduce anything that would break other parts in the = protocol). On the other hand, I understand that this may be of interest only to the = "(low-bandwidth ;-) wireless community", and SIMPLE has plenty of = unfinished work. 3GPP wants this for Rel 6, so putting this at the end = of the queue wouldn't be that good anyway. So probably this should be progressed as a non-WG item toward an = Informational RFC. I also proposed this privately to the chairs, some = 3GPP people etc. Would those people who are objecting taking this to = SIMPLE be concerned if this was the way forward with this draft? At = least the authors don't seem to have a problem with that. Regards, Markus =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Robert Sparks > Sent: 12 August, 2004 23:06 > To: simple@ietf.org > Subject: [Simple] Please comment: Do we want to take on partial > publication? >=20 >=20 > Folks - >=20 > If you haven't already read it, please take a moment and > skim > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > ial-publish-01.txt >=20 > We've had _very_ light list discussion on this draft. We talked > about it briefly at the interim in Boston, but it wasn't clear > that there was sufficient interest even in that room. >=20 > The primary question in that meeting was whether or not we > could meet the requirements this draft intends without doing > any additional standardization work (by having endpoints that > want to publish pieces act as one publisher per piece). >=20 > So speak up. Do you think this is a place SIMPLE needs to take > on more work? Who thinks we have a good enough solution for this > already? Who, in addition to the authors of this draft, is willing > to spend time working on this problem? >=20 > Thanks, >=20 > RjS >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 30 11:49:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03400; Mon, 30 Aug 2004 11:49:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1oRH-00078C-2K; Mon, 30 Aug 2004 11:51:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1oNb-0006eM-8H; Mon, 30 Aug 2004 11:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1oDd-00053W-1l for simple@megatron.ietf.org; Mon, 30 Aug 2004 11:37:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02469 for ; Mon, 30 Aug 2004 11:37:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1oFP-0006rk-B4 for simple@ietf.org; Mon, 30 Aug 2004 11:39:08 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UFbDT26307 for ; Mon, 30 Aug 2004 18:37:13 +0300 (EET DST) X-Scanned: Mon, 30 Aug 2004 18:37:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7UFb3nm019644 for ; Mon, 30 Aug 2004 18:37:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0025jmBy; Mon, 30 Aug 2004 18:37:03 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UFb2Y25381 for ; Mon, 30 Aug 2004 18:37:02 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 18:37:01 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 18:37:01 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 18:37:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Mon, 30 Aug 2004 18:37:00 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B517@esebe056.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSLnu6q5lMPHfU5QnK2n8BL3QchEwAFj21wALu97YA= To: X-OriginalArrivalTime: 30 Aug 2004 15:37:01.0319 (UTC) FILETIME=[316DF970:01C48EA7] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable The chairs have deliberated on this issue. Here is what we concluded: - We let MSRP base go as it is now, making sure that it says if an = endpoint receives an unknown header, it ignores it (just in case we = decide to go with the header approach). - Rohan will write up a separate internet draft describing the header = approach with its security considerations. - Robert will kick off an internet draft describing the body approach = (be it CPIM or something else) and its security considerations. The result is that MSRP base is not delayed and we get more time to get = this right. In the mean time, we encourage the discussion to continue. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 30 13:22:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10463; Mon, 30 Aug 2004 13:22:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1ptD-0000fk-5j; Mon, 30 Aug 2004 13:24:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1piM-0001x0-3Z; Mon, 30 Aug 2004 13:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1pf1-0000wA-4H for simple@megatron.ietf.org; Mon, 30 Aug 2004 13:09:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09315 for ; Mon, 30 Aug 2004 13:09:35 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1pgl-0000MJ-Ss for simple@ietf.org; Mon, 30 Aug 2004 13:11:31 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UH9MS02323; Mon, 30 Aug 2004 20:09:22 +0300 (EET DST) X-Scanned: Mon, 30 Aug 2004 20:09:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7UH9CFu002751; Mon, 30 Aug 2004 20:09:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00fJqubZ; Mon, 30 Aug 2004 20:09:11 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UH92Y25893; Mon, 30 Aug 2004 20:09:02 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 20:09:01 +0300 Received: from agni.research.nokia.com (hed041-225.research.nokia.com [172.21.41.225]) by kusti.research.nokia.com (Postfix) with ESMTP id 93C1993B6A; Mon, 30 Aug 2004 20:09:01 +0300 (EEST) Received: from agni.research.nokia.com (news.netsonic.fi [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i7UGMrUw004542; Mon, 30 Aug 2004 19:22:54 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i7TJLsj2013952; Sun, 29 Aug 2004 22:21:54 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Ben Campbell Subject: Re: [Simple] MSRP when used with SIP/SDP inconsistent with RFC2327 ABNF X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Ben Campbell's message of "Wed, 25 Aug 2004 12:38:52 -0500") References: Date: Sun, 29 Aug 2004 22:21:54 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Aug 2004 17:09:01.0265 (UTC) FILETIME=[0B92E410:01C48EB4] X-Spam-Score: 0.4 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Ben Campbell writes: >> RFC 2327 syntax is outdated and it contradicts with the examples >> and actual usage (like, it does not allow RTP/AVP as a transport >> protocol for media.) I think the problem lies with >> message-session-07 reference [2], [2] should refer to >> draft-ietf-mmusic-sdp-new-XX. >Hmm. I'm not sure how to handle this one; a normative reference >to a non-rfc will likely delay publication for some time, but we >do need to reference the right thing. Can the chairs offer a >comment? I'm afraid RFC 2327 is so hopelessly self-contradictory and outdated that we *must* use sdp-new. The sdp-new has been in WGLC last July. I think it is much much less controversial than msrp, so there are actually good chances that it is out of IESG before msrp. >> Please see . >I assume you mean draft-ietf-simple-msrp-relays-01.txt. Thanks. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Aug 30 17:14:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03266; Mon, 30 Aug 2004 17:14:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1tVw-0008FD-Ox; Mon, 30 Aug 2004 17:16:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1tDG-0003su-Hc; Mon, 30 Aug 2004 16:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1scy-00044r-FR for simple@megatron.ietf.org; Mon, 30 Aug 2004 16:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24213 for ; Mon, 30 Aug 2004 16:19:41 -0400 (EDT) Received: from mail.mis.stn.net ([216.191.62.13] helo=fortuna.stn.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1sem-00058t-Nt for simple@ietf.org; Mon, 30 Aug 2004 16:21:38 -0400 Received: from nas5-ip-108.mis.stn.net ([216.191.63.108] helo=jedi) by fortuna.stn.net with esmtp (Exim 4.20) id 1C1sct-00089B-Ar; Mon, 30 Aug 2004 16:19:39 -0400 From: "Peter Ridler" To: "Ben Campbell" Subject: RE: [Simple] MSRP when used with SIP/SDP inconsistent with RFC2327ABNF Date: Mon, 30 Aug 2004 16:19:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSOtYaAPHuY/qbiSe6QnBBwVQ7NaQAGEg7A In-Reply-To: Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Ben, I have looked at the draft-ietf-mmusic-sdp-new-XX and agree with Pekka. The sdp-new is the way we should go and we would not have a problem with the "accept-types" attribute and the MSRP draft can stay as is on this matter. --Peter -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Pekka Pessi Sent: Sunday, August 29, 2004 3:22 PM To: Ben Campbell Cc: simple@ietf.org Subject: Re: [Simple] MSRP when used with SIP/SDP inconsistent with RFC2327ABNF Ben Campbell writes: >> RFC 2327 syntax is outdated and it contradicts with the examples and >> actual usage (like, it does not allow RTP/AVP as a transport protocol >> for media.) I think the problem lies with >> message-session-07 reference [2], [2] should refer to >> draft-ietf-mmusic-sdp-new-XX. >Hmm. I'm not sure how to handle this one; a normative reference to a >non-rfc will likely delay publication for some time, but we do need to >reference the right thing. Can the chairs offer a comment? I'm afraid RFC 2327 is so hopelessly self-contradictory and outdated that we *must* use sdp-new. The sdp-new has been in WGLC last July. I think it is much much less controversial than msrp, so there are actually good chances that it is out of IESG before msrp. >> Please see . >I assume you mean draft-ietf-simple-msrp-relays-01.txt. Thanks. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 31 04:40:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29218; Tue, 31 Aug 2004 04:40:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C24EA-0005mc-Og; Tue, 31 Aug 2004 04:42:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C24Ao-0002kI-3i; Tue, 31 Aug 2004 04:39:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C248o-0002J8-3b for simple@megatron.ietf.org; Tue, 31 Aug 2004 04:37:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29026 for ; Tue, 31 Aug 2004 04:37:20 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C24Ak-0005i6-6k for simple@ietf.org; Tue, 31 Aug 2004 04:39:23 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i7V8anFW150604 for ; Tue, 31 Aug 2004 08:36:49 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7V8ajfe109630 for ; Tue, 31 Aug 2004 10:36:49 +0200 In-Reply-To: To: simple@ietf.org MIME-Version: 1.0 Subject: RE: [Simple] Please comment: Do we want to take on partial publication? X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Avshalom Houri Date: Tue, 31 Aug 2004 11:24:54 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 31/08/2004 11:36:48, Serialize complete at 31/08/2004 11:36:48 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0693972989==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 This is a multipart message in MIME format. --===============0693972989== Content-Type: multipart/alternative; boundary="=_alternative 002E3A31C2256F01_=" This is a multipart message in MIME format. --=_alternative 002E3A31C2256F01_= Content-Type: text/plain; charset="US-ASCII" Think that we should adopt this as working group item. It is not important only for low bandwidth networks. It is also important for very big deployments given the very big size that a presence document may turn into. Avshalom IBM simple-bounces@ietf.org wrote on 30/08/2004 05:34:59 PM: > Hi, > > It seems that there are a few individuals who are strongly opposed > to accepting this as a WG item. I'm not totally sure why people are > so worried about this kind of optional-to-implement extension. If > they don't think it's useful, they can just ignore it (of course > provided that it does not introduce anything that would break other > parts in the protocol). > > On the other hand, I understand that this may be of interest only to > the "(low-bandwidth ;-) wireless community", and SIMPLE has plenty > of unfinished work. 3GPP wants this for Rel 6, so putting this at > the end of the queue wouldn't be that good anyway. > > So probably this should be progressed as a non-WG item toward an > Informational RFC. I also proposed this privately to the chairs, > some 3GPP people etc. Would those people who are objecting taking > this to SIMPLE be concerned if this was the way forward with this > draft? At least the authors don't seem to have a problem with that. > > Regards, > Markus > > > -----Original Message----- > > From: simple-bounces@ietf.org > > [mailto:simple-bounces@ietf.org]On Behalf > > Of ext Robert Sparks > > Sent: 12 August, 2004 23:06 > > To: simple@ietf.org > > Subject: [Simple] Please comment: Do we want to take on partial > > publication? > > > > > > Folks - > > > > If you haven't already read it, please take a moment and > > skim > > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > > ial-publish-01.txt > > > > We've had _very_ light list discussion on this draft. We talked > > about it briefly at the interim in Boston, but it wasn't clear > > that there was sufficient interest even in that room. > > > > The primary question in that meeting was whether or not we > > could meet the requirements this draft intends without doing > > any additional standardization work (by having endpoints that > > want to publish pieces act as one publisher per piece). > > > > So speak up. Do you think this is a place SIMPLE needs to take > > on more work? Who thinks we have a good enough solution for this > > already? Who, in addition to the authors of this draft, is willing > > to spend time working on this problem? > > > > Thanks, > > > > RjS > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=_alternative 002E3A31C2256F01_= Content-Type: text/html; charset="US-ASCII"
Think that we should adopt this as working group item.
It is not important only for low bandwidth networks. It is also important for very big deployments given the
very big size that a presence document may turn into.

Avshalom
IBM

simple-bounces@ietf.org wrote on 30/08/2004 05:34:59 PM:

> Hi,
>
> It seems that there are a few individuals who are strongly opposed
> to accepting this as a WG item. I'm not totally sure why people are
> so worried about this kind of optional-to-implement extension. If
> they don't think it's useful, they can just ignore it (of course
> provided that it does not introduce anything that would break other
> parts in the protocol).
>
> On the other hand, I understand that this may be of interest only to
> the "(low-bandwidth ;-) wireless community", and SIMPLE has plenty
> of unfinished work. 3GPP wants this for Rel 6, so putting this at
> the end of the queue wouldn't be that good anyway.
>
> So probably this should be progressed as a non-WG item toward an
> Informational RFC. I also proposed this privately to the chairs,
> some 3GPP people etc. Would those people who are objecting taking
> this to SIMPLE be concerned if this was the way forward with this
> draft? At least the authors don't seem to have a problem with that.
>
> Regards,
>    Markus  
>
> > -----Original Message-----
> > From: simple-bounces@ietf.org
> > [mailto:simple-bounces@ietf.org]On Behalf
> > Of ext Robert Sparks
> > Sent: 12 August, 2004 23:06
> > To: simple@ietf.org
> > Subject: [Simple] Please comment: Do we want to take on partial
> > publication?
> >
> >
> > Folks -
> >
> > If you haven't already read it, please take a moment and
> > skim
> > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part
> > ial-publish-01.txt
> >
> > We've had _very_ light list discussion on this draft. We talked
> > about it briefly at the interim in Boston, but it wasn't clear
> > that there was sufficient interest even in that room.
> >
> > The primary question in that meeting was whether or not we
> > could meet the requirements this draft intends without doing
> > any additional standardization work (by having endpoints that
> > want to publish pieces act as one publisher per piece).
> >
> > So speak up. Do you think this is a place SIMPLE needs to take
> > on more work? Who thinks we have a good enough solution for this
> > already? Who, in addition to the  authors of this draft, is willing
> > to spend time working on this problem?
> >
> > Thanks,
> >
> > RjS
> >
> >
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
 --=_alternative 002E3A31C2256F01_=-- --===============0693972989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0693972989==-- From simple-bounces@ietf.org Tue Aug 31 05:46:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02219; Tue, 31 Aug 2004 05:46:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C25Ft-0006xi-AJ; Tue, 31 Aug 2004 05:48:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25CY-0004Ie-GS; Tue, 31 Aug 2004 05:45:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25A9-0003hj-1z for simple@megatron.ietf.org; Tue, 31 Aug 2004 05:42:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01895 for ; Tue, 31 Aug 2004 05:42:47 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C25Bv-0006ri-IA for simple@ietf.org; Tue, 31 Aug 2004 05:44:50 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7V9gaAh010836 for ; Tue, 31 Aug 2004 11:42:36 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 11:42:36 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id R8TYABCX; Tue, 31 Aug 2004 11:42:36 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 11:42:36 +0200 Message-ID: <6F936E2F8E16234BA8D88B2EE83383322651C0@esealnt912.al.sw.ericsson.se> X-Sybari-Trust: 353020ee 477d8de1 7b14333c 00000139 From: "Atle Monrad (GR/ETO)" To: simple@ietf.org Subject: RE: [Simple] Please comment: Do we want to take on partial public ation? Date: Tue, 31 Aug 2004 11:42:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 31 Aug 2004 09:42:36.0590 (UTC) FILETIME=[D91394E0:01C48F3E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0527537437==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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. --===============0527537437== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48F3E.D6388FD2" 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_01C48F3E.D6388FD2 Content-Type: text/plain; charset="iso-8859-1" Hello Partial publication has been requested by 3gpp for over 18 months, and we have just been waiting for Markus' solution to be adopted. My preference would be that SIMPLE adopt the i-d as WG-item. It has been hanging around for quite some time and should be familiar to the interested parties. If such optionality it is not found useful for certain clients, just leave it out... regards Atle Monrad Ericsson Mobile Platform (EMP) -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf Of Avshalom Houri Sent: Tuesday, August 31, 2004 10:25 AM To: simple@ietf.org Subject: RE: [Simple] Please comment: Do we want to take on partial publication? Think that we should adopt this as working group item. It is not important only for low bandwidth networks. It is also important for very big deployments given the very big size that a presence document may turn into. Avshalom IBM simple-bounces@ietf.org wrote on 30/08/2004 05:34:59 PM: > Hi, > > It seems that there are a few individuals who are strongly opposed > to accepting this as a WG item. I'm not totally sure why people are > so worried about this kind of optional-to-implement extension. If > they don't think it's useful, they can just ignore it (of course > provided that it does not introduce anything that would break other > parts in the protocol). > > On the other hand, I understand that this may be of interest only to > the "(low-bandwidth ;-) wireless community", and SIMPLE has plenty > of unfinished work. 3GPP wants this for Rel 6, so putting this at > the end of the queue wouldn't be that good anyway. > > So probably this should be progressed as a non-WG item toward an > Informational RFC. I also proposed this privately to the chairs, > some 3GPP people etc. Would those people who are objecting taking > this to SIMPLE be concerned if this was the way forward with this > draft? At least the authors don't seem to have a problem with that. > > Regards, > Markus > > > -----Original Message----- > > From: simple-bounces@ietf.org > > [mailto:simple-bounces@ietf.org]On Behalf > > Of ext Robert Sparks > > Sent: 12 August, 2004 23:06 > > To: simple@ietf.org > > Subject: [Simple] Please comment: Do we want to take on partial > > publication? > > > > > > Folks - > > > > If you haven't already read it, please take a moment and > > skim > > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > > ial-publish-01.txt > > > > We've had _very_ light list discussion on this draft. We talked > > about it briefly at the interim in Boston, but it wasn't clear > > that there was sufficient interest even in that room. > > > > The primary question in that meeting was whether or not we > > could meet the requirements this draft intends without doing > > any additional standardization work (by having endpoints that > > want to publish pieces act as one publisher per piece). > > > > So speak up. Do you think this is a place SIMPLE needs to take > > on more work? Who thinks we have a good enough solution for this > > already? Who, in addition to the authors of this draft, is willing > > to spend time working on this problem? > > > > Thanks, > > > > RjS > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C48F3E.D6388FD2 Content-Type: text/html; charset="iso-8859-1"

Hello

Partial publication has been requested by 3gpp for over 18 months, and we have just been waiting for Markus' solution to be adopted.

My preference would be that SIMPLE adopt the i-d as WG-item. It has been hanging around for quite some time and should be familiar to the interested parties. If such optionality it is not found useful for certain clients, just leave it out...

regards

Atle Monrad
Ericsson Mobile Platform (EMP)

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf Of Avshalom Houri
Sent: Tuesday, August 31, 2004 10:25 AM
To: simple@ietf.org
Subject: RE: [Simple] Please comment: Do we want to take on partial publication?


Think that we should adopt this as working group item.
It is not important only for low bandwidth networks. It is also important for very big deployments given the
very big size that a presence document may turn into.

Avshalom
IBM

simple-bounces@ietf.org wrote on 30/08/2004 05:34:59 PM:

> Hi,
>
> It seems that there are a few individuals who are strongly opposed
> to accepting this as a WG item. I'm not totally sure why people are
> so worried about this kind of optional-to-implement extension. If
> they don't think it's useful, they can just ignore it (of course
> provided that it does not introduce anything that would break other
> parts in the protocol).
>
> On the other hand, I understand that this may be of interest only to
> the "(low-bandwidth ;-) wireless community", and SIMPLE has plenty
> of unfinished work. 3GPP wants this for Rel 6, so putting this at
> the end of the queue wouldn't be that good anyway.
>
> So probably this should be progressed as a non-WG item toward an
> Informational RFC. I also proposed this privately to the chairs,
> some 3GPP people etc. Would those people who are objecting taking
> this to SIMPLE be concerned if this was the way forward with this
> draft? At least the authors don't seem to have a problem with that.
>
> Regards,
>    Markus  
>
> > -----Original Message-----
> > From: simple-bounces@ietf.org
> > [mailto:simple-bounces@ietf.org]On Behalf
> > Of ext Robert Sparks
> > Sent: 12 August, 2004 23:06
> > To: simple@ietf.org
> > Subject: [Simple] Please comment: Do we want to take on partial
> > publication?
> >
> >
> > Folks -
> >
> > If you haven't already read it, please take a moment and
> > skim
> > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part
> > ial-publish-01.txt
> >
> > We've had _very_ light list discussion on this draft. We talked
> > about it briefly at the interim in Boston, but it wasn't clear
> > that there was sufficient interest even in that room.
> >
> > The primary question in that meeting was whether or not we
> > could meet the requirements this draft intends without doing
> > any additional standardization work (by having endpoints that
> > want to publish pieces act as one publisher per piece).
> >
> > So speak up. Do you think this is a place SIMPLE needs to take
> > on more work? Who thinks we have a good enough solution for this
> > already? Who, in addition to the  authors of this draft, is willing
> > to spend time working on this problem?
> >
> > Thanks,
> >
> > RjS
> >
> >
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
------_=_NextPart_001_01C48F3E.D6388FD2-- --===============0527537437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0527537437==-- From simple-bounces@ietf.org Tue Aug 31 07:50:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09739; Tue, 31 Aug 2004 07:50:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C27BH-000110-QG; Tue, 31 Aug 2004 07:52:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2779-0007Ny-6l; Tue, 31 Aug 2004 07:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C275v-00078f-Vq for simple@megatron.ietf.org; Tue, 31 Aug 2004 07:46:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09583 for ; Tue, 31 Aug 2004 07:46:35 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C277u-0000x3-5R for simple@ietf.org; Tue, 31 Aug 2004 07:48:38 -0400 Received: from dynamicsoft.com ([63.113.46.99]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i7VBkFeE024783; Tue, 31 Aug 2004 07:46:15 -0400 (EDT) Message-ID: <413464F0.9030207@dynamicsoft.com> Date: Tue, 31 Aug 2004 07:45:52 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Atle Monrad (GR/ETO)" Subject: Re: [Simple] Please comment: Do we want to take on partial public ation? References: <6F936E2F8E16234BA8D88B2EE83383322651C0@esealnt912.al.sw.ericsson.se> In-Reply-To: <6F936E2F8E16234BA8D88B2EE83383322651C0@esealnt912.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit My take on this is that I find the specification of limited utility, but certainly not harmful, and thus would not object to proceeding with it. The reason I think its of limited utility is that we don't yet know whether or not it is really going to reduce bandwidth; this depends on the evolving usage of presence documents in deployment. If most folks end up using documents with a single tuple and lots of data within that tuple, the mechanism will not be useful. We don't know that yet; as such, its a solution to an anticipated problem rather than a real one. In as much as it is a proper solution to this potential problem, I think it is OK. It has clear benefits over having the PUA publish and refresh each tuple independently, though the exact scope of those benefits again depends on what presence documents end up looking like. So, I am OK with adopting and proceeding. -Jonathan R. Atle Monrad (GR/ETO) wrote: > Hello > > Partial publication has been requested by 3gpp for over 18 months, and > we have just been waiting for Markus' solution to be adopted. > > My preference would be that SIMPLE adopt the i-d as WG-item. It has been > hanging around for quite some time and should be familiar to the > interested parties. If such optionality it is not found useful > for certain clients, just leave it out... > > regards > > Atle Monrad > Ericsson Mobile Platform (EMP) > > -----Original Message----- > *From:* simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]*On > Behalf Of *Avshalom Houri > *Sent:* Tuesday, August 31, 2004 10:25 AM > *To:* simple@ietf.org > *Subject:* RE: [Simple] Please comment: Do we want to take on > partial publication? > > > Think that we should adopt this as working group item. > It is not important only for low bandwidth networks. It is also > important for very big deployments given the > very big size that a presence document may turn into. > > Avshalom > IBM > > simple-bounces@ietf.org wrote on 30/08/2004 05:34:59 PM: > > > Hi, > > > > It seems that there are a few individuals who are strongly opposed > > to accepting this as a WG item. I'm not totally sure why people are > > so worried about this kind of optional-to-implement extension. If > > they don't think it's useful, they can just ignore it (of course > > provided that it does not introduce anything that would break other > > parts in the protocol). > > > > On the other hand, I understand that this may be of interest only to > > the "(low-bandwidth ;-) wireless community", and SIMPLE has plenty > > of unfinished work. 3GPP wants this for Rel 6, so putting this at > > the end of the queue wouldn't be that good anyway. > > > > So probably this should be progressed as a non-WG item toward an > > Informational RFC. I also proposed this privately to the chairs, > > some 3GPP people etc. Would those people who are objecting taking > > this to SIMPLE be concerned if this was the way forward with this > > draft? At least the authors don't seem to have a problem with that. > > > > Regards, > > Markus > > > > > -----Original Message----- > > > From: simple-bounces@ietf.org > > > [mailto:simple-bounces@ietf.org]On Behalf > > > Of ext Robert Sparks > > > Sent: 12 August, 2004 23:06 > > > To: simple@ietf.org > > > Subject: [Simple] Please comment: Do we want to take on partial > > > publication? > > > > > > > > > Folks - > > > > > > If you haven't already read it, please take a moment and > > > skim > > > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > > > ial-publish-01.txt > > > > > > We've had _very_ light list discussion on this draft. We talked > > > about it briefly at the interim in Boston, but it wasn't clear > > > that there was sufficient interest even in that room. > > > > > > The primary question in that meeting was whether or not we > > > could meet the requirements this draft intends without doing > > > any additional standardization work (by having endpoints that > > > want to publish pieces act as one publisher per piece). > > > > > > So speak up. Do you think this is a place SIMPLE needs to take > > > on more work? Who thinks we have a good enough solution for this > > > already? Who, in addition to the authors of this draft, is willing > > > to spend time working on this problem? > > > > > > Thanks, > > > > > > RjS > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 31 11:13:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24303; Tue, 31 Aug 2004 11:13:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2AMV-0005bs-7r; Tue, 31 Aug 2004 11:15:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AHd-0001Mz-OC; Tue, 31 Aug 2004 11:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2A9w-0008SC-0Z for simple@megatron.ietf.org; Tue, 31 Aug 2004 11:02:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23615 for ; Tue, 31 Aug 2004 11:02:53 -0400 (EDT) Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ABs-0005Nh-87 for simple@ietf.org; Tue, 31 Aug 2004 11:04:59 -0400 Received: from mm-ismta3.bizmailsrvcs.net ([192.168.133.28]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040831150220.JDXB10836.oe-im1.bizmailsrvcs.net@mm-ismta3.bizmailsrvcs.net> for ; Tue, 31 Aug 2004 10:02:20 -0500 Received: from THANOSDIACAKIS3 ([12.25.200.5]) by mm-ismta3.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040831150220.PQBX1729.mm-ismta3.bizmailsrvcs.net@THANOSDIACAKIS3> for ; Tue, 31 Aug 2004 10:02:20 -0500 From: "Thanos Diacakis" To: Subject: RE: [Simple] Please comment: Do we want to take on partial publication? Date: Tue, 31 Aug 2004 09:02:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSPUMR+ISRec5WbQiuuq0D/Nz3nTgAGiPXw In-Reply-To: <413464F0.9030207@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20040831150220.PQBX1729.mm-ismta3.bizmailsrvcs.net@THANOSDIACAKIS3> X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: 7bit I would also very much support proceeding with this. In addition to being required by 3GPP, it seems it is also required by OMA, if you looking the latest publically available version of their Presence Requirements document (http://member.openmobilealliance.org/ftp/public_documents/req/Permanent_doc uments/OMA-RD_Presence-V1_0_0-20040622-D.zip) Section 6.1.3.1, Item 4. As such, it would be best if IETF undertook this work, rather than having multiple other fora undertake the same effort. Thanos --- Thanos Diacakis Openwave Systems, Inc. +1-303 385 6705 > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: Tuesday, August 31, 2004 5:46 AM > To: Atle Monrad (GR/ETO) > Cc: simple@ietf.org > Subject: Re: [Simple] Please comment: Do we want to take on > partial publication? > > My take on this is that I find the specification of limited > utility, but certainly not harmful, and thus would not object > to proceeding with it. > > The reason I think its of limited utility is that we don't > yet know whether or not it is really going to reduce > bandwidth; this depends on the evolving usage of presence > documents in deployment. If most folks end up using documents > with a single tuple and lots of data within that tuple, the > mechanism will not be useful. We don't know that yet; as > such, its a solution to an anticipated problem rather than a real one. > > In as much as it is a proper solution to this potential > problem, I think it is OK. It has clear benefits over having > the PUA publish and refresh each tuple independently, though > the exact scope of those benefits again depends on what > presence documents end up looking like. > > So, I am OK with adopting and proceeding. > > -Jonathan R. > > Atle Monrad (GR/ETO) wrote: > > > Hello > > > > Partial publication has been requested by 3gpp for over 18 > months, and > > we have just been waiting for Markus' solution to be adopted. > > > > My preference would be that SIMPLE adopt the i-d as WG-item. It has > > been hanging around for quite some time and should be > familiar to the > > interested parties. If such optionality it is not found useful for > > certain clients, just leave it out... > > > > regards > > > > Atle Monrad > > Ericsson Mobile Platform (EMP) > > > > -----Original Message----- > > *From:* simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]*On > > Behalf Of *Avshalom Houri > > *Sent:* Tuesday, August 31, 2004 10:25 AM > > *To:* simple@ietf.org > > *Subject:* RE: [Simple] Please comment: Do we want to take on > > partial publication? > > > > > > Think that we should adopt this as working group item. > > It is not important only for low bandwidth networks. It is also > > important for very big deployments given the > > very big size that a presence document may turn into. > > > > Avshalom > > IBM > > > > simple-bounces@ietf.org wrote on 30/08/2004 05:34:59 PM: > > > > > Hi, > > > > > > It seems that there are a few individuals who are > strongly opposed > > > to accepting this as a WG item. I'm not totally sure > why people are > > > so worried about this kind of optional-to-implement > extension. If > > > they don't think it's useful, they can just ignore > it (of course > > > provided that it does not introduce anything that > would break other > > > parts in the protocol). > > > > > > On the other hand, I understand that this may be of > interest only to > > > the "(low-bandwidth ;-) wireless community", and > SIMPLE has plenty > > > of unfinished work. 3GPP wants this for Rel 6, so > putting this at > > > the end of the queue wouldn't be that good anyway. > > > > > > So probably this should be progressed as a non-WG > item toward an > > > Informational RFC. I also proposed this privately to > the chairs, > > > some 3GPP people etc. Would those people who are > objecting taking > > > this to SIMPLE be concerned if this was the way > forward with this > > > draft? At least the authors don't seem to have a > problem with that. > > > > > > Regards, > > > Markus > > > > > > > -----Original Message----- > > > > From: simple-bounces@ietf.org > > > > [mailto:simple-bounces@ietf.org]On Behalf > > > > Of ext Robert Sparks > > > > Sent: 12 August, 2004 23:06 > > > > To: simple@ietf.org > > > > Subject: [Simple] Please comment: Do we want to > take on partial > > > > publication? > > > > > > > > > > > > Folks - > > > > > > > > If you haven't already read it, please take a moment and > > > > skim > > > > > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-part > > > > ial-publish-01.txt > > > > > > > > We've had _very_ light list discussion on this > draft. We talked > > > > about it briefly at the interim in Boston, but it > wasn't clear > > > > that there was sufficient interest even in that room. > > > > > > > > The primary question in that meeting was whether or not we > > > > could meet the requirements this draft intends > without doing > > > > any additional standardization work (by having > endpoints that > > > > want to publish pieces act as one publisher per piece). > > > > > > > > So speak up. Do you think this is a place SIMPLE > needs to take > > > > on more work? Who thinks we have a good enough > solution for this > > > > already? Who, in addition to the authors of this > draft, is willing > > > > to spend time working on this problem? > > > > > > > > Thanks, > > > > > > > > RjS > > > > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 31 13:20:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06688; Tue, 31 Aug 2004 13:20:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2CKm-00016K-RB; Tue, 31 Aug 2004 13:22:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2C0y-0002YE-Rr; Tue, 31 Aug 2004 13:01:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Bmk-0006wo-GI for simple@megatron.ietf.org; Tue, 31 Aug 2004 12:47:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03872 for ; Tue, 31 Aug 2004 12:47:04 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bok-0000A5-Ow for simple@ietf.org; Tue, 31 Aug 2004 12:49:11 -0400 Received: from peirce (unknown [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id E40BB154009; Tue, 31 Aug 2004 16:46:57 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline; xpolymertype="coverletter" From: Dave Cridland To: Jonathan Rosenberg Subject: Re: [Simple] XCAP as general configuration protocol. References: <20040812133605.10496.59603.polymer@peirce.gestalt.entity.net> <412F2D3B.5000609@dynamicsoft.com> In-Reply-To: <412F2D3B.5000609@dynamicsoft.com> Message-ID: <20040831164558.22087.7373.polymer@peirce.gestalt.entity.net> X-Mailer: Infotrope Polymer/0.0.3 Date: Tue, 31 Aug 2004 17:45:58 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 On Fri Aug 27 13:46:51 2004, Jonathan Rosenberg wrote: > Dave Cridland wrote: >> I'm a little confused by XCAP's purpose - is it aimed at providing >> a >> configuration protocol specifically for the needs of SIMPLE's >> protocol suite, or is it aimed at providing generalized >> configuration >> access? >> 1) How do vendor-specific extensions work? (Say, if an addressbook >> or >> bookmark collection were stored in XCAP, how would an application >> add its own data to it?) Is this handled purely by namespaces, or >> does that interfere with the Schemas defined? > > Each of the schemas in an application usage defines points where > extensions can add additional information. That additional > information > would come from a different namespace. > > Predefined points? How does the designer know where extension might be required? >> 2) Given the degree of validation effort possible to request from >> the >> server, is it within the specification to have an AUID that >> doesn't >> do any validation? > > Yes. Indeed, extensions to existing application usages, which are > not > understood by the server, will have no validation beyond XML well > formedness. > > Understood, I missed this in my original reading. > > (Obviously it'd have to do XML-well-formedness.) I'm >> quite concerned that XCAP appears to be a substantial resource-hog >> - >> performing referential integrity checks on XML can't be the >> fastest >> thing in the world > > XCAP servers don't do referential integrity checks. This is > explicitly > called out somewhere. > > *nods* Found that now. I partly missed it because it's ruled out in a sentence running over a page break. >> 3) As I understand it, the only method of searching is via the >> reduced XPath used in the URI. Is there any reason why a >> redefinition >> of a reduced XPath has been used rather than simply using XPath >> in the URI? (I can't see anyone choosing to handle these URIs in >> any way >> other than using an XPath library). > > There was a LOOONG debate on this. XPath does a lot of stuff we > really > don't need or want, as it would introduce a lot of complexity into > the > server and client for no net benefit. Thus, our approach was to use > a > strict subset. > > There does seem to be relatively high complexity already, yes. >> 4) Given that, in general, applications will wish to use a >> substanital block of configuration data, and maintain it as >> current as reasonably possible, how does an application obtain a >> list of changes since a certain time (or ETag)? The only method I >> can see is >> by polling the entire block, which, if changed, will produce a >> substantial amount of output. > > The following spec defines a format for differences in documents: > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-02.txt > > These documents would get delivered in notifications, using a SIP > event > package: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-04.txt > > Ah... So XCAP requires SIP to be of any real use? > TO be clear, it is NOT the objective of XCAP to be a feature for > feature > equivalent replacement to ACAP. The group looked at acap as the > basis of > its work: > http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.txt > > but decided not to use acap. > > As such, XCAP is "inspired" by ACAP, but not designed to be a > replacement. I suspect it meets many of the needs of any existing > ACAP > users (though I admit I didnt know there were any!), but I am sure > it > doesnt meet them all. In particular, we purposefully rejected > features > like inheritance and built in ACL support, which are present in > ACAP, > but were not needed for our applications. > > In that case I misread the last paragraph of the introduction. And yes, there are some production deployed ACAP servers out there. Not many, but some. For my purposes, which include both email client support and datastore for some web applications, it's proven extremely effective - much, much faster than the traditional solutions of SQL databases, etc. >> I'm thinking particularly of, for instance, storing bookmarks in >> XCAP, which would require some method to track which bookmarks had >> been visited recently - in other words, every bookmark usage would >> then invalidate the entire document. That's truly terrifying. > > I don't follow what you intend to store in the server. The bookmark > URL and some kind of indication of when it was last visited? Yes, exactly that. (And more, of course.) It's a useful feature which allows the notion of bookmarks and history to merge, somewhat. Having read through your comments a little more, I think I understand where XCAP fits in a little better. As I understand things, a typical XCAP client would: 1) Bootstrap its initial configuration with a GET request for the area that interested it from XCAP. (I'm unclear how it might find the XCAP server, but finding your configuration server is always fun.) 2) Possibly using this information, acquire SIP. 3) Write any changes using XCAP PUT and DELETE. Since PUT invalidates the cache, ignore any result other than success or failure for PUT. 4) Listen constantly for updates via SIP. 5) On reconnect, use acquire SIP using cached data, and then use SIP to resynchronize. Is it not possible to handle the writes via SIP, which appears to be required anyway? And if so, couldn't nearly all the complexity of XCAP be dropped out to provide a very simple configuration bootstrap protocol? What am I missing here? Dave. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 31 14:13:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11347; Tue, 31 Aug 2004 14:13:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2DAe-0002VF-Us; Tue, 31 Aug 2004 14:15:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2D72-0000pw-CM; Tue, 31 Aug 2004 14:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2CwE-0007Hv-Tg for simple@megatron.ietf.org; Tue, 31 Aug 2004 14:00:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10562 for ; Tue, 31 Aug 2004 14:00:58 -0400 (EDT) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Cy5-0002DT-FF for simple@ietf.org; Tue, 31 Aug 2004 14:03:04 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7489685; Tue, 31 Aug 2004 13:59:56 -0400 Message-Id: <5.1.0.14.0.20040831135756.02efa270@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Aug 2004 13:59:42 -0400 To: Dave Cridland From: "Joel M. Halpern" Subject: Re: [Simple] XCAP as general configuration protocol. In-Reply-To: <20040831164558.22087.7373.polymer@peirce.gestalt.entity.ne t> References: <412F2D3B.5000609@dynamicsoft.com> <20040812133605.10496.59603.polymer@peirce.gestalt.entity.net> <412F2D3B.5000609@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a If you consider getting change notifications mandatory, I suppose you could take that view. There are other cases where SIP is not being used, and change notification is not necessary, that can make use of XCAP. Yours, Joel At 05:45 PM 8/31/2004 +0100, Dave Cridland wrote: >>>4) Given that, in general, applications will wish to use a substanital >>>block of configuration data, and maintain it as current as reasonably >>>possible, how does an application obtain a list of changes since a >>>certain time (or ETag)? The only method I can see is >>> by polling the entire block, which, if changed, will produce a >>> substantial amount of output. >>The following spec defines a format for differences in documents: >>http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-02.txt >>These documents would get delivered in notifications, using a SIP event >>package: >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-04.txt >Ah... So XCAP requires SIP to be of any real use? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 31 19:46:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13406; Tue, 31 Aug 2004 19:46:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2INC-0002o5-3q; Tue, 31 Aug 2004 19:49:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2IEE-0005hS-B7; Tue, 31 Aug 2004 19:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2IC7-0005KC-5M for simple@megatron.ietf.org; Tue, 31 Aug 2004 19:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12565 for ; Tue, 31 Aug 2004 19:37:40 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2IEA-0002Zy-Ol for simple@ietf.org; Tue, 31 Aug 2004 19:39:52 -0400 Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i7VNbXPq042155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 18:37:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <41350C0D.4020305@nostrum.com> Date: Tue, 31 Aug 2004 18:38:53 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] MSRP: Contributor ID References: <5816828233DEFA41807A6CFDFDF2343C08B517@esebe056.ntc.nokia.com> In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C08B517@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: >- Rohan will write up a separate internet draft describing the header approach with its security considerations. > >- Robert will kick off an internet draft describing the body approach (be it CPIM or something else) and its security considerations. > Just to be clear: Section 4.1.1 of RFC 2779 absolutely, unambiguously, and without recourse for appeal binds SIMPLE to support CPIM in MSRP. Section 4.1.2 similarly requires us to be able to identify the sender. These mechansims, simply put, must be in MRSP, or it dies in IESG review. Full stop. So, I want to clear up any misunderstanding that this might be an either-or decision -- an impression Hisham's note may have given some particpants. The support of CPIM _will_ be part of MSRP, it _will_ contain mechanisms for identifying the sender, and there's not a thing any member of this working group can do about it. At this point, we're just debating whether there will be a redundant mechanism for doing the same thing. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple