From simple-admin@mailman.dynamicsoft.com Tue Oct 1 05:03: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 FAA02769 for ; Tue, 1 Oct 2002 05:03:31 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g91946sr006127 for ; Tue, 1 Oct 2002 05:04:06 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06577 for ; Tue, 1 Oct 2002 05:04:52 -0400 (EDT) Date: Tue, 1 Oct 2002 05:04:52 -0400 (EDT) Message-Id: <200210010904.FAA06577@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 Tue Oct 1 05:44:14 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04693 for ; Tue, 1 Oct 2002 05:44:14 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g919aJsr007417; Tue, 1 Oct 2002 05:36:19 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08522; Tue, 1 Oct 2002 05:37:03 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08511 for ; Tue, 1 Oct 2002 05:36:58 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g919baF23261 for ; Tue, 1 Oct 2002 12:37:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Oct 2002 12:21:08 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Oct 2002 12:21:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] The way forward in data manipulation work Message-ID: Thread-Topic: [Simple] The way forward in data manipulation work Thread-Index: AcJonfp0VDXcYwNMRG+hjg2v3eABFQAid3nQ To: Cc: X-OriginalArrivalTime: 01 Oct 2002 09:21:08.0335 (UTC) FILETIME=[E00E77F0:01C2692B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA08511 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, 1 Oct 2002 12:21:07 +0300 Content-Transfer-Encoding: 8bit Hi Rohan, I completely agree with you. My proposals about SOAP and BIND were there mainly to start the discussion and to show that in fact solutions already exist. There seems to be agreement that initially we need some kind of simple list management protocol (ADD member, REMOVE member, MODIFY member), so that different lists associated to SIP services could be manipulated. I think the requirements for this are pretty well covered in the existing Data Manipulation Requirements draft. This could be built on top of whatever RPC mechanism. Also, authorization management is chartered. In that case the scoping is more problematic. I think we could split the problem into two parts: general and service-specific. In the general part we should be able to define things like matching for list memberships or checking the day-of-time. These kind of IF-THEN-ELSE chains would lead to actual decisions, for which yes/no could be the general baseline. Services such as presence however need further service-specific semantics, for example the decision should describe what parts of the presence info to give to the requestor. Also, for conferences the decision may need to contain information about the granted rights. So, we should probably develop separate rules for presence and conferencing in addition to the general part. Current Data Manipulation Requirements draft proposes to use a CPL-like scripting language for this, and the only manipulation operation would be a complete REWRITE. This is OK, but if possible I would like to see if it is possible to update only part of the information to save bandwidth. So, what could we do before Atlanta? I guess the aim should be to finish the requirements draft and have a first version of "RPC-mechanism-independent" description of list management and authorization management protocols and their semantics. I understand this so that we define the commands/methods and their parameters, so that it is straightforward to map them to e.g. SOAP. If this seems a reasonable idea, I can volunteer to write a first version of this kind of description for people to comment. Markus > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 30 September, 2002 19:25 > To: Isomaki Markus (NRC/Helsinki) > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] The way forward in data manipulation work > > > Hi Markus, > > Not everyone is going to immediately have the same conclusion about > SOAP. In order to avoid the syntax wars, I suggest that we focus on > the semantics of the kind of RPC mechanism we will need. Once we have > debated the semantics, we can then have the syntax discussion. Folks > can then propose alternate SOAP and non-SOAP syntax that conveys the > agreed-upon semantics. > > Also, as I said at the mic in Yokohama, I'm not convinced > that we need > a SIP BIND method. Let's make sure we have a good semantic > description > of the binding relationship between SIP and data before we cast a > mechanism on stone. > > thanks, > -rohan > > > On Wednesday, September 25, 2002, at 06:49 AM, > Markus.Isomaki@nokia.com > wrote: > > > Hi, > > > > I think this would be a good time to see how to go forward with the > > charter items related to data manipulation. > > > > I believe Jonathan is planning to update the Data Manipulation > > Requirements draft > focusing on two > > issues: 1. List management, and 2. Authrozation policy > management. In > > Yokohama the concensus was to take this draft as basis for WG > > requirements, so maybe the next version could be taken as a > WG draft. > > It is also a good proposal to limit that draft to purely > requirements, > > leaving the "model" in Chapter 4 out of scope. Maybe then > it would be > > easiear to agree on the draft. > > > > However, some kind of model/framework draft (similar to > what is being > > done in conferencing) is also needed, and eventually it is > essential > > to agree on what protocols to use. Based on usage > guidelines SIP does > > not seem to meet the requirements. The current PUBLISH > proposal is too > > simplistic to be useful in many cases. Instead, some kind of more > > flexible RPC mechanism with some support to synchronization > seems to > > be the best choise. > > > > My proposal is thus: > > 1. Use SOAP/WSDL for data manipulation. In the first phase a > > definition is needed only for list and auth. policy management, but > > the framework does not need to limit to this. > > 2. Use SIP Events in a same fashion as "Message Waiting Indicator" > > draft to convey notifications about state changes in the managed > > objects. A collection package could be used for > optimization purposes. > > This spec could still leave the actual synchronization update > > mechanism open, but I can imagine SyncML and others could > potentially > > be usable there. > > 3. Take SIP BIND as a default mechanism to make binding > between sip: > > URIs and SOAP http: URIs. > > > > In my opinion the framework doc. should define the > terminology, have a > > few nice ascii-drawings and describe the model and the > actors within > > points 1-3 above. Also, it should tell how to specify management > > interfaces for specific objects, and how to achieve the > > synchronization. In addition more specific documents would > be needed > > for "list management", "authorization policy management" and > > "synchronization event package". > > > > I think we could have the first version of such framework > draft could > > be ready for the next IETF Atlanta meeting, and discussed > there. Then > > it could be updated and work on more specific drafts could start. > > > > But before starting anything like this, I would like to get > people's > > opinion about the technical part, and of course chairs' > opinion about > > the process. I'm sure there are plenty of other approaches, but I > > haven't heard any proposals so far. In any case, some kind > of design > > team around this matter might be a good idea. > > > > Regards, > > Markus > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 1 06:28:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06203 for ; Tue, 1 Oct 2002 06:28:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g919cIsr007486; Tue, 1 Oct 2002 05:38:18 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08557; Tue, 1 Oct 2002 05:39:02 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08546 for ; Tue, 1 Oct 2002 05:38:18 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g919c8503045 for ; Tue, 1 Oct 2002 12:38:09 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Oct 2002 12:36:35 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Oct 2002 12:36:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] The way forward in data manipulation work Message-ID: Thread-Topic: [Simple] The way forward in data manipulation work Thread-Index: AcJot+IlmtAcBOSfSgqzYQmkjm49zQAdBpbQ To: , Cc: , X-OriginalArrivalTime: 01 Oct 2002 09:36:35.0005 (UTC) FILETIME=[086516D0:01C2692E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA08546 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, 1 Oct 2002 12:36:34 +0300 Content-Transfer-Encoding: 8bit Hi, Here are some use cases (i.e. requirements) I have for the SIP URI - generic URI binding solution: - A user must be able to create dynamically new service/AoR instances. These include conferences, presence lists, IM delivery lists and any other SIP services. I assume some RPC-mechanism instead of SIP will be used for the CREATE operation. So, the user must be able to discover the (generic) URI where to send such commands. I'm not sure if this is in the scope of BIND at all, since neither SIP nor the generic URI exist yet. But, I would be happy with the solution where user could query such generic URIs using her own AoR or the domain name as the starting point. (I.e. give me the addresses of the interfaces related to this AoR or this domain.). Local service discovery mechanisms won't work for this, since the user might not be (in IP-topology) in her "home" network. - A user must be able to bind and manage objects (lists, authorization policies) related to any SIP AoR hosting an appropriate service. These services include presence (auth. policy, using matching against list memberships), presence lists (the list itself), IM delivery lists (the list itself), conferences (whatever conf. or media policies or even foor control) and any other similar ones. Binding header in BIND or OPTIONS (or INVITE) would be a sufficient solution. Markus > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 30 September, 2002 22:32 > To: Henning Schulzrinne > Cc: Sean Olson; Isomaki Markus (NRC/Helsinki); > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] The way forward in data manipulation work > > > > On Monday, September 30, 2002, at 11:03 AM, Henning Schulzrinne wrote: > > > We have discussed this before, but I still fail to see how > you can, in > > general, > > "in general" > > well, that's the disagreement. In all the specific motivating > scenarios > for SIP BIND, there has been another very reasonable way to > map between > the SIP and non-SIP URIs. I'm not convinced that a general > solution is > needed (the requirements don't bear that out IMO). > > thanks, > -rohan > > > > deduce from a SIP URL what the corresponding non-SIP URL > is. In many > > cases, you will have other means to establish the binding > (e.g., one > > could consider the various *-Info headers an example of such a > > binding), but these means tend to be within a dialog or for a > > particular request. > > > > Sean Olson wrote: > >> I would also like to see some consideration > >> of the impacts of binding SIP to HTTP. I'm not > >> at all convinced that BIND is the way to go > >> for this. Assuming we want an RPC mechanism > >> for this task (a big assumption), what is the > >> requirement for correlating the data manipulation > >> mechanism with SIP? Is this not implied by the > >> data being manipulated? > >> /sean > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 1 11:06:30 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21669 for ; Tue, 1 Oct 2002 11:06:29 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g91F6Vsr008699; Tue, 1 Oct 2002 11:06:32 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09633; Tue, 1 Oct 2002 11:07:07 -0400 (EDT) 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 LAA09622 for ; Tue, 1 Oct 2002 11:06:31 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g91F6VIm029562; Tue, 1 Oct 2002 08:06:32 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA27658; Tue, 1 Oct 2002 08:04:27 -0700 (PDT) Subject: Re: [Simple] The way forward in data manipulation work Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Markus.Isomaki@nokia.com From: Rohan Mahy In-Reply-To: Message-Id: <90F9E6DF-D54F-11D6-8705-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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, 1 Oct 2002 08:07:56 -0700 Content-Transfer-Encoding: 7bit On Tuesday, October 1, 2002, at 02:21 AM, Markus.Isomaki@nokia.com wrote: > Hi Rohan, > > I completely agree with you. My proposals about SOAP and BIND were > there mainly to start the discussion and to show that in fact > solutions already exist. > > There seems to be agreement that initially we need some kind of simple > list management protocol (ADD member, REMOVE member, MODIFY member), > so that different lists associated to SIP services could be > manipulated. I think the requirements for this are pretty well covered > in the existing Data Manipulation Requirements draft. This could be > built on top of whatever RPC mechanism. > > Also, authorization management is chartered. In that case the scoping > is more problematic. I think we could split the problem into two > parts: general and service-specific. In the general part we should be > able to define things like matching for list memberships or checking > the day-of-time. These kind of IF-THEN-ELSE chains would lead to > actual decisions, for which yes/no could be the general baseline. > Services such as presence however need further service-specific > semantics, for example the decision should describe what parts of the > presence info to give to the requestor. Also, for conferences the > decision may need to contain information about the granted rights. So, > we should probably develop separate rules for presence and > conferencing in addition to the general part. > > Current Data Manipulation Requirements draft proposes to use a > CPL-like scripting language for this, and the only manipulation > operation would be a complete REWRITE. This is OK, but if possible I > would like to see if it is possible to update only part of the > information to save bandwidth. > > So, what could we do before Atlanta? I guess the aim should be to > finish the requirements draft and have a first version of > "RPC-mechanism-independent" description of list management and > authorization management protocols and their semantics. I understand > this so that we define the commands/methods and their parameters, so > that it is straightforward to map them to e.g. SOAP. if you want to look at another document for an example of the semantics-only document, check out: draft-taylor-midcom-semantics-00.txt > If this seems a reasonable idea, I can volunteer to write a first > version of this kind of description for people to comment. fantastic. i look forward to reading it. thanks, -rohan > Markus > >> -----Original Message----- >> From: ext Rohan Mahy [mailto:rohan@cisco.com] >> Sent: 30 September, 2002 19:25 >> To: Isomaki Markus (NRC/Helsinki) >> Cc: simple@mailman.dynamicsoft.com >> Subject: Re: [Simple] The way forward in data manipulation work >> >> >> Hi Markus, >> >> Not everyone is going to immediately have the same conclusion about >> SOAP. In order to avoid the syntax wars, I suggest that we focus on >> the semantics of the kind of RPC mechanism we will need. Once we have >> debated the semantics, we can then have the syntax discussion. Folks >> can then propose alternate SOAP and non-SOAP syntax that conveys the >> agreed-upon semantics. >> >> Also, as I said at the mic in Yokohama, I'm not convinced >> that we need >> a SIP BIND method. Let's make sure we have a good semantic >> description >> of the binding relationship between SIP and data before we cast a >> mechanism on stone. >> >> thanks, >> -rohan >> >> >> On Wednesday, September 25, 2002, at 06:49 AM, >> Markus.Isomaki@nokia.com >> wrote: >> >>> Hi, >>> >>> I think this would be a good time to see how to go forward with the >>> charter items related to data manipulation. >>> >>> I believe Jonathan is planning to update the Data Manipulation >>> Requirements draft >> focusing on two >>> issues: 1. List management, and 2. Authrozation policy >> management. In >>> Yokohama the concensus was to take this draft as basis for WG >>> requirements, so maybe the next version could be taken as a >> WG draft. >>> It is also a good proposal to limit that draft to purely >> requirements, >>> leaving the "model" in Chapter 4 out of scope. Maybe then >> it would be >>> easiear to agree on the draft. >>> >>> However, some kind of model/framework draft (similar to >> what is being >>> done in conferencing) is also needed, and eventually it is >> essential >>> to agree on what protocols to use. Based on usage >> guidelines SIP does >>> not seem to meet the requirements. The current PUBLISH >> proposal is too >>> simplistic to be useful in many cases. Instead, some kind of more >>> flexible RPC mechanism with some support to synchronization >> seems to >>> be the best choise. >>> >>> My proposal is thus: >>> 1. Use SOAP/WSDL for data manipulation. In the first phase a >>> definition is needed only for list and auth. policy management, but >>> the framework does not need to limit to this. >>> 2. Use SIP Events in a same fashion as "Message Waiting Indicator" >>> draft to convey notifications about state changes in the managed >>> objects. A collection package could be used for >> optimization purposes. >>> This spec could still leave the actual synchronization update >>> mechanism open, but I can imagine SyncML and others could >> potentially >>> be usable there. >>> 3. Take SIP BIND as a default mechanism to make binding >> between sip: >>> URIs and SOAP http: URIs. >>> >>> In my opinion the framework doc. should define the >> terminology, have a >>> few nice ascii-drawings and describe the model and the >> actors within >>> points 1-3 above. Also, it should tell how to specify management >>> interfaces for specific objects, and how to achieve the >>> synchronization. In addition more specific documents would >> be needed >>> for "list management", "authorization policy management" and >>> "synchronization event package". >>> >>> I think we could have the first version of such framework >> draft could >>> be ready for the next IETF Atlanta meeting, and discussed >> there. Then >>> it could be updated and work on more specific drafts could start. >>> >>> But before starting anything like this, I would like to get >> people's >>> opinion about the technical part, and of course chairs' >> opinion about >>> the process. I'm sure there are plenty of other approaches, but I >>> haven't heard any proposals so far. In any case, some kind >> of design >>> team around this matter might be a good idea. >>> >>> Regards, >>> Markus >>> _______________________________________________ >>> simple mailing list >>> simple@mailman.dynamicsoft.com >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >> >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.com >> http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 1 17:29:55 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 RAA05668 for ; Tue, 1 Oct 2002 17:29:54 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g91LUMsr010147; Tue, 1 Oct 2002 17:30:23 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10734; Tue, 1 Oct 2002 17:31:03 -0400 (EDT) Received: from hop.funtv.com (hop.funtv.com [206.19.100.98]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10723 for ; Tue, 1 Oct 2002 17:30:21 -0400 (EDT) Received: from skim (sns.funtv.com [206.19.96.100]) by hop.funtv.com (8.8.8+Sun/8.8.8) with SMTP id OAA10018; Tue, 1 Oct 2002 14:30:22 -0700 (PDT) Message-ID: <008601c26991$e0196410$400015ac@skim> From: "Seonman Kim" To: Cc: "Seonman Kim" MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Simple] MESSAGE with MSN Messenger Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 1 Oct 2002 14:31:16 -0700 Content-Transfer-Encoding: 7bit Hi, First of all, I would like to thank you all who replied to my former question on NOTIFY with MSN messenger. With your helps, I could successfully use Messenger using SUBSCRIBE and NOTIFY. Now, I have another problem, and it is MESSAGE request with MSN messenger. I tested to send IM messages using the messenger, and I found the IM in Messenger behaves differently from SIMPLE specification. The followings are what I found with MSN messenger when sending IM. - The first MESSAGE request creates a dialog with Record-Route header. The subsequent MESSAGE request uses Route header field within the same dialog and incremented CSeq number. - When a user typing characters, a INFO request message is sent within the same dialog. INFO message contains XML body that indicates the user is typing. - When a user close the window, BYE message is sent to the counterpart within the same dialog. I attach the SIP messages generated during the IM session. Even with these messages traffic, the callee (recipient) messenger did not show anything (did not show IM notification, windows, at all.), even if it answered 200 OK responses for every MESSAGE, INFO, and BYE message. It was really weird. I have no idea why the messenger didn't show anything, and I am just suspicious that MSN messenger's Communication Services Options was not properly implemented as designed. If anyone knows about this problem, please let me know. It would be a great help. One more question: does anybody know what "msgr" tag means in Content-Type header field in MESSAGE request? Thanks, Seonman --- SIP messages --------- [Messenger A (seonman) to Proxy at 206.xxx.xxx.203] MESSAGE sip:smkim320@206.xxx.xxx.203 SIP/2.0 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967 From: "seonman" ;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb To: Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 1 MESSAGE Contact: User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQ BhAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAH IAa QBmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANA AoA Content-Length: 2 Hi ------------ [Proxy to Messenger B (smkim320) at 192.168.1.12] MESSAGE sip:192.168.1.12:13085;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bK15c8f59bcda0cd8b4d357144186e027e.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bK9248414244a5bb33e17ab36fbe55da12.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 1 MESSAGE Max-Forwards: 69 Record-Route: , Contact: User-Agent: Windows RTC/1.0 Content-Type: text/plain;charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQB hAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAHI AaQ BmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANAA oA Content-Length: 2 Hi ---------- [Messenger B to Proxy] SIP/2.0 200 OK Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bK15c8f59bcda0cd8b4d357144186e027e.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bK9248414244a5bb33e17ab36fbe55da12.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 1 MESSAGE Record-Route: Record-Route: Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 ------ [Proxy to Messenger A] SIP/2.0 200 OK Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 1 MESSAGE Record-Route: , Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 ---- [Messenger A to Proxy] INFO sip:smkim320@206.xxx.xxx.203:5060 SIP/2.0 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967 From: "seonman" ;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 2 INFO Route: Route: Contact: User-Agent: Windows RTC/1.0 Content-Type: application/xml Content-Length: 96 ----- [Proxy to Message B] INFO sip:192.168.1.12:13085;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bK358edf072c6ede295aec9bd448769303.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bK179906ba2110173b588bb618634708c2.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 2 INFO Max-Forwards: 69 Contact: User-Agent: Windows RTC/1.0 Content-Type: application/xml Content-Length: 96 -------------------- [Messenger B to Proxy] SIP/2.0 200 OK Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bK358edf072c6ede295aec9bd448769303.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bK179906ba2110173b588bb618634708c2.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 2 INFO Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 -------------- [Proxy to Messenger A] SIP/2.0 200 OK Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 2 INFO Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 ----- [Messenger A to Proxy] MESSAGE sip:smkim320@206.xxx.xxx.203:5060 SIP/2.0 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967 From: "seonman" ;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 4 MESSAGE Route: Route: Contact: User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQ BhAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAH IAa QBmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANA AoA Content-Length: 4 Hi2. ---- [Proxy to Messenger B] MESSAGE sip:192.168.1.12:13085;transport=tcp SIP/2.0^M Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bKb7fede42ac653625717eadd49859075e.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bKd43a1aaa4b390cbf1e47f6f867ed6b10.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 4 MESSAGE Max-Forwards: 69 Contact: User-Agent: Windows RTC/1.0 Content-Type: text/plain;charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQB hAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAHI AaQ BmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANAA oA Content-Length: 4 Hi2. ---------- [Messenger B to Proxy] SIP/2.0 200 OK Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bKb7fede42ac653625717eadd49859075e.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bKd43a1aaa4b390cbf1e47f6f867ed6b10.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 4 MESSAGE Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 --------- [Proxy to Messenger A] SIP/2.0 200 OK Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 4 MESSAGE Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 ---- [Messenger A to Proxy] BYE sip:smkim320@206.xxx.xxx.203:5060 SIP/2.0 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967 From: "seonman" ;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 5 BYE Route: Route: Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 ---- [Proxy to Messenger B] BYE sip:192.168.1.12:13085;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bK731a0b999804a0b32c65648301642612.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bK45d61c916a23a7d209ce7d9f0148af6a.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 5 BYE Max-Forwards: 69 Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 ----- [Messenger B to Proxy] SIP/2.0 200 OK Via: SIP/2.0/TCP 206.xxx.xxx.203:5060;branch=z9hG4bK731a0b999804a0b32c6564830162612.4 Via: SIP/2.0/UDP 206.xxx.xxx.203:5060;branch=z9hG4bK45d61c916a23a7d209ce7d9f0148af6a.2 Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 5 BYE Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 ---- [Proxy to Messenger A] SIP/2.0 200 OK Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100 To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd From: "seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1 edb Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64 CSeq: 5 BYE Contact: User-Agent: Windows RTC/1.0 Content-Length: 0 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 4 20:21:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26714 for ; Fri, 4 Oct 2002 20:21:10 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g950LYsr022548; Fri, 4 Oct 2002 20:21:34 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23383; Fri, 4 Oct 2002 20:22:16 -0400 (EDT) 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 UAA23372 for ; Fri, 4 Oct 2002 20:21:30 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g950LNIm006744; Fri, 4 Oct 2002 17:21:23 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABB06256; Fri, 4 Oct 2002 17:19:18 -0700 (PDT) Subject: Re: [Simple] collection template Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Ben Campbell , Jonathan Rosenberg , simple@mailman.dynamicsoft.com To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64150@DYN-TX-EXCH-001.dynamicsoft.com> Message-Id: <95624906-D7F8-11D6-B998-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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, 4 Oct 2002 17:22:51 -0700 Content-Transfer-Encoding: 7bit I found this culling through half-finished replies.... On Monday, September 16, 2002, at 11:02 AM, Adam Roach wrote: >> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> >> If I susbscrbe to "collection" >> without an event scope, I now have to expect NOTIFY requests for >> arbitrary events. > > Unless the proposal is something of an overhaul of event processing > (which I advise against), your NOTIFY messages would be NOTIFY for > the event "collection" under Jonathan's proposal. > > I've got to admit, I share Ben and Sean's reservations about this > approach. I am likewise concerned by treating collections as a package. The multiple-event type especially bothers me. I'm with Adam and Sean. A collection template would clearly work and give us the semantics we need. The package approach is dancing on a slippery slope. As I add to this 2 weeks later I will compare this to the combined REGISTER/SUBSCRIBE discussion in SIP. The arguments for doing a package instead of a template are sort of vague and squishy. Let's please just do the template instead. It will work. thanks, -rohan > /a > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 9 16:14:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02856 for ; Wed, 9 Oct 2002 16:14:40 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g99KEMad010508; Wed, 9 Oct 2002 16:14:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10155; Wed, 9 Oct 2002 16:14:19 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10144 for ; Wed, 9 Oct 2002 16:13:08 -0400 (EDT) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g99KD9YH007873; Wed, 9 Oct 2002 16:13:09 -0400 (EDT) Message-ID: <3DA48DD4.6010904@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: Markus.Isomaki@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] The way forward in data manipulation work References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 09 Oct 2002 16:13:08 -0400 Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Hi, > > I think this would be a good time to see how to go forward with the > charter items related to data manipulation. > > I believe Jonathan is planning to update the Data Manipulation > Requirements draft focusing on two > issues: 1. List management, and 2. Authrozation policy management. In > Yokohama the concensus was to take this draft as basis for WG > requirements, so maybe the next version could be taken as a WG draft. Yes, that is the plan. > It is also a good proposal to limit that draft to purely > requirements, leaving the "model" in Chapter 4 out of scope. Maybe > then it would be easiear to agree on the draft. Agreed. > > However, some kind of model/framework draft (similar to what is being > done in conferencing) is also needed, and eventually it is essential > to agree on what protocols to use. Definitely. Requirements only make sense in the context of a framework. The data manipulations draft has some frameworks in there. I have turned it into a single framework, put up front, followed by a section for requirements on each of the two components (buddy list manipulation and authorization manipulation). I also added a terminology section. > My proposal is thus: 1. Use SOAP/WSDL for data manipulation. In the > first phase a definition is needed only for list and auth. policy > management, but the framework does not need to limit to this. 2. Use > SIP Events in a same fashion as "Message Waiting Indicator" draft to > convey notifications about state changes in the managed objects. A > collection package could be used for optimization purposes. This spec > could still leave the actual synchronization update mechanism open, > but I can imagine SyncML and others could potentially be usable > there. 3. Take SIP BIND as a default mechanism to make binding > between sip: URIs and SOAP http: URIs. I agree completely on points 1 and 2, although as others have pointed out, the scope of the document would not include making statements on the specific protocol. Rather, it should defined the requiremetns for the protocols. > I think we could have the first version of such framework draft could > be ready for the next IETF Atlanta meeting, and discussed there. Then > it could be updated and work on more specific drafts could start. In fact, I have just submitted an updated version of the requirements document, as a SIMPLE work item. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-simple-data-req-00.txt there is now much more details on authorization requirements, based on comments and suggestions made on the list. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 11 07:29:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16927 for ; Fri, 11 Oct 2002 07:29:58 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9BBUXad016359; Fri, 11 Oct 2002 07:30:33 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16906; Fri, 11 Oct 2002 07:31:18 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16895 for ; Fri, 11 Oct 2002 07:30:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16833; Fri, 11 Oct 2002 07:28:21 -0400 (EDT) Message-Id: <200210111128.HAA16833@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-data-req-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: Fri, 11 Oct 2002 07:28:21 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Manipulation of Data Elements in SIMPLE Systems Author(s) : J. Rosenberg, M. Isomaki Filename : draft-ietf-simple-data-req-00.txt Pages : 16 Date : 2002-10-10 In an instant messaging and presence application, it is frequently necessary for the user to configure a number of pieces of information. Users will need to manipulate their presentity list, adding and removing presentities, and manipulate their authorization lists, which specify the set of users that can subscribe to their presence. In this document, we provide a framework and requirements for such data manipulations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-data-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-data-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-10140905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-data-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-data-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-10140905.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 11 14:56: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 OAA02301 for ; Fri, 11 Oct 2002 14:56:44 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9BIvGad017902; Fri, 11 Oct 2002 14:57:16 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18339; Fri, 11 Oct 2002 14:58:03 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18328 for ; Fri, 11 Oct 2002 14:57:10 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9BIv41u033954 for ; Fri, 11 Oct 2002 20:57:08 +0200 Received: from d12ml013.de.ibm.com (d12ml013_cs0 [9.165.223.39]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9BIv3hW078586 for ; Fri, 11 Oct 2002 20:57:03 +0200 From: "Rainer R Janssen" To: "simple" Message-ID: X-MIMETrack: Serialize by Router on D12ML013/12/M/IBM(Release 5.0.9a |January 7, 2002) at 11/10/2002 20:57:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Rainer R Janssen/Germany/IBM is out of the office. 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 Oct 2002 20:57:02 +0200 I will be out of the office starting 11.10.2002 and will not return until 18.10.2002. In urgent cases you can reach me on my mobil +49.172.8377043 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 15 18:17:02 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17252 for ; Tue, 15 Oct 2002 18:17:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9FMHOrY007578; Tue, 15 Oct 2002 18:17:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06696; Tue, 15 Oct 2002 18:18:07 -0400 (EDT) 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 SAA06685 for ; Tue, 15 Oct 2002 18:17:43 -0400 (EDT) Received: from sbb.cs.columbia.edu (sbb.cs.columbia.edu [128.59.19.193]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FMHgm6001903 for ; Tue, 15 Oct 2002 18:17:43 -0400 (EDT) Received: from sbb.cs.columbia.edu (localhost [127.0.0.1]) by sbb.cs.columbia.edu (8.12.6/8.12.1) with ESMTP id g9FMHg9l017786; Tue, 15 Oct 2002 18:17:42 -0400 (EDT) Received: from localhost (kns10@localhost) by sbb.cs.columbia.edu (8.12.6/8.12.6/Submit) with ESMTP id g9FMHfnp017783; Tue, 15 Oct 2002 18:17:42 -0400 (EDT) X-Authentication-Warning: sbb.cs.columbia.edu: kns10 owned process doing -bs From: Kundan Singh To: cc: Xiaotao Wu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Simple] sip proxy/registrar as presence agent 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, 15 Oct 2002 18:17:41 -0400 (EDT) Hi I have a question on implementation of PA co-located with proxy/registrar server. If the server wants to support both the following kinds of scenarios: - acts as a presence agent that sends NOTIFY to subscriber (if approved) when user phone REGISTERs. This subscription can be managed (approved, rejected) from the web interface, for example. - allow end-points (colocated with presence agents) to REGISTER. This end-point acts as a presence agent and manages its own buddy list for IM and call. Suppose subscriber S, SUBSCRIBEs to the server P for target user, but the target user phone/endpoint is not yet REGISTERed. and the subscriber is not yet approved by the target user. P sends back "202 Pending". Now target user's phone/endpoint R (colocated with PA) REGISTERs with P. How can the server P inform the target endpoint R that the user S was/is interested in subscribing to R. (1) If the server P sends new SUBSCRIBE to R (like a UAC) then it can not do digest authentication because P may not know the password for user S. And R may not know how to authenticate P (not in buddy list). (2) S will refresh SUBSCRIBE after sometime, that will get proxied to R also, and it can work. But this will happen only once every one hour ("Expires:" header). (3) The target user will have different identifiers: bob@server for PA colocated with proxy, and bob@endpoint_address for PA colocated with endpoint. And S will have to SUBSCRIBE to both independently. What is the right approach so that R can know that S had sent SUBSCRIBE and then R can start sending NOTIFY to S. Thanks. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 16 00:45:14 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24974 for ; Wed, 16 Oct 2002 00:45:13 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9G4jVrY008691; Wed, 16 Oct 2002 00:45:32 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07881; Wed, 16 Oct 2002 00:46:05 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07870 for ; Wed, 16 Oct 2002 00:45:36 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9G4jIYH011417; Wed, 16 Oct 2002 00:45:21 -0400 (EDT) Message-ID: <3DACEEDD.1090709@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: Kundan Singh CC: simple@mailman.dynamicsoft.com, Xiaotao Wu Subject: Re: [Simple] sip proxy/registrar as presence agent References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 16 Oct 2002 00:45:17 -0400 Content-Transfer-Encoding: 7bit The right solution is for the server to terminate the subscription, with a specific reason that informs the client that it should re-subscribe. In particular, the Subscription-State header in the NOTIFY would look like: NOTIFY sip:subscriber@example.com SIP/2.0 Subscription-State: terminated;reason=deactivated the client would genreate a brand new SUBSCRIBE (not on the same dialog), which the server can then proxy. -Jonathan R. Kundan Singh wrote: > Hi > > I have a question on implementation of PA co-located with proxy/registrar > server. > > If the server wants to support both the following kinds of scenarios: > - acts as a presence agent that sends NOTIFY to subscriber (if approved) > when user phone REGISTERs. This subscription can be managed (approved, > rejected) from the web interface, for example. > - allow end-points (colocated with presence agents) to REGISTER. This > end-point acts as a presence agent and manages its own buddy list for IM > and call. > > Suppose subscriber S, SUBSCRIBEs to the server P for target user, > but the target user phone/endpoint is not yet REGISTERed. > and the subscriber is not yet approved by the target user. > P sends back "202 Pending". > > Now target user's phone/endpoint R (colocated with PA) REGISTERs with P. > How can the server P inform the target endpoint R that the user S was/is > interested in subscribing to R. > (1) If the server P sends new SUBSCRIBE to R (like a UAC) then it can not > do digest authentication because P may not know the password for user S. > And R may not know how to authenticate P (not in buddy list). > (2) S will refresh SUBSCRIBE after sometime, that will get proxied to R > also, and it can work. But this will happen only once every one hour > ("Expires:" header). > (3) The target user will have different identifiers: bob@server for > PA colocated with proxy, and bob@endpoint_address for PA colocated with > endpoint. And S will have to SUBSCRIBE to both independently. > > What is the right approach so that R can know that S had sent SUBSCRIBE > and then R can start sending NOTIFY to S. > > Thanks. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Oct 17 10:18:44 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 KAA12327 for ; Thu, 17 Oct 2002 10:18:44 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9HEJJrY014623; Thu, 17 Oct 2002 10:19:19 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13837; Thu, 17 Oct 2002 10:20:05 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13824 for ; Thu, 17 Oct 2002 10:19:26 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9HEJZFh007491 for ; Thu, 17 Oct 2002 10:19:36 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAS95775; Thu, 17 Oct 2002 10:24:16 -0400 (EDT) Message-ID: <3DAEC6ED.DD57CEA0@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simple Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Requirements for SIP Capabilities in PIDF 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, 17 Oct 2002 10:19:25 -0400 Content-Transfer-Encoding: 7bit The following draft is now available on the server. Several of us believe that when using presence with sip in general (as opposed to using it solely for IM), more information is required for the presence client to operate effectively. This is a start at defining requirements for what added information is required and how it should relate to other sip usage. I believe this is the proper wg in which to discuss this. Thanks, Paul -------- Original Message -------- Subject: I-D ACTION:draft-kyzivat-simple-prescaps-reqts-00.txt Date: Thu, 17 Oct 2002 07:33:26 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for SIP Capabilities in PIDF Author(s) : P. Kyzivat Filename : draft-kyzivat-simple-prescaps-reqts-00.txt Pages : 7 Date : 2002-10-16 This document sets forth requirements for the definition of elements for representation of SIP specific features within the Presence Information Data Format (PIDF), as well as for guidelines on how to use these new elements with PIDF to represent the capabilities of a SIP User Agent Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kyzivat-simple-prescaps-reqts-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-kyzivat-simple-prescaps-reqts-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-kyzivat-simple-prescaps-reqts-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. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Oct 17 12:17:40 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16213 for ; Thu, 17 Oct 2002 12:17:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9HGIJrY015292; Thu, 17 Oct 2002 12:18:19 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14247; Thu, 17 Oct 2002 12:19:05 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14236 for ; Thu, 17 Oct 2002 12:18:09 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9HGI9H12470 for ; Thu, 17 Oct 2002 19:18:09 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 19:18:06 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 19:18:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] The way forward in data manipulation work - list manipulation Message-ID: Thread-Topic: [Simple] The way forward in data manipulation work Thread-Index: AcJwUEImQy0sjX+ES1KlVovfQwoBDgFpPO1w To: Cc: X-OriginalArrivalTime: 17 Oct 2002 16:18:05.0732 (UTC) FILETIME=[C6324E40:01C275F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA14236 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, 17 Oct 2002 19:18:05 +0300 Content-Transfer-Encoding: 8bit Hi, I think one of the main questions about the data manipulation requirements is how to deal with lists. The choises made at this point may have a surprising impact on the usability aspects, as explained below. In practice I think there are two scenarios: 1. Each application instance has its own dedicated list(s). For example presence lists and chat conference access lists are always separate entities in their respective servers. 2. It is possible to share the same list stored somewhere in the "network" (i.e. represented by some URI) by multiple applications. If the list is changed, it is reflected in each application that the list is currently bound to. These options don't change much the requirements for the list manipulation protocol. As seen in the current requirements draft, the list manipulation reqs for presence collection and presence authorization are basically identical. From user's point of view there is a major difference. It would be nice to be able to use the same list for multiple purposes. In that case it would be better to have the list stored only once, so that there would be only one list to manipulate. The biggest obstacle I see in this kind of generic list model is the application-specific URI schemes, in practice pres: and im:. If im: URI is added to some list and the user then wants to bind that list to a presence collection, there is a miss-match. On the other hand, lists comprising only sip: URIs would be usable accross different SIP services. I understand that some of this discusion is implementation related. I guess what I'm trying to say that I'd like the final solution be such that the general list concept would not be excluded. As technical requirement that should be quite easy to formulate, i.e. some form of indirection/binding between lists and SIP URIs is needed. If this is agreeable, I can propose some text to the draft. Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 09 October, 2002 23:13 > To: Isomaki Markus (NRC/Helsinki) > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] The way forward in data manipulation work > > > inline. > > Markus.Isomaki@nokia.com wrote: > > Hi, > > > > I think this would be a good time to see how to go > forward with the > > charter items related to data manipulation. > > > > I believe Jonathan is planning to update the Data Manipulation > > Requirements draft > focusing on two > > issues: 1. List management, and 2. Authrozation policy > management. In > > Yokohama the concensus was to take this draft as basis for WG > > requirements, so maybe the next version could be taken as > a WG draft. > > Yes, that is the plan. > > > It is also a good proposal to limit that draft to purely > > requirements, leaving the "model" in Chapter 4 out of scope. Maybe > > then it would be easiear to agree on the draft. > > Agreed. > > > > > However, some kind of model/framework draft (similar to > what is being > > done in conferencing) is also needed, and eventually it > is essential > > to agree on what protocols to use. > > Definitely. Requirements only make sense in the context of a > framework. > The data manipulations draft has some frameworks in there. I > have turned > it into a single framework, put up front, followed by a section for > requirements on each of the two components (buddy list > manipulation and > authorization manipulation). I also added a terminology section. > > > My proposal is thus: 1. Use SOAP/WSDL for data > manipulation. In the > > first phase a definition is needed only for list and auth. policy > > management, but the framework does not need to limit to > this. 2. Use > > SIP Events in a same fashion as "Message Waiting > Indicator" draft to > > convey notifications about state changes in the managed objects. A > > collection package could be used for optimization > purposes. This spec > > could still leave the actual synchronization update > mechanism open, > > but I can imagine SyncML and others could potentially be usable > > there. 3. Take SIP BIND as a default mechanism to make binding > > between sip: URIs and SOAP http: URIs. > > I agree completely on points 1 and 2, although as others have pointed > out, the scope of the document would not include making statements on > the specific protocol. Rather, it should defined the requiremetns for > the protocols. > > > > I think we could have the first version of such framework > draft could > > be ready for the next IETF Atlanta meeting, and discussed > there. Then > > it could be updated and work on more specific drafts could start. > > In fact, I have just submitted an updated version of the requirements > document, as a SIMPLE work item. Until it appears in the > archives, you > can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-simple-data-req-00.txt > > there is now much more details on authorization requirements, > based on > comments and suggestions made on the list. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 21 16:37:46 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14595 for ; Mon, 21 Oct 2002 16:37:46 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9LKcIL5002856; Mon, 21 Oct 2002 16:38:18 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02366; Mon, 21 Oct 2002 16:39:04 -0400 (EDT) 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 OAA14566 for ; Thu, 17 Oct 2002 14:09:48 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9HI9Mm7027750; Thu, 17 Oct 2002 14:09:37 -0400 (EDT) From: Xiaotao Wu To: cc: Kundan Singh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Simple] What if a PUA crashed, but the registration of the PUA still valid 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, 17 Oct 2002 14:09:22 -0400 (EDT) Hi, For a Presence Server (PA colocated with proxy), if the PUA which the Presence Server proxys the SUBSCRIBE to crashed, but the registration of the PUA is still valid (since PUA crashed, the PUA did not unregister itself), for an incoming SUBSCRIBE, what's the status should be in the notification from the Presence Server? PUA (a) Presence Server PUA (b) | | | | +<-- REGISTER ----+ | | | +--- SUBSCRIBE->+ | | | | | +---- SUBSCRIBE --> | | | | +<---- 200 OK ----+ | | | +<-- 200 OK ----+ | | | \ | / | | \|/ | | X CRASH!!! | (subscription | /|\ | expired) | / | \ | | | +-- SUBSCRIBE ->+ | | | | | +--- SUBSCRIBE -->+ | | | | | | | | (timeout) | | | | | | | | | | | 202??? | | +<--- ??? ------+ | | 200??? | | -Xiaotao _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 21 23:37: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 XAA23258 for ; Mon, 21 Oct 2002 23:37:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9M3cBL5004084; Mon, 21 Oct 2002 23:38:11 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03679; Mon, 21 Oct 2002 23:39:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03668 for ; Mon, 21 Oct 2002 23:38:20 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9M3cFYH015419; Mon, 21 Oct 2002 23:38:16 -0400 (EDT) Message-ID: <3DB4C826.7040603@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: Xiaotao Wu CC: simple@mailman.dynamicsoft.com, Kundan Singh Subject: Re: [Simple] What if a PUA crashed, but the registration of the PUA still valid References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 21 Oct 2002 23:38:14 -0400 Content-Transfer-Encoding: 7bit inline. Xiaotao Wu wrote: > Hi, > > For a Presence Server (PA colocated with proxy), if the PUA which the > Presence Server proxys the SUBSCRIBE to crashed, but the registration of > the PUA is still valid (since PUA crashed, the PUA did not unregister > itself), for an incoming SUBSCRIBE, what's the status should be in the > notification from the Presence Server? There is no notification. The SUBSCRIBE refresh from the client will result in a 408 from the presence server (this is normal proxy behavior). That, based on 3261, will cause the client to terminate the dialog. So, if it still wants the subscription, it has to subscribe with a brand new request. This reaches the presence server, which can now accept the subscription, migrating it from the PUA back to the server. -Jonathan R. > > PUA (a) Presence Server PUA (b) > > | | | > | +<-- REGISTER ----+ > | | | > +--- SUBSCRIBE->+ | > | | | > | +---- SUBSCRIBE --> > | | | > | +<---- 200 OK ----+ > | | | > +<-- 200 OK ----+ | > | | \ | / > | | \|/ > | | X CRASH!!! > | (subscription | /|\ > | expired) | / | \ > | | | > +-- SUBSCRIBE ->+ | > | | | > | +--- SUBSCRIBE -->+ > | | | > | | | > | | (timeout) | > | | | > | | | > | | | > | 202??? | | > +<--- ??? ------+ | > | 200??? | | > > > -Xiaotao > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Oct 24 02:12:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27514 for ; Thu, 24 Oct 2002 02:12:02 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9O6CIL5012622; Thu, 24 Oct 2002 02:12:18 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12312; Thu, 24 Oct 2002 02:13:04 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12299 for ; Thu, 24 Oct 2002 02:12:04 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9O6C2KV005003; Thu, 24 Oct 2002 08:12:02 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Oct 2002 08:12:02 +0200 Message-ID: From: "Vesa Torvinen (LMF)" To: "'Markus.Isomaki@nokia.com'" , jdrosen@dynamicsoft.com Cc: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Comment on draft-ietf-simple-data-req-00 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 24 Oct 2002 08:11:59 +0200 Hi, I have been wondering if the presence authorization policy should include a fourth piece (in addition to acceptance, notification and content policies), i.e. the security policy. As an end-user, I could imagine setting an authorizatin policy saying that the confidentiality of all notifications should be protected, for example. The other filterin criteria, notification frequencies and the contents of notifications could still be valid, however, the notification would not be delivered to the watcher if encryption was not available. I can also imagine a scenario in which my Presence Agent has no trust relationship with a particular watcher, and can not authenticate the watcher. In this case, I as an end-user might be willing to set this trust relationship, e.g. by defining a subscription specific HTTP Digest password for that watcher, and by distributing the password to the watcher using some other communication channel (e.g. phone or face-to-face contact). Maybe the security policy could look something like this: --------- Security Policy: The component of presence authorization policy that determines the minimum security requirements for subscriptions and notifications. --------- Security Policy Requirements REQ 1: It MUST be possible for the user to determine the minimum security functions to be used with subscriptions and notifications. REQ 2: It SHOULD be possible for the user to bind the watcher authorization to a particular authentication function and credential. ----------- But maybe you have already discussed this issue and decided something else? (Checked the mail archive but did not find anything...) Vesa _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Oct 24 06:33:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01378 for ; Thu, 24 Oct 2002 06:33:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9OAYBL5013249; Thu, 24 Oct 2002 06:34:11 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13096; Thu, 24 Oct 2002 06:35:04 -0400 (EDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13083 for ; Thu, 24 Oct 2002 06:34:24 -0400 (EDT) From: gobbo.max@libero.it Received: from libero.it (193.70.192.42) by smtp2.libero.it (6.5.028) id 3DA310EF0028050C for simple@mailman.dynamicsoft.com; Thu, 24 Oct 2002 12:34:23 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 To: "=?iso-8859-1?Q?simple?=" X-XaM3-API-Version: 3.2 R24 (B46) X-type: 0 X-SenderIP: 193.205.164.87 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA13083 Subject: [Simple] =?iso-8859-1?Q?Question?= Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 24 Oct 2002 12:34:23 +0200 Content-Transfer-Encoding: 8bit Hi, I'm an Italian student working on the SCTP. I would try to work on this argument: -Instant messaging on SCTP. Is there someone who is working on this arguments? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Oct 24 20:35:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28280 for ; Thu, 24 Oct 2002 20:35:27 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9P0aCL5016510; Thu, 24 Oct 2002 20:36:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15549; Thu, 24 Oct 2002 20:37:03 -0400 (EDT) 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 UAA15538 for ; Thu, 24 Oct 2002 20:36:54 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9P0agPP019762; Thu, 24 Oct 2002 17:36:42 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABE87674; Thu, 24 Oct 2002 17:34:12 -0700 (PDT) Subject: Re: [Simple] Comment on draft-ietf-simple-data-req-00 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Markus.Isomaki@nokia.com'" , jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com To: "Vesa Torvinen (LMF)" From: Rohan Mahy In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 Oct 2002 17:37:07 -0700 Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 11:11 PM, Vesa Torvinen (LMF) wrote: > Hi, > > I have been wondering if the presence authorization policy > should include a fourth piece (in addition to acceptance, > notification and content policies), i.e. the security policy. > As an end-user, I could imagine setting an authorizatin > policy saying that the confidentiality of all notifications > should be protected, for example. The other filterin criteria, > notification frequencies and the contents of notifications > could still be valid, however, the notification would not be > delivered to the watcher if encryption was not available. > > I can also imagine a scenario in which my Presence Agent has > no trust relationship with a particular watcher, and can not > authenticate the watcher. In this case, I as an end-user might > be willing to set this trust relationship, e.g. by defining a > subscription specific HTTP Digest password for that watcher, > and by distributing the password to the watcher using some > other communication channel (e.g. phone or face-to-face > contact). self-signed cert? thx, -r > Maybe the security policy could look something like this: > > --------- > > Security Policy: The component of presence authorization policy > that determines the minimum security requirements for subscriptions > and notifications. > > --------- > > Security Policy Requirements > > REQ 1: It MUST be possible for the user to determine the minimum > security functions to be used with subscriptions and notifications. > > REQ 2: It SHOULD be possible for the user to bind the watcher > authorization to a particular authentication function and credential. > > ----------- > > But maybe you have already discussed this issue and decided > something else? (Checked the mail archive but did not find > anything...) > > Vesa > _______________________________________________ > 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 Fri Oct 25 03:24:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14782 for ; Fri, 25 Oct 2002 03:24:37 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9P7PGL5017404; Fri, 25 Oct 2002 03:25:17 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16787; Fri, 25 Oct 2002 03:26:04 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16776 for ; Fri, 25 Oct 2002 03:25:05 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.60]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9P7P5YH017970; Fri, 25 Oct 2002 03:25:06 -0400 (EDT) Message-ID: <3DB8F1D0.7050906@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: gobbo.max@libero.it CC: simple Subject: Re: [Simple] Question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 25 Oct 2002 03:25:04 -0400 Content-Transfer-Encoding: 7bit None of the current proposals use SCTP for IM. However, I happen to think its a good idea. Since SCTP is message oriented, it provides framing for you, which is good for IM, especially when used with persistent connections. You could also send each IM on a separate stream, avoiding HOL blocking of a small IM behind a large one. -Jonathan R. gobbo.max@libero.it wrote: > Hi, > I'm an Italian student working on the SCTP. > I would try to work on this argument: > -Instant messaging on SCTP. > Is there someone who is working on this arguments? > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 25 03:41:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14927 for ; Fri, 25 Oct 2002 03:41:21 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9P7g9L5017496; Fri, 25 Oct 2002 03:42:09 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16869; Fri, 25 Oct 2002 03:43:03 -0400 (EDT) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16858 for ; Fri, 25 Oct 2002 03:42:49 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.60]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9P7glYH017977; Fri, 25 Oct 2002 03:42:48 -0400 (EDT) Message-ID: <3DB8F5F6.3010309@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: "Vesa Torvinen (LMF)" CC: "'Markus.Isomaki@nokia.com'" , simple@mailman.dynamicsoft.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Comment on draft-ietf-simple-data-req-00 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 25 Oct 2002 03:42:46 -0400 Content-Transfer-Encoding: 7bit I think that this is generally a good idea. Some comments below. Vesa Torvinen (LMF) wrote: > Hi, > > I have been wondering if the presence authorization policy > should include a fourth piece (in addition to acceptance, > notification and content policies), i.e. the security policy. > As an end-user, I could imagine setting an authorizatin > policy saying that the confidentiality of all notifications > should be protected, for example. The other filterin criteria, > notification frequencies and the contents of notifications > could still be valid, however, the notification would not be > delivered to the watcher if encryption was not available. I agree with this requirement, but think its really two additional requirements in the existing categories. What you are saying is that there is an acceptance policy that says "dont accept unless I can encrypt towards this used", and a content policy which says that the notifications are to be encrypted. Now, determining that you can encrypt notifications towards a subscriber is a bit hard. I see a few ways: * the SUBSCRIBE was received using sips * the SUBSCRIBE was authenticated using S/MIME, and included a cert for the subscriber * a cert for the subscriber exists in the presence server Similarly, encrypting notifications can occur with sips or with smime. > > I can also imagine a scenario in which my Presence Agent has > no trust relationship with a particular watcher, and can not > authenticate the watcher. In this case, I as an end-user might > be willing to set this trust relationship, e.g. by defining a > subscription specific HTTP Digest password for that watcher, > and by distributing the password to the watcher using some > other communication channel (e.g. phone or face-to-face > contact). Thats possible, although its better if you act as your own CA and hand these folks certifications. Much more secure. > > Maybe the security policy could look something like this: > > --------- > > Security Policy: The component of presence authorization policy > that determines the minimum security requirements for subscriptions > and notifications. As I propose above, I think there are security aspects to the existing components, and I would rather distribute your requirements to those. > > --------- > > Security Policy Requirements > > REQ 1: It MUST be possible for the user to determine the minimum > security functions to be used with subscriptions and notifications. I would state as: * it MUST be possible for a user to specify that a subscription should not be accepted unless the subscriber is authenticated with a specific mechanism (smime, digest, etc.) * it MUST be possible for a user to specify that a subscription should not be accepted unless the notifications to that subscriber can be encrypted * it must be possible for a user to specify that a notification should be encrypted Now, whether you want to use this protocol to upload digest shared secrets, for example, I am not sure... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 25 05:22:28 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 FAA16664 for ; Fri, 25 Oct 2002 05:22:28 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9P9NCL5017769; Fri, 25 Oct 2002 05:23:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17176; Fri, 25 Oct 2002 05:24:03 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17165 for ; Fri, 25 Oct 2002 05:23:57 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9P9NqQ2017604; Fri, 25 Oct 2002 11:23:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 25 Oct 2002 11:23:52 +0200 Message-ID: From: "Vesa Torvinen (LMF)" To: "'Jonathan Rosenberg'" Cc: "'Markus.Isomaki@nokia.com'" , simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Comment on draft-ietf-simple-data-req-00 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 25 Oct 2002 11:23:44 +0200 Jonathan, In general, I like your version of requirements. Some further comments (with 3GPP'ish hat on): 1) About the digest passwords: There are system architectures in which it is not very likely that Watcher and Presence Server will have direct trust relationship. It is not very likely either that S/MIME is available. My opinion is, that in this kind of context, the procedure for letting the presentity to upload digest passwords would be efficient and cheap solution. I am not sure if this issue is a general requirement for this protocol... or even if this is a good idea at all. I would love to hear more opinions about it! 2) About the encryption: Again, there are architectures which may follow some kind of 'transitive trust model', and in which S/MIME or SIPS are not necessarily available. Still, the trust model assumes that it can guarantee confidentiality if requested. In practice, this can be done using IPsec security gateways within the network, and IPsec over the more vulnerable part of the network (i.e. the air interface). In other words, there might be other ways (in addition to sips or certificates) to know that confidentiality can be guaranteed. I would talk about 'confidentiality' instead of 'encryption' in the requirements. Vesa -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 25. lokakuuta 2002 10:43 To: Vesa Torvinen (LMF) Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com Subject: Re: Comment on draft-ietf-simple-data-req-00 I think that this is generally a good idea. Some comments below. Vesa Torvinen (LMF) wrote: > Hi, > > I have been wondering if the presence authorization policy > should include a fourth piece (in addition to acceptance, > notification and content policies), i.e. the security policy. > As an end-user, I could imagine setting an authorizatin > policy saying that the confidentiality of all notifications > should be protected, for example. The other filterin criteria, > notification frequencies and the contents of notifications > could still be valid, however, the notification would not be > delivered to the watcher if encryption was not available. I agree with this requirement, but think its really two additional requirements in the existing categories. What you are saying is that there is an acceptance policy that says "dont accept unless I can encrypt towards this used", and a content policy which says that the notifications are to be encrypted. Now, determining that you can encrypt notifications towards a subscriber is a bit hard. I see a few ways: * the SUBSCRIBE was received using sips * the SUBSCRIBE was authenticated using S/MIME, and included a cert for the subscriber * a cert for the subscriber exists in the presence server Similarly, encrypting notifications can occur with sips or with smime. > > I can also imagine a scenario in which my Presence Agent has > no trust relationship with a particular watcher, and can not > authenticate the watcher. In this case, I as an end-user might > be willing to set this trust relationship, e.g. by defining a > subscription specific HTTP Digest password for that watcher, > and by distributing the password to the watcher using some > other communication channel (e.g. phone or face-to-face > contact). Thats possible, although its better if you act as your own CA and hand these folks certifications. Much more secure. > > Maybe the security policy could look something like this: > > --------- > > Security Policy: The component of presence authorization policy > that determines the minimum security requirements for subscriptions > and notifications. As I propose above, I think there are security aspects to the existing components, and I would rather distribute your requirements to those. > > --------- > > Security Policy Requirements > > REQ 1: It MUST be possible for the user to determine the minimum > security functions to be used with subscriptions and notifications. I would state as: * it MUST be possible for a user to specify that a subscription should not be accepted unless the subscriber is authenticated with a specific mechanism (smime, digest, etc.) * it MUST be possible for a user to specify that a subscription should not be accepted unless the notifications to that subscriber can be encrypted * it must be possible for a user to specify that a notification should be encrypted Now, whether you want to use this protocol to upload digest shared secrets, for example, I am not sure... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 25 07:29:26 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 HAA20340 for ; Fri, 25 Oct 2002 07:29:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9PBUAL5018069; Fri, 25 Oct 2002 07:30:10 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17553; Fri, 25 Oct 2002 07:31:04 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17542 for ; Fri, 25 Oct 2002 07:30:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20076; Fri, 25 Oct 2002 07:28:29 -0400 (EDT) Message-Id: <200210251128.HAA20076@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-niemi-simple-im-wireless-reqs-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: Fri, 25 Oct 2002 07:28:28 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Instant Messaging in 3GPP Wireless Systems Author(s) : A. Niemi Filename : draft-niemi-simple-im-wireless-reqs-00.txt Pages : 9 Date : 2002-10-24 This document lists the requirements specific to 3GPP wireless Instant Messaging systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-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-niemi-simple-im-wireless-reqs-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-niemi-simple-im-wireless-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-24142231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-simple-im-wireless-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142231.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 25 10:30:28 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 KAA26328 for ; Fri, 25 Oct 2002 10:30:28 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9PEV8L5018759; Fri, 25 Oct 2002 10:31:09 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18092; Fri, 25 Oct 2002 10:32:03 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18081 for ; Fri, 25 Oct 2002 10:31:41 -0400 (EDT) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9PEVfo0003160; Fri, 25 Oct 2002 10:31:41 -0400 (EDT) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-91.cisco.com [161.44.87.91]) by cia.cisco.com (Mirapoint) with ESMTP id ABG97559; Fri, 25 Oct 2002 10:21:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20021025102623.00b3def0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vesa Torvinen (LMF)" From: Michael Hammer Subject: Re: [Simple] RE: Comment on draft-ietf-simple-data-req-00 Cc: "'Jonathan Rosenberg'" , "'Markus.Isomaki@nokia.com'" , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 25 Oct 2002 10:31:25 -0400 Inline. At 11:23 AM 10/25/2002 +0200, Vesa Torvinen (LMF) wrote: >Jonathan, > >In general, I like your version of requirements. Some further comments >(with 3GPP'ish hat on): > >1) About the digest passwords: > >There are system architectures in which it is not very likely that Watcher >and Presence Server will have direct trust relationship. It is not very >likely either that S/MIME is available. My opinion is, that in this kind >of context, the procedure for letting the presentity to upload digest >passwords would be efficient and cheap solution. By solution, do you mean to say that this will establish a chain of trust between the two? Is the goal here to assure that notifications are integrity or confidentiality protected, or is there any intent to be assured that you really know to whom notifications are being sent? MH >I am not sure if this issue is a general requirement for this protocol... >or even if this is a good idea at all. I would love to hear more opinions >about it! > >2) About the encryption: > >Again, there are architectures which may follow some kind of 'transitive >trust model', and in which S/MIME or SIPS are not necessarily available. >Still, the trust model assumes that it can guarantee confidentiality if >requested. In practice, this can be done using IPsec security gateways >within the network, and IPsec over the more vulnerable part of the network >(i.e. the air interface). In other words, there might be other ways (in >addition to sips or certificates) to know that confidentiality can be >guaranteed. > >I would talk about 'confidentiality' instead of 'encryption' in the >requirements. > >Vesa > >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 25. lokakuuta 2002 10:43 >To: Vesa Torvinen (LMF) >Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com >Subject: Re: Comment on draft-ietf-simple-data-req-00 > > >I think that this is generally a good idea. Some comments below. > > >Vesa Torvinen (LMF) wrote: > > Hi, > > > > I have been wondering if the presence authorization policy > > should include a fourth piece (in addition to acceptance, > > notification and content policies), i.e. the security policy. > > As an end-user, I could imagine setting an authorizatin > > policy saying that the confidentiality of all notifications > > should be protected, for example. The other filterin criteria, > > notification frequencies and the contents of notifications > > could still be valid, however, the notification would not be > > delivered to the watcher if encryption was not available. > >I agree with this requirement, but think its really two additional >requirements in the existing categories. What you are saying is that >there is an acceptance policy that says "dont accept unless I can >encrypt towards this used", and a content policy which says that the >notifications are to be encrypted. > >Now, determining that you can encrypt notifications towards a subscriber >is a bit hard. I see a few ways: > > * the SUBSCRIBE was received using sips > * the SUBSCRIBE was authenticated using S/MIME, and included a cert >for the subscriber > * a cert for the subscriber exists in the presence server > >Similarly, encrypting notifications can occur with sips or with smime. > > > > > I can also imagine a scenario in which my Presence Agent has > > no trust relationship with a particular watcher, and can not > > authenticate the watcher. In this case, I as an end-user might > > be willing to set this trust relationship, e.g. by defining a > > subscription specific HTTP Digest password for that watcher, > > and by distributing the password to the watcher using some > > other communication channel (e.g. phone or face-to-face > > contact). > >Thats possible, although its better if you act as your own CA and hand >these folks certifications. Much more secure. > > > > > > Maybe the security policy could look something like this: > > > > --------- > > > > Security Policy: The component of presence authorization policy > > that determines the minimum security requirements for subscriptions > > and notifications. > >As I propose above, I think there are security aspects to the existing >components, and I would rather distribute your requirements to those. > > > > > --------- > > > > Security Policy Requirements > > > > REQ 1: It MUST be possible for the user to determine the minimum > > security functions to be used with subscriptions and notifications. > >I would state as: > >* it MUST be possible for a user to specify that a subscription should >not be accepted unless the subscriber is authenticated with a specific >mechanism (smime, digest, etc.) > >* it MUST be possible for a user to specify that a subscription should >not be accepted unless the notifications to that subscriber can be encrypted > >* it must be possible for a user to specify that a notification should >be encrypted > > >Now, whether you want to use this protocol to upload digest shared >secrets, for example, I am not sure... > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 25 10:49:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26934 for ; Fri, 25 Oct 2002 10:49:23 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9PEo7L5018889; Fri, 25 Oct 2002 10:50:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18177; Fri, 25 Oct 2002 10:51:03 -0400 (EDT) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17390 for ; Fri, 25 Oct 2002 06:36:10 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g9PAa9U07349 for ; Fri, 25 Oct 2002 12:36:09 +0200 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g9PAa82T005772 for ; Fri, 25 Oct 2002 12:36:08 +0200 (MET DST) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 12:36:51 +0200 Message-ID: From: Brazier Lachlan To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C12.6B068480" Subject: [Simple] Accept header Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 25 Oct 2002 12:36:46 +0200 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27C12.6B068480 Content-Type: text/plain; charset="iso-8859-1" Hello, sorry if this question was awnsered before. I have a question concerning the Accept header. RFC3261 states: 20.1 Accept The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value of application/sdp. An empty Accept header field means that no formats are acceptable. whereas RFC2616 (HTTP1.1) states in chapter "14.1 Accept" ....If no Accept header field is present, then it is assumed that the client accepts all media types. ...... Here I asume that RFC3261 counts concerning the Accept header. Is this correct? What's the difference between "no Accept header field" and "empty Accept header field" ? Which behaviour is defined in SIMPLE, as draft-ietf-simple-presence-07.txt says, that ...All subscribers MUST support the "application/cpim-pidf+xml" presence data format described in [5]..... Does this mean, that even when the Accept header field is empty, the Subscriber MUST support the media type "application/cpim-pidf+xml"? Actually I believe, a PA should send an error response containing an Accept header field with "application/cpim-pidf+xml". Is this correct? Thanks Lachlan Brazier ------_=_NextPart_001_01C27C12.6B068480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+QWNjZXB0 IGhlYWRlcjwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPkhlbGxv LDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+c29ycnkgaWYgdGhpcyBxdWVzdGlvbiB3YXMgYXdu c2VyZWQgYmVmb3JlLiBJIGhhdmUgYSBxdWVzdGlvbiBjb25jZXJuaW5nIHRoZSBBY2NlcHQgaGVh ZGVyLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlJGQzMyNjEgc3RhdGVzOjwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPjIwLjEgQWNjZXB0PC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IFRoZSBBY2NlcHQgaGVhZGVyIGZpZWxkIGZvbGxv d3MgdGhlIHN5bnRheCBkZWZpbmVkIGluIFtIMTQuMV0uJm5ic3A7IFRoZTwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IHNlbWFudGljcyBhcmUgYWxzbyBpZGVudGljYWwsIHdp dGggdGhlIGV4Y2VwdGlvbiB0aGF0IGlmIG5vIEFjY2VwdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jm5ic3A7Jm5ic3A7IGhlYWRlciBmaWVsZCBpcyBwcmVzZW50LCB0aGUgc2VydmVyIFNIT1VM RCBhc3N1bWUgYSBkZWZhdWx0IHZhbHVlIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJz cDsmbmJzcDsgYXBwbGljYXRpb24vc2RwLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PiZuYnNwOyZuYnNwOyBBbiBlbXB0eSBBY2NlcHQgaGVhZGVyIGZpZWxkIG1lYW5zIHRoYXQgbm8g Zm9ybWF0cyBhcmUgYWNjZXB0YWJsZS48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJ WkU9Mj53aGVyZWFzIFJGQzI2MTYgKEhUVFAxLjEpIHN0YXRlcyBpbiBjaGFwdGVyICZxdW90OzE0 LjEgQWNjZXB0JnF1b3Q7PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Li4uLklmIG5v IEFjY2VwdCBoZWFkZXIgZmllbGQgaXMgcHJlc2VudCwgdGhlbiBpdCBpcyBhc3N1bWVkIHRoYXQg dGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgY2xpZW50IGFjY2VwdHMg YWxsIG1lZGlhIHR5cGVzLiAuLi4uLi48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJ WkU9Mj5IZXJlIEkgYXN1bWUgdGhhdCBSRkMzMjYxIGNvdW50cyBjb25jZXJuaW5nIHRoZSBBY2Nl cHQgaGVhZGVyLiBJcyB0aGlzIGNvcnJlY3Q/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5XaGF0 J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAmcXVvdDtubyBBY2NlcHQgaGVhZGVyIGZpZWxkJnF1 b3Q7IGFuZCAmcXVvdDtlbXB0eSBBY2NlcHQgaGVhZGVyIGZpZWxkJnF1b3Q7ID88L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5XaGljaCBiZWhhdmlvdXIgaXMgZGVmaW5lZCBpbiBTSU1Q TEUsIGFzIGRyYWZ0LWlldGYtc2ltcGxlLXByZXNlbmNlLTA3LnR4dCBzYXlzLCB0aGF0PC9GT05U Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Li4uQWxsIHN1YnNjcmliZXJzIE1VU1Qgc3VwcG9y dCB0aGUgJnF1b3Q7YXBwbGljYXRpb24vY3BpbS1waWRmK3htbCZxdW90OyBwcmVzZW5jZSBkYXRh IGZvcm1hdCBkZXNjcmliZWQgaW4gWzVdLi4uLi48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9Mj5Eb2VzIHRoaXMgbWVhbiwgdGhhdCBldmVuIHdoZW4gdGhlIEFjY2VwdCBoZWFkZXIgZmll bGQgaXMgZW1wdHksIHRoZSBTdWJzY3JpYmVyIE1VU1Qgc3VwcG9ydCB0aGUgbWVkaWEgdHlwZSAm cXVvdDthcHBsaWNhdGlvbi9jcGltLXBpZGYreG1sJnF1b3Q7PzwvRk9OVD48L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5BY3R1YWxseSBJIGJlbGlldmUsIGEgUEEgc2hvdWxkIHNlbmQgYW4gZXJyb3Ig cmVzcG9uc2UgY29udGFpbmluZyBhbiBBY2NlcHQgaGVhZGVyIGZpZWxkIHdpdGggJnF1b3Q7YXBw bGljYXRpb24vY3BpbS1waWRmK3htbCZxdW90Oy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpF PTI+SXMgdGhpcyBjb3JyZWN0PzwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0y PlRoYW5rczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+TGFjaGxhbiBCcmF6aWVyPC9GT05UPg0K PC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C27C12.6B068480-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 25 18:03:28 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 SAA13476 for ; Fri, 25 Oct 2002 18:03:27 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9PM4DL5020685; Fri, 25 Oct 2002 18:04:13 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19541; Fri, 25 Oct 2002 18:05:05 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19528 for ; Fri, 25 Oct 2002 18:04:35 -0400 (EDT) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9PM3gFu027771 for ; Fri, 25 Oct 2002 18:03:43 -0400 (EDT) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 17:04:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642A6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 25 Oct 2002 17:04:22 -0500 [Sliding in under the wire for the -00 deadline] An i-d describing a template event package for collections has been submitted to the drafts editor. Until a copy appears in the archives, you can download a copy from: http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.txt HTML version also available: http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.htm l This work is still rather rough around the edges, but I think it gives a good starting point for discussion. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Oct 27 22:11: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 WAA14712 for ; Sun, 27 Oct 2002 22:11: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 g9S3CGL5024511; Sun, 27 Oct 2002 22:12:17 -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 WAA28230; Sun, 27 Oct 2002 22:13:07 -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 WAA28219 for ; Sun, 27 Oct 2002 22:12:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9S3BuYH019238; Sun, 27 Oct 2002 22:11:56 -0500 (EST) Message-ID: <3DBCAAFA.6070806@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft 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: Brazier Lachlan CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Accept header References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 27 Oct 2002 22:11:54 -0500 Content-Transfer-Encoding: 7bit Brazier Lachlan wrote: > Hello, > sorry if this question was awnsered before. I have a question concerning > the Accept header. > > RFC3261 states: > > 20.1 Accept > > The Accept header field follows the syntax defined in [H14.1]. The > semantics are also identical, with the exception that if no Accept > header field is present, the server SHOULD assume a default value of > application/sdp. > > An empty Accept header field means that no formats are acceptable. > > > whereas RFC2616 (HTTP1.1) states in chapter "14.1 Accept" > > ....If no Accept header field is present, then it is assumed that the > client accepts all media types. ...... > > > Here I asume that RFC3261 counts concerning the Accept header. Yes. Is this > correct? > What's the difference between "no Accept header field" and "empty Accept > header field" ? Empty means it looks like: SUBSCRIBE sip:presentity@domain.com SIP/2.0 Accept: From: sip:subscriber@domain.com ...... this means, "I don't support ANY document formats". no accept field looks like: SUBSCRIBE sip:presentity@domain.com SIP/2.0 From: sip:subscriber@domain.com which means, "The accept header has a default value". > > Which behaviour is defined in SIMPLE, as > draft-ietf-simple-presence-07.txt says, that > > ...All subscribers MUST support the "application/cpim-pidf+xml" presence > data format described in [5]..... Now, this brings an interesting point. Since the default accept header field value is SDP, as bis says, it would seem that a subscriber has to include application/cpim-pidf+xml in an Accept header in every subscriber request. That needs to be corrected in the presence doc. > > Does this mean, that even when the Accept header field is empty, the > Subscriber MUST support the media type "application/cpim-pidf+xml"? An empty Accept header field in a SUBSCRIBE would be illegal, in violation of the presence spec, since it means you don't support pidf. > > Actually I believe, a PA should send an error response containing an > Accept header field with "application/cpim-pidf+xml". yup. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 28 04:55:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01857 for ; Mon, 28 Oct 2002 04:55:51 -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 g9S9u0su000362; Mon, 28 Oct 2002 04:56:01 -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 EAA00325; Mon, 28 Oct 2002 04:51:00 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00298 for ; Mon, 28 Oct 2002 04:47:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9S9l6Q2028308; Mon, 28 Oct 2002 10:47:06 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 10:47:06 +0100 Message-ID: From: "Vesa Torvinen (LMF)" To: "'Michael Hammer'" Cc: "'Jonathan Rosenberg'" , "'Markus.Isomaki@nokia.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] RE: Comment on draft-ietf-simple-data-req-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 10:46:59 +0100 Michael, You seem to ask me how Digest is useful in this context. I am thinking a model in which the authentication would take place with subscriptions. Integrity protection would probably be required to do this securely. If you can re-use the authenticated & integrity protected "security tunnel" (e.g. TLS) with notifications, you are quite safe in assuming that they are sent to the intended recipient. Right? If you have to initiate security every time you send notification, you may still trust on some SIP headers that were authenticated & protected during subscription (e.g. Contact). However, Digest would not server the Presence Server to know that the recipient is the correct one. Instead, Digest could be used by the Watcher to know that the messages really originate from an entity that knows the same passwords that was used during subscription. The confidentiality part is a different story and not really related to Digest. The presentity may have an interest to require confidentiality protection for all notifications. But maybe you were concerned on the semantics of these 'security policies' to the end-user? That the end-user would assume better security than it actually is? Vesa -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: 25. lokakuuta 2002 17:31 To: Vesa Torvinen (LMF) Cc: 'Jonathan Rosenberg'; 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com Subject: Re: [Simple] RE: Comment on draft-ietf-simple-data-req-00 Inline. At 11:23 AM 10/25/2002 +0200, Vesa Torvinen (LMF) wrote: >Jonathan, > >In general, I like your version of requirements. Some further comments >(with 3GPP'ish hat on): > >1) About the digest passwords: > >There are system architectures in which it is not very likely that Watcher >and Presence Server will have direct trust relationship. It is not very >likely either that S/MIME is available. My opinion is, that in this kind >of context, the procedure for letting the presentity to upload digest >passwords would be efficient and cheap solution. By solution, do you mean to say that this will establish a chain of trust between the two? Is the goal here to assure that notifications are integrity or confidentiality protected, or is there any intent to be assured that you really know to whom notifications are being sent? MH >I am not sure if this issue is a general requirement for this protocol... >or even if this is a good idea at all. I would love to hear more opinions >about it! > >2) About the encryption: > >Again, there are architectures which may follow some kind of 'transitive >trust model', and in which S/MIME or SIPS are not necessarily available. >Still, the trust model assumes that it can guarantee confidentiality if >requested. In practice, this can be done using IPsec security gateways >within the network, and IPsec over the more vulnerable part of the network >(i.e. the air interface). In other words, there might be other ways (in >addition to sips or certificates) to know that confidentiality can be >guaranteed. > >I would talk about 'confidentiality' instead of 'encryption' in the >requirements. > >Vesa > >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: 25. lokakuuta 2002 10:43 >To: Vesa Torvinen (LMF) >Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com >Subject: Re: Comment on draft-ietf-simple-data-req-00 > > >I think that this is generally a good idea. Some comments below. > > >Vesa Torvinen (LMF) wrote: > > Hi, > > > > I have been wondering if the presence authorization policy > > should include a fourth piece (in addition to acceptance, > > notification and content policies), i.e. the security policy. > > As an end-user, I could imagine setting an authorizatin > > policy saying that the confidentiality of all notifications > > should be protected, for example. The other filterin criteria, > > notification frequencies and the contents of notifications > > could still be valid, however, the notification would not be > > delivered to the watcher if encryption was not available. > >I agree with this requirement, but think its really two additional >requirements in the existing categories. What you are saying is that >there is an acceptance policy that says "dont accept unless I can >encrypt towards this used", and a content policy which says that the >notifications are to be encrypted. > >Now, determining that you can encrypt notifications towards a subscriber >is a bit hard. I see a few ways: > > * the SUBSCRIBE was received using sips > * the SUBSCRIBE was authenticated using S/MIME, and included a cert >for the subscriber > * a cert for the subscriber exists in the presence server > >Similarly, encrypting notifications can occur with sips or with smime. > > > > > I can also imagine a scenario in which my Presence Agent has > > no trust relationship with a particular watcher, and can not > > authenticate the watcher. In this case, I as an end-user might > > be willing to set this trust relationship, e.g. by defining a > > subscription specific HTTP Digest password for that watcher, > > and by distributing the password to the watcher using some > > other communication channel (e.g. phone or face-to-face > > contact). > >Thats possible, although its better if you act as your own CA and hand >these folks certifications. Much more secure. > > > > > > Maybe the security policy could look something like this: > > > > --------- > > > > Security Policy: The component of presence authorization policy > > that determines the minimum security requirements for subscriptions > > and notifications. > >As I propose above, I think there are security aspects to the existing >components, and I would rather distribute your requirements to those. > > > > > --------- > > > > Security Policy Requirements > > > > REQ 1: It MUST be possible for the user to determine the minimum > > security functions to be used with subscriptions and notifications. > >I would state as: > >* it MUST be possible for a user to specify that a subscription should >not be accepted unless the subscriber is authenticated with a specific >mechanism (smime, digest, etc.) > >* it MUST be possible for a user to specify that a subscription should >not be accepted unless the notifications to that subscriber can be encrypted > >* it must be possible for a user to specify that a notification should >be encrypted > > >Now, whether you want to use this protocol to upload digest shared >secrets, for example, I am not sure... > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 28 11:12:55 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 LAA16381 for ; Mon, 28 Oct 2002 11:12:54 -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 g9SGDasu001504; Mon, 28 Oct 2002 11:13:36 -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 LAA01357; Mon, 28 Oct 2002 11:09:39 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01344 for ; Mon, 28 Oct 2002 11:07:19 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SG7Ii2029660 for ; Mon, 28 Oct 2002 11:07:19 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAT67537; Mon, 28 Oct 2002 11:11:57 -0500 (EST) Message-ID: <3DBD60A8.B4A616F5@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simple References: <200210281127.GAA03058@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-olson-simple-publish-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 11:07:04 -0500 Content-Transfer-Encoding: 7bit I question the need for the Stream header. Its use seems entirely analogous to the use of a common Callid header in REGISTER requests. Why is it necessary to introduce a new header for PUBLISH when it wasn't necessary for REGISTER? Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 28 11:35:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17643 for ; Mon, 28 Oct 2002 11:35:35 -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 g9SGaOsu001693; Mon, 28 Oct 2002 11:36:24 -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 LAA01449; Mon, 28 Oct 2002 11:37:08 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01396 for ; Mon, 28 Oct 2002 11:22:45 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SGMaPe001938; Mon, 28 Oct 2002 11:22:37 -0500 (EST) Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-91.cisco.com [161.44.87.91]) by cia.cisco.com (Mirapoint) with ESMTP id ABH11651; Mon, 28 Oct 2002 11:12:08 -0500 (EST) Message-Id: <4.3.2.7.2.20021028110517.03f19450@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vesa Torvinen (LMF)" From: Michael Hammer Subject: RE: [Simple] RE: Comment on draft-ietf-simple-data-req-00 Cc: "'Jonathan Rosenberg'" , "'Markus.Isomaki@nokia.com'" , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 11:22:17 -0500 Content-Transfer-Encoding: quoted-printable Vesa,

Just doing a "reality check."  From your 3rd paragraph below, this seems to sum up what is really being "authenticated":

You "know that the messages really originate from an
entity that knows the same passwords that was used during
subscription."

Most of the schemes I have seen thus far seem to provide little true authentication of the identity asserted, unless this involves some infrastructure and security policies that provide some confidence that such identities correspond with the real world, i.e. could support a contract in a court of law.  Not that this is always necessary.  Just wanted to be precise about what is actually occurring.

Mike Hammer



At 10:46 AM 10/28/2002 +0100, Vesa Torvinen (LMF) wrote:
Michael,

You seem to ask me how Digest is useful in this context.

I am thinking a model in which the authentication would take
place with subscriptions. Integrity protection would probably
be required to do this securely. If you can re-use the
authenticated & integrity protected "security tunnel" (e.g. TLS)
with notifications, you are quite safe in assuming that they
are sent to the intended recipient. Right?

If you have to initiate security every time you send
notification, you may still trust on some SIP headers that
were authenticated & protected during subscription (e.g. Contact).
However, Digest would not server the Presence Server to know that
the recipient is the correct one. Instead, Digest could be used by
the Watcher to know that the messages really originate from an
entity that knows the same passwords that was used during
subscription.

The confidentiality part is a different story and not really
related to Digest. The presentity may have an interest to require
confidentiality protection for all notifications.

But maybe you were concerned on the semantics of these 'security
policies' to the end-user? That the end-user would assume better
security than it actually is?

Vesa

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: 25. lokakuuta 2002 17:31
To: Vesa Torvinen (LMF)
Cc: 'Jonathan Rosenberg'; 'Markus.Isomaki@nokia.com';
simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: Comment on draft-ietf-simple-data-req-00


Inline.

At 11:23 AM 10/25/2002 +0200, Vesa Torvinen (LMF) wrote:
>Jonathan,
>
>In general, I like your version of requirements. Some further comments
>(with 3GPP'ish hat on):
>
>1) About the digest passwords:
>
>There are system architectures in which it is not very likely that Watcher
>and Presence Server will have direct trust relationship. It is not very
>likely either that S/MIME is available. My opinion is, that in this kind
>of context, the procedure for letting the presentity to upload digest
>passwords would be efficient and cheap solution.

By solution, do you mean to say that this will establish a chain of trust
between the two?  Is the goal here to assure that notifications are
integrity or confidentiality protected, or is there any intent to be
assured that you really know to whom notifications are being sent?

MH


>I am not sure if this issue is a general requirement for this protocol...
>or even if this is a good idea at all. I would love to hear more opinions
>about it!
>
>2) About the encryption:
>
>Again, there are architectures which may follow some kind of 'transitive
>trust model', and in which S/MIME or SIPS are not necessarily available.
>Still, the trust model assumes that it can guarantee confidentiality if
>requested. In practice, this can be done using IPsec security gateways
>within the network, and IPsec over the more vulnerable part of the network
>(i.e. the air interface). In other words, there might be other ways (in
>addition to sips or certificates) to know that confidentiality can be
>guaranteed.
>
>I would talk about 'confidentiality' instead of 'encryption' in the
>requirements.
>
>Vesa
>
>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>Sent: 25. lokakuuta 2002 10:43
>To: Vesa Torvinen (LMF)
>Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com
>Subject: Re: Comment on draft-ietf-simple-data-req-00
>
>
>I think that this is generally a good idea. Some comments=20 below.
>
>
>Vesa Torvinen (LMF) wrote:
> > Hi,
> >
> > I have been wondering if the presence authorization=20 policy
> > should include a fourth piece (in addition to acceptance,
> > notification and content policies), i.e. the security policy.
> > As an end-user, I could imagine setting an authorizatin
> > policy saying that the confidentiality of all notifications
> > should be protected, for example. The other filterin criteria,
> > notification frequencies and the contents of=20 notifications
> > could still be valid, however, the notification would not be
> > delivered to the watcher if encryption was not available.
>
>I agree with this requirement, but think its really two additional
>requirements in the existing categories. What you are saying is that
>there is an acceptance policy that says "dont accept unless I can
>encrypt towards this used", and a content policy which says that the
>notifications are to be encrypted.
>
>Now, determining that you can encrypt notifications towards a subscriber
>is a bit hard. I see a few ways:
>
>    * the SUBSCRIBE was received using sips
>    * the SUBSCRIBE was authenticated using S/MIME, and included a cert
>for the subscriber
>    * a cert for the subscriber exists in the presence server
>
>Similarly, encrypting notifications can occur with sips or with smime.
>
> >
> > I can also imagine a scenario in which my Presence Agent has
> > no trust relationship with a particular watcher, and can not
> > authenticate the watcher. In this case, I as an end-user might
> > be willing to set this trust relationship, e.g. by defining a
> > subscription specific HTTP Digest password for that watcher,
> > and by distributing the password to the watcher using=20 some
> > other communication channel (e.g. phone or face-to-face
> > contact).
>
>Thats possible, although its better if you act as your own CA and hand
>these folks certifications. Much more secure.
>
>
> >
> > Maybe the security policy could look something like this:
> >
> > ---------
> >
> > Security Policy: The component of presence authorization policy
> > that determines the minimum security requirements for subscriptions
> > and notifications.
>
>As I propose above, I think there are security aspects to the existing
>components, and I would rather distribute your requirements to those.
>
> >
> > ---------
> >
> > Security Policy Requirements
> >
> > REQ 1: It MUST be possible for the user to determine the minimum
> > security functions to be used with subscriptions and notifications.
>
>I would state as:
>
>* it MUST be possible for a user to specify that a subscription should
>not be accepted unless the subscriber is authenticated with a specific
>mechanism (smime, digest, etc.)
>
>* it MUST be possible for a user to specify that a subscription should
>not be accepted unless the notifications to that subscriber can be encrypted
>
>* it must be possible for a user to specify that a notification should
>be encrypted
>
>
>Now, whether you want to use this protocol to upload digest shared
>secrets, for example, I am not sure...
>
>-Jonathan R.
>
>--
>Jonathan D. Rosenberg, Ph.D.            = ;    72 Eagle Rock Ave.
>Chief Scientist           &= nbsp;            = ;     First Floor
>dynamicsoft          &= nbsp;            = ;          East Hanover, NJ 07936
>jdrosen@dynamicsoft.com        &= nbsp;            FAX:   (973) 952-5050
>http://www.jdrosen.net &n= bsp;            =        PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
_______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 28 11:59:20 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18740 for ; Mon, 28 Oct 2002 11:59:20 -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 g9SH09su001895; Mon, 28 Oct 2002 12:00:09 -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 MAA01603; Mon, 28 Oct 2002 12:01:04 -0500 (EST) Received: from web20709.mail.yahoo.com (web20709.mail.yahoo.com [216.136.226.182]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA01581 for ; Mon, 28 Oct 2002 12:00:24 -0500 (EST) Message-ID: <20021028170024.84188.qmail@web20709.mail.yahoo.com> Received: from [207.46.137.250] by web20709.mail.yahoo.com via HTTP; Mon, 28 Oct 2002 09:00:24 PST From: Sean Olson Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt To: Paul Kyzivat , Simple In-Reply-To: <3DBD60A8.B4A616F5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 09:00:24 -0800 (PST) The analogy breaks down in situations that need more persistence of the stream identifier. If Call-ID where to persist across all requests, across reboots, and potentially across devices, then it would be a perfect fit :) It may be that we find a better way to accomplish this. The "Stream" header is a first shot at satisfying the need for a compositor to identify the source of a publication. Thanks, Sean Olson Microsoft --- Paul Kyzivat wrote: > I question the need for the Stream header. Its use > seems entirely analogous to the use of a common > Callid header in REGISTER requests. Why is it > necessary to introduce a new header for PUBLISH when > it wasn't necessary for REGISTER? > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 28 14:19:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25487 for ; Mon, 28 Oct 2002 14:19:02 -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 g9SJIFsu002492; Mon, 28 Oct 2002 14:18:16 -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 OAA01993; Mon, 28 Oct 2002 14:19:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01977 for ; Mon, 28 Oct 2002 14:18:44 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SJIggM012426; Mon, 28 Oct 2002 11:18:42 -0800 (PST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAT69642; Mon, 28 Oct 2002 14:22:22 -0500 (EST) Message-ID: <3DBD8D49.AABAE379@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: Simple Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt References: <20021028170024.84188.qmail@web20709.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 14:17:29 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > The analogy breaks down in situations that need > more persistence of the stream identifier. If Call-ID > where to persist across all requests, across reboots, > and potentially across devices, then it would be a > perfect fit :) Hmm. If that analogy doesn't hold then it would be helpful to have a more complete description of the semantics of a stream. I guess the discussion of section 1.1.4 Publisher Instance is intended to provide this. But it doesn't line up especially well with the definition of Stream in 3.3. Section 3.3 focuses on providing a context within which to process messages in order, while 1.1.4 focuses on distinct publishing instances. From your comments, you suggest that a distinct instance might not always reside on the same device. Once you say that, the possibility arises that you might have two physical devices simultaneously claiming to have the same logical identity. And that messes up the suggested means of ordering messages within a stream. Actually, even moving a stream from one device to another might cause ordering to be messed up if there is significant clock skew. Based on the available descriptions, I don't yet understand what I might want to use this feature for. You authors obviously have something in mind that motivates the exact options you have selected. Maybe a more specific example would help. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Oct 28 14:42:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26363 for ; Mon, 28 Oct 2002 14:42:21 -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 g9SJh9su002653; Mon, 28 Oct 2002 14:43:09 -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 OAA02117; Mon, 28 Oct 2002 14:44:03 -0500 (EST) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02106 for ; Mon, 28 Oct 2002 14:43:29 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9SJgbpR003517; Mon, 28 Oct 2002 14:42:37 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Oct 2002 13:43:29 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642B2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'George Foti (LMC)'" , Adam Roach , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 13:43:28 -0600 > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > is it correct > to assume that either of the following is correct: > > a) The RLS will send *individual* SUBSCRIBE to all members of > all sub-lists > included in the main resource list created by the user when > he SUBSCRIBEs to > that list. That would be valid. Of course, the RLS has to know the membership of all of the sublists to do so. > b) The RLS can do procedure (a) for 1 or more sub-lists (in > the original > list) but can also send a SUBSCRIBE to another RLS for some > sub-lists (in > the original list). The later RLS can be responsbile for > maintaining some > lists, and in turn will implement procedure (a). That would also be valid. The only revision I would make to your assertion is: "can do procedure (a) for _zero_ or more sublists..." Finally, the RLS might have complete information about all of the states involved, in which case it would generate *no* subscribes to any other node at all. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 01:42:28 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 BAA12995 for ; Tue, 29 Oct 2002 01:42:28 -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 g9T6hCsu004432; Tue, 29 Oct 2002 01:43:13 -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 BAA04118; Tue, 29 Oct 2002 01:44:04 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04107 for ; Tue, 29 Oct 2002 01:43:28 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9T6hjB06287 for ; Tue, 29 Oct 2002 08:43:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Oct 2002 08:43:27 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 08:43:27 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C27F16.7BD29B35" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD01@esebe004.ntc.nokia.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Thread-Index: AcJ+eRDfLWn0kqBcTMCacCs21pA+EwAnNK3w To: X-OriginalArrivalTime: 29 Oct 2002 06:43:27.0236 (UTC) FILETIME=[7C5E5440:01C27F16] Subject: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-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: Tue, 29 Oct 2002 08:43:26 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C27F16.7BD29B35 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, New draft is now available. Basically draft presents a solution for the = requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.=20 All comments are welcome. - Mikko > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 28 October, 2002 13:27 > Subject: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : SIMPLE PIDF presence capabilities extension > Author(s) : M. Lonnfors, K. Kiss > Filename : draft-lonnfors-simple-prescaps-ext-00.txt > Pages : 14 > Date : 2002-10-25 > =09 > Interoperation of Instant Messaging and Presence systems has been > defined in IMPP Working Group. IMPP WG has come up with baseline > interoperable operations and formats for Presence and Instant > Messaging systems. However, these base formats might need > standardized extensions in order to enable building rational > applications using Presence and Instant Messaging. This memo > proposes an extension to PIDF presence document format to be used in > SIMPLE based Presence systems [1] but may also be applied to other > protocols as well. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres caps-ext-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-lonnfors-simple-prescaps-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-lonnfors-simple-prescaps-ext-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C27F16.7BD29B35 Content-Type: application/octet-stream; name="ATT48751.TXT" Content-Description: ATT48751.TXT Content-Disposition: attachment; filename="ATT48751.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTEwLTI1MTEyNTI3LkktREBpZXRmLm9yZz4NCg0K RU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvbm5mb3JzLXNpbXBs ZS1wcmVzY2Fwcy1leHQtMDAudHh0DQo= ------_=_NextPart_001_01C27F16.7BD29B35 Content-Type: application/octet-stream; name="draft-lonnfors-simple-prescaps-ext-00.URL" Content-Description: draft-lonnfors-simple-prescaps-ext-00.URL Content-Disposition: attachment; filename="draft-lonnfors-simple-prescaps-ext-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1sb25uZm9ycy1zaW1wbGUtcHJlc2NhcHMtZXh0LTAwLnR4dA0K ------_=_NextPart_001_01C27F16.7BD29B35-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 03:10:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24530 for ; Tue, 29 Oct 2002 03:10: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 g9T8B9su004688; Tue, 29 Oct 2002 03:11:09 -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 DAA04449; Tue, 29 Oct 2002 03:12:03 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04438 for ; Tue, 29 Oct 2002 03:11:51 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9T8C8B18273 for ; Tue, 29 Oct 2002 10:12:08 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Oct 2002 10:11:50 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 10:11:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD02@esebe004.ntc.nokia.com> Thread-Topic: Comment to draft-olson-simple-publish-01.txt Thread-Index: AcJ/ItSFNOFThJd3TZGWj22LKYTYqQ== To: X-OriginalArrivalTime: 29 Oct 2002 08:11:49.0726 (UTC) FILETIME=[D4E617E0:01C27F22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA04438 Subject: [Simple] Comment to draft-olson-simple-publish-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 10:11:49 +0200 Content-Transfer-Encoding: 8bit Hi, Thanks for the new version. Here are some concerns/comments: - Sections 1.1.5 and 3.4: Facet header I am bit confused how this is indented to work. If each PUA always publishes full state then how is it really possible to use facet header to indicate to which watcher instances published information is targeted to? As it is currently defined one PUA could only publish all its information to one or multiple facets i.e. it is not possible to give some part of that info so some facets and some other parts to other facet. In current case it is all or nothing. I would see that better approach would be to include this kind of information into published content and to authorization rules but not to publish protocol itself. Also it is completely unspecified what should happen if PA does not support the requested facet. Should it report an error or should there be some default behavior. Building interoperable system in my mind requires that these procedures are defined. - Document does not specify any error handling mechanism for publish. I think there can be cases where either PA or compositor does not for some reason understand what PUA has published or that compositor for some reason cannot add published data into some existing data. Without any error reporting mechanism is might very hard for PUAs to know what went wrong and what PUA could do to correct its actions. - Section 1.1.3 and examples Document states that it is possible to associate Class to tuple-ids. This is also used in examples. As draft-ietf-impp-cpim-pidf-05.txt currently stands this is not allowed. I don't know if this is going to change in future versions of PIDF but at a moment associating any semantics to tuple-ids is forbidden. Best Regards - Mikko _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 05:21:24 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26796 for ; Tue, 29 Oct 2002 05:21: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 g9TAM9su005021; Tue, 29 Oct 2002 05:22:09 -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 FAA04871; Tue, 29 Oct 2002 05:23:03 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04860 for ; Tue, 29 Oct 2002 05:22:34 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TAMqB19927 for ; Tue, 29 Oct 2002 12:22:52 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Oct 2002 12:22:35 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 12:22:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194504F@esebe013.ntc.nokia.com> Thread-Topic: A omment to draft-olson-simple-publish-01 Thread-Index: AcJ/NRipidRp8W5eRkaRzKbK9qZ2Bw== To: X-OriginalArrivalTime: 29 Oct 2002 10:22:34.0925 (UTC) FILETIME=[190075D0:01C27F35] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA04860 Subject: [Simple] A omment to draft-olson-simple-publish-01 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 Oct 2002 12:22:34 +0200 Content-Transfer-Encoding: 8bit Hi, Thanks for the much improved -01. One comment though: Although the draft says that 489 (Bad Event) should be sent in case the composer doesn't understand the published event state, there is no mention of Allow-Events used in that case. Allow-Events is mandatory in 489 according to RFC 3265. If it is also mandatory for 489 to a PUBLISH, it would seem logical that it is also (optionally) used with OPTIONS (for one). Would then Allow-Events in a 2xx to OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both? Why not a new pair of headers, which share the event-type (for packages) namespace with Event/Allow-Events, something like what's described in http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-00.txt AFAIK, we are not running out of space with header names ;) Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 06:19: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 GAA28164 for ; Tue, 29 Oct 2002 06:19:25 -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 g9TBKBsu005168; Tue, 29 Oct 2002 06:20:11 -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 GAA05046; Tue, 29 Oct 2002 06:21:04 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05029 for ; Tue, 29 Oct 2002 06:20:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27754; Tue, 29 Oct 2002 06:17:42 -0500 (EST) Message-Id: <200210291117.GAA27754@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-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: Tue, 29 Oct 2002 06:17:42 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Instant Message Sessions in SIMPLE Author(s) : B. Campbell, J. Rosenberg Filename : draft-campbell-simple-im-sessions-00.txt Pages : 11 Date : 2002-10-28 The SIP MESSAGE method is used to send instant messages, where each message is independent of any other message. This is often called pager-mode messaging, due to the fact that this model is similar to that of most two-way pager devices. Another model is called session- mode. In session-mode, the instant messages are part of a media session that provides ordering, a security context, and other functions. This media session is established using a SIP INVITE, just as an audio or video session would be established. This document describes a method of initiating and managing message sessions using SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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-campbell-simple-im-sessions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-28163248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-campbell-simple-im-sessions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-campbell-simple-im-sessions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28163248.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 06:19:54 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28366 for ; Tue, 29 Oct 2002 06:19:54 -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 g9TBKYsu005185; Tue, 29 Oct 2002 06:20:34 -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 GAA05062; Tue, 29 Oct 2002 06:21:30 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05035 for ; Tue, 29 Oct 2002 06:20:08 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27770; Tue, 29 Oct 2002 06:17:47 -0500 (EST) Message-Id: <200210291117.GAA27770@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-campbell-simple-cpimmsg-sessions-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: Tue, 29 Oct 2002 06:17:47 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Instant Message Transport Sessions using the CPIM Message Format Author(s) : B. Campbell et al. Filename : draft-campbell-simple-cpimmsg-sessions-00.txt Pages : 12 Date : 2002-10-28 Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. Each message can be sent independently using the SIP MESSAGE method, or messages can be associated into sessions that are initiated using SIP. The first approach is often referred to as pager-mode messaging, due to its similarity to the behavior of two way pager devices. The second approach is often called session-mode messaging, or simply message sessions. This document describes a message session mechanism based on the Common Presence and Instant Messaging message format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-campbell-simple-cpimmsg-sessions-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-campbell-simple-cpimmsg-sessions-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-campbell-simple-cpimmsg-sessions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-28163257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-campbell-simple-cpimmsg-sessions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-campbell-simple-cpimmsg-sessions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28163257.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 10:04:26 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 KAA07515 for ; Tue, 29 Oct 2002 10:04:26 -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 g9TF58su006097; Tue, 29 Oct 2002 10:05:09 -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 KAA05688; Tue, 29 Oct 2002 10:06:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05677 for ; Tue, 29 Oct 2002 10:05:58 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9TF6CQt010998 for ; Tue, 29 Oct 2002 10:06:12 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAT75090; Tue, 29 Oct 2002 10:10:49 -0500 (EST) Message-ID: <3DBEA3D4.A0FBA6FB@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD01@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 10:05:56 -0500 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > > Hi, > > New draft is now available. Basically draft presents a solution for the requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt. > All comments are welcome. Obviously Mikko and I have been cooperating on this. We were both interested in the subject. I thought it would be helpful to be clear about the requirements rather than jumping directly to a proposed solution, so I posted a requirements draft last week. Since then I have been waiting for Mikko to submit this in order to have more fodder for discussion. There is already a work item to produce a SIP-specific profile for PIDF. I consider these drafts to be a *partial* response to that work item. I realize there is a desire for some addition generalized status values beyond open/closed, such as busy. That is a minefield, and we have chosen not to address it. Instead, we are focusing on some attributes that should be less controversial because they are drawn from the callerprefs draft, whose basic concepts have been accepted for a long time. (I am open to discussion about whether these specific drafts should be expanded to cover the more general requirement, or whether that should be left separate.) The assertion of these drafts is that capabilities a UAS can specify when registering are information that is equally important in a presence document. I believe Mikko is most concerned with supported media. I also consider that to be of major importance, but I also believe all the others are of potential value in a presence document. The callerprefs draft is still itself in a state of flux. The work here should remain dependent on the outcome of that work. But I believe it would be helpful to begin progressing these documents now. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 11:08:23 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10956 for ; Tue, 29 Oct 2002 11:08:22 -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 g9TG9Asu006499; Tue, 29 Oct 2002 11:09:10 -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 LAA05942; Tue, 29 Oct 2002 11:10:04 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05929 for ; Tue, 29 Oct 2002 11:09:01 -0500 (EST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g9TG91106880 for ; Tue, 29 Oct 2002 10:09:01 -0600 From: Robert Sparks To: simple@mailman.dynamicsoft.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Message-Id: <1035907512.1691.35.camel@RjS.localdomain> Mime-Version: 1.0 Subject: [Simple] IETF55 Agenda 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: 29 Oct 2002 10:05:12 -0600 Content-Transfer-Encoding: 7bit Please send me requests for agenda time at the Atlanta SIMPLE meeting. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 13:07:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16997 for ; Tue, 29 Oct 2002 13:07:37 -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 g9TI8Lsu007156; Tue, 29 Oct 2002 13:08:22 -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 NAA06422; Tue, 29 Oct 2002 13:09:07 -0500 (EST) Received: from flash.Vancouver.com ([209.53.210.16]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06411 for ; Tue, 29 Oct 2002 13:08:37 -0500 (EST) Received: from thunder.Vancouver.com ([192.168.200.99]) by flash.Vancouver.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 10:12:51 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0FD1B48D522C08408A3CFD737CD35B5512037A@thunder.vancouver.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Presence & SRV - Problem solved? Thread-Index: AcJ/dig+yxzJ7+40Sp6jeR1ytZbRgQ== From: "Ryan Chapman" To: X-OriginalArrivalTime: 29 Oct 2002 18:12:51.0680 (UTC) FILETIME=[CB7F9600:01C27F76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA06411 Subject: [Simple] Presence & SRV - Problem solved? 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 Oct 2002 10:12:51 -0800 Content-Transfer-Encoding: 8bit Hello all, I'm writing a SIMPLE-based presence infrastructure, but I'm having some difficulty determining exactly how to deal with a presence URI (e.g., pres:somebody@somewhere.com). In the CPIM draft, we are told to query _im._sip.example.com for im:fred@example.com, and then that the "choice of IM transfer protocol is a local configuration option for each system." Given this, which SRV RR should my SIP layer query? If I translate my presence URI to a SIP URI as specified (somewhere!) in the mailing archive by simply replacing "pres" with "sip", then what good was my first SRV lookup? In other words, my SIP layer would simply lookup _sip._udp.example.com, ignoring whatever results my previous query returned. One way that I can see to solve this problem is to use the first lookup as a mechanism for determining the domain name associated with the URI. In other words, pres:somebody@somewhere.com would generate a lookup for _pres._sip.somewhere.com, which would give me an RR for the presence service. Using this result, I would generate a SIP URI that would look something like sip:somebody@sippresenceserver.somewhere.com. At this point, the SIP layer would query _sip._udp.sippresenceserver.somewhere.com, yielding the desired results. My primary goal is to have my presence server be decoupled from our proxy/registrar, so the presence URI should send the message to a different location than a normal SIP URI would. Thanks in advance, Ryan Chapman _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 16:20:33 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 QAA25932 for ; Tue, 29 Oct 2002 16:20:32 -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 g9TLIEsu008057; Tue, 29 Oct 2002 16:18:14 -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 QAA06961; Tue, 29 Oct 2002 16:19:04 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06950 for ; Tue, 29 Oct 2002 16:18:52 -0500 (EST) Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g9TLIr107922 for ; Tue, 29 Oct 2002 15:18:53 -0600 Message-ID: <3DBEFB35.1040908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Message Session IDs 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 Oct 2002 15:18:45 -0600 Content-Transfer-Encoding: 7bit You have probably noticed 2 new IDs on message sessions that hit the repository this morning. These drafts, while listing a small number of authors, are actually the result of a great deal of discussion among several people, including myself, Jonathan, Rohan, Jon, Robert, Dean, Brian, and Allison. (Please do not take this to mean that every person listed necessarily agree with every point in the drafts ;-) ) draft-campbell-simple-im-sessions-00 discusses the use of the SDP offer/answer model for initiating message sessions, without talking much about the message sessions themselves. draft-campbell-simple-cpimmsg-sessions-00 proposes a message session transport that involves transporting messages over TCP or TLS using the message/cpim format. This draft depends on the signaling methods described in the im-sessions draft. Neither of these drafts are complete, but we hope they can generate some discussion prior to the Atlanta meeting. Thanks! Ben. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 16:35: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 QAA26537 for ; Tue, 29 Oct 2002 16:35:42 -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 g9TLZGsu008176; Tue, 29 Oct 2002 16:35:16 -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 QAA07031; Tue, 29 Oct 2002 16:36:05 -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 QAA07020 for ; Tue, 29 Oct 2002 16:35:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9TLZxYH021051; Tue, 29 Oct 2002 16:36:00 -0500 (EST) Message-ID: <3DBEFF3C.3090006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 16:35:56 -0500 Content-Transfer-Encoding: 7bit let me add some more to what Ben has said here. Ben Campbell wrote: > You have probably noticed 2 new IDs on message sessions that hit the > repository this morning. These drafts, while listing a small number of > authors, are actually the result of a great deal of discussion among > several people, including myself, Jonathan, Rohan, Jon, Robert, Dean, > Brian, and Allison. (Please do not take this to mean that every person > listed necessarily agree with every point in the drafts ;-) ) > > draft-campbell-simple-im-sessions-00 discusses the use of the SDP > offer/answer model for initiating message sessions, without talking much > about the message sessions themselves. > > draft-campbell-simple-cpimmsg-sessions-00 proposes a message session > transport that involves transporting messages over TCP or TLS using the > message/cpim format. This draft depends on the signaling methods > described in the im-sessions draft. This is the evolution of a long chain of drafts, starting with the IMTP proposal (http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt), followed by the session-of-MESSAGE proposal (http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-00.txt). At Yokohama, there was some support for the simple-message-session approach, but there were still concerns that this was not-quite-right. The essence of the problem is that SIP is not a session protocol. So, a group of folks got together, and we came to agree on some important points. First, SIPs strength is that it can set up all different kinds of sessions. There is no constraint that there be only ONE session transport protocol. However, we do need a baseline protocol that everyone agrees to implement. SIP can be used to signal something else if others are developed. Given that this is a baseline, the criteria we developed was minimalism. What is the minimal IM session transport we can develop which meets our requirements? Our conclusion was a CPIM-over-TCP approach. This is a really lightweight transport, its amenable to intermediaries [indeed, its intermediaries are much simpler than a sip proxy], and it suffers from none of the problems we had with trying to use SIP MESSAGE for this (congestion control, overlapping transactions, etc.). As the simple-im-sessions draft discusses, there are many many benefits to the session model. As such, I consider it really important to FINALLY close on this contentious issue, and have a solution that we can start to deploy. I personally hope that over the next few weeks, we can get consensus on these drafts as the basis for mesaging sessions. Please share your thoughts. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 16:55:35 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 QAA27444 for ; Tue, 29 Oct 2002 16:55:34 -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 g9TLuFsu008312; Tue, 29 Oct 2002 16:56:15 -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 QAA07111; Tue, 29 Oct 2002 16:57:04 -0500 (EST) Received: from hotmail.com (oe63.law3.hotmail.com [209.185.240.79]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07100 for ; Tue, 29 Oct 2002 16:56:38 -0500 (EST) From: hdhunter@hotmail.com Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 29 Oct 2002 13:56:39 -0800 X-Originating-IP: [63.229.217.250] Reply-To: "Mike Peterson" Wrom: LBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWW To: References: <200210291701.MAA06174@mailman.dynamicsoft.com> 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 29 Oct 2002 21:56:39.0559 (UTC) FILETIME=[0F235170:01C27F96] Subject: [Simple] unsubscribe 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 Oct 2002 15:54:52 -0600 Content-Transfer-Encoding: 7bit ----- Original Message ----- Wrom: CUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRK To: Sent: Tuesday, October 29, 2002 11:01 AM Subject: simple digest, Vol 1 #547 - 10 msgs > Send simple mailing list submissions to > simple@mailman.dynamicsoft.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.dynamicsoft.com/mailman/listinfo/simple > or, via email, send a message with subject or body 'help' to > simple-request@mailman.dynamicsoft.com > > You can reach the person managing the list at > simple-admin@mailman.dynamicsoft.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of simple digest..." > > > Today's Topics: > > 1. Re: Re: draft-olson-simple-publish-01.txt (Sean Olson) > 2. Re: Re: draft-olson-simple-publish-01.txt (Paul Kyzivat) > 3. RE: collection template (Adam Roach) > 4. FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt (mikko.lonnfors@nokia.com) > 5. Comment to draft-olson-simple-publish-01.txt (mikko.lonnfors@nokia.com) > 6. A omment to draft-olson-simple-publish-01 (aki.niemi@nokia.com) > 7. I-D ACTION:draft-campbell-simple-im-sessions-00.txt (Internet-Drafts@ietf.org) > 8. I-D ACTION:draft-campbell-simple-cpimmsg-sessions-00.txt (Internet-Drafts@ietf.org) > 9. Re: FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt (Paul Kyzivat) > 10. IETF55 Agenda Requests (Robert Sparks) > > --__--__-- > > Message: 1 > Date: Mon, 28 Oct 2002 09:00:24 -0800 (PST) > Wrom: JVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAA > Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt > To: Paul Kyzivat , Simple > > The analogy breaks down in situations that need > more persistence of the stream identifier. If Call-ID > where to persist across all requests, across reboots, > and potentially across devices, then it would be a > perfect fit :) It may be that we find a better way > to accomplish this. The "Stream" header is a first > shot at satisfying the need for a compositor to > identify the source of a publication. > > Thanks, > Sean Olson > Microsoft > > > --- Paul Kyzivat wrote: > > I question the need for the Stream header. Its use > > seems entirely analogous to the use of a common > > Callid header in REGISTER requests. Why is it > > necessary to introduce a new header for PUBLISH when > > it wasn't necessary for REGISTER? > > > > Paul > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Y! Web Hosting - Let the expert host your web site > http://webhosting.yahoo.com/ > > --__--__-- > > Message: 2 > Date: Mon, 28 Oct 2002 14:17:29 -0500 > Wrom: LPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQB > To: Sean Olson > CC: Simple > Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt > > > > Sean Olson wrote: > > > > The analogy breaks down in situations that need > > more persistence of the stream identifier. If Call-ID > > where to persist across all requests, across reboots, > > and potentially across devices, then it would be a > > perfect fit :) > > Hmm. If that analogy doesn't hold then it would be helpful to have a more complete description of the semantics of a stream. I guess the discussion of section 1.1.4 Publisher Instance is intended to provide this. But it doesn't line up especially well with the definition of Stream in 3.3. Section 3.3 focuses on providing a context within which to process messages in order, while 1.1.4 focuses on distinct publishing instances. From your comments, you suggest that a distinct instance might not always reside on the same device. Once you say that, the possibility arises that you might have two physical devices simultaneously claiming to have the same logical identity. And that messes up the suggested means of ordering messages within a stream. Actually, even moving a stream from one device to another might cause ordering to be messed up if there is significant clock skew. > > Based on the available descriptions, I don't yet understand what I might want to use this feature for. You authors obviously have something in mind that motivates the exact options you have selected. Maybe a more specific example would help. > > Paul > > --__--__-- > > Message: 3 > Wrom: GJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSW > To: "'George Foti (LMC)'" , > Adam Roach > , simple@mailman.dynamicsoft.com > Subject: RE: [Simple] collection template > Date: Mon, 28 Oct 2002 13:43:28 -0600 > > > -----Original Message----- > > Wrom: ZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULH > > > > is it correct > > to assume that either of the following is correct: > > > > a) The RLS will send *individual* SUBSCRIBE to all members of > > all sub-lists > > included in the main resource list created by the user when > > he SUBSCRIBEs to > > that list. > > That would be valid. Of course, the RLS has to know the membership > of all of the sublists to do so. > > > b) The RLS can do procedure (a) for 1 or more sub-lists (in > > the original > > list) but can also send a SUBSCRIBE to another RLS for some > > sub-lists (in > > the original list). The later RLS can be responsbile for > > maintaining some > > lists, and in turn will implement procedure (a). > > That would also be valid. The only revision I would make to your > assertion is: "can do procedure (a) for _zero_ or more sublists..." > > Finally, the RLS might have complete information about all of > the states involved, in which case it would generate *no* > subscribes to any other node at all. > > /a > > --__--__-- > > Message: 4 > Wrom: PQkko.lonnfors@nokia.com > Date: Tue, 29 Oct 2002 08:43:26 +0200 > To: > Subject: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C27F16.7BD29B35 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi, > > New draft is now available. Basically draft presents a solution for the = > requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.=20 > All comments are welcome. > > - Mikko > > > -----Original Message----- > > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 28 October, 2002 13:27 > > Subject: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > >=20 > >=20 > > A New Internet-Draft is available from the on-line=20 > > Internet-Drafts directories. > >=20 > >=20 > > Title : SIMPLE PIDF presence capabilities extension > > Author(s) : M. Lonnfors, K. Kiss > > Filename : draft-lonnfors-simple-prescaps-ext-00.txt > > Pages : 14 > > Date : 2002-10-25 > > =09 > > Interoperation of Instant Messaging and Presence systems has been > > defined in IMPP Working Group. IMPP WG has come up with baseline > > interoperable operations and formats for Presence and Instant > > Messaging systems. However, these base formats might need > > standardized extensions in order to enable building rational > > applications using Presence and Instant Messaging. This memo > > proposes an extension to PIDF presence document format to be used in > > SIMPLE based Presence systems [1] but may also be applied to other > > protocols as well. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres > caps-ext-00.txt > > To remove yourself from the IETF Announcement list, send a message to=20 > 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-lonnfors-simple-prescaps-ext-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > 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-lonnfors-simple-prescaps-ext-00.txt". > =09 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------_=_NextPart_001_01C27F16.7BD29B35 > Content-Type: application/octet-stream; > name="ATT48751.TXT" > Content-Transfer-Encoding: base64 > Content-Description: ATT48751.TXT > Content-Disposition: attachment; > filename="ATT48751.TXT" > > Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt > c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl > eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTEwLTI1MTEyNTI3LkktREBpZXRmLm9yZz4NCg0K > RU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvbm5mb3JzLXNpbXBs > ZS1wcmVzY2Fwcy1leHQtMDAudHh0DQo= > > ------_=_NextPart_001_01C27F16.7BD29B35 > Content-Type: application/octet-stream; > name="draft-lonnfors-simple-prescaps-ext-00.URL" > Content-Transfer-Encoding: base64 > Content-Description: draft-lonnfors-simple-prescaps-ext-00.URL > Content-Disposition: attachment; > filename="draft-lonnfors-simple-prescaps-ext-00.URL" > > W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 > cy9kcmFmdC1sb25uZm9ycy1zaW1wbGUtcHJlc2NhcHMtZXh0LTAwLnR4dA0K > > ------_=_NextPart_001_01C27F16.7BD29B35-- > > --__--__-- > > Message: 5 > From: mikko.lonnfors@nokia.com > Date: Tue, 29 Oct 2002 10:11:49 +0200 > To: > Subject: [Simple] Comment to draft-olson-simple-publish-01.txt > > Hi, > > Thanks for the new version. Here are some concerns/comments: > > - Sections 1.1.5 and 3.4: Facet header > I am bit confused how this is indented to work. If each PUA always publishes full state then how is it really possible to use facet header to indicate to which watcher instances published information is targeted to? As it is currently defined one PUA could only publish all its information to one or multiple facets i.e. it is not possible to give some part of that info so some facets and some other parts to other facet. In current case it is all or nothing. I would see that better approach would be to include this kind of information into published content and to authorization rules but not to publish protocol itself. > Also it is completely unspecified what should happen if PA does not support the requested facet. Should it report an error or should there be some default behavior. Building interoperable system in my mind requires that these procedures are defined. > > - Document does not specify any error handling mechanism for publish. I think there can be cases where either PA or compositor does not for some reason understand what PUA has published or that compositor for some reason cannot add published data into some existing data. Without any error reporting mechanism is might very hard for PUAs to know what went wrong and what PUA could do to correct its actions. > > - Section 1.1.3 and examples > Document states that it is possible to associate Class to tuple-ids. This is also used in examples. As draft-ietf-impp-cpim-pidf-05.txt currently stands this is not allowed. I don't know if this is going to change in future versions of PIDF but at a moment associating any semantics to tuple-ids is forbidden. > > Best Regards > - Mikko > > --__--__-- > > Message: 6 > From: aki.niemi@nokia.com > Date: Tue, 29 Oct 2002 12:22:34 +0200 > To: > Subject: [Simple] A omment to draft-olson-simple-publish-01 > > Hi, > > Thanks for the much improved -01. One comment though: > > Although the draft says that 489 (Bad Event) should be sent in case the composer doesn't understand the published event state, there is no mention of Allow-Events used in that case. Allow-Events is mandatory in 489 according to RFC 3265. If it is also mandatory for 489 to a PUBLISH, it would seem logical that it is also (optionally) used with OPTIONS (for one). Would then Allow-Events in a 2xx to OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both? > > Why not a new pair of headers, which share the event-type (for packages) namespace with Event/Allow-Events, something like what's described in > > http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-00. txt > > AFAIK, we are not running out of space with header names ;) > > Cheers, > Aki > > > --__--__-- > > Message: 7 > To: IETF-Announce: ; > CC: simple@mailman.dynamicsoft.com > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Date: Tue, 29 Oct 2002 06:17:42 -0500 > Subject: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-00.txt > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Instant Message Sessions in SIMPLE > Author(s) : B. Campbell, J. Rosenberg > Filename : draft-campbell-simple-im-sessions-00.txt > Pages : 11 > Date : 2002-10-28 > > The SIP MESSAGE method is used to send instant messages, where each > message is independent of any other message. This is often called > pager-mode messaging, due to the fact that this model is similar to > that of most two-way pager devices. Another model is called session- > mode. In session-mode, the instant messages are part of a media > session that provides ordering, a security context, and other > functions. This media session is established using a SIP INVITE, > just as an audio or video session would be established. > This document describes a method of initiating and managing message > sessions using SIP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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-campbell-simple-im-sessions-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <2002-10-28163248.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-campbell-simple-im-sessions-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-campbell-simple-im-sessions-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2002-10-28163248.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > > > --__--__-- > > Message: 8 > To: IETF-Announce: ; > CC: simple@mailman.dynamicsoft.com > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Date: Tue, 29 Oct 2002 06:17:47 -0500 > Subject: [Simple] I-D ACTION:draft-campbell-simple-cpimmsg-sessions-00.txt > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Instant Message Transport Sessions using the CPIM > Message Format > Author(s) : B. Campbell et al. > Filename : draft-campbell-simple-cpimmsg-sessions-00.txt > Pages : 12 > Date : 2002-10-28 > > Instant Messaging (IM) refers to the transfer of messages between > users in near real-time. These messages are usually, but not > required to be, short. IMs are often used in a conversational mode, > that is, the transfer of messages back and forth is fast enough for > participants to maintain an interactive conversation. Each message > can be sent independently using the SIP MESSAGE method, or messages > can be associated into sessions that are initiated using SIP. The > first approach is often referred to as pager-mode messaging, due to > its similarity to the behavior of two way pager devices. The second > approach is often called session-mode messaging, or simply message > sessions. This document describes a message session mechanism based > on the Common Presence and Instant Messaging message format. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-campbell-simple-cpimmsg-sessions-0 0.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-campbell-simple-cpimmsg-sessions-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-campbell-simple-cpimmsg-sessions-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <2002-10-28163257.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-campbell-simple-cpimmsg-sessions-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-campbell-simple-cpimmsg-sessions-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2002-10-28163257.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > > > --__--__-- > > Message: 9 > Date: Tue, 29 Oct 2002 10:05:56 -0500 > From: Paul Kyzivat > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > > mikko.lonnfors@nokia.com wrote: > > > > Hi, > > > > New draft is now available. Basically draft presents a solution for the requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt. > > All comments are welcome. > > Obviously Mikko and I have been cooperating on this. We were both interested in the subject. I thought it would be helpful to be clear about the requirements rather than jumping directly to a proposed solution, so I posted a requirements draft last week. Since then I have been waiting for Mikko to submit this in order to have more fodder for discussion. > > There is already a work item to produce a SIP-specific profile for PIDF. I consider these drafts to be a *partial* response to that work item. I realize there is a desire for some addition generalized status values beyond open/closed, such as busy. That is a minefield, and we have chosen not to address it. Instead, we are focusing on some attributes that should be less controversial because they are drawn from the callerprefs draft, whose basic concepts have been accepted for a long time. (I am open to discussion about whether these specific drafts should be expanded to cover the more general requirement, or whether that should be left separate.) > > The assertion of these drafts is that capabilities a UAS can specify when registering are information that is equally important in a presence document. I believe Mikko is most concerned with supported media. I also consider that to be of major importance, but I also believe all the others are of potential value in a presence document. > > The callerprefs draft is still itself in a state of flux. The work here should remain dependent on the outcome of that work. But I believe it would be helpful to begin progressing these documents now. > > Paul > > --__--__-- > > Message: 10 > From: Robert Sparks > To: simple@mailman.dynamicsoft.com > Date: 29 Oct 2002 10:05:12 -0600 > Subject: [Simple] IETF55 Agenda Requests > > Please send me requests for agenda time at the Atlanta SIMPLE meeting. > > RjS > > > > > > --__--__-- > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > End of simple Digest > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 19:35: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 TAA03030 for ; Tue, 29 Oct 2002 19:35:25 -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 g9U0aCsu008987; Tue, 29 Oct 2002 19:36:12 -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 TAA07899; Tue, 29 Oct 2002 19:37:06 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07888 for ; Tue, 29 Oct 2002 19:36:14 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9U0aQ82007598 for ; Tue, 29 Oct 2002 19:36:27 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAT80987; Tue, 29 Oct 2002 19:40:53 -0500 (EST) Message-ID: <3DBF2970.22BFCCF9@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simple References: <200210291117.GAA27770@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: comedia in draft-campbell-simple-*-sessions-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: Tue, 29 Oct 2002 19:36:00 -0500 Content-Transfer-Encoding: 7bit Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such a way that multiple sessions can be demultiplexed from a single connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for the use of the comedia spec to establish the connections. It also wishes to reuse a single connection for multiple sessions. This presents a problem, because the comedia draft (ietf-mmusic-sdp-comedia-04) does not provide a way to share a connection among multiple sessions. It was constrained from doing so because it made no assumption about the protocol to be used on the connection. As a result it had to come up with a way to associate connections with sessions without regard to media content. Either a way must be found to change comedia to provide this capability, or else comedia must be abandoned in favor of some other arrangement for negotiating a connection. (It would be nice to make comedia work for this.) Rohan and I talked about this, and began to think we could find an enhancement to comedia that would permit this, but then it got very ugly trying to figure out when connections should go away, especially between a pair of intermediaries. This is going to require some work. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 20:07:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03700 for ; Tue, 29 Oct 2002 20:07:17 -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 g9U188su009116; Tue, 29 Oct 2002 20:08:08 -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 UAA08003; Tue, 29 Oct 2002 20:09:03 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07992 for ; Tue, 29 Oct 2002 20:08:51 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9U193aP009892 for ; Tue, 29 Oct 2002 20:09:04 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAT81079; Tue, 29 Oct 2002 20:13:40 -0500 (EST) Message-ID: <3DBF311F.B8AC9254@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simple Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 20:08:47 -0500 Content-Transfer-Encoding: 7bit I forgot in prior message, so first let me say that I like the direction this is going much better than the prior attempts! I'm having difficulty understanding the purpose of the From meta-data header. Section 3 says: "When used in an instant message session, the From and To meta-data headers are used to identify the session. There is no expectation that these headers actually identify the participants in the session- -they are used only as tokens to identify the session itself." Section 5 says: "This message MUST contain a ... From meta-data header value, which SHOULD be used to identify the sender, but MAY be set to some other value for purposes of anonymity." I figure there are a few kinds of things this header could contain: - It could always contain the same value as the From/To (depending on direction of message) of the sip session that established the media session. - It could carry the URI from the a:uri line of the message sender. - It could be the sip: or im: address of the actual message source. In simple cases it would be the same as the To/From address of the invite, but would be different when conferencing. I can't think of any other plausible alternatives. The first two are useless redundant information that can be inferred. The last would be useful. So I will assume that is the intent even though it conflicts with section 3. Please let me know if this is a wrong assumption. This is sensitive information that ought to have end-to-end confidentiality protection. At the same time, this From header is a peer of the To header. The To header apparently is intended to carry the URI from the a:uri line of the SDP from the destination message. It is needed for the recipient to demux a shared connection and send the message to the proper session. Intermediaries must also do this demuxing, so they also need access to the To header. So the To header can't be confidential end-to-end. How is confidentiality going to work so it hides the From header and not the To header? I think these need to go into different envelopes. Why shouldn't the To go in the outer envelope? Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 21:27:28 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 VAA05011 for ; Tue, 29 Oct 2002 21:27:27 -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 g9U2SCsu009319; Tue, 29 Oct 2002 21:28:12 -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 VAA08250; Tue, 29 Oct 2002 21:29: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 VAA08239 for ; Tue, 29 Oct 2002 21:28:52 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9U2SrYH021119; Tue, 29 Oct 2002 21:28:53 -0500 (EST) Message-ID: <3DBF43E4.4050107@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Simple Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 21:28:52 -0500 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > I forgot in prior message, so first let me say that I like the > direction this is going much better than the prior attempts! > > I'm having difficulty understanding the purpose of the From meta-data > header. > > Section 3 says: > > "When used in an instant message session, the From and To meta-data > headers are used to identify the session. There is no expectation > that these headers actually identify the participants in the session- > -they are used only as tokens to identify the session itself." > > Section 5 says: > > "This message MUST contain a ... From meta-data header value, which > SHOULD be used to identify the sender, but MAY be set to some other > value for purposes of anonymity." Oops. This was something we changed several revs in, and it looks like it didn't get changed everywhere. Its supposed to be the identity of the sender, ie., section 5 is correct. > > I figure there are a few kinds of things this header could contain: > > - It could always contain the same value as the From/To (depending on > direction of message) of the sip session that established the media > session. > > - It could carry the URI from the a:uri line of the message sender. > > - It could be the sip: or im: address of the actual message source. > In simple cases it would be the same as the To/From address of the > invite, but would be different when conferencing. Yes. This is exactly the intent. > > I can't think of any other plausible alternatives. The first two are > useless redundant information that can be inferred. The last would be > useful. So I will assume that is the intent even though it conflicts > with section 3. Please let me know if this is a wrong assumption. You are absolutely correct. > > This is sensitive information that ought to have end-to-end > confidentiality protection. > > At the same time, this From header is a peer of the To header. The To > header apparently is intended to carry the URI from the a:uri line of > the SDP from the destination message. It is needed for the recipient > to demux a shared connection and send the message to the proper > session. Intermediaries must also do this demuxing, so they also need > access to the To header. So the To header can't be confidential > end-to-end. > > How is confidentiality going to work so it hides the From header and > not the To header? > > I think these need to go into different envelopes. Why shouldn't the > To go in the outer envelope? Hmm. Sounds reasonable. Its almost more like a request URI type of thing. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Oct 29 23:29:26 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 XAA07512 for ; Tue, 29 Oct 2002 23:29:25 -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 g9U4UAsu009603; Tue, 29 Oct 2002 23:30:10 -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 XAA08600; Tue, 29 Oct 2002 23:31:04 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08589 for ; Tue, 29 Oct 2002 23:30:22 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g9U4UEpA004739; Tue, 29 Oct 2002 22:30:15 -0600 (CST) Message-ID: <3DBF6051.6020502@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Simple Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 22:30:09 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > > I forgot in prior message, so first let me say that I like the > > direction this is going much better than the prior attempts! > > > > I'm having difficulty understanding the purpose of the From meta-data > > header. > > > > Section 3 says: > > > > "When used in an instant message session, the From and To meta-data > > headers are used to identify the session. There is no expectation > > that these headers actually identify the participants in the session- > > -they are used only as tokens to identify the session itself." > > > > Section 5 says: > > > > "This message MUST contain a ... From meta-data header value, which > > SHOULD be used to identify the sender, but MAY be set to some other > > value for purposes of anonymity." > > Oops. > > This was something we changed several revs in, and it looks like it > didn't get changed everywhere. Its supposed to be the identity of the > sender, ie., section 5 is correct. > > > > > I figure there are a few kinds of things this header could contain: > > > > - It could always contain the same value as the From/To (depending on > > direction of message) of the sip session that established the media > > session. > > > > - It could carry the URI from the a:uri line of the message sender. > > > > - It could be the sip: or im: address of the actual message source. > > In simple cases it would be the same as the To/From address of the > > invite, but would be different when conferencing. > > Yes. This is exactly the intent. > > > > > I can't think of any other plausible alternatives. The first two are > > useless redundant information that can be inferred. The last would be > > useful. So I will assume that is the intent even though it conflicts > > with section 3. Please let me know if this is a wrong assumption. > > You are absolutely correct. > > > > > This is sensitive information that ought to have end-to-end > > confidentiality protection. > > > > At the same time, this From header is a peer of the To header. The To > > header apparently is intended to carry the URI from the a:uri line of > > the SDP from the destination message. It is needed for the recipient > > to demux a shared connection and send the message to the proper > > session. Intermediaries must also do this demuxing, so they also need > > access to the To header. So the To header can't be confidential > > end-to-end. > > > > How is confidentiality going to work so it hides the From header and > > not the To header? > > > > I think these need to go into different envelopes. Why shouldn't the > > To go in the outer envelope? > > Hmm. Sounds reasonable. Its almost more like a request URI type of thing. I also agree it sounds reasonable--although if we were to do that we might want to call it something other than To. That way, we could keep a more symetric use of To and From in the message/cpim headers. The main reason we chose To in the first place is it already existed in cpim-msgfmt--that is, it did not require an extension. It seems to me that putting an additional header in the outer envelope _does_ require an extension, so we might as well name it whatever we wish. If we were to do this, does it also make sense to move MsgID to the outer envelope? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 01:18:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10026 for ; Wed, 30 Oct 2002 01:18:22 -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 g9U6JAsu009847; Wed, 30 Oct 2002 01:19:10 -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 BAA08954; Wed, 30 Oct 2002 01:20:05 -0500 (EST) Received: from mta0 ([61.144.161.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08941 for ; Wed, 30 Oct 2002 01:19:32 -0500 (EST) Received: from D70286 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H4S00AVM6TO1X@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Wed, 30 Oct 2002 14:17:49 +0800 (CST) From: Deepankar To: simple@mailman.dynamicsoft.com Message-id: <00bb01c27fdc$46074750$ac064d0a@D70286> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] uploading of Presence docs to PA 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, 30 Oct 2002 14:19:16 +0800 This is a multi-part message in MIME format. --Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT To upload a presence document form a PUA to the PA, presence-07 says, there could be two methods. one is, constructing a presence doc using registrations, and the other is, to explicitly upload the document. This is implementation choice, I believe. If I manipulate REGISTER to carry a body with a presence doc, then backward compatibility will be a problem, and in the other case, an explicit out of band connection is needed to achieve it. The spec says , manipulation of REGISTER's is not recommended. Any thoughts worked on lately !! Deeps --Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
To upload a presence document form a PUA to the PA, presence-07 says, there could be two methods. one is, constructing a presence doc using registrations, and the other is, to explicitly upload the document. This is implementation choice, I believe.
If I manipulate REGISTER to carry a body with a presence doc, then backward compatibility will be a problem, and in the other case, an explicit out of band connection is needed to achieve it. The spec says , manipulation of REGISTER's is not recommended.
 
Any thoughts worked on lately !!
 
Deeps
 
--Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 03:44:23 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05795 for ; Wed, 30 Oct 2002 03:44:23 -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 g9U8j9su010220; Wed, 30 Oct 2002 03:45:09 -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 DAA09453; Wed, 30 Oct 2002 03:46:04 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09442 for ; Wed, 30 Oct 2002 03:45:56 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9U8jWb25390 for ; Wed, 30 Oct 2002 10:45:32 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 30 Oct 2002 10:45:55 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Oct 2002 10:45:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Message Session IDs Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945053@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Message Session IDs Thread-Index: AcJ/zclJxQZw4cxxT4qnE6f859ZEFAAIgUAw To: , Cc: , X-OriginalArrivalTime: 30 Oct 2002 08:45:55.0194 (UTC) FILETIME=[C2817DA0:01C27FF0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA09442 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, 30 Oct 2002 10:45:54 +0200 Content-Transfer-Encoding: 8bit Hi, First off, I also think this current approach does look cleaner and better than the previous ones. More inline: > > > I think these need to go into different envelopes. Why > shouldn't the > > > To go in the outer envelope? > > > > Hmm. Sounds reasonable. Its almost more like a request URI > type of thing. > > I also agree it sounds reasonable--although if we were to do that we > might want to call it something other than To. That way, we > could keep a > more symetric use of To and From in the message/cpim headers. > The main > reason we chose To in the first place is it already existed in > cpim-msgfmt--that is, it did not require an extension. It seems to me > that putting an additional header in the outer envelope > _does_ require > an extension, so we might as well name it whatever we wish. I also agree. This looks much more like a SessionID than a To. Also, since cpim-msgfmt allows multiple Tos, it might have been a problem anyway. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 05:35:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07542 for ; Wed, 30 Oct 2002 05:35: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 g9UAaAsu010535; Wed, 30 Oct 2002 05:36:10 -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 FAA09759; Wed, 30 Oct 2002 05:37:04 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09748 for ; Wed, 30 Oct 2002 05:36:49 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9UAb8B12628 for ; Wed, 30 Oct 2002 12:37:08 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 30 Oct 2002 12:36:48 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Oct 2002 12:36:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945054@esebe013.ntc.nokia.com> Thread-Topic: I-D ACTION:draft-niemi-simple-im-wireless-reqs-00.txt Thread-Index: AcJ8OMFIQ2GhKS6/QFKk1YgsjrXSBQDxp5CQ To: X-OriginalArrivalTime: 30 Oct 2002 10:36:48.0926 (UTC) FILETIME=[40706BE0:01C28000] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA09748 Subject: [Simple] 3GPP Messaging requirements 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, 30 Oct 2002 12:36:48 +0200 Content-Transfer-Encoding: 8bit Hi All, Like promised in Yokohama, there is now a document available describing the 3GPP requirements to Instant Messaging. It lists requirements for both pager mode and session mode IM. Here's a link for your convenience: http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt I'd especially like to draw your attention to the requirements for session mode IM, as well as the requirements for data manipulation. Note also, that when 3GPP talks about session based messaging, there is a strong flavor of multiparty sessions to it. The conferencing aspects, and the chat-room type aspects of this document should be considered already in the current message session work. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 09:07:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15324 for ; Wed, 30 Oct 2002 09:07:26 -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 g9UE8Bsu011140; Wed, 30 Oct 2002 09:08:12 -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 JAA10399; Wed, 30 Oct 2002 09:09:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10388 for ; Wed, 30 Oct 2002 09:08:26 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UE8fW2016040 for ; Wed, 30 Oct 2002 09:08:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAT83224; Wed, 30 Oct 2002 09:13:19 -0500 (EST) Message-ID: <3DBFE7D9.CE57E118@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simple Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com> <3DBF6051.6020502@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 30 Oct 2002 09:08:25 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > > Hmm. Sounds reasonable. Its almost more like a request URI type of thing. > > I also agree it sounds reasonable--although if we were to do that we > might want to call it something other than To. That way, we could keep a > more symetric use of To and From in the message/cpim headers. The main > reason we chose To in the first place is it already existed in > cpim-msgfmt--that is, it did not require an extension. It seems to me > that putting an additional header in the outer envelope _does_ require > an extension, so we might as well name it whatever we wish. Yes. I was going to complain about the name "To" in my earlier message but didn't want to appear petty. (I *am* petty, but didn't want to appear that way. :-) I don't think "To" has the right connotation. > > If we were to do this, does it also make sense to move MsgID to the > outer envelope? I don't know about this. If it is only needed by the endpoints then it might as well be in the inner envelope. Protecting it should help protect against some kinds of attacks. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 09:37:20 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16592 for ; Wed, 30 Oct 2002 09:37:20 -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 g9UEcAsu011308; Wed, 30 Oct 2002 09:38:10 -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 JAA10499; Wed, 30 Oct 2002 09:39:04 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10488 for ; Wed, 30 Oct 2002 09:38:10 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g9UEc3pA046745; Wed, 30 Oct 2002 08:38:04 -0600 (CST) Message-ID: <3DBFEEC2.8010109@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Deepankar CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] uploading of Presence docs to PA References: <00bb01c27fdc$46074750$ac064d0a@D70286> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 30 Oct 2002 08:37:54 -0600 Content-Transfer-Encoding: 7bit Deepankar wrote: > To upload a presence document form a PUA to the PA, presence-07 says, > there could be two methods. one is, constructing a presence doc using > registrations, and the other is, to explicitly upload the document. This > is implementation choice, I believe. > If I manipulate REGISTER to carry a body with a presence doc, then > backward compatibility will be a problem, and in the other case, an > explicit out of band connection is needed to achieve it. The spec says , > manipulation of REGISTER's is not recommended. > > Any thoughts worked on lately !! > > Deeps > Look at draft-olson-simple-publish-01 that was published last week. Thanks! Ben. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 09:39:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16669 for ; Wed, 30 Oct 2002 09:39:18 -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 g9UEe9su011380; Wed, 30 Oct 2002 09:40:09 -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 JAA10531; Wed, 30 Oct 2002 09:41:04 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10520 for ; Wed, 30 Oct 2002 09:40:57 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g9UEeTpA046874; Wed, 30 Oct 2002 08:40:29 -0600 (CST) Message-ID: <3DBFEF54.1020907@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Simple Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com> <3DBF6051.6020502@dynamicsoft.com> <3DBFE7D9.CE57E118@cisco.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 30 Oct 2002 08:40:20 -0600 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > Ben Campbell wrote: [...] > >>If we were to do this, does it also make sense to move MsgID to the >>outer envelope? > > > I don't know about this. If it is only needed by the endpoints then it might as well be in the inner envelope. Protecting it should help protect against some kinds of attacks. > On reflection, I agree with you. I had it in my head that an intermediary might use it for ordering purposes, but now that I am more awake I realize there is no need for that. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 15:42:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10177 for ; Wed, 30 Oct 2002 15:42:37 -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 g9UKhMsu013127; Wed, 30 Oct 2002 15:43:23 -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 PAA11693; Wed, 30 Oct 2002 15:44:09 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01982 for ; Mon, 28 Oct 2002 14:18:56 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9SJInW18015; Mon, 28 Oct 2002 13:18:49 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9SJInN22250; Mon, 28 Oct 2002 13:18:49 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9SJImh13626; Mon, 28 Oct 2002 14:18:48 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 28 Oct 2002 14:18:48 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037B1E@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Adam Roach'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] collection template MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 14:18:46 -0500 Some clarification Adam: When a user creates a resource list, I assume that he can refer to other lists there in, so basically we have a case of recursion. Now is it correct to assume that either of the following is correct: a) The RLS will send *individual* SUBSCRIBE to all members of all sub-lists included in the main resource list created by the user when he SUBSCRIBEs to that list. b) The RLS can do procedure (a) for 1 or more sub-lists (in the original list) but can also send a SUBSCRIBE to another RLS for some sub-lists (in the original list). The later RLS can be responsbile for maintaining some lists, and in turn will implement procedure (a). Thnx/gf > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Friday, October 25, 2002 6:04 PM > To: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] collection template > > > [Sliding in under the wire for the -00 deadline] > > An i-d describing a template event package for collections has been > submitted to the drafts editor. Until a copy appears in the archives, > you can download a copy from: > > http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t emplate-00.txt HTML version also available: http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.htm l This work is still rather rough around the edges, but I think it gives a good starting point for discussion. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 16:01: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 QAA11560 for ; Wed, 30 Oct 2002 16:01: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 g9UL2Wsu013271; Wed, 30 Oct 2002 16:02:33 -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 PAA11752; Wed, 30 Oct 2002 15:57:21 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06624 for ; Tue, 29 Oct 2002 14:22:34 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9TJMHW01040; Tue, 29 Oct 2002 13:22:17 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9TJMG718607; Tue, 29 Oct 2002 13:22:16 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9TJMGh02577; Tue, 29 Oct 2002 14:22:16 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Oct 2002 14:21:51 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037B26@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Paul Kyzivat'" , Sean Olson Cc: Simple Subject: RE: [Simple] Re: draft-olson-simple-publish-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 14:22:09 -0500 I have the same concern. Sections 1.1.4 & 3.3 are not well aligned with respect to the real intent for Stream header. Is it meant to be used as : 1) A unique correlation identifier 2) A way for sequencing for data from the *same* source 3) Both 1) & 2) If it is case 3 than I am not sure how will that really work if the semantics is not defined. Rgds/gf > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, October 28, 2002 2:17 PM > To: Sean Olson > Cc: Simple > Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt > > > > > Sean Olson wrote: > > > > The analogy breaks down in situations that need > > more persistence of the stream identifier. If Call-ID > > where to persist across all requests, across reboots, > > and potentially across devices, then it would be a > > perfect fit :) > > Hmm. If that analogy doesn't hold then it would be helpful to > have a more complete description of the semantics of a > stream. I guess the discussion of section 1.1.4 Publisher > Instance is intended to provide this. But it doesn't line up > especially well with the definition of Stream in 3.3. Section > 3.3 focuses on providing a context within which to process > messages in order, while 1.1.4 focuses on distinct publishing > instances. From your comments, you suggest that a distinct > instance might not always reside on the same device. Once you > say that, the possibility arises that you might have two > physical devices simultaneously claiming to have the same > logical identity. And that messes up the suggested means of > ordering messages within a stream. Actually, even moving a > stream from one device to another might cause ordering to be > messed up if there is significant clock skew. > > Based on the available descriptions, I don't yet understand > what I might want to use this feature for. You authors > obviously have something in mind that motivates the exact > options you have selected. Maybe a more specific example would help. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 16:53:35 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 QAA14459 for ; Wed, 30 Oct 2002 16:53:35 -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 g9ULs8su013537; Wed, 30 Oct 2002 16:54:08 -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 QAA11926; Wed, 30 Oct 2002 16:51:20 -0500 (EST) Received: from web13308.mail.yahoo.com (web13308.mail.yahoo.com [216.136.175.44]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA09182 for ; Wed, 30 Oct 2002 02:25:31 -0500 (EST) Message-ID: <20021030072532.20510.qmail@web13308.mail.yahoo.com> Received: from [61.11.48.130] by web13308.mail.yahoo.com via HTTP; Tue, 29 Oct 2002 23:25:32 PST From: kamaraju krishna To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] need help 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 Oct 2002 23:25:32 -0800 (PST) Hello sirs i am new to sip protocol development & we are developing sip protocols for controller based product. we are already developed tcp/ip stack for controller based product. i need information about how to build packet and how to encode data in to BNF format and where this BNF information is available, pl give above information. is there any proxy server service providers are avilable for SIP protocol testing ? please send any SIP related information like sip design, development, source code sites and any other sites related to sip protocols. Regards K.V.N.krishna P.L . LINKWELL TELESYSTEMS, HYDERABAD. INDIA krishna_kamaraju@yahoo.com __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 30 19:43: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 TAA20368 for ; Wed, 30 Oct 2002 19:43:46 -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 g9V0gksu014230; Wed, 30 Oct 2002 19:42: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 TAA12427; Wed, 30 Oct 2002 19:38:45 -0500 (EST) Received: from mta0 ([61.144.161.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12414 for ; Wed, 30 Oct 2002 19:36:09 -0500 (EST) Received: from D70286 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H4T003TSLL5M2@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Thu, 31 Oct 2002 08:34:19 +0800 (CST) From: Deepankar Subject: Re: [Simple] uploading of Presence docs to PA To: Ben Campbell Cc: simple@mailman.dynamicsoft.com Message-id: <002801c28075$7339ec20$ac064d0a@D70286> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00bb01c27fdc$46074750$ac064d0a@D70286> <3DBFEEC2.8010109@dynamicsoft.com> 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, 31 Oct 2002 08:35:44 +0800 Content-Transfer-Encoding: 7BIT Hey thanks Ben ! I was dying to look at some work done on this. Somehow, I was out of context on this one. Thanks again, and would be in loop for the 01. Deeps ----- Original Message ----- From: "Ben Campbell" To: "Deepankar" Cc: Sent: Wednesday, October 30, 2002 10:37 PM Subject: Re: [Simple] uploading of Presence docs to PA > Deepankar wrote: > > To upload a presence document form a PUA to the PA, presence-07 says, > > there could be two methods. one is, constructing a presence doc using > > registrations, and the other is, to explicitly upload the document. This > > is implementation choice, I believe. > > If I manipulate REGISTER to carry a body with a presence doc, then > > backward compatibility will be a problem, and in the other case, an > > explicit out of band connection is needed to achieve it. The spec says , > > manipulation of REGISTER's is not recommended. > > > > Any thoughts worked on lately !! > > > > Deeps > > > > Look at draft-olson-simple-publish-01 that was published last week. > > Thanks! > > Ben. > > _______________________________________________ > 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 Oct 31 06:22:28 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 GAA13389 for ; Thu, 31 Oct 2002 06:22:27 -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 g9VBN1su015564; Thu, 31 Oct 2002 06:23:01 -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 GAA14249; Thu, 31 Oct 2002 06:18:09 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14225 for ; Thu, 31 Oct 2002 06:14:45 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12649; Thu, 31 Oct 2002 06:12:06 -0500 (EST) Message-Id: <200210311112.GAA12649@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-sparks-simple-jabber-sessions-00.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 31 Oct 2002 06:12:05 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Establishing jabber Messaging Sessions with the Session Initiation Protocol Author(s) : R. Sparks Filename : draft-sparks-simple-jabber-sessions-00.txt Pages : 10 Date : 2002-10-30 This document explores modeling jabber message streams as media sessions, and how they can be initiated with the Session Initiation Protocol. It also explores how these sessions can be integrated into existing session-based multimedia communication applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-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-sparks-simple-jabber-sessions-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-sparks-simple-jabber-sessions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-30155227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sparks-simple-jabber-sessions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sparks-simple-jabber-sessions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-30155227.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Oct 31 07:05:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14860 for ; Thu, 31 Oct 2002 07:05: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 g9VC6Esu015738; Thu, 31 Oct 2002 07:06:14 -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 HAA14399; Thu, 31 Oct 2002 07:03:19 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14240 for ; Thu, 31 Oct 2002 06:17:18 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13107; Thu, 31 Oct 2002 06:14:39 -0500 (EST) Message-Id: <200210311114.GAA13107@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-kiss-simple-presence-wireless-reqs-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 31 Oct 2002 06:14:39 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Presence Service based on 3GPP specifications and wireless environment characteristics Author(s) : K. Kiss, G. Bajko Filename : draft-kiss-simple-presence-wireless-reqs-01.txt Pages : 13 Date : 2002-10-30 This Internet-Draft defines requirements for Presence Service based on 3GPP specifications and wireless environment characteristics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kiss-simple-presence-wireless-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-30162645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kiss-simple-presence-wireless-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-30162645.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple