From simple-admin@mailman.dynamicsoft.com Tue Jan 1 05:00:45 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09020 for ; Tue, 1 Jan 2002 05:00:45 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g019wU3a002691 for ; Tue, 1 Jan 2002 04:58:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04641 for ; Tue, 1 Jan 2002 05:00:42 -0500 (EST) Date: Tue, 1 Jan 2002 05:00:42 -0500 (EST) Message-Id: <200201011000.FAA04641@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk This is a reminder, sent out once a month, about your mailman.dynamicsoft.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Wed Jan 9 11:15:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06427 for ; Wed, 9 Jan 2002 11:15:38 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g09GBsvw017821; Wed, 9 Jan 2002 11:11:54 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10192; Wed, 9 Jan 2002 11:14:04 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10181 for ; Wed, 9 Jan 2002 11:13:40 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g09GBMvw017811 for ; Wed, 9 Jan 2002 11:11:22 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Jan 2002 11:13:06 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E932@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Draft minutes SIMPLE meeting IETF52 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 11:13:04 -0500 Here is a draft of the simple minutes for IETF52. Please review and submit corrections before Friday 1/11. RjS ------------- SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions Minutes - 12/12/2001 1300-1500 MDT - IETF52 Chairs: Jon Peterson - jon.peterson@neustar.com Robert Sparks - rsparks@dynamicsoft.com Summary: Charter and logistics * An update to the SIMPLE charter has been submitted reflecting the SIP/SIPPING split, the proposed SIP change process, and the watcherinfo/CPIM mapping deliverables. Publication has been tabled pending outcome of disussions in SIPPING (see the SIPPING minutes) * MESSAGE has been handed off to SIP - currently scheduled for last call in May. Brian Rosen will work with us to move that call to an earlier date draft-ietf-simple-presence: * The presence draft will be modified to rely directly on sip-events, which will in turn rely on sip-bis instead of 2543. The result will be shorter documents with less opportunity for unintentional contradiction. * We will provide Alerts (notification with indirect content). Primary remaining issue: Lifetime of URI in an Alert. Both the sip-events and presence drafts will have to change to reflect this. * There is consensus to establish a presence subscription dialog based on the first arriving NOTIFY or 2xx response to the SUBSCRIBE * There is consensus to leave the current forking text as is. Subscribers SHOULD accept only one NOTIFY. If merging is required, the burden lies on the subscriber. draft-ietf-simple-winfo-package: draft-ietf-simple-winfo-format: * Proposed recent format changes accepted with the additional removal of most-recently-subscribed * Sip-events and the format draft will reconcile the descriptions of reasons for terminating subscriptions draft-mankin-im-session-guide: * Hum against taking this on as a SIMPLE work item Opinion was that work on the draft should continue in the transport area * SIMPLE group urged to internalize its guidelines * Applicability of the requirements being placed on OPES wrt intermediary discovery and disclosure needs to be discussed draft-rosenberg-simple-im-transport: * Weakly expressed support. Moderately strong hum against proceeding with this proposal. - concerns over keeping IMTP and SIP syncronized * Alternate proposal solicited - if none appears before early January, work will proceed with IMTP * Split opinions on whether a proposal must be held to mankin-im-session-guide --------------------------------------------------------------------- Full Notes (thanks to Brian Stucker - bstucker@nortelnetworks.com) Charter Updates: Have submitted a new charter. * Charter resubmitted a couple of weeks ago * Now reflects SIP/SIPPING split and proposed SIP change process. * Presence 'extension' deliverable now 'event package and related protocol mechanisms' * Presence publication tabled in SIMPLE, currently considered in SIPPING. * Dec 01- Presence event package, watcherinfo, CPIM mapping. * Jan 02 - Messaging drafts Transferred deliverables * Draft-ietf-simple-im-01/draft-ietf-sip-message-00 - Status (any SIP chairs want to speak to schedule?) - SIP drafts page say May 02 - be nice if that could be moved in a bit. * Brian Rosen: Drafts dates are based on logistics problems. We can move it up if we can get the draft ready, get reviewers, list comment, etc. But we can move it up if there is a need? * Jon: Would be nice if we could have this in the first quarter? * Brian: We'll look into it. * Draft-donovan-publish-requirements-01 - An actual proposal discussed in SIPPING yesterday. - Clear that SIPPING will only do requirements for publication. * Where will it go from there? SIP WG? * The IETF would like to do the right thing, and not get too rule bound. Hope is that the same people will spend some time in SIPPING and make sure that the right approach is formed. The method document has to come out of SIP. * SIPPING needs to look at the problem of whether or not we need a new method. * Question begs, is presence publication urgently needed in SIMPLE, and that needs to be looked into. ------------------------------------ Presence Open Issues: * Open issues in presence-04 - Dependencies and duplication * Currently - Rfc-2543 <- sip events <- presence - Problem is that sip events is duplicating text from bis-05. * Can we simply make sip events dependent on bis, thereby shortening it. - Presence is duplicating text from sip events. * Proposal - Bis <- sip events <- presence * Bis is nearing completion so timing is not going to be much different * Requires cleanup of redundant text across all three documents in progress. This will be done. - Alerts * Would be nice to only be notified of change in presence, not actual presence. * Actual presence could then be fetched with HTTP * Why is this useful? - Large presence documents wouldn't get fragmented. - Large presence docs could be fetched when time is good (ie. Not in a call). * Details - SUBSCRIBE would have Accept header indicate support - Presence of application/uri-list - Still have to support application/cpim-pidf+xml - Etc * Issues with Alerts - Broader than presence. Probably belongs in sip-events * Presence would then state that its allowed. - Security issues * Just because SIP can be authenticated, doesn't mean HTTP can. - Transitive trust vs. e2e - Henning brought up concerns on this. - HTTP SIP interactions * Requires a way for SIP server to manipulate content on web server. - Henning brought up concerns on this. - Duration of URL validity * Need to specify - presumably subscription duration. * Proposal - Really useful, really simple - Add to sip-events and presence. Henning: Similar to web server problem. Jonathan: does require an interaction between HTTP and SIP; don't have to do it. Henning: Must specify something that will work well. Brian: Doesn't have to be HTTP, could use other mechanisms. Jonathan: Must develop a baseline. Call for opinions: Sean: I don't see this as a major issue, or a hard thing to do. Adam: I'm in support for this, I don't see a problem. The issues that Henning brings up are not completely trivial, but they're easy to take care of. Can be added to sip-events, but doesn't see a need. Rosenberg: Wants a general mechanism the same across all packages and to specify behaviors. Need to specify the duration that the presence URL is good for. Sean/Rohan: Don't go into such detail about the implementation. It's unimportant how long the document sticks around. Henning: We need to make sure that the semantics are complete and equivalent. Brian Stucker: Agrees that need to specify amount of time for URL to be valid, just as there is one for subscription. Interval doesn't need to be specified. Sean: There's no guarantee that the semantics are equivalent. Adam: This sounds like the argument about how to encode a piece of content versus what it means. Rosenberg: This is an automata that is processing this URL, so it needs to have an idea of how long the URL is good for. Jon: Is there any value in leaving this URL open for our application? Rohan: I don't think that's what Rosenberg is proposing. Diana: Likes the consistiency. Does this trickle to general SIP? Henning: The semantics that we are arguing about here are buyer beware problems. This is a presence document, versus this document is not going to be around after a period of time. We wouldn't specify that this is a presence document, we're specifying other attributes. Adam: I don't have a problem with the proposal, but it sounds like the semantics of the usage should be in the presence document. Jonathan: Need to specify what URL means and have well-defined semantics to work. Henning: sending a JPEG isn't particularly useful. Sean: Your implementation has to handle it - doesn't need standardization. Adam: How is content encoded Vs. what does it mean? Jonathan: Wants to define what it means when you return a URL. It's important to remember that a person isn't using this URI, an automata is. Andrew: This is like W3C semantic web problem. Jonathan: Disagree - not solving that problem Jon: What do we want the Presence URI to mean? Rohan: That's not what Jonathan is proposing. Henning: 2 issues: what are the time properties and what is the content. In events, this would not be a presence document. The semantics being argued are hints to the implementor - these are the semantic expectations. Agree that semantics need to be specified. Jonathan: Most web browsers accept *.*. This URI should be very specific and have full semantic content, unlike normal web request. Rosenberg: Presence package would say that this is a one-shot document, etc. Conclusion: Continue discussion on the list. - NOTIFY/200 Race condition * ASSUME you want to only accept one NOTIFY * Sip-events says you should accept the one that matches 2xx to SUBSCRIBE. * Proposals - Buffer NOTIFYs until 2xx, then 481 all that non-matching ones. - Accept all NOTIFYs, when 2xx arrives, refersh all non-matching. - Accept first NOTIFY * SUB 2xx is ignored - Accept first message * SUB 2xx if its first * NOTIFY it its first * Probably also an issue for sip-events, not presence. - Forking * Definitely the biggest issue. * Some problems are not presence specific - HERFP * Proposal - Keep what's in the document. If they need aggregation, then put a point in the network and leave it be. - If there are multiple PUA, you get partial presence, no guarantees. - Subscribers SHOULD accept only one NOTIFY - Burden is on the subscriber to implement merging if it wants. - Won't generally be needed based on domain requirements and frequently won't happen because HERFP. Conclusion: No time for discussion, taken to list. ---------------------------------------- Watcherinfo Open Issues - Events leading to terminated * See previous discussion - State maintenance for pending/waiting * Possible Dos? Sub is authenticated * -01 will talk about setting policy for this - Tradeoff between user experience and state storage Stucker: isn't this just a policy issue? Why does this belong in watcher info? Rosenberg: When you have watcher subs you need to keep state for things being watched. The fact that there's a watcher info on t you need a state. Want to specify a caution with regards to potential for attacks. The watcherinfo draft defines a model for presence. We shouldn't have this in sip-events. Stucker: Are you going to add when to indicate when subscription is active? Jonathan: Both have an approved. Want these to align between 2 documents - he's only showing error cases where they don't align Adam: There are 2 other states: Pending and Active. These are whys for the failures. Jonathan: Should the state machine be in sip-events. Watcher -info defines a model; you could have much more states and a more complex state machine. - Elements in data format * Watcherinfo data - Uri of watcher - Status of subscription - Event which triggered notification - Duration time in last state - First-subscribed - Most-recently subscribed - Added: expiration - Removed: Notify-address Chris: let's ditch most-recently subscribed, it's not very useful. Rosenberg: Okey-dokey. Rosenberg: The watcherinfo draft defines a model for presence. We shouldn't have this in sip-events. - Status in winfo/sip events proposal on the list. Conclusion: No Comments (thus consensus implied) --------------------------------------- Guidelines for IM Sessions: * Context: - IM payloads are moving away from short-text only, towards * Images * Video clips * Mp3 and other audio data * Etc. * Large populations of users meeting over shared infrastructure (interconnect of AOL, MSN, etc). - Sessions of Messages: * SIP message is the medium. - Transport Background * In order of concern, reliable transport of serious amounts of data raises concerns of: - Congetion collapse * Will congestion of the system invoke protocol actions that increase data sent into the system? (1986 TCP collapse) - Scope of fate-sharing * Can desired end-to-end behavior and properties be achieved and maintained through intermediaries? - Congestion avoidance and shared effects * When J users share a filled or congested path, and adapt, can they get close to each having 1/Jth of capacity? Allison Mankin: We have to be that when we do congestion control that TCP adapts it's behavior to the congestion on the link. Want to be sure that there aren't unanticipated effects from the extremely large amount of traffic. * Guidelines Draft - Purpose is to distill transport concerns, with some related architectural and security concerns. - Session model * When data of IM (or session of IM) is carried within headers seen/modified /operated-on by intermediaries * If you took the MESSAGE, without the headers, and threw it onto an end-to-end TCP connection, it wouldn't create any of these issues. If you have UDP in the middle, you can run into congestion problems. * If IM clients stop off at the various intermediaries, they get 1/N*M bandwidth (N intermediaries, M IM clients) instead of 1/M, which is a significant penalty. It's because of the TCP queuing system. Rosenberg: This could happen for a lot of reasons. Allison: We don't want congestion collapse, but there are some other interesting things going on. Rosenberg: If we use TCP then this isn't our problem. Allison: No, the answer is that if you use TCP, don't get greedy with the number of intermediaries. Christian: There is a fundamental problem here, and it's with TCP. Allison: I think we still have some value to look into the transport dynamic, and moderate the use of intermediaries. Working on another paper to fully research this. This scenario is a worst case. - Multi-Intermediary protocols * Diameter/Apex/Opes/SIP-SIMPLE - Guidelines for Sessions * Signaling MUST be able to negotiate a common underlying transport * MUST not use UDP because of congestion control issues. * Session/transport solution SHOULD support (MUST?) specifying a single transport protocol for entire session path. * MUST not use multiple parallel reliable transport connections. David Oran: Why be so harsh, what's wrong with using UDP in a congestion safe way? Jon (summary): What we're talking about is that this is the session model, not setting up the session. Allison: Yes, this is a problem with long streams of data. - Guidelines for Sessions * Does design lead to a well-formed session protocol? - Does the design carry the right data over aggregated transport, session membership, data sequencing, identification and so on? - Is it designed right for the security goals? - Draft-iab-opes-00.txt an RFC-t-be from IAB. - Model for some more architectural guidelines: * SHOULD not interpose without consent, by at least one of the parties * MUST support mechanism for discovery of intermediaries * MUST disclose (either in signaling phase or session) the intermediaries * More... need to discuss in email. Rosenberg: The intermediaries are not there to modify the content. It's just there to deal with NATs, etc. Such as in SIP. Allison: There is an area where the consent issue may be a bit gray. It's not a perfect match. Jon: I think we're trying to speak as to what the direction should be, not where intermediaries should be deployed. If the client is informed about what is going on, then it can take action. Henning: I would hesitate to draw too close a parallel on that, because there are properties in there that make the predictability issue a bit harder. There are issues with discovery and finding that we've had for some time. The other thing is that content modification (via headers, etc) doesn't necessarily match with the consent model in OPES. As long as these are transport entities that don't do much, then you can't extrapolate for OPES. Rosenberg: Why is this not such a problem for email? Allison: We're going to have to wrap up, we're running out of time. * Next? - End goal is for SIMPLE WG to internalize and feel ownership of the guidelines - Document should stay individual or be in the set of WG documents? Jon: we did make a good try at generalizing these issues. Wcom: I believe that the draft is bloated and it confuses signaling and transport, so let's get rid of it. Jon: That's unfair, we're responding to what this WG has already gotten itself into. IMPP WG chair: I don't think that this belongs in either working group. ------------------------- IMTP Proposal: * Motivations - Requirements for IM transport * Congest * Reliable * Arbitrary sizes * Framing * Per-im content typing * E2e privacy, integrity, authenticity * Works through nat * Rapid delivery * Lightweight * Parser reuse * Compressible * Support for different content types * Muxing * Logging - The hard configuration (PC in enterprise 1 going through a ent 1 proxy to internet, over to proxy in enterprise 2 to a PC in enterprise 2). * How about SIP? - Pros: * Parser reuse * Proxies as intermediaries * NAT traversal easy * Logging, framing, sequencing all done - Cons: * SIP has features that would get in the way - Record-routing - Redirection - Forking * Messages might go over UDP * Performance of Proxy as pure forwarding intermediary is poor. * Idea: Sip Subset - IMTP proper subset of SIP * Remove unneeded features - Forking, redirection, recursion, record-routing and route * Introduce restrictions - Only TCP * Change protocol field to IMTP/1.0 from SIP/2.0 - Most proxies won't route - BUT, one-liner to fix that - Want this to be explicit about what protocol is running - Proxy with proper configuration can route IMTP * No forking, no record-routing, no redirect, TCP only * Can use REGISTER to set up IMTP bindings Allison: How hard would it be to put in error checking so that if there were an inappropriate header were present it could be dealt with. Rosenberg: It is a minimal SIP request Mic: How do we specify IMTP? Where will this be done, where will discussion be held for this since it's a different transport protocol. Rosenberg: There will be a separate document for IMTP, and will go into this WG. It is burdensome to tie SIP and IMTP together, so let's not. Rosenberg: We're working on the end-to-end nature of the protocol to specify a key for the session to create an end-to-end solution. We can use that key into S/MIME so I can encrypt the content of the message path. Security: working on SDP extensions for key exchange (MIKEY) (2 pass) Could use key as input to S/MIME to encrypt e2e. Whatever solutions we develop for SIP would apply to IMTP. Andrew: What is our reaction? It's not obvious that there's not good engineering necessarily here, but this is what we need to do to get things done. Henry: What is the problem we're trying to solve? We have fast servers, we have bandwidth, so why is this a problem. Jonathan: Want a session model for SIP. Cullen: Can deal with IMTP being a profile in SIP. Can't deal with divergences between the 2. Should keep synced with SIP. Henning: As long as it's done by reference, then it's not as big of a problem. Rosenberg: It's not that clear, but it's not by reference. Dean: Either IMTP reduces to the argument against a session model or argues against using SIP how we're using it now. Believes that if SIP as we've defined it doesn't scale then it's broke, but if it's not broke, then why can't it be used as is for the session MESSAGE problem. Rosenberg: SIP has the idea of finding the user, and the delivery of the content. The session model for SIP for SIP works by finding the user, then delivering the large data by another piece. SIP is good for the discovery problem and NOT good for the delivery of large data. Dean: I would argue that if we can't do signaling for call setup, then we can't do messaging, and vice versa. If you want to use a new protocol, why not use BEEP or another protocol? Rosenberg: Nobody has come forth. Rohan: I think we should make it so that it absolutely should not go through a proxy. David Oran: if there is anything to be gained by the MESSAGE method in the IMTP versus in SIP then let's converge them. I don't think it's a big deal with IMTP being renamed. If people think profiling is a reasonable way, then look at MEGACO. Is there anything to be gained from the Message method in paging and the message method in session? People have said that it's easier. Dave Oran: Could you share a TCP connection with SIP? Jonathan: No, but you can share TCP between IMTP. Rosenberg: I am getting the feeling that it's not a good consensus. Christian: I like this proposal because it's easy to specify. Do we just have MESSAGE, nothing else, and enable us to do this? It's easy to implement, easy to undertand, etc. Henning: We have to solve this problem. Chairs consensus gathering: * Do we want to pursue this? Hum vote: - Yes? Delayed hum. - No? stronger hum. * Is the session model for messaging important? - Yes? Hum - No? small hum. Rohan: Proposes that unless you get alternative proposals within a reasonable timeframe, that we should just go with this. Jon: We'll send something out on the list, and if we don't get a response by the end of the holidays, we'll go with IMTP by default. Chairs consensus gathering: * If we are going to have a proposal for Sessions of messages, should they adhere to guidelines? - Yes? Hum - No? Equal hum _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jan 9 18:04:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19714 for ; Wed, 9 Jan 2002 18:04:39 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g09N11vw021220; Wed, 9 Jan 2002 18:01:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11433; Wed, 9 Jan 2002 18:03:15 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11419 for ; Wed, 9 Jan 2002 18:02:49 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g09N0Pvw021205 for ; Wed, 9 Jan 2002 18:00:28 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Jan 2002 18:02:10 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E93E@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19961.AAD8F45E" Subject: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 18:02:08 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C19961.AAD8F45E Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, January 08, 2002 7:46 AM Subject: I-D ACTION:draft-mrose-simple-exchange-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IM Simple Exchange (IMSX) Author(s) : M. Rose Filename : draft-mrose-simple-exchange-00.txt Pages : 27 Date : 07-Jan-02 The Common Presence and Instant Messaging profile (CPIM) is a set of syntax and semantics for instant messaging (IM) and online presence services, independent of the underlying transfer infrastructure. The Session Initiation Protocol (SIP) negotiates session information for media streams. This memo defines a BEEP profile, IMSX, for exchanging CPIM messages after SIP has performed signalling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mrose-simple-exchange-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mrose-simple-exchange-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C19961.AAD8F45E Content-Type: message/rfc822 To: Subject: Date: Wed, 9 Jan 2002 18:02:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C19961.AAD8F45E" ------_=_NextPart_002_01C19961.AAD8F45E Content-Type: text/plain ------_=_NextPart_002_01C19961.AAD8F45E Content-Type: application/octet-stream; name="ATT06680.txt" Content-Disposition: attachment; filename="ATT06680.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020107135159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mrose-simple-exchange-00.txt ------_=_NextPart_002_01C19961.AAD8F45E Content-Type: message/external-body; site="internet-drafts"; dir="draft-mrose-simple-exchange-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C19961.AAD8F45E-- ------_=_NextPart_000_01C19961.AAD8F45E-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Jan 9 19:17:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21680 for ; Wed, 9 Jan 2002 19:17:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0A0Dkvw021799; Wed, 9 Jan 2002 19:13:46 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11723; Wed, 9 Jan 2002 19:16:03 -0500 (EST) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11537 for ; Wed, 9 Jan 2002 18:24:50 -0500 (EST) Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g09NH9h08906 for ; Wed, 9 Jan 2002 15:17:09 -0800 (PST) Message-ID: <085b01c19964$be7d0c10$0301000a@FATORA> From: "Marshall T. Rose" To: References: <9BF66EBF6BEFD942915B4D4D45C051F338E93E@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 15:24:09 -0800 Content-Transfer-Encoding: 7bit > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-00.txt if you prefer the html version, go to: http://www.beepcore.org/beepcore/docs/profile-imsx.html enjoy! /mtr _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 10 12:05:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19279 for ; Thu, 10 Jan 2002 12:05:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0AH1ovw025230; Thu, 10 Jan 2002 12:01:50 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14810; Thu, 10 Jan 2002 12:04:04 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14799 for ; Thu, 10 Jan 2002 12:03:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AH39VZ012062; Thu, 10 Jan 2002 12:03:10 -0500 (EST) Message-ID: <3C3DC92C.6090902@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: jack@atosc.org CC: simple@mailman.dynamicsoft.com References: <3C3DAC3B.107B48CD@wellx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [Sip] simple-presence-04 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 12:02:36 -0500 Content-Transfer-Encoding: 7bit Aymeric MOIZARD wrote: > My question is about the tupple element in > draft-ietf-simple-presence-04.txt > (Is it the correct mailing list to use?) The simple list is the right list. I've changed the recipient line. > > The draft draft-ietf-simple-presence-04.txt shows examples > of "application/cpim-pidf+xml" body where "name" is an > attribute of "tuple". > > > > > open > > schema="http://www.ietf.org/dtd/im-type-phone.dtd">on-hook > > sip:user@example.com > > > > I found that definition in draft-ietf-impp-cpim-pidf-01.txt > where "id" is a mandatory attribute for tuple. > > > id %TUPLEID; #REQUIRED > > > The example and defintions does not match! > Did I choose wrong versions of drafts? Any other > explanations? The two docuemtns have been evolving idenpdently, and fall out of sync as they evolve. When the pidf spec is stable, we can make sure the presence doc formats are all up to date. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 10 14:58:09 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22608 for ; Thu, 10 Jan 2002 14:58:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0AJskvw026971; Thu, 10 Jan 2002 14:54:46 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15351; Thu, 10 Jan 2002 14:57:02 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15274 for ; Thu, 10 Jan 2002 14:39:34 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0AJVPF25224; Thu, 10 Jan 2002 11:31:25 -0800 (PST) From: Rohan Mahy To: "Marshall T. Rose" cc: Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt In-Reply-To: <085b01c19964$be7d0c10$0301000a@FATORA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 11:31:25 -0800 (PST) Hi Marshall, I have a few suggestions and questions on your draft. 1) In the security considerations section you use MUST strength for both DIGEST-MD5 and TLS_RSA_WITH_3DES_EDE_CBC_SHA. I think requiring TLS and 3DES is too restrictive, especially for small devices or lightweight implementations. I propose using MUST strength for authentication and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for privacy and "all". 2) Please briefly (one sentence) mention the I: and L: convention before you use it in the examples. 3a) You mention middleboxes briefly, but I wasn't sure what you are really recommending when you say it may be needed for "proxies to transparently rewrite the transport information " I assume you mean SIP proxies? This is *AN* approach, but we won't be able to get to end-to-end integrity if this is required, hence my next question... 3b) I am assuming that IMSX assumes that the two BEEP entities will communicate directly without relays. How would this work with a couple of BEEP relays involved? What address would you advertise in SDP? If this is possible, I think this is very useful for getting around the middlebox traversal problem. 4) I didn't get a good sense from your examples how to come up with unique cid: URLs (especially if the originator is behind a NAT). Do these have to be unique for all users/sessions, per BEEP session, or per beep request? 5) I think an example or call-flow showing multiplexed bidirectional messages would be really useful. 6) I'm assuming that the proposed transformation between im: and sip: URLs is to merely replace the scheme. Is this correct? thanks, -rohan On Wed, 9 Jan 2002, Marshall T. Rose wrote: > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-00.txt > > if you prefer the html version, go to: > > http://www.beepcore.org/beepcore/docs/profile-imsx.html > > enjoy! > > /mtr > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 10 19:32:32 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26690 for ; Thu, 10 Jan 2002 19:32:31 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0B0Plvw029301; Thu, 10 Jan 2002 19:25:48 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16166; Thu, 10 Jan 2002 19:28:05 -0500 (EST) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16155 for ; Thu, 10 Jan 2002 19:27:58 -0500 (EST) Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g0B0K8500929; Thu, 10 Jan 2002 16:20:08 -0800 (PST) Message-ID: <011001c19a36$ba29fd30$0301000a@FATORA> From: "Marshall T. Rose" To: "Rohan Mahy" Cc: , "Marshall Rose" References: Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 16:27:17 -0800 Content-Transfer-Encoding: 7bit > 1) In the security considerations section you use MUST strength for both > DIGEST-MD5 and TLS_RSA_WITH_3DES_EDE_CBC_SHA. I think requiring TLS and > 3DES is too restrictive, especially for small devices or lightweight > implementations. I propose using MUST strength for authentication > and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for > privacy and "all". the particular wording you see, and the particular technologises list reflect what the IESG is letting go through these days. in other words, they've been returning drafts to working groups and individual submissions, asking for language with these choices. it is important to appreciate the distinction between what gets implemented and what gets provisioned. the requirement is that tls be available in implementations, not that it has to be used by administrators. implementors are free to sell products with other technologies. administrators are free to configure or not whatever comes with the software. so what all this means is that administrators responsible for people with small devices won't turn privacy on. that's okay. what's important is that, two administrators agreeing to use privacy know that there will be at least one choice available, tls, regardless of what products they're using. they can then make a reasoned cost-benefit analysis as to what gets provisioned. > 2) Please briefly (one sentence) mention the I: and L: convention before > you use it in the examples. ok. > 3a) You mention middleboxes briefly, but I wasn't sure what you are really > recommending when you say it may be needed for "proxies to transparently > rewrite the transport information " I assume you mean SIP proxies? > This is *AN* approach, but we won't be able to get to end-to-end integrity > if this is required, hence my next question... > > 3b) I am assuming that IMSX assumes that the two BEEP entities will > communicate directly without relays. How would this work with a > couple of BEEP relays involved? What address would you advertise in SDP? > If this is possible, I think this is very useful for getting around the > middlebox traversal problem. i don't think the text could be any clearer: the IMSX peers have no interest in the network topology. the SIP infrastructure is responsible for ensuring end-to-end usability of the transport information. if middleboxes are involved, then the SIP infrastructure will have to deal with this. the problem is no different for any other application protocol making use of the SIP infrastructure. there is no explicit relaying model. if you want that, this is the wrong architecture. if you want to solve the middlebox problem, this is the wrong working group. > 4) I didn't get a good sense from your examples how to come up with > unique cid: URLs (especially if the originator is behind a NAT). > Do these have to be unique for all users/sessions, per BEEP session, or > per beep request? i think the email folks solved this problem long ago. generating a unique url is trivial, particularly, since it is used to refer only to data contained within the message... > 5) I think an example or call-flow showing multiplexed bidirectional > messages would be really useful. well, there are lots of call-flow diagrams in the sip document, to pick one and i guess i can copy it... > 6) I'm assuming that the proposed transformation between im: and sip: URLs > is to merely replace the scheme. Is this correct? that's really for the group to decide... /mtr _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 10 23:11:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00881 for ; Thu, 10 Jan 2002 23:11:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0B48ivw000076; Thu, 10 Jan 2002 23:08:44 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16855; Thu, 10 Jan 2002 23:11:02 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16474 for ; Thu, 10 Jan 2002 21:09:23 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0B28gF23956; Thu, 10 Jan 2002 18:08:42 -0800 (PST) From: Rohan Mahy To: "Marshall T. Rose" cc: , Marshall Rose Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt In-Reply-To: <011001c19a36$ba29fd30$0301000a@FATORA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 18:08:42 -0800 (PST) Hi Marshall, Thanks for the quick response. A few more comments inline... On Thu, 10 Jan 2002, Marshall T. Rose wrote: > > 1) In the security considerations section you use MUST strength for both > > DIGEST-MD5 and TLS_RSA_WITH_3DES_EDE_CBC_SHA. I think requiring TLS and > > 3DES is too restrictive, especially for small devices or lightweight > > implementations. I propose using MUST strength for authentication > > and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for > > privacy and "all". > > the particular wording you see, and the particular technologises list > reflect what the IESG is letting go through these days. in other words, > they've been returning drafts to working groups and individual submissions, > asking for language with these choices. > > it is important to appreciate the distinction between what gets implemented > and what gets provisioned. the requirement is that tls be available in > implementations, not that it has to be used by administrators. the problem is that some lightweight SIP implementations (e.g phones) will be unable to implement BEEP and TLS and RSA and 3DES. this is not an administrator level problem, it is an implementation burden. if I haven't convinced you, then I will talk to the appropriate AD. This shouldn't be your problem. > implementors are free to sell products with other technologies. > administrators are free to configure or not whatever comes with the > software. > > so what all this means is that administrators responsible for people with > small devices won't turn privacy on. that's okay. what's important is that, > two administrators agreeing to use privacy know that there will be at least > one choice available, tls, regardless of what products they're using. they > can then make a reasoned cost-benefit analysis as to what gets provisioned. > > > > 2) Please briefly (one sentence) mention the I: and L: convention before > > you use it in the examples. > > ok. > > > > 3a) You mention middleboxes briefly, but I wasn't sure what you are really > > recommending when you say it may be needed for "proxies to transparently > > rewrite the transport information " I assume you mean SIP proxies? > > This is *AN* approach, but we won't be able to get to end-to-end integrity > > if this is required, hence my next question... > > > > > 3b) I am assuming that IMSX assumes that the two BEEP entities will > > communicate directly without relays. How would this work with a > > couple of BEEP relays involved? What address would you advertise in SDP? > > If this is possible, I think this is very useful for getting around the > > middlebox traversal problem. > > i don't think the text could be any clearer: the IMSX peers have no interest > in the network topology. the SIP infrastructure is responsible for ensuring > end-to-end usability of the transport information. if middleboxes are > involved, then the SIP infrastructure will have to deal with this. the > problem is no different for any other application protocol making use of the > SIP infrastructure. How about: "Note that with the introduction of middleboxes [7], such as firewalls and network address translators, IMSX peers are responsible for using transport addresses which are usable end-to-end by their peers, or sending SIP through proxies or other entities which rewrite these addresses as appropriate to allow end-to-end communication." ?? > there is no explicit relaying model. if you want that, this is the wrong > architecture. if you want to solve the middlebox problem, this is the wrong > working group. sorry, I was thinking of APEX. > > 4) I didn't get a good sense from your examples how to come up with > > unique cid: URLs (especially if the originator is behind a NAT). > > Do these have to be unique for all users/sessions, per BEEP session, or > > per beep request? > > i think the email folks solved this problem long ago. generating a unique > url is trivial, particularly, since it is used to refer only to data > contained within the message... ok, you may want to mention that the url is unique only within the message. thanks again, -rohan > > > 5) I think an example or call-flow showing multiplexed bidirectional > > messages would be really useful. > > well, there are lots of call-flow diagrams in the sip document, to pick one > and i guess i can copy it... > > > > 6) I'm assuming that the proposed transformation between im: and sip: URLs > > is to merely replace the scheme. Is this correct? > > that's really for the group to decide... > > /mtr > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jan 11 13:27:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24630 for ; Fri, 11 Jan 2002 13:27:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0BINlvw004149; Fri, 11 Jan 2002 13:23:48 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19406; Fri, 11 Jan 2002 13:26:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19395 for ; Fri, 11 Jan 2002 13:25:16 -0500 (EST) Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA02201 for ; Fri, 11 Jan 2002 13:24:41 -0500 (EST) Received: from diamond.cs.columbia.edu (localhost [127.0.0.1]) by diamond.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0BIOeAT026081 for ; Fri, 11 Jan 2002 13:24:40 -0500 (EST) Received: (from petkos@localhost) by diamond.cs.columbia.edu (8.12.1/8.12.1/Submit) id g0BIOeEv026080 for simple@mailman.dynamicsoft.com; Fri, 11 Jan 2002 13:24:40 -0500 (EST) From: "Petri K. Koskelainen" Message-Id: <200201111824.g0BIOeEv026080@diamond.cs.columbia.edu> To: simple@mailman.dynamicsoft.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] IMTP Extensions draft available Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 13:24:40 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, New IMTP-related draft is now available: http://www.ietf.org/internet-drafts/draft-koskelainen-imtpext-00.txt "IMTP extensions for message threading" Abstract The IMTP specification defines a session-based IM transport as well as the message format for it. However, it does not support message threads or discussion topics which are useful in applications such as multi-party chat. This document defines extensions to IMTP which allow applications to utilize threads and sub-threads within an IMTP message session. Also, the extensions enable message identification. BR, -- Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jan 11 13:49:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25398 for ; Fri, 11 Jan 2002 13:49:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0BIjhvw004442; Fri, 11 Jan 2002 13:45:43 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19488; Fri, 11 Jan 2002 13:48:03 -0500 (EST) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19212 for ; Fri, 11 Jan 2002 12:28:02 -0500 (EST) Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g0BHK7504606; Fri, 11 Jan 2002 09:20:07 -0800 (PST) Message-ID: <04c701c19ac5$39ab5890$0301000a@FATORA> From: "Marshall T. Rose" To: "Rohan Mahy" Cc: References: Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 09:27:20 -0800 Content-Transfer-Encoding: 7bit > > it is important to appreciate the distinction between what gets implemented > > and what gets provisioned. the requirement is that tls be available in > > implementations, not that it has to be used by administrators. > > the problem is that some lightweight SIP implementations (e.g phones) will > be unable to implement BEEP and TLS and RSA and 3DES. this is not an > administrator level problem, it is an implementation burden. > > if I haven't convinced you, then I will talk to the appropriate AD. This > shouldn't be your problem. sure. > How about: > > "Note that with the introduction of middleboxes [7], such as firewalls and > network address translators, IMSX peers are responsible for using > transport addresses which are usable end-to-end by their peers, or sending > SIP through proxies or other entities which rewrite these addresses as > appropriate to allow end-to-end communication." ?? i don't think this works because of the "IMSX peers are responsible" part. this implies some kind of topology-specific behavior on the part of IMSX, which isn't there. IMSX doesn't know, nor care, about topology. that's someone else's job... the requirement on the part of IMSX is stated in the previous paragraph, to wit: As with any model based on dynamic rendezvous, it is critically important that each application faithfully record the appropriate transport information in the corresponding SDP announcement. > > > 4) I didn't get a good sense from your examples how to come up with > > > unique cid: URLs (especially if the originator is behind a NAT). > > > Do these have to be unique for all users/sessions, per BEEP session, or > > > per beep request? > > > > i think the email folks solved this problem long ago. generating a unique > > url is trivial, particularly, since it is used to refer only to data > > contained within the message... > > ok, you may want to mention that the url is unique only within the > message. ok. /mtr _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jan 11 18:06:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02650 for ; Fri, 11 Jan 2002 18:06:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0BN1mvw006928; Fri, 11 Jan 2002 18:01:49 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20297; Fri, 11 Jan 2002 18:04:02 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19783 for ; Fri, 11 Jan 2002 15:26:10 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0BKPTF14729; Fri, 11 Jan 2002 12:25:29 -0800 (PST) From: Rohan Mahy To: "Marshall T. Rose" cc: Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt In-Reply-To: <04c701c19ac5$39ab5890$0301000a@FATORA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 12:25:29 -0800 (PST) On Fri, 11 Jan 2002, Marshall T. Rose wrote: [snip] > > How about: > > > > "Note that with the introduction of middleboxes [7], such as firewalls and > > network address translators, IMSX peers are responsible for using > > transport addresses which are usable end-to-end by their peers, or sending > > SIP through proxies or other entities which rewrite these addresses as > > appropriate to allow end-to-end communication." ?? > > i don't think this works because of the "IMSX peers are responsible" part. > this implies some kind of topology-specific behavior on the part of IMSX, > which isn't there. IMSX doesn't know, nor care, about topology. that's > someone else's job... the requirement on the part of IMSX is stated in the > previous paragraph, to wit: > > As with any model based on dynamic rendezvous, > it is critically important that each application faithfully record the > appropriate transport information in the corresponding SDP > announcement. One of the ways that we are getting SIP intiated media through middleboxes is to have the SIP UA "lie" about its address. A SIP UA might use STUN to get public addresses for RTP and RTCP media, or TURN to establish use of a media relay. What I meant by IMSX peer was the host that IMSX runs on. An alternate rewording would be "SIP User Agents implementing IMSX are responsible..." This is an alternative to the requirement for a proxy to do rewriting. Some relevant pointers to this method of middlebox traversal are below. draft-rosenberg-midcom-stun-00.txt draft-rosenberg-midcom-turn-00.txt draft-rosenberg-sipping-nat-scenarios-00.txt hope this makes sense. thanks, -rohan _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jan 11 19:19:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03467 for ; Fri, 11 Jan 2002 19:19:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0C0Fivw007346; Fri, 11 Jan 2002 19:15:44 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20555; Fri, 11 Jan 2002 19:18:02 -0500 (EST) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20543 for ; Fri, 11 Jan 2002 19:17:17 -0500 (EST) Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g0C09M505745; Fri, 11 Jan 2002 16:09:22 -0800 (PST) Message-ID: <066c01c19afe$66498730$0301000a@FATORA> From: "Marshall T. Rose" To: "Rohan Mahy" Cc: , "Marshall Rose" References: Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 16:16:36 -0800 Content-Transfer-Encoding: 7bit > One of the ways that we are getting SIP intiated media through middleboxes > is to have the SIP UA "lie" about its address. A SIP UA might use STUN to > get public addresses for RTP and RTCP media, or TURN to establish use of a > media relay. What I meant by IMSX peer was the host that IMSX runs > on. An alternate rewording would be "SIP User Agents implementing > IMSX are responsible..." This is an alternative to the requirement > for a proxy to do rewriting. Some relevant pointers to this method of > middlebox traversal are below. > > draft-rosenberg-midcom-stun-00.txt > draft-rosenberg-midcom-turn-00.txt > draft-rosenberg-sipping-nat-scenarios-00.txt > > hope this makes sense. yes, it makes sense, i just question whether it belongs in imsx. how about this text: Note that with the introduction of middleboxes [7], such as firewalls and network address translators, it may be necessary to rewrite the transport information in order to account for administratively- mandated media gateways or address translation. Accordingly, SIP user agents are responsible for either directly rewriting the transport information, or, sending the SDP announcement through the appropriate intermediaries that will transparently rewrite the transport information. In a phrase, "res ipsa loquitur". /mtr _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jan 11 19:21:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03516 for ; Fri, 11 Jan 2002 19:21:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0C0Hjvw007405; Fri, 11 Jan 2002 19:17:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20582; Fri, 11 Jan 2002 19:20:05 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20569 for ; Fri, 11 Jan 2002 19:19:07 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0C0IRF11485; Fri, 11 Jan 2002 16:18:27 -0800 (PST) From: Rohan Mahy To: "Marshall T. Rose" cc: , Marshall Rose Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt In-Reply-To: <066c01c19afe$66498730$0301000a@FATORA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 16:18:27 -0800 (PST) On Fri, 11 Jan 2002, Marshall T. Rose wrote: > > > One of the ways that we are getting SIP intiated media through middleboxes > > is to have the SIP UA "lie" about its address. A SIP UA might use STUN to > > get public addresses for RTP and RTCP media, or TURN to establish use of a > > media relay. What I meant by IMSX peer was the host that IMSX runs > > on. An alternate rewording would be "SIP User Agents implementing > > IMSX are responsible..." This is an alternative to the requirement > > for a proxy to do rewriting. Some relevant pointers to this method of > > middlebox traversal are below. > > > > draft-rosenberg-midcom-stun-00.txt > > draft-rosenberg-midcom-turn-00.txt > > draft-rosenberg-sipping-nat-scenarios-00.txt > > > > hope this makes sense. > > yes, it makes sense, i just question whether it belongs in imsx. how about > this text: > > Note that with the introduction of middleboxes [7], such as firewalls > and network address translators, it may be necessary to rewrite the > transport information in order to account for administratively- > mandated media gateways or address translation. Accordingly, SIP > user agents are responsible for either directly rewriting the > transport information, or, sending the SDP announcement through the > appropriate intermediaries that will transparently rewrite the > transport information. In a phrase, "res ipsa loquitur". > > /mtr sounds good. thanks, -rohan _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jan 22 23:07:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20860 for ; Tue, 22 Jan 2002 23:07:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0N3pim2014826; Tue, 22 Jan 2002 22:51:44 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07813; Tue, 22 Jan 2002 22:54:03 -0500 (EST) Received: from hotmail.com (f132.law14.hotmail.com [64.4.21.132]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07801 for ; Tue, 22 Jan 2002 22:53:06 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Jan 2002 19:52:30 -0800 Received: from 195.212.29.120 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 23 Jan 2002 03:52:29 GMT X-Originating-IP: [195.212.29.120] From: "Tang Lihua" To: simple@mailman.dynamicsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jan 2002 03:52:30.0273 (UTC) FILETIME=[617DBB10:01C1A3C1] Subject: [Simple] Somes questions about behavior of PS Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 11:52:29 +0800 Hi,guys I want to clarify the behaviour of PS. My questions are as follows: About Registrar 1. How to upload buddylist or watcherlist to PS? Through registration or other way? If a buddylist is stored in PS, should PS automaticly send out subscription to each buddy on the list? And it's strange that in this case a watcher will receive notifications but no subscription is sent out by the watcher itself. Also another problem is that it will burden PS with handling all the buddylists or watcherlists. 2. If a user gets unregistered, remove this user from database or just mark it as 'Unregistered'? How can the PS know an offline presentity is a once registered user? Is User Managerment a need? About Authentication 1. Is the authentication in PS a server-side(as proxy) or a ua-side one(as PA) one? If a subscription is sent to an offline presentity, should the PS challenge the subscriber? 2. Should the PS maintain access password lists of each presentity for each possible watcher? Is there a better way for PS to authorize the watcher? 2. Draft says, 'For pending subscriptions, the state of the presentity SHOULD include some kind of textual note that indicates a pending status.' Is there any solution to it till now? More, how can the PS notify the watcher that a buddy is offline now or a buddy gets online? Thanks for your comments! Best regards, Tang Lihua _________________________________________________________________ 享用世界上最大的 Web 电子邮件系统 —— MSN Hotmail。 http://www.hotmail.com/cn _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 24 00:41:25 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07192 for ; Thu, 24 Jan 2002 00:41:24 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0O5aim2023913; Thu, 24 Jan 2002 00:36:44 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12443; Thu, 24 Jan 2002 00:39:04 -0500 (EST) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12432 for ; Thu, 24 Jan 2002 00:38:41 -0500 (EST) Received: from cwc.nus.edu.sg ([172.16.2.230]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id NAA08505 for ; Thu, 24 Jan 2002 13:36:37 +0800 (SGT) Message-ID: <3C4F9F4D.1040101@cwc.nus.edu.sg> From: Nirmalya Ghosh Organization: Centre for Wireless Communications, Singapore User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Call-ID & CSeq changes in MESSAGE requests Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 13:44:45 +0800 Content-Transfer-Encoding: 7bit Hi All, I have been reading through the draft on Sip Extensions for Instant Messaging (simple-im-01) and I have a doubt regarding the change of Call-ID & CSeq headers. Since MESSAGE requests do not create an implied session (implying no call-leg, or call-state), does this mean that the Call-leg keeps changing and the CSeq MAY remain the same in subsequent MESSAGE requests, or vice versa? Thanks & Regards, Nirmalya _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 24 10:25:47 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23602 for ; Thu, 24 Jan 2002 10:25:47 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0OFLcm2026254; Thu, 24 Jan 2002 10:21:38 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14205; Thu, 24 Jan 2002 10:24:03 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14194 for ; Thu, 24 Jan 2002 10:23:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OFNTGe029372; Thu, 24 Jan 2002 10:23:39 -0500 (EST) Message-ID: <3C5026CB.E1C4F40F@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nirmalya Ghosh CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Call-ID & CSeq changes in MESSAGE requests References: <3C4F9F4D.1040101@cwc.nus.edu.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 10:22:51 -0500 Content-Transfer-Encoding: 7bit Nirmalya Ghosh wrote: > > Hi All, > I have been reading through the draft on Sip Extensions for Instant > Messaging (simple-im-01) and I have a doubt regarding the change of > Call-ID & CSeq headers. Since MESSAGE requests do not create an implied > session (implying no call-leg, or call-state), does this mean that the > Call-leg keeps changing and the CSeq MAY remain the same in subsequent > MESSAGE requests, or vice versa? Yes, the Call-ID will change in each subsequent message. Furthermore, since CSeq is defined within the space of a call leg, the value of the CSeq header in each message are really independent and unrelated. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Jan 29 13:26:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12560 for ; Tue, 29 Jan 2002 13:26:38 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0TINlgZ010492; Tue, 29 Jan 2002 13:23:48 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06207; Tue, 29 Jan 2002 13:26:05 -0500 (EST) Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06196 for ; Tue, 29 Jan 2002 13:25:46 -0500 (EST) Received: from paloverde.INRS-Telecom.UQuebec.CA (paloverde [192.26.211.111]) by ozias.inrs-telecom.uquebec.ca (8.11.3/8.11.3) with ESMTP id g0TIP3b01821 for ; Tue, 29 Jan 2002 13:25:03 -0500 (EST) Received: from inrs-telecom.uquebec.ca by paloverde.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id NAA16834; Tue, 29 Jan 2002 13:25:03 -0500 (EST) Message-ID: <3C56E8FF.2CCAB19B@inrs-telecom.uquebec.ca> From: =?iso-8859-1?Q?H=E9l=E8ne?= Montarou X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: multipart/mixed; boundary="------------EA092FC0C53693519E1A26AE" Subject: [Simple] Misunderstanding of Presence Service with SIP Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 13:25:03 -0500 This is a multi-part message in MIME format. --------------EA092FC0C53693519E1A26AE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Sir, I am studying SIP and the presence service. There is some points I misunderstand concerning the model proposed in RFC 2778 and the analogy between PUA's addresses and presentities'addresses. A. Concerning the model : So, if I understand well: - A principal can manipulate zero or more presentities, - A principal interacts with the system via one or several user agents so one or several Presence User Agent (PUA), - A PUA can not have several presentities due to an addressing problem but several PUAs can send their presence information to the same presentity. Finally, the configuration in the document attached (configuration.ps) are allowed. Is it correct from now? - We supposed all the entities are colocalised. In the second case, PUAs share the same address so that the presentity can be reach via this same address, is not it ?? In this case, we could say that the address identify uniquely the principal. In the first case, presentities have different addresses. Only PUAs of the Principal can be identify uniquely through presentities. A watcher which would like to know the principal presence information (state of all devices and services on devices of this principal) has to know the PUAs ' presentities addresses, is not it ?? As an example , PUAs could be different programs/applications.. so services on the same computer like email, phone, conference.. etc.. is that correct ? could you give me some more example ? - When PUAs and presentities are delocalised, they can have different addresses. If we consider both configuration above, how is it possible to identify a PUA uniquely for a watcher ? and principal uniquely ? What should be the presentity address in particular in the second case ? As an example, PUAs could be programs/applications/several devices (mobile phone, fixe phone and PC ) with three different addresses. For this example, is the second configuration still allowed? B. Concerning the CPIM format: - The presence information contained in a tuple concern a PUA. - A list of tuples for the same presentity means that several PUAs send information at the same presentity. Is it correct ? Here the example from the Internet Draft "CPIM Presence Information Data Format": OPEN BUSY HOME im:shingo@mobilecarrier.ne.jp Don't Disturb Please! 2001-10-27T16:49:29Z OPEN mailto:shingo@jp.fujitsu.com I'll be in Tokyo tomorrow Could you explain it in terms of Principal, PUA, Presentity, devices, services and addresses ? Waiting for your answer, I thank you very much in advance. This would help me a lot in my understanding of SIP and presence. Regards, H閘鑞e Montarou. ---------------------------------------------- INRS-T閘閏ommunications Place Bonaventure 900, de la Gaucheti鑢e Ouest Niveau C, Case Postale 644 Montr閍l, QC H5A 1C6 Canada ---------------------------------------------- --------------EA092FC0C53693519E1A26AE Content-Type: application/postscript; name="configuration.ps" Content-Disposition: inline; filename="configuration.ps" Content-Transfer-Encoding: 7bit %!PS-Adobe-2.0 EPSF-2.0 %%Title: configurations.fig %%Creator: fig2dev Version 3.1 Patchlevel 2 %%CreationDate: Mon Jan 28 13:20:51 2002 %%For: montarou@paloverde (Helene Montarou) %Magnification: 1.00 %%Orientation: Portrait %%BoundingBox: 0 0 285 243 %%Pages: 0 %%BeginSetup %%IncludeFeature: *PageSize A4 %%EndSetup %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save -90.0 290.0 translate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def %%EndProlog $F2psBegin 10 setmiterlimit n 0 842 m 0 0 l 595 0 l 595 842 l cp clip 0.06000 0.06000 sc 7.500 slw % Polyline n 3075 1800 m 3600 1800 l gs col-1 s gr % Polyline n 3075 1725 m 3600 1275 l gs col-1 s gr % Polyline n 3075 1875 m 3600 2325 l gs col-1 s gr % Polyline n 4200 1200 m 4650 1200 l gs col-1 s gr % Polyline n 4200 1800 m 4650 1800 l gs col-1 s gr % Polyline n 4200 2400 m 4650 2400 l gs col-1 s gr % Polyline n 3075 4200 m 3600 4200 l gs col-1 s gr % Polyline n 3059 4294 m 3584 4744 l gs col-1 s gr % Polyline n 3059 4106 m 3584 3656 l gs col-1 s gr % Polyline n 4211 3663 m 4736 4113 l gs col-1 s gr % Polyline n 4200 4200 m 4725 4200 l gs col-1 s gr % Polyline n 4179 4775 m 4704 4325 l gs col-1 s gr /Times-Roman ff 180.00 scf sf 1500 900 m gs 1 -1 sc (1. ) col-1 sh gr /Times-Roman ff 180.00 scf sf 2100 1875 m gs 1 -1 sc (Principal \(x\) ) col-1 sh gr /Times-Roman ff 180.00 scf sf 3750 1800 m gs 1 -1 sc (PUA) col-1 sh gr /Times-Roman ff 180.00 scf sf 3750 2400 m gs 1 -1 sc (PUA) col-1 sh gr /Times-Roman ff 180.00 scf sf 3750 1275 m gs 1 -1 sc (PUA) col-1 sh gr /Times-Roman ff 180.00 scf sf 4800 1200 m gs 1 -1 sc (Presentity \(@PUA\)) col-1 sh gr /Times-Roman ff 180.00 scf sf 4800 1800 m gs 1 -1 sc (Presentity \(@PUA\)) col-1 sh gr /Times-Roman ff 180.00 scf sf 4800 2400 m gs 1 -1 sc (Presentity \(@PUA\)) col-1 sh gr /Times-Roman ff 180.00 scf sf 1500 3300 m gs 1 -1 sc (.2.) col-1 sh gr /Times-Roman ff 180.00 scf sf 2100 4200 m gs 1 -1 sc (Principal \(x\) ) col-1 sh gr /Times-Roman ff 180.00 scf sf 3750 3675 m gs 1 -1 sc (PUA) col-1 sh gr /Times-Roman ff 180.00 scf sf 3750 4275 m gs 1 -1 sc (PUA) col-1 sh gr /Times-Roman ff 180.00 scf sf 3750 4800 m gs 1 -1 sc (PUA) col-1 sh gr /Times-Roman ff 180.00 scf sf 4875 4200 m gs 1 -1 sc (Presentity \(@ ?? \)) col-1 sh gr $F2psEnd rs --------------EA092FC0C53693519E1A26AE-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple