From simple-bounces@ietf.org Fri Feb 02 11:37:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1O1-0004nH-S2; Fri, 02 Feb 2007 11:35:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1O0-0004nA-BB for simple@ietf.org; Fri, 02 Feb 2007 11:35:40 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD1Ny-0004CB-12 for simple@ietf.org; Fri, 02 Feb 2007 11:35:40 -0500 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l12GZbPN056465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Feb 2007 10:35:37 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <74F4613B-339F-4884-8C15-0DBC4831AD03@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Robert Sparks Date: Fri, 2 Feb 2007 10:35:34 -0600 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Simple] WG -00 preapproval X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The secretariat is asking for WG chair preapproval of any new WG -00 drafts in a couple of weeks. I don't think we have any new SIMPLE -00's in the works. If I have forgotten something, please remind me ASAP. This doesn't apply to individual -00s, only those that start out draft-ietf-simple- Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From evvmehknxl@consul.com Sat Feb 03 15:36:59 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDRd5-0002Q7-Pr for simple-archive@lists.ietf.org; Sat, 03 Feb 2007 15:36:59 -0500 Received: from [124.197.178.214] (helo=[124.197.178.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDRd4-0008Ro-CC for simple-archive@lists.ietf.org; Sat, 03 Feb 2007 15:36:59 -0500 From: "Girls COMICS" To: simple-archive@lists.ietf.org Subject: Aggressive Investors Alert Date: Sat, 3 Feb 2007 20:36:47 +0000 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C747D3.0690E860" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdH0waQxoalPbkSQBiP8dy9jg5Jag== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <2D425DE9F7DA2A9.649147E1B7@consul.com> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ------=_NextPart_000_0003_01C747D3.0690E860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Get MGOA on Monday, Its going to explode!

Trading Date: Monday, Febuary 05, 2007
Company: MEGOLA INC
Symbol: MGOA
Current Price: $0.05
Short Term Target: $0.50
Rating: 10/10
Recommendation: BUY NOW

CORUNNA, ON -- (MARKET WIRE) -- 02/02/07 Megola Inc. (PKSHEETS: MGOA), a leading environmental solution provider, announced today that it has placed its first order for Hartindo Anti-Fire products, which will be used for product demonstrations and obtaining the required industry approvals. The shipment is set to arrive from Malaysia by the end of February, early March.

This company is going to break into the dollar market yielding MASSIVE returns. Take advantage, get in NOW, make massive returns! This is an ACTIVE and GROWING company.

Get in with MGOA before its over 0.50!
------=_NextPart_000_0003_01C747D3.0690E860-- From simple-bounces@ietf.org Sun Feb 04 14:31:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDn33-0002l2-Sz; Sun, 04 Feb 2007 14:29:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDn32-0002kw-Rf for simple@ietf.org; Sun, 04 Feb 2007 14:29:12 -0500 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDn30-0006S5-LK for simple@ietf.org; Sun, 04 Feb 2007 14:29:12 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1399309wxd for ; Sun, 04 Feb 2007 11:29:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SKrgGzLE2MJDK70oOJDDt0+b1QJUTJ1QveGbm4GABIqoX1GrR4caN0zU3BdiCK8KGald05AUlmqR5IH39QxSnqMcPkuPJBMvPUkTAS+jpsdXn0iwdIgyioZBFsGewC5X0LtldyLiogPFC/vWCYs6tCjNNCQRO0ACKZt1bjyQj/w= Received: by 10.90.89.5 with SMTP id m5mr7877975agb.1170617350144; Sun, 04 Feb 2007 11:29:10 -0800 (PST) Received: by 10.90.115.10 with HTTP; Sun, 4 Feb 2007 11:29:10 -0800 (PST) Message-ID: Date: Sun, 4 Feb 2007 19:29:10 +0000 From: Tiago To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] XCAP PUT Validation: Not UTF-8 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1118325568==" Errors-To: simple-bounces@ietf.org --===============1118325568== Content-Type: multipart/alternative; boundary="----=_Part_36038_13510286.1170617350122" ------=_Part_36038_13510286.1170617350122 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, how exactly works the validation that the content's enconding in a XCAP PUT operation is UTF-8? Is there any public domain Java class that does this? Thanks in advance, Tiago ------=_Part_36038_13510286.1170617350122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, how exactly works the validation that the content's enconding in a XCAP PUT operation is UTF-8? Is there any public domain Java class that does this?

Thanks in advance,

Tiago
------=_Part_36038_13510286.1170617350122-- --===============1118325568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1118325568==-- From simple-bounces@ietf.org Sun Feb 04 19:57:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDs9T-0007ln-Bp; Sun, 04 Feb 2007 19:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDs9R-0007lh-Sy for simple@ietf.org; Sun, 04 Feb 2007 19:56:09 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDs9N-0003Qv-IF for simple@ietf.org; Sun, 04 Feb 2007 19:56:09 -0500 Received: by nf-out-0910.google.com with SMTP id l36so2001983nfa for ; Sun, 04 Feb 2007 16:56:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O2HGAn0XGrUPNycam7DLpJIY/R2HsP/ap2oA9ji66y1PcmAb7zYF0LcbzCnoOGkf7L3Xb0Q4sJIYaKv/zs02btUOGDmVTy7NDrAv0hQk664lU6e39E6UFn0i1IXxB1WTNSYYgZu5ie/18lN2Hv5T3DZxKT3VS1iA08aMkWv353Q= Received: by 10.82.113.6 with SMTP id l6mr1867324buc.1170636964709; Sun, 04 Feb 2007 16:56:04 -0800 (PST) Received: by 10.82.113.20 with HTTP; Sun, 4 Feb 2007 16:56:04 -0800 (PST) Message-ID: <66cd252f0702041656r51d82967k4c7b013a41f62de5@mail.gmail.com> Date: Mon, 5 Feb 2007 11:56:04 +1100 From: "Hisham Khartabil" To: "Miguel Garcia" Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt In-Reply-To: <458954D3.9080209@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <458954D3.9080209@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: simple@ietf.org, Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Miguel Thanks for your comments. Some replies inline... On 21/12/06, Miguel Garcia wrote: > Here are my comments to IMDN-02.txt > > Delete completely Section 13. I will not. The text in there lets readers that we thought about msrp. > > > - Comment in the terminology (Section 3). The 'IM Sender' definition > indicates that the IM Sender might be different from the IMDN recipient. > Doesn't this create a security threat by allowing endpoints to redirect > IMDNs to third parties? This text is in there to indicate that resolving someone's AoR when sending the IMDN may in fact result in a different User Agent. The text does not suggest that an IM recipient may change the IM Sender address when sending IMDNs (although we cannot control that). I'll clarify. > > - Terminology, Section 3. I would suggest to decouple the IMDN payload > from the fact that is an XML document of MIME type message/imdn+xml, > because in the future you could create other MIME types, and still be an > IMDN payload. So I would suggest to replace: > > o IMDN Payload or XML Document: An XML document carrying the > disposition notification information. It is always of MIME type > "message/imdn+xml". > > with: > > o IMDN Payload: An document, typically an XML document, carrying the > disposition notification information. I would like to keep it as xml, but i will soften the "always" part. > > - Section 5.3. We could think of use the term "rendered" rather than > "read". This change is huge and way too late, imo. I'll add clarifying text but will not change the whole draft. > - General question, not tied to any section. What happens if the IM > sender has several devices or SIP instances, sends an IM and requests > IMDN? The desired effect is that IMDNs are received in the same device > where the IM was sent out. This is calling for something like GRUU, but > I don't think we can use GRUU in MESSAGE requests. It would be nice to > either have a solution or just write the limitations of the > specification with respect several devices/instances. This is mentioned in the draft, but is not called for as a limitation. I can indicate that it is a limitation. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 05:40:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1Fq-0000T6-EL; Mon, 05 Feb 2007 05:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1Fo-0000Sv-IV for simple@ietf.org; Mon, 05 Feb 2007 05:39:20 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE1Fm-0005or-4Y for simple@ietf.org; Mon, 05 Feb 2007 05:39:20 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15Aambl018635; Mon, 5 Feb 2007 12:36:54 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 12:38:30 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 12:38:50 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 12:38:50 +0200 Message-ID: <45C7093A.2000307@nokia.com> Date: Mon, 05 Feb 2007 12:38:50 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Stafford, Matthew" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 10:38:50.0177 (UTC) FILETIME=[D2B61B10:01C74911] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070205123654-48A4CBB0-2F061ABC/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "'simple@ietf.org'" Subject: [Simple] Comments to draft-stafford-simple-dmdn-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi: So, a summary of draft-stafford-simple-dmdn is that there is a use case that is not covered by the current IMDN, which is: - An MSRP session is intercepted by a store-and-forward server. The sender would like to be informed when the final recipient receives or reads the message(s). One first question about the use case. It appears form the text in the draft that the use case applies only to large messages. However, I can envision store-and-forward servers that store a complete MSRP session (not only ONE large message). I think it is important to consider these collections of MSRP messages, because, imagine we add something to the CPIM headers of each MSRP SEND requesting delivery disposition notification, then the sender will receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND request. I guess this is not reasonable. On the other hand, if there isn't a store-and-forward server in the path, then there is no need for the sender to receive additional notifications, because the success reports in MSRP will do the job. So, I guess where we are going is to get some sort of conditional IMDN for MSRP. The condition being the unavailability of the recipient to get the messages and a store-and-forward server storing them. This will obviously apply to either large messages or short ones. Any views on this? BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 07:14:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2jL-0001xp-HE; Mon, 05 Feb 2007 07:13:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2jK-0001xk-Kl for simple@ietf.org; Mon, 05 Feb 2007 07:13:54 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE2jA-00018L-Le for simple@ietf.org; Mon, 05 Feb 2007 07:13:54 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E960F20928; Mon, 5 Feb 2007 13:13:35 +0100 (CET) X-AuditID: c1b4fb3c-b07c9bb0000007de-f9-45c71f6fa155 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C77712090F; Mon, 5 Feb 2007 13:13:35 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 13:13:35 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 13:13:35 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E0546236E; Mon, 5 Feb 2007 14:13:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7123E4DBB4; Mon, 5 Feb 2007 14:13:34 +0200 (EET) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0AF3B4DA95; Mon, 5 Feb 2007 14:13:34 +0200 (EET) Subject: RE: [Simple] Internal WG Review: Recharter of SIP forInstantMessaging and Presence Leveraging Extensions (simple) From: "Salvatore Loreto (JO/LMF)" To: simple@ietf.org In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3609D244F9@TBDCEXCH10.US.Cingular.Net> References: <451C9AB8BFB6B64EA11547A3D966DB3609D244F9@TBDCEXCH10.US.Cingular.Net> Content-Type: text/plain Date: Mon, 05 Feb 2007 14:14:13 +0200 Message-Id: <1170677654.3489.9.camel@n95.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 05 Feb 2007 12:13:35.0198 (UTC) FILETIME=[0F3F77E0:01C7491F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: pkyzivat@cisco.com, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, -how continue (or better change) a conversation triggered by a MESSAGE in a new MRSP session -issues related to MRSP sessions established for just sending one message (e.g. imdn or similar functionality) I do think that both the issues summarized above (and mentioned in the previous mails) are problems that SIMPLE should try to address. br sal On Wed, 2007-01-31 at 08:48 -0600, Stafford, Matthew wrote: > Re wireless service providers wanting something similar to MMS: I would > say not only in its own right, but as an interworking vehicle with the > MMS installed base. This is important, I think, from the POV of > facilitating SIMPLE deployment- something I would very much like to see! > > In the context of this conversation, I am eager to hear comments on an > internet draft posted a couple of weeks ago: > http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt > > The draft sets forth use cases involving MSRP- use cases in which imdn > (or similar) functionality would be very useful. In many instances, use > cases can be supported with existing building blocks. But here we do see > a gap, and think that the best solution would be a new/extended building > block devised by IETF. As I indicated in a Jan 19 message posted to this > list, we understand the need to go ahead and progress the imdn draft > (sans MSRP). > > I'm not necessarily inviting detailed discussion of this draft (in the > midst of the current rechartering discussion, that might be premature). > At this point, I'm wanting to know whether this sort of thing will be in > scope (and "lobbying" for the answer to be yes...) > > Best, > Matt Stafford > > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Wednesday, January 31, 2007 3:37 AM > To: pkyzivat@cisco.com; simple@ietf.org > Subject: RE: [Simple] Internal WG Review: Recharter of SIP > forInstantMessaging and Presence Leveraging Extensions (simple) > > Hi, > > Yes, I think this is a feature that would be needed in practice. Having > two messaging mechanisms without clear guidance on how they relate to > each other is going to cause interoperability issues - if not on the > protocol level then at least on the UI-to-UI or user-to-user level. > > Another thing is that there should be some kind of > specification/guideline on how to actually deliver one-shot messages > that are larger than 1300 bytes. One way is to use MSRP, another to do > content indirection with MESSAGE. In MSRP the key is the ability for the > sender to indicate (at least as a preference/hint) that the session is > established for just sending a single message, not to open a > conversation. This is wanted by providers who would like to be able to > offer something similar to MMS service on top of a SIP infra. > > SIMPLE WG has not been very enthusiastic about this in the past, so I > think OMA has already defined a particular mechanism for MSRP. If > everyone who is interested in this is anyway involved in OMA, as it > seems, there would be not much value for IETF to do anything about it. > However, if there is real interest outside OMA, it would be useful to > have some work in SIMPLE WG. > > Markus > > > >-----Original Message----- > >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >Sent: 31 January, 2007 00:15 > >To: simple@ietf.org > >Subject: Re: [Simple] Internal WG Review: Recharter of SIP for > >InstantMessaging and Presence Leveraging Extensions (simple) > > > >Wasn't there some talk of a need to specify how to choose > >between MESSAGE and MSRP, and/or to transition between them in > >support of a single conversation? > > > >E.g. send a MESSAGE because there may never be a conversation, > >but then INVITE with an MSRP session to continue the > >conversation. The need here would be for a way to tie these > >things together so it is clear that they are part of the same > >conversation. There are obviously issues with involving the > >same pair of UAs in both. > > > >I seem to recall this was discussed at some point, but I'm not > >sure and if so I don't remember the outcome. > > > > Paul > > > >IESG Secretary wrote: > >> A new charter for the SIP for Instant Messaging and Presence > >> Leveraging Extensions (simple) working group in the Real-time > >> Applications and Infrastructure Area of the IETF is being > >considered. > >> The draft charter is provided below for your review and comment. > >> > >> Review time is one week. > >> > >> The IETF Secretariat > >> > >> +++ > >> > >> SIP for Instant Messaging and Presence Leveraging Extensions > >(simple) > >> > >====================================================================== > >> > >> Last Modified: 2007-1-24 > >> > >> Current Status: Active Working Group > >> > >> Chair(s): > >> Robert Sparks > >> Hisham Khartabil > >> > >> > >> Real-time Applications and Infrastructure Area Director(s): > >> Jon Peterson Cullen Jennings > >> > >> > >> Real-time Applications and Infrastructure Area Advisor: > >> Jon Peterson > >> > >> Technical Advisor(s): > >> Jon Peterson > >> > >> Mailing Lists: > >> General Discussion: simple@ietf.org > >> To Subscribe: simple-request@ietf.org > >> In Body: subscribe > >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html > >> > >> Description of Working Group: > >> > >> This working group focuses on the application of the Session > >> Initiation Protocol (SIP, RFC 3261) to the suite of services > >> collectively known as instant messaging and presence (IMP). The IETF > >> has committed to producing an interoperable standard for these > >> services compliant to the requirements for IM outlined in RFC 2779 > >> (including the security and privacy requirements there) and in the > >> Common Presence and Instant Messaging (CPIM) specification, > >developed > >> within the IMPP working group. As the most common services for which > >> SIP is used share quite a bit in common with IMP, the adaptation of > >> SIP to IMP seems a natural choice given the widespread support for > >> (and relative maturity of) the SIP standard. > >> > >> This group has completed the majority of its primary goals and will > >> focus on the remaining tasks documented here and concluding. Any > >> proposed new work should be socialized with the chairs and > >AD early to > >> determine if this WG is an appropriate venue. > >> > >> The primary remaining work of this group will be to complete: > >> > >> 1. The MSRP proposed standard mechanism for transporting sessions of > >> messages initiated using the SIP, compliant to the > >requirments of RFC > >> 2779, CPIM and BCP 41. > >> > >> 2. The XCAP framework for representing and carrying > >configuration and > >> policy information in SIMPLE systems. > >> > >> 3. A mechanism for representing partial changes (patches) to XML > >> documents and extensions to the SIMPLE publication and notification > >> mechanisms to convey these partial changes. > >> > >> 4. A mechanism for initiating and managing Instant Message > >group chat. > >> > >> 5. An annotated overview of the SIMPLE protocol definition documents. > >> > >> Any SIP extensions proposed in the course of this development will, > >> after a last call process, be transferred to the SIP WG for > >> consideration as formal SIP extensions. > >> > >> Any mechanisms created for managing Instant Message group chat are > >> intended to provide a bridge to the conferencing protocols that will > >> be defined in XCON. They will be limited in scope to address only > >> simple Instant Message chat with nicknames and will not attempt to > >> address complex conferencing concepts such as sidebars. Their design > >> must anticipate operating in conjunction with the conferencing > >> protocols XCON is working towards. > >> > >> The working group will work within the framework for presence and IM > >> described in RFC 2778. The extensions it defines must also be > >> compliant with the SIP processes for extensions. The group cannot > >> modify baseline SIP behavior or define a new version of SIP > >for IM and > >> presence. If the group determines that any capabilities requiring an > >> extension to SIP are needed, the group will seek to define such > >> extensions within the SIP working group, and then use them here. > >> > >> Goals and Milestones: > >> Done Submission of event package for presence to IESG for > >publication > >> as Proposed Standard Done Submission of watcher information > >drafts to > >> IESG for publication as Proposed Standards Done Submission > >of proposed > >> event list mechanism to the SIP working group Done Submission of > >> requirements for event publishing to the IESG for publication as > >> Proposed Standard Done Submission of proposed mechanism for event > >> publishing to the SIP working group Done Submission of SIMPLE PIDF > >> profile to IESG for publication as Proposed Standard Done Submission > >> of base XCAP draft to IESG for publication as Proposed Standard Done > >> Submission of indication of instant message preparation using SIP to > >> IESG for publication as a Proposed Standard Done Submission of XCAP > >> usage for manipulation of presence document content Done > >Submission of > >> XCAP usage for setting presence authorization to IESG for > >publication > >> as Proposed Standard Done Submission of Filtering mechanisms to IESG > >> for publication as a Proposed Standard Done Submission of instant > >> messaging session draft to IESG for publication as a > >Proposed Standard > >> Done Submission of instant messaging session relay drafts to > >IESG for > >> publication as Proposed Standards Done Submission of Partial > >> Notification mechanism to IESG for publication as a Proposed > >Standard > >> Feb 2007 Submission of an Instant Message Disposition Notification > >> mechanism to the IESG for publication as a Proposed Standard > >Feb 2007 > >> Submission of XCAP event package to IESG or appropriate > >working group > >> targeting publication as Proposed Standard Feb 2007 Submission of > >> proposed mechanisms meeting the advanced messaging > >requirements to the > >> IESG or appropriate working group Mar 2007 Submission of a > >performance > >> and scalability analysis of the SIMPLE presence mechanisms > >to the IESG > >> for publication as Informational Jun 2007 Submission of SIMPLE > >> protocol annotated overview draft to IESG for publication as > >> Informational Aug 2007 Submission of proposed mechanisms for > >> initiating and managing Instant Message group chat to the IESG for > >> publication as Proposed Standard Aug 2007 Conclusion of SIMPLE > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 08:03:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3U1-0003Wn-Po; Mon, 05 Feb 2007 08:02:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3Tz-0003UQ-Qo for simple@ietf.org; Mon, 05 Feb 2007 08:02:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE3Tt-0008S9-7F for simple@ietf.org; Mon, 05 Feb 2007 08:02:07 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C9C8208A7; Mon, 5 Feb 2007 14:01:58 +0100 (CET) X-AuditID: c1b4fb3c-b1fccbb0000007de-fc-45c72ac6a649 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 70D40520001; Mon, 5 Feb 2007 14:01:58 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 14:01:41 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 14:01:41 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6AC36236E; Mon, 5 Feb 2007 15:01:41 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2FEBE4DBB4; Mon, 5 Feb 2007 15:01:41 +0200 (EET) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CA4F84DA95; Mon, 5 Feb 2007 15:01:40 +0200 (EET) Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt From: "Salvatore Loreto (JO/LMF)" To: Miguel Garcia In-Reply-To: <45C7093A.2000307@nokia.com> References: <45C7093A.2000307@nokia.com> Content-Type: text/plain Date: Mon, 05 Feb 2007 15:02:20 +0200 Message-Id: <1170680541.3489.36.camel@n95.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 05 Feb 2007 13:01:41.0632 (UTC) FILETIME=[C7B25800:01C74925] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi , some comments in line br /sal On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: > Hi: > > So, a summary of draft-stafford-simple-dmdn is that there is a use case > that is not covered by the current IMDN, which is: > > - An MSRP session is intercepted by a store-and-forward server. The > sender would like to be informed when the final recipient receives or > reads the message(s). > > One first question about the use case. It appears form the text in the > draft that the use case applies only to large messages. However, I can > envision store-and-forward servers that store a complete MSRP session > (not only ONE large message). you are right, if you have a store-and-forward in the path this is a possible scenario, even if I can not imagine at present a specific use case. (e.g. Why someone would establish a MSRP session with an off-line user and start to chat with him?) > > I think it is important to consider these collections of MSRP messages, > because, imagine we add something to the CPIM headers of each MSRP SEND > requesting delivery disposition notification, then the sender will > receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND > request. I guess this is not reasonable. I agree. A solution could be that the store-and-forward server collect all the message in one single big message, but in this case it shouldn't be any more a simple store-and-forward. > > On the other hand, if there isn't a store-and-forward server in the > path, then there is no need for the sender to receive additional > notifications, because the success reports in MSRP will do the job. > > So, I guess where we are going is to get some sort of conditional IMDN > for MSRP. The condition being the unavailability of the recipient to get > the messages and a store-and-forward server storing them. This will > obviously apply to either large messages or short ones. I don't have a clear view on this, but maybe if we introduce a indication that an MRSP session is established for just sending one message, this indication could help. > Any views on this? > > BR, > > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 08:12:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3do-0000nP-7v; Mon, 05 Feb 2007 08:12:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3dm-0000n1-UN for simple@ietf.org; Mon, 05 Feb 2007 08:12:14 -0500 Received: from extmail06.cingular.com ([170.35.209.249] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE3dl-0001Dn-Kk for simple@ietf.org; Mon, 05 Feb 2007 08:12:14 -0500 Received: from ([10.152.130.27]) by extmail06.cingular.com with ESMTP id KP-TRPY2.124815391; Mon, 05 Feb 2007 08:11:40 -0500 Received: from WWDCEXCH05.US.Cingular.Net ([10.152.130.167]) by wd07xsmtp001.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 08:11:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Mon, 5 Feb 2007 08:11:39 -0500 Message-ID: <2CD978485EFA9D4EBB6091522D1B10B506778D16@WWDCEXCH05.US.Cingular.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJJmWRLfF8LH5ZS9GvpvEcuWGLkAAAFFJQ To: "Salvatore Loreto \(JO/LMF\)" , "Miguel Garcia" X-OriginalArrivalTime: 05 Feb 2007 13:11:39.0995 (UTC) FILETIME=[2C594AB0:01C74927] From: "Shih, Jerry" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Actually, in OMA LARGE message definition, it is a one direction (send-only) session, not really a regular MSRP session; so no chat in this case. It is used as a one-shot message and the only reason it needs to set-up a session is because it is over the MESSAGE method size. The sending UE knows (but the user will not know that) that it is a one-time message when it sets up the session (send-only). Jerry Shih Cingular Wireless, now the new AT&T +1 404.236.5902 (Office) +1 678.925.3568 (Mobile) -----Original Message----- From: Salvatore Loreto (JO/LMF) [mailto:salvatore.loreto@ericsson.com]=20 Sent: Monday, February 05, 2007 8:02 AM To: Miguel Garcia Cc: 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Hi , some comments in line br /sal On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: > Hi: >=20 > So, a summary of draft-stafford-simple-dmdn is that there is a use case=20 > that is not covered by the current IMDN, which is: >=20 > - An MSRP session is intercepted by a store-and-forward server. The=20 > sender would like to be informed when the final recipient receives or=20 > reads the message(s). >=20 > One first question about the use case. It appears form the text in the > draft that the use case applies only to large messages. However, I can > envision store-and-forward servers that store a complete MSRP session=20 > (not only ONE large message). you are right, if you have a store-and-forward in the path this is a possible scenario, even if I can not imagine at present a specific use case. (e.g. Why someone would establish a MSRP session with an off-line user and start to chat with him?) >=20 > I think it is important to consider these collections of MSRP messages,=20 > because, imagine we add something to the CPIM headers of each MSRP SEND=20 > requesting delivery disposition notification, then the sender will=20 > receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND=20 > request. I guess this is not reasonable. I agree.=20 A solution could be that the store-and-forward server collect all the message in one single big message, but in this case it shouldn't be any more a simple store-and-forward. >=20 > On the other hand, if there isn't a store-and-forward server in the=20 > path, then there is no need for the sender to receive additional=20 > notifications, because the success reports in MSRP will do the job. >=20 > So, I guess where we are going is to get some sort of conditional IMDN > for MSRP. The condition being the unavailability of the recipient to get=20 > the messages and a store-and-forward server storing them. This will=20 > obviously apply to either large messages or short ones. I don't have a clear view on this, but maybe if we introduce a indication that an MRSP session is established for just sending one message, this indication could help. > Any views on this? >=20 > BR, >=20 > Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 08:17:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3in-0001wH-1j; Mon, 05 Feb 2007 08:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3il-0001vD-P7 for simple@ietf.org; Mon, 05 Feb 2007 08:17:23 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE3ik-0001yv-AC for simple@ietf.org; Mon, 05 Feb 2007 08:17:23 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15DEVQr008344; Mon, 5 Feb 2007 15:14:51 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 15:17:02 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 15:16:42 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 15:16:41 +0200 Message-ID: <45C72E4D.8090808@nokia.com> Date: Mon, 05 Feb 2007 15:17:01 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Salvatore Loreto (JO/LMF)" Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt References: <45C7093A.2000307@nokia.com> <1170680541.3489.36.camel@n95.nomadiclab.com> In-Reply-To: <1170680541.3489.36.camel@n95.nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 13:16:41.0968 (UTC) FILETIME=[E056B700:01C74927] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Some inline discussion: Salvatore Loreto (JO/LMF) wrote: > Hi , > > some comments in line > > br > /sal > > On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: >> Hi: >> >> So, a summary of draft-stafford-simple-dmdn is that there is a use case >> that is not covered by the current IMDN, which is: >> >> - An MSRP session is intercepted by a store-and-forward server. The >> sender would like to be informed when the final recipient receives or >> reads the message(s). >> >> One first question about the use case. It appears form the text in the >> draft that the use case applies only to large messages. However, I can >> envision store-and-forward servers that store a complete MSRP session >> (not only ONE large message). > > you are right, if you have a store-and-forward in the path this is a > possible scenario, even if I can not imagine at present a specific use > case. (e.g. Why someone would establish a MSRP session with an off-line > user and start to chat with him?) Well, look at commercial systems. They do it. I can do it. I actually do it... I establish a session with some offline friend to send a few messages, or pending items, such as my latest pictures. This is a real use case. >> I think it is important to consider these collections of MSRP messages, >> because, imagine we add something to the CPIM headers of each MSRP SEND >> requesting delivery disposition notification, then the sender will >> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND >> request. I guess this is not reasonable. > > I agree. > A solution could be that the store-and-forward server collect all the > message in one single big message, but in this case it shouldn't be any > more a simple store-and-forward. Certainly that is one possibility. Another one is to promote the IMDN request to the INVITE, and provide a "session-level" IMDN. In any case, I think these should be dependent on the presence of a store-and-forward server in the path. /Miguel > >> On the other hand, if there isn't a store-and-forward server in the >> path, then there is no need for the sender to receive additional >> notifications, because the success reports in MSRP will do the job. >> >> So, I guess where we are going is to get some sort of conditional IMDN >> for MSRP. The condition being the unavailability of the recipient to get >> the messages and a store-and-forward server storing them. This will >> obviously apply to either large messages or short ones. > > I don't have a clear view on this, > but maybe if we introduce a indication that an MRSP session is > established for just sending one message, this indication could help. > > >> Any views on this? >> >> BR, >> >> Miguel > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 08:39:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE440-0005p6-Md; Mon, 05 Feb 2007 08:39:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE43z-0005oy-Rs for simple@ietf.org; Mon, 05 Feb 2007 08:39:19 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE43p-0005ri-Rt for simple@ietf.org; Mon, 05 Feb 2007 08:39:19 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2C68520699; Mon, 5 Feb 2007 14:39:05 +0100 (CET) X-AuditID: c1b4fb3c-af7c7bb0000007de-1e-45c73379a950 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0DD3E204FE; Mon, 5 Feb 2007 14:39:05 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 14:39:04 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 14:39:04 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 01A5B26CD; Mon, 5 Feb 2007 15:39:03 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 848774DBB4; Mon, 5 Feb 2007 15:39:03 +0200 (EET) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 28A0B4DA95; Mon, 5 Feb 2007 15:39:03 +0200 (EET) Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt From: "Salvatore Loreto (JO/LMF)" To: Miguel Garcia In-Reply-To: <45C72E4D.8090808@nokia.com> References: <45C7093A.2000307@nokia.com> <1170680541.3489.36.camel@n95.nomadiclab.com> <45C72E4D.8090808@nokia.com> Content-Type: text/plain Date: Mon, 05 Feb 2007 15:39:43 +0200 Message-Id: <1170682783.3489.55.camel@n95.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 05 Feb 2007 13:39:04.0247 (UTC) FILETIME=[00663C70:01C7492B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Miguel, see the discussion on line br /sal > > On Mon, 2007-02-05 at 12:38 +0200, Miguel Garcia wrote: > >> Hi: > >> > >> So, a summary of draft-stafford-simple-dmdn is that there is a use case > >> that is not covered by the current IMDN, which is: > >> > >> - An MSRP session is intercepted by a store-and-forward server. The > >> sender would like to be informed when the final recipient receives or > >> reads the message(s). > >> > >> One first question about the use case. It appears form the text in the > >> draft that the use case applies only to large messages. However, I can > >> envision store-and-forward servers that store a complete MSRP session > >> (not only ONE large message). > > > > you are right, if you have a store-and-forward in the path this is a > > possible scenario, even if I can not imagine at present a specific use > > case. (e.g. Why someone would establish a MSRP session with an off-line > > user and start to chat with him?) > > > Well, look at commercial systems. They do it. I can do it. I actually do > it... I establish a session with some offline friend to send a few > messages, or pending items, such as my latest pictures. This is a real > use case. Yes I am aware that some IM programs behave in this way. What I don't see is the necessity to have or provide a delivery notification in this scenario, and in fact they don't do. But I understand and fully agree with your concern about adding some header for Deliver Notification in the CPIM headers of each MSRP SEND request. > > > >> I think it is important to consider these collections of MSRP messages, > >> because, imagine we add something to the CPIM headers of each MSRP SEND > >> requesting delivery disposition notification, then the sender will > >> receive one MESSAGE request (message 15 in Figure 1) per MSRP SEND > >> request. I guess this is not reasonable. > > > > I agree. > > A solution could be that the store-and-forward server collect all the > > message in one single big message, but in this case it shouldn't be any > > more a simple store-and-forward. > > Certainly that is one possibility. Another one is to promote the IMDN > request to the INVITE, and provide a "session-level" IMDN. yes, promoting the IMDN request to the INVITE could work in both the scenario: the only one large message and several short/normal messages. It can say to the final recipient to send an IMDN to the original sender when as soon as he has received the whole large message or all the short messages. For example as soon the store and forward server close the MSRP session. But promoting the IMDN request to the INVITE levels means we have also put at this level same information about the original sender. what do you think about? > > In any case, I think these should be dependent on the presence of a > store-and-forward server in the path. > > > > /Miguel > > > > > >> On the other hand, if there isn't a store-and-forward server in the > >> path, then there is no need for the sender to receive additional > >> notifications, because the success reports in MSRP will do the job. > >> > >> So, I guess where we are going is to get some sort of conditional IMDN > >> for MSRP. The condition being the unavailability of the recipient to get > >> the messages and a store-and-forward server storing them. This will > >> obviously apply to either large messages or short ones. > > > > I don't have a clear view on this, > > but maybe if we introduce a indication that an MRSP session is > > established for just sending one message, this indication could help. > > > > > >> Any views on this? > >> > >> BR, > >> > >> Miguel > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 08:45:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE49o-0000uP-9d; Mon, 05 Feb 2007 08:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE49n-0000nV-31 for simple@ietf.org; Mon, 05 Feb 2007 08:45:19 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE47k-0006gX-RO for simple@ietf.org; Mon, 05 Feb 2007 08:43:14 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15DdWjE016550; Mon, 5 Feb 2007 15:39:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 15:42:55 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 15:42:35 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 15:42:34 +0200 Message-ID: <45C7345E.5060208@nokia.com> Date: Mon, 05 Feb 2007 15:42:54 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Salvatore Loreto (JO/LMF)" Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt References: <45C7093A.2000307@nokia.com> <1170680541.3489.36.camel@n95.nomadiclab.com> <45C72E4D.8090808@nokia.com> <1170682783.3489.55.camel@n95.nomadiclab.com> In-Reply-To: <1170682783.3489.55.camel@n95.nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 13:42:34.0576 (UTC) FILETIME=[7DC3E500:01C7492B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Salvatore Loreto (JO/LMF) wrote: > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do > you think about? > I think it is not a straight forward option. At least, I would like to re-use IMDN as much as possible. Including IMDN requests in INVITE requests is not feasible today, since IMDN requests are embedded in CPIM messages, and we don't have CPIM in INVITE requests. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 20:15:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEEui-0006hZ-UU; Mon, 05 Feb 2007 20:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEEuh-0006hM-SU for simple@ietf.org; Mon, 05 Feb 2007 20:14:27 -0500 Received: from maillog.itri.org.tw ([61.61.254.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEEuc-0006lA-Qi for simple@ietf.org; Mon, 05 Feb 2007 20:14:27 -0500 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.12.10/8.12.10) with ESMTP id l161EdVR017091; Tue, 6 Feb 2007 09:14:40 +0800 (CST) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id l161Gph4001387; Tue, 6 Feb 2007 09:16:51 +0800 (CST) Received: from ms1.itri.org.tw ([140.96.147.43]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id l161GpCZ001384; Tue, 6 Feb 2007 09:16:51 +0800 (CST) Received: from 52092035393 ([140.96.147.156]) by ms1.itri.org.tw (Lotus Domino Release 7.0.1FP1) with ESMTP id 2007020609135765-13674 ; Tue, 6 Feb 2007 09:13:57 +0800 From: =?big5?B?pvOt9b6xaG9jcw==?= To: "'Simple WG'" , Subject: [simple] [Sip-implementors] XCAP Server for list uage implementation (how to limit the number of sub-element>?) Date: Tue, 6 Feb 2007 09:18:22 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdEuv6mNsflTfN+TOSUhB8asVMshgAChTawAAKbUiAAAF8LQAAqRitQABkKCWA= In-Reply-To: <200702010028.l110Sp2b012445@myspam.itri.org.tw> X-MIMETrack: Itemize by SMTP Server on MS4/ITRI(Release 7.0.1FP1 | May 25, 2006) at 2007-02-01 16:58:10, Serialize by Router on MS4/ITRI(Release 7.0.1FP1 | May 25, 2006) at 2007-02-01 16:58:10, Serialize complete at 2007-02-01 16:58:10, Itemize by SMTP Server on ITRISMTP6/ITRI(Release 7.0.1FP1|April 17, 2006) at 02/02/2007 01:27:45 PM, Serialize by POP3 Server on MS3/ITRI(Release 7.0.1FP1 | May 25, 2006) at 2007-02-02 13:28:33, Serialize complete at 2007-02-02 13:28:33, Itemize by SMTP Server on MS1/ITRI(Release 7.0.1FP1 | May 25, 2006) at 2007-02-06 09:13:57, Serialize by Router on MS1/ITRI(Release 7.0.1FP1 | May 25, 2006) at 2007-02-06 09:13:58, Serialize complete at 2007-02-06 09:13:58 x-mail: myspam.itri.org.tw l125QsXH001132 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 x-perlmx-spam: Gauge=IIIIIIII, Probability=8%, X-Seen-By filter1.cs.columbia.edu x-mailman-version: 2.1.6 x-mss: DELAYRELEASE@myspam.itri.org.tw x-beenthere: sip-implementors@cs.columbia.edu Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: simple@ietf.org Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dear there, I didn't get any response, so I post my question again. Any feedback is welcome. The question is described as followings, I would like to ask a question about XCAP List Usage implementation. If I want to implement a XCAP Server providing rls-services document manipulation, but I want to limit the number of under the element, that is per list has a maximum number of 200 sub-elements. Is the XCAP Server allowed to do this? When a XCAP Client want to put an entry but exceed this limitation, what XCAP Server should respond to client (return an error code?) Thanks in advance. BR, Jeffrey %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 20:45:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFOM-0003Mr-7H; Mon, 05 Feb 2007 20:45:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFOK-0003Kd-V7 for simple@ietf.org; Mon, 05 Feb 2007 20:45:04 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEFOJ-0004cR-KC for simple@ietf.org; Mon, 05 Feb 2007 20:45:04 -0500 Received: by nf-out-0910.google.com with SMTP id l36so22314nfa for ; Mon, 05 Feb 2007 17:45:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i3oNWh62Ocu++36kLtWFx1qh20CLFBoQQKL4abCiT+q1JrW3wvLfbWo04BEWjOIBT/1Ac5cbHDCHy+1hAX6sOUovbS0kIemeM9/2M8UslxHqrv5o7Ov5hGLyq1Arto/+C0iwZKAC/3t5nkCSIQ69oN9YaNESgP72kklHPK7MgvU= Received: by 10.82.111.8 with SMTP id j8mr3184019buc.1170726302711; Mon, 05 Feb 2007 17:45:02 -0800 (PST) Received: by 10.82.113.20 with HTTP; Mon, 5 Feb 2007 17:44:58 -0800 (PST) Message-ID: <66cd252f0702051744t581f7f99s37f060c574e75ce0@mail.gmail.com> Date: Tue, 6 Feb 2007 12:45:00 +1100 From: "Hisham Khartabil" To: "Ben Campbell" In-Reply-To: <06239BA4-97E3-489F-A367-FCD86660F2B4@estacado.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <06239BA4-97E3-489F-A367-FCD86660F2B4@estacado.net> X-Spam-Score: 0.6 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Simple WG , Eric Burger , Robert Sparks Subject: [Simple] Re: IMDN-02 WGLC comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Ben, Thanks for your comments. Some replies inline... On 24/12/06, Ben Campbell wrote: > > We use the term "address" a lot when we really mean "URI". They are > not interchangeable terms. Can you clarify the difference? > Section 7.1.3: > > I mentioned this on the previous draft, but I missed any discussion > or change due to that comment, so I will make it again. I don't see > the value of allowing the sender to request aggregation, considering > that the list server has no obligation to pay any attention. Since > aggregation policy has a major affect on URI list server performance > and scalability, I doubt _anyone_ will configure such a server to pay > attention to sender preferences for aggregation. IMHO, the ability > for the sender to request whether aggregation will be used or not > adds no value to justify the complexity. Yes, you are right. I will remove that complexity. > 7.2.1: Second paragraph: put quotes around "processing". > > Paragraph 4: What is the motivation for requiring the Message-ID CPIM > header field in an IMDN, since you can't send an IMDN to an IMDN? That was a topic of the that IETF meeting. We agreed to make it that way since Eric pointed out that there might be future use for it. No one objected. > > Section 10: Do we reference the constructions for URI and "token" > somewhere? Also, shouldn't we use a more general construction for > [ Formal-name ] "<" URI ">"? (such as addrspec?) That's ok. This is a copy of the To header field definition in CPIM. > > Section 11.1.5 : If there was any normative language requiring the IM > recipient to do something with , I missed it. There are none. > > 12.2: > > Paragraph 6: Why "MAY"? are we allowing an intermediary to consume > "processing" notices from downstream without forwarding them back > upstream? No, its saying that the intermeidary may *generate*. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 05 22:31:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEH25-0000Gr-Ug; Mon, 05 Feb 2007 22:30:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEH25-0000Gi-2D for simple@ietf.org; Mon, 05 Feb 2007 22:30:13 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEH23-0007fq-MJ for simple@ietf.org; Mon, 05 Feb 2007 22:30:13 -0500 Received: from [10.0.1.3] (adsl-68-94-4-7.dsl.rcsntx.swbell.net [68.94.4.7]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l163TtLf020909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Feb 2007 21:29:59 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <66cd252f0702051744t581f7f99s37f060c574e75ce0@mail.gmail.com> References: <06239BA4-97E3-489F-A367-FCD86660F2B4@estacado.net> <66cd252f0702051744t581f7f99s37f060c574e75ce0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34BE63B0-74B3-4A4E-B409-1E7381536E54@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Mon, 5 Feb 2007 21:29:52 -0600 To: "Hisham Khartabil" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.6 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Simple WG , Eric Burger , Robert Sparks Subject: [Simple] Re: IMDN-02 WGLC comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Feb 5, 2007, at 7:45 PM, Hisham Khartabil wrote: > Hi Ben, > > Thanks for your comments. Some replies inline... > > On 24/12/06, Ben Campbell wrote: > >> >> We use the term "address" a lot when we really mean "URI". They are >> not interchangeable terms. > > Can you clarify the difference? A URI is an identifier at a higher level than an address, assuming most people associate the term "address" with IP address. A URI can contain a user part, for example, that identifies an account, user, inbox, etc at a domain. That is, it can map to more than just an address. > > >> Section 7.1.3: >> >> I mentioned this on the previous draft, but I missed any discussion >> or change due to that comment, so I will make it again. I don't see >> the value of allowing the sender to request aggregation, considering >> that the list server has no obligation to pay any attention. Since >> aggregation policy has a major affect on URI list server performance >> and scalability, I doubt _anyone_ will configure such a server to pay >> attention to sender preferences for aggregation. IMHO, the ability >> for the sender to request whether aggregation will be used or not >> adds no value to justify the complexity. > > Yes, you are right. I will remove that complexity. > >> 7.2.1: Second paragraph: put quotes around "processing". >> >> Paragraph 4: What is the motivation for requiring the Message-ID CPIM >> header field in an IMDN, since you can't send an IMDN to an IMDN? > > That was a topic of the that IETF meeting. We agreed to make it that > way since Eric pointed out that there might be future use for it. No > one objected. Okay. Sorry, I must have had too much beer ;-) > > >> >> Section 10: Do we reference the constructions for URI and "token" >> somewhere? Also, shouldn't we use a more general construction for >> [ Formal-name ] "<" URI ">"? (such as addrspec?) > > That's ok. This is a copy of the To header field definition in CPIM. I'm not sure which of the two parts of my comment you refer to with "That's okay". If the second part, if that is how CPIM defines it and we are just copying from CPIM, then I am okay with it. If the first part (URI and "token"), then these terms have no normative meaning unless they are either referenced or defined, right? > >> >> Section 11.1.5 : If there was any normative language requiring the IM >> recipient to do something with , I missed it. > > There are none. Then under what circumstances will the recipient copy a subject into ? > >> >> 12.2: > >> >> Paragraph 6: Why "MAY"? are we allowing an intermediary to consume >> "processing" notices from downstream without forwarding them back >> upstream? > > No, its saying that the intermeidary may *generate*. I'm not sure what I was thinking at the time--I assume it is okay if multiple intermediaries send a "processing" IMDN to the same message, right? > > Thanks, > Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 06 11:52:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETXh-0006rC-6T; Tue, 06 Feb 2007 11:51:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETXg-0006qz-1D for simple@ietf.org; Tue, 06 Feb 2007 11:51:40 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HETXd-00089n-Fx for simple@ietf.org; Tue, 06 Feb 2007 11:51:40 -0500 Received: from [172.17.2.71] ([172.17.2.71]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l16GpMsD003443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Feb 2007 10:51:22 -0600 (CST) (envelope-from emcmurry@estacado.net) In-Reply-To: <34BE63B0-74B3-4A4E-B409-1E7381536E54@estacado.net> References: <06239BA4-97E3-489F-A367-FCD86660F2B4@estacado.net> <66cd252f0702051744t581f7f99s37f060c574e75ce0@mail.gmail.com> <34BE63B0-74B3-4A4E-B409-1E7381536E54@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03BC7F21-DA8B-4DAA-94FD-3DA95BB4A11F@estacado.net> Content-Transfer-Encoding: 7bit From: Eric McMurry Subject: Re: [Simple] Re: IMDN-02 WGLC comments Date: Tue, 6 Feb 2007 10:51:12 -0600 To: Ben Campbell X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Robert Sparks , Simple WG , Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Feb 5, 2007, at 9:29 PM, Ben Campbell wrote: > > On Feb 5, 2007, at 7:45 PM, Hisham Khartabil wrote: > > >> Hi Ben, >> >> Thanks for your comments. Some replies inline... >> >> On 24/12/06, Ben Campbell wrote: >> >> >>> >>> >> >> >>> >>> Paragraph 6: Why "MAY"? are we allowing an intermediary to consume >>> "processing" notices from downstream without forwarding them back >>> upstream? >>> >> >> No, its saying that the intermeidary may *generate*. >> > > I'm not sure what I was thinking at the time--I assume it is okay > if multiple intermediaries send a "processing" IMDN to the same > message, right? > It seems reasonable for this to happen. Consider the case of an exploder followed by a store and forward server. A "processing" IMDN could be sent by the exploder followed by one or more "stored" IMDNs. > > >> >> Thanks, >> Hisham >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 07 02:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgmB-00078M-HY; Wed, 07 Feb 2007 01:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgmA-00078C-Ab for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEgm5-0005x4-Os for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l176xLej005164; Wed, 7 Feb 2007 00:59:21 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 00:59:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Wed, 7 Feb 2007 01:59:15 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502906B43@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <45C7345E.5060208@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJLLd0xL7iQuDFQEyjNxalySfZ0gBVdXMg From: "Nancy Greene \(QA/EMC\)" To: "Miguel Garcia" , "Salvatore Loreto \(JO/LMF\)" X-OriginalArrivalTime: 07 Feb 2007 06:59:20.0952 (UTC) FILETIME=[7E115780:01C74A85] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org We can have CPIM in an MSRP SEND though, so that is where we should be concentrating. Especially if we have this large message mode where only one message is sent within the SIP session and that is the one that is actually deferred. Nancy=20 -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Monday, February 05, 2007 8:43 AM To: Salvatore Loreto (JO/LMF) Cc: 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Salvatore Loreto (JO/LMF) wrote: > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do=20 > you think about? >=20 I think it is not a straight forward option. At least, I would like to re-use IMDN as much as possible. Including IMDN requests in INVITE requests is not feasible today, since IMDN requests are embedded in CPIM messages, and we don't have CPIM in INVITE requests. /Miguel --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 07 02:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgmD-00078U-2A; Wed, 07 Feb 2007 01:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4From simple-bounces@ietf.org Wed Feb 07 02:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgmB-00078M-HY; Wed, 07 Feb 2007 01:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgmA-00078C-Ab for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEgm5-0005x4-Os for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l176xLej005164; Wed, 7 Feb 2007 00:59:21 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 00:59:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Date: Wed, 7 Feb 2007 01:59:15 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502906B43@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <45C7345E.5060208@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Thread-Index: AcdJLLd0xL7iQuDFQEyjNxalySfZ0gBVdXMg From: "Nancy Greene \(QA/EMC\)" To: "Miguel Garcia" , "Salvatore Loreto \(JO/LMF\)" X-OriginalArrivalTime: 07 Feb 2007 06:59:20.0952 (UTC) FILETIME=[7E115780:01C74A85] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org We can have CPIM in an MSRP SEND though, so that is where we should be concentrating. Especially if we have this large message mode where only one message is sent within the SIP session and that is the one that is actually deferred. Nancy=20 -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Monday, February 05, 2007 8:43 AM To: Salvatore Loreto (JO/LMF) Cc: 'simple@ietf.org' Subject: Re: [Simple] Comments to draft-stafford-simple-dmdn-00.txt Salvatore Loreto (JO/LMF) wrote: > But promoting the IMDN request to the INVITE levels means we have also > put at this level same information about the original sender. what do=20 > you think about? >=20 I think it is not a straight forward option. At least, I would like to re-use IMDN as much as possible. Including IMDN requests in INVITE requests is not feasible today, since IMDN requests are embedded in CPIM messages, and we don't have CPIM in INVITE requests. /Miguel --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 07 02:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgmD-00078U-2A; Wed, 07 Feb 2007 01:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgmA-00078H-Sl for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEgm8-0005y4-C0 for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l177MZkx015563; Wed, 7 Feb 2007 01:22:35 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 00:59:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification Date: Wed, 7 Feb 2007 01:59:18 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502906B44@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3609A6E355@TBDCEXCH10.US.Cingular.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New Draft: Deferred Messaging Disposition Notification Thread-Index: AccivrzyD0uDK4agSi2n0Jz4+p42YQZI/3SQANlhM6ACzrlyIA== From: "Nancy Greene \(QA/EMC\)" To: "Stafford, Matthew" , X-OriginalArrivalTime: 07 Feb 2007 06:59:24.0889 (UTC) FILETIME=[806A1490:01C74A85] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Shih, Jerry" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I have a couple of comments on the DMDN draft: - in the flow in fig 1, it seems that steps 11-12 need to be followed by a step 12 a carrying a REPORT going from Bob's UA to the App server. This report, whether it is a success REPORT or failure REPORT is then translated into an IMDN in a SIP MESSAGE as shown in steps 15-16. Note that the BYE in steps 13-14 needs to be moved to be after the IMDN SIP MESSAGE in steps 15-16.=20 - to set the IMDN Route header, it seems it would be straightforward - any Record-Route header in the INVITE kept when the message was deferred is later used to set the IMDN Route header in the SIP MESSAGE carrying the MSRP REPORT. Nancy -----Original Message----- From: Stafford, Matthew [mailto:matthew.stafford@cingular.com]=20 Sent: Tuesday, January 23, 2007 6:48 PM To: simple@ietf.org Cc: Shih, Jerry Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification Prague agenda item request: we would like to have a timeslot (20 minutes if possible) to present & discuss this draft. One of my co-authors, Jerry Shih, will be attending the session. Thanks, Matt -----Original Message----- From: Stafford, Matthew Sent: Friday, January 19, 2007 10:45 AM To: simple@ietf.org Cc: Wuthnow, Mark; Shih, Jerry Subject: [Simple] New Draft: Deferred Messaging Disposition Notification We had some discussion about a month ago re: pulling MSRP out of the IMDN draft. Thanks to Ben, Miguel and Hisham for their responses. I'd say the upshot of that discussion was twofold: the "slimmed-down" IMDN draft needs to go ahead, and any push to expand IMDN's applicability needs to start with clear documentation of requirements. Jointly with two colleagues at Cingular/AT&T, I have submitted an I-D to address the latter point. It is now posted at http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt This draft is intended to start the ball rolling by .43) id 1HEgmA-00078H-Sl for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEgm8-0005y4-C0 for simple@ietf.org; Wed, 07 Feb 2007 01:59:30 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l177MZkx015563; Wed, 7 Feb 2007 01:22:35 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 00:59:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification Date: Wed, 7 Feb 2007 01:59:18 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7502906B44@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3609A6E355@TBDCEXCH10.US.Cingular.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New Draft: Deferred Messaging Disposition Notification Thread-Index: AccivrzyD0uDK4agSi2n0Jz4+p42YQZI/3SQANlhM6ACzrlyIA== From: "Nancy Greene \(QA/EMC\)" To: "Stafford, Matthew" , X-OriginalArrivalTime: 07 Feb 2007 06:59:24.0889 (UTC) FILETIME=[806A1490:01C74A85] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Shih, Jerry" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I have a couple of comments on the DMDN draft: - in the flow in fig 1, it seems that steps 11-12 need to be followed by a step 12 a carrying a REPORT going from Bob's UA to the App server. This report, whether it is a success REPORT or failure REPORT is then translated into an IMDN in a SIP MESSAGE as shown in steps 15-16. Note that the BYE in steps 13-14 needs to be moved to be after the IMDN SIP MESSAGE in steps 15-16.=20 - to set the IMDN Route header, it seems it would be straightforward - any Record-Route header in the INVITE kept when the message was deferred is later used to set the IMDN Route header in the SIP MESSAGE carrying the MSRP REPORT. Nancy -----Original Message----- From: Stafford, Matthew [mailto:matthew.stafford@cingular.com]=20 Sent: Tuesday, January 23, 2007 6:48 PM To: simple@ietf.org Cc: Shih, Jerry Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification Prague agenda item request: we would like to have a timeslot (20 minutes if possible) to present & discuss this draft. One of my co-authors, Jerry Shih, will be attending the session. Thanks, Matt -----Original Message----- From: Stafford, Matthew Sent: Friday, January 19, 2007 10:45 AM To: simple@ietf.org Cc: Wuthnow, Mark; Shih, Jerry Subject: [Simple] New Draft: Deferred Messaging Disposition Notification We had some discussion about a month ago re: pulling MSRP out of the IMDN draft. Thanks to Ben, Miguel and Hisham for their responses. I'd say the upshot of that discussion was twofold: the "slimmed-down" IMDN draft needs to go ahead, and any push to expand IMDN's applicability needs to start with clear documentation of requirements. Jointly with two colleagues at Cingular/AT&T, I have submitted an I-D to address the latter point. It is now posted at http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt This draft is intended to start the ball rolling by presenting use cases. It makes a straw proposal that IMDN usage be extended to MSRP. (I do understand that there may be other, better ways to meet the requirements- but this draft still seems to be a reasonable starting point.) Best, Matt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple presenting use cases. It makes a straw proposal that IMDN usage be extended to MSRP. (I do understand that there may be other, better ways to meet the requirements- but this draft still seems to be a reasonable starting point.) Best, Matt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 07 03:58:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEicY-00037c-Cd; Wed, 07 Feb 2007 03:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEicW-00037X-MZ for simple@ietf.org; Wed, 07 Feb 2007 03:57:40 -0500 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEicS-0006Tz-Sj for simple@ietf.org; Wed, 07 Feb 2007 03:57:40 -0500 Received: from veyron.eu.tieto.com ([194.110.47.230]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 10:57:26 +0200 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 10:57:23 +0200 Received: from 10.15.1.32 ([10.15.1.32]) by sagaris.eu.tieto.com ([131.207.197.143]) via Exchange Front-End Server email2.tietoenator.com ([192.176.143.12]) with Microsoft Exchange Server HTTP-DAV ; Wed, 7 Feb 2007 08:57:22 +0000 Received: from brcalnik by email2.tietoenator.com; 07 Feb 2007 09:57:30 +0100 From: Martin Hynar To: jdrosen@cisco.com, IETF WG SIMPLE Date: Wed, 07 Feb 2007 09:57:30 +0100 Message-Id: <1170838650.3241.1.camel@brcalnik> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) X-OriginalArrivalTime: 07 Feb 2007 08:57:23.0842 (UTC) FILETIME=[FBCC9620:01C74A95] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [Simple] Possible ambiguous interpretation in xcap diff X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1959138287==" Errors-To: simple-bounces@ietf.org --===============1959138287== Content-Type: multipart/alternative; boundary="=-/2sEz+4fR1UYicA2OtL0" --=-/2sEz+4fR1UYicA2OtL0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, I have read last version (04) of the XCAP Diff Format and there is one thing in the schema that might cause ambiguous interpretation. In the text, there is clearly explained that is the root element with elements as children. However, the way how the elements are defined in the xml schema allows to start with element, omitting the intended element as a root. Both and elements are defined on the same level using declaration. This causes that these are equal in a way that they can be used as root. I would propose to change schema to define "type" of the element on the top level: ... and then define element as follows: ... ... This way, there will clear which of the two elements is the root. br, Martin +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 432 817 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --=-/2sEz+4fR1UYicA2OtL0 Content-Type: text/html; charset=utf-8 Hello,

I have read last version (04) of the XCAP Diff Format and there is one thing in the schema that might cause ambiguous interpretation. In the text, there is clearly explained that <xcap-diff> is the root element with <document> elements as children. However, the way how the elements are defined in the xml schema allows to start with <document> element, omitting the intended <xcap-diff> element as a root.

Both <xcap-diff> and <document> elements are defined on the same level using <element name="..."> declaration. This causes that these are equal in a way that they can be used as root. I would propose to change schema to define "type" of the <document> element on the top level:

<xs:complexType name="documentType">
  ...
</xs:complexType>

and then define <xcap-diff> element as follows:

<xs:element name="xcap-diff">
  ...
  <xs:element name="document" type="documentType"/>
  ...
</xs:element>

This way, there will clear which of the two elements is the root.

br, Martin



+-------------------------------------+
  Martin Hynar
  Software Specialist

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 432 817
  E-mail: Martin.Hynar@TietoEnator.com

  Vystavni 292/13
  CZ-709 16 Ostrava

www.tietoenator.com


Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.
--=-/2sEz+4fR1UYicA2OtL0-- --===============1959138287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1959138287==-- From simple-bounces@ietf.org Wed Feb 07 15:51:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtkC-0003VR-J4; Wed, 07 Feb 2007 15:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtjv-0003RR-FL; Wed, 07 Feb 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEtjv-0003Sd-17; Wed, 07 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EF1AE32997; Wed, 7 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtju-0001bG-PT; Wed, 07 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-06.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --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 : Publication of Partial Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-publish-06.txt Pages : 15 Date : 2007-2-7 The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-publish-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-publish-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-7112103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-publish-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-publish-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7112103.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 07 15:51:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtl5-0005IX-HU; Wed, 07 Feb 2007 15:51:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtkR-0003eJ-Ew; Wed, 07 Feb 2007 15:50:35 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEtkP-0002bK-5Z; Wed, 07 Feb 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DD8141760B; Wed, 7 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtju-0001ax-L8; Wed, 07 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-imdn-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Instant Message Disposition Notification Author(s) : E. Burger, H. Khartabil Filename : draft-ietf-simple-imdn-03.txt Pages : 34 Date : 2007-2-7 Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing and read notifications, for page-mode instant messages. The Common Profile for Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP entities behave using this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-imdn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-imdn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-7110852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-imdn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-imdn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7110852.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From hichwitbnj@rima-tde.net Wed Feb 07 16:53:13 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEuj3-0005Fk-Hl for simple-archive@lists.ietf.org; Wed, 07 Feb 2007 16:53:13 -0500 Received: from 152.red-83-41-44.dynamicip.rima-tde.net ([83.41.44.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEuj1-0002QD-Nx for simple-archive@lists.ietf.org; Wed, 07 Feb 2007 16:53:13 -0500 From: "Privacy Subscribe" To: simple-archive@lists.ietf.org Subject: Wall Street Alert! Date: Wed, 7 Feb 2007 22:53:07 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C74B0A.BBF72180" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdLCrv3cnaMhGCETzSsq728Nw7i4Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.9 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_NextPart_000_0000_01C74B0A.BBF72180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This one is on the move!! Who? *MGOA*

MGOA DOESN'T SLEEP IT WILL EXPLODE on Wednesday !!!!

Trade Date: Wednesday, Febuary 07, 2007
Organization: MEGOLA Inc. Enviromental Solutions
Ticker: MGOA
Current: $0.065 +0.006 +10.2%
Short Term Target: $0.50

Megola Inc. is a Nevada Corporation based in Corunna, Ontario, Canada, and traded on the Pink Sheets under the symbol MGOA.

Megola Inc. is committed to solving environmental problems without the use of harsh chemicals that, in the long run, can have deleterious effects on company budgets and our environment. Megola Inc. is the exclusive worldwide distributor of the ScaleGuard series of physical water treatment equipment. Megola Inc. has created a distribution network throughout the world in which many companies are having great success as the ScaleGuard family continues to perform admirably.

Now go check your favorite news source. Check your Level 2 market data. You will see that MGOA is set for an explosion!
------=_NextPart_000_0000_01C74B0A.BBF72180-- From simple-bounces@ietf.org Wed Feb 07 18:15:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEw09-0006Do-58; Wed, 07 Feb 2007 18:14:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEw07-0006Df-7E for simple@ietf.org; Wed, 07 Feb 2007 18:14:55 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEw05-00028T-R3 for simple@ietf.org; Wed, 07 Feb 2007 18:14:55 -0500 Received: by ug-out-1314.google.com with SMTP id 72so295936ugd for ; Wed, 07 Feb 2007 15:14:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nMZW9NZ2x6rCyNq+iGEyYNiUEzlN494ng9z4DUjV/ViebpmEahiZl1Z+fdKi3lnoDVoXHawRWZd4N7KFH2SxmB5tOtDqbIY0tvXHFZiNtDtFZOPc1xtnze2WYQhXGWiwP8/ck+mZdPc1/CbugwqCgI4a317YgSqTQaA7YALo88c= Received: by 10.82.111.8 with SMTP id j8mr858881buc.1170890092891; Wed, 07 Feb 2007 15:14:52 -0800 (PST) Received: by 10.82.113.20 with HTTP; Wed, 7 Feb 2007 15:14:52 -0800 (PST) Message-ID: <66cd252f0702071514o1c70b57dpf354c6ccfbc0760b@mail.gmail.com> Date: Thu, 8 Feb 2007 10:14:52 +1100 From: "Hisham Khartabil" To: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-03.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This version of the draft is post WGLC. Most changes are minor. One major change is the removal of allowing the IM Sender to request aggregation. Originally, an intermediary could ignore the the aggregation request or it could aggregate without the IM Sender requesting it. Therefore, the IM Sender requesting aggregation did not make a difference to the intermediary's behavior. This draft is now ready to go to IESG. Regards, Hisham On 08/02/07, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. > > Title : Instant Message Disposition Notification > Author(s) : E. Burger, H. Khartabil > Filename : draft-ietf-simple-imdn-03.txt > Pages : 34 > Date : 2007-2-7 > > Instant Messaging (IM) refers to the transfer of messages between > users in real-time. This document provides a mechanism whereby > endpoints can request Instant Message Disposition Notifications > (IMDN), including delivery, processing and read notifications, for > page-mode instant messages. > > The Common Profile for Instant Messaging (CPIM) data format specified > in RFC 3862 is extended with new header fields that enable endpoints > to request IMDNs. A new message format is also defined to convey > IMDNs. > > This document also describes how SIP entities behave using this > extension. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-simple-imdn-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-imdn-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 08 17:06:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFHOE-0007Q0-Ef; Thu, 08 Feb 2007 17:05:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFHOC-0007Pv-Iu for simple@ietf.org; Thu, 08 Feb 2007 17:05:12 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFHOA-0002oS-3I for simple@ietf.org; Thu, 08 Feb 2007 17:05:12 -0500 Received: from [172.17.2.71] ([172.17.2.71]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l18M55bx072850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Feb 2007 16:05:05 -0600 (CST) (envelope-from emcmurry@estacado.net) In-Reply-To: <66cd252f0702071514o1c70b57dpf354c6ccfbc0760b@mail.gmail.com> References: <66cd252f0702071514o1c70b57dpf354c6ccfbc0760b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17654E8B-FDE5-4151-A031-A12E1E396833@estacado.net> Content-Transfer-Encoding: 7bit From: Eric McMurry Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-03.txt Date: Thu, 8 Feb 2007 16:04:56 -0600 To: Hisham Khartabil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The namespace in this version has changed to: NS: imdn As far as I know, there can't be a space in this. This looks like the result of a global replace on "header" with "header field". Eric On Feb 7, 2007, at 5:14 PM, Hisham Khartabil wrote: > This version of the draft is post WGLC. Most changes are minor. One > major change is the removal of allowing the IM Sender to request > aggregation. Originally, an intermediary could ignore the the > aggregation request or it could aggregate without the IM Sender > requesting it. Therefore, the IM Sender requesting aggregation did not > make a difference to the intermediary's behavior. > > This draft is now ready to go to IESG. > > Regards, > Hisham > > On 08/02/07, Internet-Drafts@ietf.org > wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIP for Instant Messaging and >> Presence Leveraging Extensions Working Group of the IETF. >> >> Title : Instant Message Disposition Notification >> Author(s) : E. Burger, H. Khartabil >> Filename : draft-ietf-simple-imdn-03.txt >> Pages : 34 >> Date : 2007-2-7 >> >> Instant Messaging (IM) refers to the transfer of messages between >> users in real-time. This document provides a mechanism whereby >> endpoints can request Instant Message Disposition Notifications >> (IMDN), including delivery, processing and read notifications, for >> page-mode instant messages. >> >> The Common Profile for Instant Messaging (CPIM) data format >> specified >> in RFC 3862 is extended with new header fields that enable >> endpoints >> to request IMDNs. A new message format is also defined to convey >> IMDNs. >> >> This document also describes how SIP entities behave using this >> extension. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-03.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-simple-imdn-03.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-simple-imdn-03.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need >> "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been >> split >> up into multiple messages), so check your local >> documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 08 19:07:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJHd-0003Hp-3j; Thu, 08 Feb 2007 19:06:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJHb-0003HF-8Q for simple@ietf.org; Thu, 08 Feb 2007 19:06:31 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJH8-0007cc-9C for simple@ietf.org; Thu, 08 Feb 2007 19:06:31 -0500 Received: by ug-out-1314.google.com with SMTP id 72so567502ugd for ; Thu, 08 Feb 2007 16:06:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y+0MBnxfdfrEOVCGbHZDh6tXsvrxnTCkfTEPzfUeA3AIuEjmw2/dJB+SXM3zV80/bUlarnQK94SUtVGzZrtekiVjhsNJsZ/AFAPARx3KcZBYSx+CLO6iopCy82xaD8urXPmdUiw00SLSg6/z0DfJ5cxqXqGeNLGjgGx2iPxnUw4= Received: by 10.82.120.14 with SMTP id s14mr3674519buc.1170979560930; Thu, 08 Feb 2007 16:06:00 -0800 (PST) Received: by 10.82.113.20 with HTTP; Thu, 8 Feb 2007 16:06:00 -0800 (PST) Message-ID: <66cd252f0702081606j1e20299fse4ced08d291e2612@mail.gmail.com> Date: Fri, 9 Feb 2007 11:06:00 +1100 From: "Hisham Khartabil" To: "Eric McMurry" Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-03.txt In-Reply-To: <17654E8B-FDE5-4151-A031-A12E1E396833@estacado.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <66cd252f0702071514o1c70b57dpf354c6ccfbc0760b@mail.gmail.com> <17654E8B-FDE5-4151-A031-A12E1E396833@estacado.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Oops, you are right. I'll change it and submit a new version. Thanks, Hisham On 09/02/07, Eric McMurry wrote: > The namespace in this version has changed to: > > NS: imdn > > As far as I know, there can't be a space in this. This looks like > the result of a global replace on "header" with "header field". > > Eric > > On Feb 7, 2007, at 5:14 PM, Hisham Khartabil wrote: > > > This version of the draft is post WGLC. Most changes are minor. One > > major change is the removal of allowing the IM Sender to request > > aggregation. Originally, an intermediary could ignore the the > > aggregation request or it could aggregate without the IM Sender > > requesting it. Therefore, the IM Sender requesting aggregation did not > > make a difference to the intermediary's behavior. > > > > This draft is now ready to go to IESG. > > > > Regards, > > Hisham > > > > On 08/02/07, Internet-Drafts@ietf.org > > wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the SIP for Instant Messaging and > >> Presence Leveraging Extensions Working Group of the IETF. > >> > >> Title : Instant Message Disposition Notification > >> Author(s) : E. Burger, H. Khartabil > >> Filename : draft-ietf-simple-imdn-03.txt > >> Pages : 34 > >> Date : 2007-2-7 > >> > >> Instant Messaging (IM) refers to the transfer of messages between > >> users in real-time. This document provides a mechanism whereby > >> endpoints can request Instant Message Disposition Notifications > >> (IMDN), including delivery, processing and read notifications, for > >> page-mode instant messages. > >> > >> The Common Profile for Instant Messaging (CPIM) data format > >> specified > >> in RFC 3862 is extended with new header fields that enable > >> endpoints > >> to request IMDNs. A new message format is also defined to convey > >> IMDNs. > >> > >> This document also describes how SIP entities behave using this > >> extension. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-03.txt > >> > >> To remove yourself from the I-D Announcement list, send a message to > >> i-d-announce-request@ietf.org with the word unsubscribe in the > >> body of > >> the message. > >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- > >> announce > >> to change your subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the > >> username "anonymous" and a password of your e-mail address. After > >> logging in, type "cd internet-drafts" and then > >> "get draft-ietf-simple-imdn-03.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE /internet-drafts/draft-ietf-simple-imdn-03.txt". > >> > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need > >> "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant > >> mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been > >> split > >> up into multiple messages), so check your local > >> documentation on > >> how to manipulate these messages. > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > >> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 09 17:23:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFe7d-00025p-7T; Fri, 09 Feb 2007 17:21:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFe7b-00025h-9v for simple@ietf.org; Fri, 09 Feb 2007 17:21:35 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFe7W-0002MC-UZ for simple@ietf.org; Fri, 09 Feb 2007 17:21:35 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2007 14:21:28 -0800 X-IronPort-AV: i="4.13,308,1167638400"; d="scan'208"; a="110979367:sNHT47022156" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l19MLSpw032647; Fri, 9 Feb 2007 14:21:28 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l19MLQDo015282; Fri, 9 Feb 2007 14:21:28 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 14:21:18 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 14:21:18 -0800 Message-ID: <45CCF3DC.20008@cisco.com> Date: Fri, 09 Feb 2007 17:21:16 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Hynar References: <1170838650.3241.1.camel@brcalnik> In-Reply-To: <1170838650.3241.1.camel@brcalnik> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2007 22:21:19.0069 (UTC) FILETIME=[9F0FA0D0:01C74C98] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2385; t=1171059688; x=1171923688; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Possible=20ambiguous=20interpretation=20in=20xcap=20d iff |Sender:=20; bh=gIDca0PlLONwDgGicHiH7Zv7+Z1uVDEfAOg63uHrKNE=; b=GfxJXYxqYm+XXP5oAia1iUIl8bPrtLw8qUfmwjHt3y/SUZ3U9VT/wfYL5JRNrNJ08svYr6PW 2og4uCVNzchh/yKua4nYoYMFMmItYVWLSh1FQmbNiD7pOEgPXUkDna4r; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF WG SIMPLE Subject: [Simple] Re: Possible ambiguous interpretation in xcap diff X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This seems fine to me. I'll make the change. THanks, Jonathan R. Martin Hynar wrote: > Hello, > > I have read last version (04) of the XCAP Diff Format and there is one > thing in the schema that might cause ambiguous interpretation. In the > text, there is clearly explained that is the root element > with elements as children. However, the way how the elements > are defined in the xml schema allows to start with element, > omitting the intended element as a root. > > Both and elements are defined on the same level > using declaration. This causes that these are equal > in a way that they can be used as root. I would propose to change schema > to define "type" of the element on the top level: > > > ... > > > and then define element as follows: > > > ... > > ... > > > This way, there will clear which of the two elements is the root. > > br, Martin > > > > *+-------------------------------------+* > * **Martin Hynar* > Software Specialist > > * **TietoEnator* > Czech Software Center > Phone: +420 597 459 713 > Mobile: +420 724 432 817 > E-mail:*_ _**_Martin.Hynar@TietoEnator.com_* > > Vystavni 292/13 > CZ-709 16 Ostrava > > *_www.tietoenator.com _* > > > /Please note: The information contained in this message may be legally > privileged and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, you are hereby notified > that any unauthorized use, distribution or copying of this communication > is strictly prohibited. If you have received this communication in > error, please notify us immediately by replying to the message and > deleting it from your computer. Thank You./ > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 09 17:26:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeCX-0005qb-Ur; Fri, 09 Feb 2007 17:26:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeCX-0005qS-E8 for simple@ietf.org; Fri, 09 Feb 2007 17:26:41 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFeCW-0003WE-1f for simple@ietf.org; Fri, 09 Feb 2007 17:26:41 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 09 Feb 2007 14:26:34 -0800 X-IronPort-AV: i="4.13,308,1167638400"; d="scan'208"; a="38581781:sNHT18512037054" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l19MQVgv026091; Fri, 9 Feb 2007 14:26:31 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l19MQFH6028885; Fri, 9 Feb 2007 14:26:31 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 14:26:31 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 14:26:29 -0800 Message-ID: <45CCF513.7010503@cisco.com> Date: Fri, 09 Feb 2007 17:26:27 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?Big5?B?pvOt9b6xaG9jcw==?= Subject: Re: [simple] [Sip-implementors] XCAP Server for list uage implementation (how to limit the number of sub-element>?) References: In-Reply-To: Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Feb 2007 22:26:30.0051 (UTC) FILETIME=[586BB730:01C74C99] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1877; t=1171059991; x=1171923991; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[simple]=20[Sip-implementors]=20XCAP=20Server=20for=2 0list=20uage=20implementation=0A=20(how=20to=20limit=20the=20number=20of=2 0=20sub-element>?) |Sender:=20; bh=SGTl4ZHKz4EVPMBPIfDfy7361cSjXX577t4YbsbRnTw=; b=O64uwdAXAzHc7+4yAx55UbmVjO2arCmwtWLOPhlf7jLOaLR7KLqNarxLjIjphLG4EOkzhUij l2dNmgUN1jZzYwrDRXg+rzl+vlzocHgB+8xUrGojZsBVKfrIniyWQw4d; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'Simple WG' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Sorry for the long delay in responding. Right now there is no standard way to signal this. Effectively you are extending the application usage with additional validation constraints. In that case, if the user adds too many you would reject with a 409 and have it contain an xcap-error document with an element containing the error code and data (such as the maximum allowed buddies) you have defined. -Jonathan R. ¦ó­õ¾±hocs wrote: > > Dear there, > > I didn't get any response, so I post my question again. Any feedback is > welcome. > > The question is described as followings, > > I would like to ask a question about XCAP List Usage implementation. If I > want to implement a XCAP Server providing rls-services document > manipulation, but I want to limit the number of under the > element, that is per list has a maximum number of 200 sub-elements. > Is the XCAP Server allowed to do this? When a XCAP Client want to put an > entry but exceed this limitation, what XCAP Server should respond to client > (return an error code?) > > Thanks in advance. > > BR, > Jeffrey > > > %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C > This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From jpixdqzp@carsoninc.com Sat Feb 10 11:03:30 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFuhG-0006Fa-R0 for simple-archive@lists.ietf.org; Sat, 10 Feb 2007 11:03:30 -0500 Received: from [84.4.46.8] (helo=[84.4.46.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFuhA-0003Kb-H5 for simple-archive@lists.ietf.org; Sat, 10 Feb 2007 11:03:30 -0500 From: "disabled." To: simple-archive@lists.ietf.org Subject: Rocket Stock Report Date: Sat, 10 Feb 2007 17:03:13 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C74D35.5998F3B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdNNVmYhFkQyrd0TMGyKydXsKu+YA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.3 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0000_01C74D35.5998F3B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
THIS COMPANY IS GOING TO EXPLODE WITH FLAVOR!

**CBFE** WATCH NEWS THIS WEEK TO SEE WHAT 6 TOP UNIVERSITIES SAY ABOUT THIS WONDERFUL BAMBOO AND ITS JUICE!

Organization: China Biolife Enterprises, Inc.
Ticker: CBFE
Trading Date: Monday, February 12 2007
Price: $1.30

DONG SHAN DISTRICT GUANGZHOU, CHINA, Jan 08, 2007 (MRKET WIRE via COMTEX) -- China Biolife Enterprises, Inc. (PNKSHEETS: CBFE), a Nevada Corporation, focused on the bamboo extracts and nutraceutical markets in China. The company is pleased to announce that it is in the final stage of negotiations to acquire the bamboo extracts division from ChangRong Bamboo Wooden Craftwork Ltd. Co.

CAN YOU GAIN SPEEDY PROFITS ON THIS??

WATCH CBFE MONDAY AT OPEN!

------=_NextPart_000_0000_01C74D35.5998F3B0-- From simple-bounces@ietf.org Mon Feb 12 02:37:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVjA-0001CB-Ad; Mon, 12 Feb 2007 02:35:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVj9-0001C5-GI for simple@ietf.org; Mon, 12 Feb 2007 02:35:55 -0500 Received: from gate01.nexlink.ch ([80.86.198.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGVj8-0005pO-4a for simple@ietf.org; Mon, 12 Feb 2007 02:35:55 -0500 Received: from mail02.nexlink.ch ([10.51.9.2]) by gate01.nexlink.ch (8.13.1/8.13.1) with ESMTP id l1C7ZM7o018021 for ; Mon, 12 Feb 2007 08:35:22 +0100 Received: from localhost ([127.0.0.1] helo=mail01.nexlink.ch) by mail02.nexlink.ch with esmtp (Exim 4.63) (envelope-from ) id 1HGVic-0007mn-1l for simple@ietf.org; Mon, 12 Feb 2007 08:35:22 +0100 MIME-Version: 1.0 From: =?UTF-8?B?Sm/Dq2wgUmVwaXF1ZXQ=?= To: simple@ietf.org Date: Mon, 12 Feb 2007 08:35:22 +0100 Message-Id: <38231.1171265722@tech-invite.com> X-Mailer: AtMail 4.61 - 10.52.0.2 - joel.repiquet@tech-invite.com X-Spam-Score: 1.5 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Simple] CPIM in the SIMPLE re-charter X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joel.repiquet@tech-invite.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678774198==" Errors-To: simple-bounces@ietf.org --===============0678774198== Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" a common mistake in the SIMPLE proposed re-charter about CPIM acronym:
it stands for "Common Profile for Instant Messaging"
and not for "Common Presence and Instant Messaging"

--===============0678774198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0678774198==-- From simple-bounces@ietf.org Mon Feb 12 11:02:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdd4-0007DB-4I; Mon, 12 Feb 2007 11:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdd1-0007CR-Vs; Mon, 12 Feb 2007 11:02:08 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGdcx-0005YI-La; Mon, 12 Feb 2007 11:02:07 -0500 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l1CG1nBQ080777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Feb 2007 10:01:50 -0600 (CST) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 12 Feb 2007 10:01:45 -0600 To: sip-implementors@cs.columbia.edu, SIP LIST , simple@ietf.org, sipping LIST X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Simple] Registration for SIPit 20 is open X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org SIPit 20 will be hosted by Alcatel-Lucent in Antwerp, Belgium April 16-20,2007. Registration is now open - see http://www.sipit.net for more information. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 12 14:11:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgZA-0000ZH-4X; Mon, 12 Feb 2007 14:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgZ9-0000VF-FE for simple@ietf.org; Mon, 12 Feb 2007 14:10:19 -0500 Received: from smtp20.msg.oleane.net ([62.161.4.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGgZ1-00073j-Vn for simple@ietf.org; Mon, 12 Feb 2007 14:10:17 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp20.msg.oleane.net (MTA) with ESMTP id l1CJAAEa005603 for ; Mon, 12 Feb 2007 20:10:11 +0100 Message-Id: <200702121910.l1CJAAEa005603@smtp20.msg.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 12 Feb 2007 20:10:09 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdO2WnHC1//ZyCzQlWdIAgV1P7b8Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Simple] P2P SIP and IMS X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0582086647==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0582086647== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03FD_01C74EE1.CC629790" This is a multi-part message in MIME format. ------=_NextPart_000_03FD_01C74EE1.CC629790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Embedding P2P concepts into the IMS infrastructure: the right approach? The 8th edition of the International SIP conference will start in two weeks: February 27 to March 02, 2007. The program is mainly dedicated to P2P SIP and IMS issues addressed by key specialists and service providers. Get all details at: http://www.upperside.fr/sip2007/sip2007intro.htm ------=_NextPart_000_03FD_01C74EE1.CC629790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Embedding P2P concepts into the IMS = infrastructure: the right approach?

The 8th edition of the International SIP = conference will start in two weeks: February 27 to March 02, 2007. =

The program is mainly dedicated to P2P SIP and IMS = issues addressed by key specialists and service = providers.

 

Get all details at:

http:= //www.upperside.fr/sip2007/sip2007intro.htm<= /p>

 

------=_NextPart_000_03FD_01C74EE1.CC629790-- --===============0582086647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0582086647==-- From simple-bounces@ietf.org Tue Feb 13 08:59:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyBS-0005jJ-Np; Tue, 13 Feb 2007 08:59:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyBR-0005ir-5i for simple@ietf.org; Tue, 13 Feb 2007 08:59:01 -0500 Received: from bay0-omc1-s11.bay0.hotmail.com ([65.54.246.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGyBP-0005pl-KD for simple@ietf.org; Tue, 13 Feb 2007 08:59:00 -0500 Received: from hotmail.com ([65.55.134.105]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 13 Feb 2007 05:58:58 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Feb 2007 05:58:58 -0800 Message-ID: Received: from 65.55.134.123 by by129fd.bay129.hotmail.msn.com with HTTP; Tue, 13 Feb 2007 13:58:54 GMT X-Originating-IP: [193.108.42.5] X-Originating-Email: [gustav_kung@hotmail.com] X-Sender: gustav_kung@hotmail.com In-Reply-To: From: "Gustav E" To: simple@ietf.org Bcc: Date: Tue, 13 Feb 2007 14:58:54 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Feb 2007 13:58:58.0658 (UTC) FILETIME=[1BA0E420:01C74F77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Simple] List in list in RLS service? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi all, Concider the following example RLS document: Sven presence My basic question here is if it is allowed to have a list-based service containg yet another level of list(s). I'm not sure of why one would need such a construction, but rather interested in finding out if it can ever occur. >From my understanding this should not break the rls-services schema in list-usage-05. Do you agree? I'm a bit confused of the text (4.4.5 Additional constraints): ---- o In addition, an RLS services document can contain a element, which in turn can contain , and elements. The constraints defined for these elements in Section 3.4.7 MUST be enforced. ---- Should this be interpreted as additional sub-elements are not allowed? BR, /Gustav E _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 13 13:03:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH1z6-0002YS-RQ; Tue, 13 Feb 2007 13:02:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH1z5-0002YF-Mm for simple@ietf.org; Tue, 13 Feb 2007 13:02:31 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH1z4-0006AK-B5 for simple@ietf.org; Tue, 13 Feb 2007 13:02:31 -0500 Received: from [192.168.0.108] (ppp-70-249-153-236.dsl.rcsntx.swbell.net [70.249.153.236]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l1DI2SVW027039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2007 12:02:29 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45D1FD2F.7000703@nostrum.com> Date: Tue, 13 Feb 2007 12:02:23 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Gustav E Subject: Re: [Simple] List in list in RLS service? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.153.236 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Nested lists are certainly allowed, but this isn't how they would be represented. The schema of RFC 4662 does not allow for a element to appear as a child of a element. RFC 4662 contains a number of examples that demonstrate exactly the "nested list" concept. The diagram at the end of section 5.5 gives a high-level overview of the MIME structure of a list (Top level document) that contains another list (part B) and an element (part C). More concretely, if you look at the NOTIFY that starts on page 28, you'll see that the top-most list (Content ID <2BEI83@pres.vancouver.example.com>) contains another list (sip:adam-friends@stockolm.example.org). The contents of this second list are expanded in a *different* MIME part (Content ID <1KQhyE@pres.vancouver.example.com>), *not* within the XML for the top-most list. This approach has the very important property that each list may be signed (using an S/MIME signature) by their respective authorities to guarantee that they have not been modified in transit. It also allows such content to be S/MIME encrypted, thus preventing unauthorized disclosure to intermediaries. /a Gustav E wrote: > Hi all, > > Concider the following example RLS document: > > > xmlns:rl="urn:ietf:params:xml:ns:resource-lists"> > > > > > Sven > > > > > > > presence > > > > > My basic question here is if it is allowed to have a list-based > service containg yet another level of list(s). I'm not sure of why one > would need such a construction, but rather interested in finding out > if it can ever occur. >> From my understanding this should not break the rls-services schema in > list-usage-05. Do you agree? > > I'm a bit confused of the text (4.4.5 Additional constraints): > ---- > o In addition, an RLS services document can contain a > element, which in turn can contain , and > elements. The constraints defined for these elements > in Section 3.4.7 MUST be enforced. > ---- > > Should this be interpreted as additional sub-elements are not > allowed? > > BR, > /Gustav E > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 13 17:40:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6Jy-0000Gt-QQ; Tue, 13 Feb 2007 17:40:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6Jv-0000B8-2J; Tue, 13 Feb 2007 17:40:19 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HH6Js-0008FL-LK; Tue, 13 Feb 2007 17:40:18 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 7ED961761B; Tue, 13 Feb 2007 22:39:46 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1HH6JO-0006am-8S; Tue, 13 Feb 2007 17:39:46 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 13 Feb 2007 17:39:46 -0500 X-Spam-Score: -2.3 (--) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Robert Sparks , simple@ietf.org Subject: [Simple] WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A modified charter has been submitted for the SIP for Instant Messaging and Presence Leveraging Extensions (simple)working group in the Real- time Applications and Infrastructure Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 19th. +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) ====================================================================== Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to determine if this WG is an appropriate venue. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From uadzdwx@compustore.net Fri Feb 16 03:04:57 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHy5R-0001Pw-3J for simple-archive@lists.ietf.org; Fri, 16 Feb 2007 03:04:57 -0500 Received: from [80.70.102.134] (helo=[80.70.102.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHy5P-0000c7-OI for simple-archive@lists.ietf.org; Fri, 16 Feb 2007 03:04:57 -0500 From: "Although" To: simple-archive@lists.ietf.org Subject: Stock Trader Alert Date: Fri, 16 Feb 2007 11:04:53 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C751BA.49353860" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdRukk1NSUp+QZhQPSobuQU+/Oe6w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <74C8B96E31930FF.49ECA4AB78@compustore.net> X-Spam-Score: 1.5 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ------=_NextPart_000_0002_01C751BA.49353860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
*** POTENTIAL POWERHOUSE GAINS POSSIBLE WITH ***HXPN***

Harris Exploration Inc
Acquisition, Exploration and Development

Tick: HXPN
Opening: $1.50
GET IN ON FRIDAY FEBRUARY 16th 2007!
Extended Day Target: $2.00

Breaking News Headline:
Harris Exploration Inc. Ecuador Gold Project

GUAYAQUIL, ECUADOR -- (MRKT WIRE) -- 02/15/07
Harris Exploration Inc., (PKSHEET: HXPN). The geographic location of the Balsapamba property is identified as the Balsapamba Parish, Canton San Miguel de Bolivar, Bolivar Province in the Republic of Ecuador. The property is described as a polymetallic property, indicating the presence of several various mineral resources which have been divided into five mineralized blocks. These blocks are identified as Andres, Juan, Gilbert, El Cangrejo and Diana.

INFORMED INVESTORS ARE WINNERS, WATCH HXPN Trade on FRIDAY!
------=_NextPart_000_0002_01C751BA.49353860-- From rwntcwiiqg@estnet.bg Sat Feb 17 04:49:50 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIMCU-0008UI-VG for simple-archive@lists.ietf.org; Sat, 17 Feb 2007 04:49:50 -0500 Received: from [87.119.98.136] (helo=87-119-98-136.estnet.bg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIMCT-000752-BP for simple-archive@lists.ietf.org; Sat, 17 Feb 2007 04:49:50 -0500 From: "themind exact" To: simple-archive@lists.ietf.org Subject: Investor's Insight Date: Sat, 17 Feb 2007 11:49:28 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C75289.ADA04EF0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdSia2gOTfHIDlUQiuhuOO88OKF/A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <9857EE29E98AC8E.3C52E86BAB@estnet.bg> X-Spam-Score: 4.0 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ------=_NextPart_000_0002_01C75289.ADA04EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
::: PURE BIOFUELS CORP (PBOF.OB) :::

Stock Radar Presents
Get Ready!! PBOF continues!

Don't you dare take your eyes off this one Tue,20 morning.
CURRENT PRICE: 1.50 USD
Extended Day Target: 2.025 USD (35%)

---
Breaking News Headline:
Entry into a Material Definitive Agreement, Change in Directors or Principal O

---
When this St0ck moves... WATCH OUT! CATCH THE NEW LEADER!

------=_NextPart_000_0002_01C75289.ADA04EF0-- From ldkdifxp@blueswitch.com Thu Feb 22 04:48:17 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKAYj-0003vn-7Y for simple-archive@lists.ietf.org; Thu, 22 Feb 2007 04:48:17 -0500 Received: from [81.198.26.211] (helo=[81.198.26.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKAYh-0006ef-SI for simple-archive@lists.ietf.org; Thu, 22 Feb 2007 04:48:17 -0500 From: "Order" To: simple-archive@lists.ietf.org Subject: Personal Finance Date: Thu, 22 Feb 2007 11:48:31 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C75677.6035E430" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdWd2A1TLq7ieFUTfiIWaCibCnB+Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <86439689CE9AFFA.F71230B68A@blueswitch.com> X-Spam-Score: 3.2 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ------=_NextPart_000_0001_01C75677.6035E430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+Physicians Adult Daycare, Inc. Incorporates New Techgnology+

Physicians Adult Daycare, Inc. (phya.pk)

DATE : FEB 22, 2007
Company: PHYSICIANS ADULT DAY
Currently: $0.31 (+0.02) (+6.90% in a day!!!)
Expected Day Target: $0.76

News:
Physicians Adult Daycare, Inc. (PHYA) announced that the Company is in the final negotiation stages with TOTALtrak Global, Inc., a global provider of leading-edge Radio Frequency Identification (RFID)-based and patent-pending Multi-Range (MRID) technology solutions, to implement this versatile and powerful technology into the Company's innovative adult daycare program......
------=_NextPart_000_0001_01C75677.6035E430-- From rbdyikhommp@iol.cz Thu Feb 22 12:33:01 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHoT-0004nP-23 for simple-archive@lists.ietf.org; Thu, 22 Feb 2007 12:33:01 -0500 Received: from 58.206.broadband2.iol.cz ([83.208.206.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HKHoR-0004u4-L5 for simple-archive@lists.ietf.org; Thu, 22 Feb 2007 12:33:00 -0500 From: "Have" To: simple-archive@lists.ietf.org Subject: Economic Events & Analysis Date: Thu, 22 Feb 2007 18:32:53 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C756AF.DD393D50" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdWr905MiigyyFXQzqOpR/vQ4C4Xw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <9193341471DE4F6.5E1BA3A46F@iol.cz> X-Spam-Score: 1.4 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ------=_NextPart_000_0005_01C756AF.DD393D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+Physicians Adult Daycare, Inc. Incorporates New Techgnology+

Physicians Adult Daycare, Inc. (phya.pk)

DATE : FEB 22, 2007
Company: PHYSICIANS ADULT DAY
Currently: $0.31 (+0.02) (+6.90% in a day!!!)
Expected Day Target: $0.76

News:
Physicians Adult Daycare, Inc. (PHYA) announced that the Company is in the final negotiation stages with TOTALtrak Global, Inc., a global provider of leading-edge Radio Frequency Identification (RFID)-based and patent-pending Multi-Range (MRID) technology solutions, to implement this versatile and powerful technology into the Company's innovative adult daycare program......
------=_NextPart_000_0005_01C756AF.DD393D50-- From simple-bounces@ietf.org Fri Feb 23 17:16:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKigY-0001OZ-9q; Fri, 23 Feb 2007 17:14:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKigW-0001Nw-Ou for simple@ietf.org; Fri, 23 Feb 2007 17:14:36 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKigT-0006gf-DG for simple@ietf.org; Fri, 23 Feb 2007 17:14:36 -0500 Received: from [172.17.1.75] ([172.17.1.75]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l1NMDTas040862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Feb 2007 16:13:29 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Fri, 23 Feb 2007 16:13:24 -0600 To: Simple WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Cullen Jennings , rohan@ekabal.com, Adam Roach , Robert Sparks Subject: [Simple] Updated MSRP draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, I just submitted a revised version of the MSRP base specification. This version contains some minor changes as a result of feedback from the URI review. The previous version of the draft has been through IETF last call and IESG review. The substantive changes are as follows: 1) We removed the prohibition against percent-encoded characters in the authority part of the URI, and mentioned the implied need to consider percent-encoded character normalization in URI comparison. We received strong feedback that prohibiting percent-encoding was a bad idea, due to the fact that if we don't allow the conventional methods of encoding reserved characters, implementers will invent their own proprietary ways. 2) We removed the slash character from the allowed set of characters for the Session-ID component of the URI. We received feedback that a slash should only be used as a delimiter between hierarchical components. Since Session-Id does not describe a hierarchy, the slash is not appropriate. 3) We changed the ABNF for the host part of the URI from " [ userinfo "@"] hostport " to "authority" . This was to adapt to the newer definitions in RFC 3896, which defines "authority" as " [ userinfo "@"] host [ ":" port ] " Until the revision becomes available from the repository, you can view it at one of the following links: http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-19.txt http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-19.html Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From obcuavuofy@bezeqint.net Sun Feb 25 01:18:43 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLCiZ-00035H-68 for simple-archive@lists.ietf.org; Sun, 25 Feb 2007 01:18:43 -0500 Received: from bzq-88-152-188-117.red.bezeqint.net ([88.152.188.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLCiW-0006iQ-DY for simple-archive@lists.ietf.org; Sun, 25 Feb 2007 01:18:42 -0500 From: "checking" To: simple-archive@lists.ietf.org Subject: Personal Finance Date: Sun, 25 Feb 2007 08:18:31 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C758B5.890353D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdYtYkDzePK0H5lQtOOtQz0Ni5EJw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <52941686E46B155.015854F366@bezeqint.net> X-Spam-Score: 4.2 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ------=_NextPart_000_0005_01C758B5.890353D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
*GDKI* STILL MOVING LIKE A COMET AND ITS ONLY GOING TO GET BETTER!

Watch this SUPERNOVA closely Monday!

GOLDMARK INDUSTRIES INC
Symbol: GDKI
Price: $0.13
GET IN ON February 26 Monday, 2007

NEWS RELEASED ON 2007/02/20 05:39
Goldmark Industries, Inc. (Pk Sheet:GDKI), is excited to announce that its recent acquisition, Habana Blues, which was nominated for four Goya awards, the equivalent of the Oscars in Spain, has been requested by numerous film festivals across the nation and will be featured at the exclusive Latin American Film Festival in Champaign, Illinois, February 23rd to March 1st. The film, which was released by Warner Home Video International, has been making waves since its success at the prestigious Cannes International Film Festival. Goldmark is currently in negotiations for the award-winning film’s theatrical release.
------=_NextPart_000_0005_01C758B5.890353D0-- From simple-bounces@ietf.org Mon Feb 26 15:25:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmOQ-0002wb-7J; Mon, 26 Feb 2007 15:24:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmOO-0002wR-SB for simple@ietf.org; Mon, 26 Feb 2007 15:24:16 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmOL-0000xB-NG for simple@ietf.org; Mon, 26 Feb 2007 15:24:16 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2007 12:24:11 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="362996480:sNHT53121248" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKOAUM022080; Mon, 26 Feb 2007 15:24:10 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKO9OK015926; Mon, 26 Feb 2007 15:24:10 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:24:05 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:24:04 -0500 Message-ID: <45E341E4.60206@cisco.com> Date: Mon, 26 Feb 2007 15:24:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Simple] List in list in RLS service? References: <45D1FD2F.7000703@nostrum.com> In-Reply-To: <45D1FD2F.7000703@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:24:04.0787 (UTC) FILETIME=[0F532030:01C759E4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4136; t=1172521450; x=1173385450; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20List=20in=20list=20in=20RLS=20service? |Sender:=20 |To:=20Adam=20Roach=20; bh=zvzmg7+bN4x58nIjRtoFvhahef1FJ5WW5hzCKPX7gKQ=; b=KKUTTHhZUH1m0CJckjK2vosoMkZ+3PUkAPq1q1AlgtHPZ+csqr5pb0j7tz6IWUy2aDy83NaB GjyG3O2y3idxkj8543/O+6E0xHkg3+UVDnsrwW8yA6fdcepQVqzc/8LI; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I think the question was actually around the schema in draft-ietf-simple-xcap-list-usage, not rfc4662. To answer your question for list-usage, it is permitted that the embedded within can be hierarchical (containing other elements), though I see no value in doing so. The text in 4.4.5 is in error, and should include as permitted. I will correct that in auth48 (which has just started - yay!) -Jonathan R. Adam Roach wrote: > Nested lists are certainly allowed, but this isn't how they would be > represented. The schema of RFC 4662 does not allow for a element > to appear as a child of a element. > > RFC 4662 contains a number of examples that demonstrate exactly the > "nested list" concept. The diagram at the end of section 5.5 gives a > high-level overview of the MIME structure of a list (Top level document) > that contains another list (part B) and an element (part C). > > More concretely, if you look at the NOTIFY that starts on page 28, > you'll see that the top-most list (Content ID > <2BEI83@pres.vancouver.example.com>) contains another list > (sip:adam-friends@stockolm.example.org). The contents of this second > list are expanded in a *different* MIME part (Content ID > <1KQhyE@pres.vancouver.example.com>), *not* within the XML for the > top-most list. > > This approach has the very important property that each list may be > signed (using an S/MIME signature) by their respective authorities to > guarantee that they have not been modified in transit. It also allows > such content to be S/MIME encrypted, thus preventing unauthorized > disclosure to intermediaries. > > /a > > Gustav E wrote: > >> Hi all, >> >> Concider the following example RLS document: >> >> >> > xmlns:rl="urn:ietf:params:xml:ns:resource-lists"> >> >> >> >> >> Sven >> >> >> >> >> >> >> presence >> >> >> >> >> My basic question here is if it is allowed to have a list-based >> service containg yet another level of list(s). I'm not sure of why one >> would need such a construction, but rather interested in finding out >> if it can ever occur. >> >>> From my understanding this should not break the rls-services schema in >> >> list-usage-05. Do you agree? >> >> I'm a bit confused of the text (4.4.5 Additional constraints): >> ---- >> o In addition, an RLS services document can contain a >> element, which in turn can contain , and >> elements. The constraints defined for these elements >> in Section 3.4.7 MUST be enforced. >> ---- >> >> Should this be interpreted as additional sub-elements are not >> allowed? >> >> BR, >> /Gustav E >> >> _________________________________________________________________ >> Express yourself instantly with MSN Messenger! Download today it's >> FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 15:35:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmZ1-00056x-Fs; Mon, 26 Feb 2007 15:35:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmYz-0004wH-Hb for simple@ietf.org; Mon, 26 Feb 2007 15:35:13 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmYx-0003JW-Ll for simple@ietf.org; Mon, 26 Feb 2007 15:35:13 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2007 12:35:10 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="362998806:sNHT69439296" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKZAmQ003257; Mon, 26 Feb 2007 15:35:10 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKXUW1026988; Mon, 26 Feb 2007 15:35:10 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:34:56 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:34:56 -0500 Message-ID: <45E34470.1020109@cisco.com> Date: Mon, 26 Feb 2007 15:34:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Salvatore Loreto (JO/LMF)" Subject: Re: [Simple] Internal WG Review: Recharter of SIP forInstantMessaging and Presence Leveraging Extensions (simple) References: <451C9AB8BFB6B64EA11547A3D966DB3609D244F9@TBDCEXCH10.US.Cingular.Net> <1170677654.3489.9.camel@n95.nomadiclab.com> In-Reply-To: <1170677654.3489.9.camel@n95.nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:34:56.0486 (UTC) FILETIME=[93C48060:01C759E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12803; t=1172522110; x=1173386110; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Internal=20WG=20Review=3A=20Recharter=20of =20SIP=09forInstantMessaging=0A=20and=20Presence=20Leveraging=20Extensions =20(simple) |Sender:=20 |To:=20=22Salvatore=20Loreto=20(JO/LMF)=22=20; bh=sPjhw0kDV9OkAiS2RXtJWE74VedNYhl1yv0YuAB6c/g=; b=B9vIlo5eFwx35Tl4sU5qWWzpVrN+Su1xg5oqrnGR3ZgS1A9fimn+XAs6UhL52lsiFIVcK4MR uH7fOW5kE7pLUg7XmR6QGnesTMRasQIwtpO6xChxCgbhRk75YqFBk7ya; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: pkyzivat@cisco.com, simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I also think we need to deal with this. This is one of a few cases where we have several solutions and not clear enough guidance on how to make it interoperate. What happens if one side supports MSRP, and the other, just MESSAGE? Do MSRP endpoints also need to do MESSAGE as a fallback? This is in addition to the questions around how and if to transition from MESSAGE to MSRP and so on. -Jonathan R. Salvatore Loreto (JO/LMF) wrote: > Hi, > > > -how continue (or better change) a conversation triggered by a MESSAGE > in a new MRSP session > > -issues related to MRSP sessions established for just sending one > message (e.g. imdn or similar functionality) > > I do think that both the issues summarized above (and mentioned in the > previous mails) are problems that SIMPLE should try to address. > > br > sal > > On Wed, 2007-01-31 at 08:48 -0600, Stafford, Matthew wrote: > >>Re wireless service providers wanting something similar to MMS: I would >>say not only in its own right, but as an interworking vehicle with the >>MMS installed base. This is important, I think, from the POV of >>facilitating SIMPLE deployment- something I would very much like to see! >> >>In the context of this conversation, I am eager to hear comments on an >>internet draft posted a couple of weeks ago: >>http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt >> >>The draft sets forth use cases involving MSRP- use cases in which imdn >>(or similar) functionality would be very useful. In many instances, use >>cases can be supported with existing building blocks. But here we do see >>a gap, and think that the best solution would be a new/extended building >>block devised by IETF. As I indicated in a Jan 19 message posted to this >>list, we understand the need to go ahead and progress the imdn draft >>(sans MSRP). >> >>I'm not necessarily inviting detailed discussion of this draft (in the >>midst of the current rechartering discussion, that might be premature). >>At this point, I'm wanting to know whether this sort of thing will be in >>scope (and "lobbying" for the answer to be yes...) >> >>Best, >>Matt Stafford >> >>-----Original Message----- >>From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>Sent: Wednesday, January 31, 2007 3:37 AM >>To: pkyzivat@cisco.com; simple@ietf.org >>Subject: RE: [Simple] Internal WG Review: Recharter of SIP >>forInstantMessaging and Presence Leveraging Extensions (simple) >> >>Hi, >> >>Yes, I think this is a feature that would be needed in practice. Having >>two messaging mechanisms without clear guidance on how they relate to >>each other is going to cause interoperability issues - if not on the >>protocol level then at least on the UI-to-UI or user-to-user level. >> >>Another thing is that there should be some kind of >>specification/guideline on how to actually deliver one-shot messages >>that are larger than 1300 bytes. One way is to use MSRP, another to do >>content indirection with MESSAGE. In MSRP the key is the ability for the >>sender to indicate (at least as a preference/hint) that the session is >>established for just sending a single message, not to open a >>conversation. This is wanted by providers who would like to be able to >>offer something similar to MMS service on top of a SIP infra. >> >>SIMPLE WG has not been very enthusiastic about this in the past, so I >>think OMA has already defined a particular mechanism for MSRP. If >>everyone who is interested in this is anyway involved in OMA, as it >>seems, there would be not much value for IETF to do anything about it. >>However, if there is real interest outside OMA, it would be useful to >>have some work in SIMPLE WG. >> >>Markus >> >> >> >>>-----Original Message----- >>>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>Sent: 31 January, 2007 00:15 >>>To: simple@ietf.org >>>Subject: Re: [Simple] Internal WG Review: Recharter of SIP for >>>InstantMessaging and Presence Leveraging Extensions (simple) >>> >>>Wasn't there some talk of a need to specify how to choose >>>between MESSAGE and MSRP, and/or to transition between them in >>>support of a single conversation? >>> >>>E.g. send a MESSAGE because there may never be a conversation, >>>but then INVITE with an MSRP session to continue the >>>conversation. The need here would be for a way to tie these >>>things together so it is clear that they are part of the same >>>conversation. There are obviously issues with involving the >>>same pair of UAs in both. >>> >>>I seem to recall this was discussed at some point, but I'm not >>>sure and if so I don't remember the outcome. >>> >>> Paul >>> >>>IESG Secretary wrote: >>> >>>>A new charter for the SIP for Instant Messaging and Presence >>>>Leveraging Extensions (simple) working group in the Real-time >>>>Applications and Infrastructure Area of the IETF is being >>> >>>considered. >>> >>>>The draft charter is provided below for your review and comment. >>>> >>>>Review time is one week. >>>> >>>>The IETF Secretariat >>>> >>>>+++ >>>> >>>>SIP for Instant Messaging and Presence Leveraging Extensions >>> >>>(simple) >>> >>>====================================================================== >>> >>>>Last Modified: 2007-1-24 >>>> >>>>Current Status: Active Working Group >>>> >>>>Chair(s): >>>>Robert Sparks >>>>Hisham Khartabil >>>> >>>> >>>>Real-time Applications and Infrastructure Area Director(s): >>>>Jon Peterson Cullen Jennings >>>> >>>> >>>>Real-time Applications and Infrastructure Area Advisor: >>>>Jon Peterson >>>> >>>>Technical Advisor(s): >>>>Jon Peterson >>>> >>>>Mailing Lists: >>>>General Discussion: simple@ietf.org >>>>To Subscribe: simple-request@ietf.org >>>>In Body: subscribe >>>>Archive: http://www.ietf.org/mail-archive/web/simple/index.html >>>> >>>>Description of Working Group: >>>> >>>>This working group focuses on the application of the Session >>>>Initiation Protocol (SIP, RFC 3261) to the suite of services >>>>collectively known as instant messaging and presence (IMP). The IETF >>>>has committed to producing an interoperable standard for these >>>>services compliant to the requirements for IM outlined in RFC 2779 >>>>(including the security and privacy requirements there) and in the >>>>Common Presence and Instant Messaging (CPIM) specification, >>> >>>developed >>> >>>>within the IMPP working group. As the most common services for which >>>>SIP is used share quite a bit in common with IMP, the adaptation of >>>>SIP to IMP seems a natural choice given the widespread support for >>>>(and relative maturity of) the SIP standard. >>>> >>>>This group has completed the majority of its primary goals and will >>>>focus on the remaining tasks documented here and concluding. Any >>>>proposed new work should be socialized with the chairs and >>> >>>AD early to >>> >>>>determine if this WG is an appropriate venue. >>>> >>>>The primary remaining work of this group will be to complete: >>>> >>>>1. The MSRP proposed standard mechanism for transporting sessions of >>>>messages initiated using the SIP, compliant to the >>> >>>requirments of RFC >>> >>>>2779, CPIM and BCP 41. >>>> >>>>2. The XCAP framework for representing and carrying >>> >>>configuration and >>> >>>>policy information in SIMPLE systems. >>>> >>>>3. A mechanism for representing partial changes (patches) to XML >>>>documents and extensions to the SIMPLE publication and notification >>>>mechanisms to convey these partial changes. >>>> >>>>4. A mechanism for initiating and managing Instant Message >>> >>>group chat. >>> >>>>5. An annotated overview of the SIMPLE protocol definition documents. >>>> >>>>Any SIP extensions proposed in the course of this development will, >>>>after a last call process, be transferred to the SIP WG for >>>>consideration as formal SIP extensions. >>>> >>>>Any mechanisms created for managing Instant Message group chat are >>>>intended to provide a bridge to the conferencing protocols that will >>>>be defined in XCON. They will be limited in scope to address only >>>>simple Instant Message chat with nicknames and will not attempt to >>>>address complex conferencing concepts such as sidebars. Their design >>>>must anticipate operating in conjunction with the conferencing >>>>protocols XCON is working towards. >>>> >>>>The working group will work within the framework for presence and IM >>>>described in RFC 2778. The extensions it defines must also be >>>>compliant with the SIP processes for extensions. The group cannot >>>>modify baseline SIP behavior or define a new version of SIP >>> >>>for IM and >>> >>>>presence. If the group determines that any capabilities requiring an >>>>extension to SIP are needed, the group will seek to define such >>>>extensions within the SIP working group, and then use them here. >>>> >>>>Goals and Milestones: >>>>Done Submission of event package for presence to IESG for >>> >>>publication >>> >>>>as Proposed Standard Done Submission of watcher information >>> >>>drafts to >>> >>>>IESG for publication as Proposed Standards Done Submission >>> >>>of proposed >>> >>>>event list mechanism to the SIP working group Done Submission of >>>>requirements for event publishing to the IESG for publication as >>>>Proposed Standard Done Submission of proposed mechanism for event >>>>publishing to the SIP working group Done Submission of SIMPLE PIDF >>>>profile to IESG for publication as Proposed Standard Done Submission >>>>of base XCAP draft to IESG for publication as Proposed Standard Done >>>>Submission of indication of instant message preparation using SIP to >>>>IESG for publication as a Proposed Standard Done Submission of XCAP >>>>usage for manipulation of presence document content Done >>> >>>Submission of >>> >>>>XCAP usage for setting presence authorization to IESG for >>> >>>publication >>> >>>>as Proposed Standard Done Submission of Filtering mechanisms to IESG >>>>for publication as a Proposed Standard Done Submission of instant >>>>messaging session draft to IESG for publication as a >>> >>>Proposed Standard >>> >>>>Done Submission of instant messaging session relay drafts to >>> >>>IESG for >>> >>>>publication as Proposed Standards Done Submission of Partial >>>>Notification mechanism to IESG for publication as a Proposed >>> >>>Standard >>> >>>>Feb 2007 Submission of an Instant Message Disposition Notification >>>>mechanism to the IESG for publication as a Proposed Standard >>> >>>Feb 2007 >>> >>>>Submission of XCAP event package to IESG or appropriate >>> >>>working group >>> >>>>targeting publication as Proposed Standard Feb 2007 Submission of >>>>proposed mechanisms meeting the advanced messaging >>> >>>requirements to the >>> >>>>IESG or appropriate working group Mar 2007 Submission of a >>> >>>performance >>> >>>>and scalability analysis of the SIMPLE presence mechanisms >>> >>>to the IESG >>> >>>>for publication as Informational Jun 2007 Submission of SIMPLE >>>>protocol annotated overview draft to IESG for publication as >>>>Informational Aug 2007 Submission of proposed mechanisms for >>>>initiating and managing Instant Message group chat to the IESG for >>>>publication as Proposed Standard Aug 2007 Conclusion of SIMPLE >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 15:37:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmas-0006rb-OB; Mon, 26 Feb 2007 15:37:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmar-0006rD-6e for simple@ietf.org; Mon, 26 Feb 2007 15:37:09 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLman-0003cw-2R for simple@ietf.org; Mon, 26 Feb 2007 15:37:09 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 12:37:04 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="42766741:sNHT60191361" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKb4Yi005507; Mon, 26 Feb 2007 12:37:04 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKaxi6028836; Mon, 26 Feb 2007 12:37:03 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:37:02 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:37:02 -0500 Message-ID: <45E344EE.2050800@cisco.com> Date: Mon, 26 Feb 2007 15:37:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:37:02.0392 (UTC) FILETIME=[DED03B80:01C759E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7949; t=1172522224; x=1173386224; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Internal=20WG=20Review=3A=20Recharter=20of =20SIP=20for=20Instant=09Messaging=0A=20and=20Presence=20Leveraging=20Exte nsions=20(simple) |Sender:=20; bh=Qnoz2vh7H5e2nPmacL6xm9SxQwviggqFKFKgWUA7LZM=; b=JhgGf4/CarDdalnMjF/B5UbqXhJkvbbQ2rJVNvxySraLVK41J6hTwO12vukmxwthlqF/JAJG 2KGXpRjMAW8WEXdhfFLFzarSBy7NjHSu3oAHW4lVhv2c2jONH/6KadRO; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org THey would have to fomally be done in SIP, but I think it makes sense to cultivate them in SIMPLE. Sort of like RFC 4662 worked. -Jonathan R. Avshalom Houri wrote: > > Regarding: > > Mar 2007 Submission of a performance and scalability analysis of the > SIMPLE presence mechanisms to the IESG for publication as Informational > > Assuming that we will find things that need to be improved in e.g. 3265 > what will be the mechanism for the improvements? Via SIP WG? > > --Avshalom > > > > *IESG Secretary * > > 30/01/2007 23:33 > > > To > iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks > , Hisham Khartabil > cc > > Subject > [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and > Presence Leveraging Extensions (simple) > > > > > > > > > A new charter for the SIP for Instant Messaging and Presence Leveraging > Extensions (simple) working group in the Real-time Applications and > Infrastructure Area of the IETF is being considered. The draft charter > is provided below for your review and comment. > > Review time is one week. > > The IETF Secretariat > > +++ > > SIP for Instant Messaging and Presence Leveraging Extensions (simple) > ====================================================================== > > Last Modified: 2007-1-24 > > Current Status: Active Working Group > > Chair(s): > Robert Sparks > Hisham Khartabil > > > Real-time Applications and Infrastructure Area Director(s): > Jon Peterson > Cullen Jennings > > Real-time Applications and Infrastructure Area Advisor: > Jon Peterson > > Technical Advisor(s): > Jon Peterson > > Mailing Lists: > General Discussion: simple@ietf.org > To Subscribe: simple-request@ietf.org > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/simple/index.html > > Description of Working Group: > > This working group focuses on the application of the Session Initiation > Protocol (SIP, RFC 3261) to the suite of services collectively known as > instant messaging and presence (IMP). The IETF has committed to > producing an interoperable standard for these services compliant to > the requirements for IM outlined in RFC 2779 (including the security > and privacy requirements there) and in the Common Presence and Instant > Messaging (CPIM) specification, developed within the IMPP working > group. As the most common services for which SIP is used share quite a > bit in common with IMP, the adaptation of SIP to IMP seems a natural > choice given the widespread support for (and relative maturity of) the > SIP standard. > > This group has completed the majority of its primary goals and will > focus on the remaining tasks documented here and concluding. Any > proposed new work should be socialized with the chairs and AD early to > determine if this WG is an appropriate venue. > > The primary remaining work of this group will be to complete: > > 1. The MSRP proposed standard mechanism for transporting sessions of > messages initiated using the SIP, compliant to the requirments of RFC > 2779, CPIM and BCP 41. > > 2. The XCAP framework for representing and carrying configuration and > policy information in SIMPLE systems. > > 3. A mechanism for representing partial changes (patches) to XML > documents and extensions to the SIMPLE publication and notification > mechanisms to convey these partial changes. > > 4. A mechanism for initiating and managing Instant Message group chat. > > 5. An annotated overview of the SIMPLE protocol definition documents. > > Any SIP extensions proposed in the course of this development will, > after a last call process, be transferred to the SIP WG for > consideration as formal SIP extensions. > > Any mechanisms created for managing Instant Message group chat are > intended to provide a bridge to the conferencing protocols that will > be defined in XCON. They will be limited in scope to address only > simple Instant Message chat with nicknames and will not attempt > to address complex conferencing concepts such as sidebars. Their > design must anticipate operating in conjunction with the conferencing > protocols XCON is working towards. > > The working group will work within the framework for presence and IM > described in RFC 2778. The extensions it defines must also be > compliant with the SIP processes for extensions. The group cannot > modify baseline SIP behavior or define a new version of SIP for IM and > presence. If the group determines that any capabilities requiring an > extension to SIP are needed, the group will seek to define such > extensions within the SIP working group, and then use them here. > > Goals and Milestones: > Done Submission of event package for presence to IESG for publication as > Proposed Standard > Done Submission of watcher information drafts to IESG for publication as > Proposed Standards > Done Submission of proposed event list mechanism to the SIP working group > Done Submission of requirements for event publishing to the IESG for > publication as Proposed Standard > Done Submission of proposed mechanism for event publishing to the SIP > working group > Done Submission of SIMPLE PIDF profile to IESG for publication as > Proposed Standard > Done Submission of base XCAP draft to IESG for publication as Proposed > Standard > Done Submission of indication of instant message preparation using SIP > to IESG for publication as a Proposed Standard > Done Submission of XCAP usage for manipulation of presence document > content > Done Submission of XCAP usage for setting presence authorization to IESG > for publication as Proposed Standard > Done Submission of Filtering mechanisms to IESG for publication as a > Proposed Standard > Done Submission of instant messaging session draft to IESG for > publication as a Proposed Standard > Done Submission of instant messaging session relay drafts to IESG for > publication as Proposed Standards > Done Submission of Partial Notification mechanism to IESG for > publication as a Proposed Standard > Feb 2007 Submission of an Instant Message Disposition Notification > mechanism to the IESG for publication as a Proposed Standard > Feb 2007 Submission of XCAP event package to IESG or appropriate working > group targeting publication as Proposed Standard > Feb 2007 Submission of proposed mechanisms meeting the advanced > messaging requirements to the IESG or appropriate working group > Mar 2007 Submission of a performance and scalability analysis of the > SIMPLE presence mechanisms to the IESG for publication as Informational > Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG > for publication as Informational > Aug 2007 Submission of proposed mechanisms for initiating and managing > Instant Message group chat to the IESG for publication as Proposed > Standard > Aug 2007 Conclusion of SIMPLE > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 15:42:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmfY-0001yD-2A; Mon, 26 Feb 2007 15:42:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmfW-0001wW-MF for simple@ietf.org; Mon, 26 Feb 2007 15:41:58 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmfN-0004cE-5D for simple@ietf.org; Mon, 26 Feb 2007 15:41:58 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2007 12:41:48 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="116292185:sNHT60019839" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKfl85030660; Mon, 26 Feb 2007 15:41:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKflOC020537; Mon, 26 Feb 2007 15:41:47 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:41:36 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:41:36 -0500 Message-ID: <45E345FF.4080705@cisco.com> Date: Mon, 26 Feb 2007 15:41:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tiago Subject: Re: [Simple] XCAP URI Parsing: Extension Selector??? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:41:36.0312 (UTC) FILETIME=[82151B80:01C759E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=948; t=1172522507; x=1173386507; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20XCAP=20URI=20Parsing=3A=20Extension=20Sele ctor??? |Sender:=20 |To:=20Tiago=20; bh=bVmilTLoRjyEW7I6fI55QETf5nYvkoKYet/IRAUsVak=; b=AuMuoWsTcug/HDx4jB1T0E1UuY8o0oc+b7O5mwgLwqLRxTYoYB/yoVSbsnimmXIkYmnf0Noy /nlRb61miwR3iOB3BJc04UcQnnpm9+vHHyBY5sr5xzcYPgy3UrRDK59U; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org You wouldn't differentiate by BNF. Its a terminal selector when the thing you've selected is the last thing in the node selector, and that can be an attribute in addition to an element. -Jonathan R. Tiago wrote: > Hi all, how can identify a terminal extension selector from an element > selector, in the XCAP URI, if it can be anything except '/' ? > > Regards, > > /snip > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 15:44:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmiK-00039V-W2; Mon, 26 Feb 2007 15:44:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmiJ-000391-2x for simple@ietf.org; Mon, 26 Feb 2007 15:44:51 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmiG-00051a-E9 for simple@ietf.org; Mon, 26 Feb 2007 15:44:51 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2007 12:44:47 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="116292703:sNHT46797417" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKilau007313; Mon, 26 Feb 2007 15:44:47 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKiPVd029690; Mon, 26 Feb 2007 15:44:38 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:44:29 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:44:28 -0500 Message-ID: <45E346AC.4060404@cisco.com> Date: Mon, 26 Feb 2007 15:44:28 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:44:28.0858 (UTC) FILETIME=[E8ED89A0:01C759E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2667; t=1172522687; x=1173386687; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Conflict=20in=20draft-ietf-simple-xcap-12 |Sender:=20 |To:=20Silvestr.Peknik@tietoenator.com; bh=2p2qfwlz0lSlZisy2ZibZMXkh6scFxOOHR91OeuOMVg=; b=JwgPMu+stdxEuNSXDHaYQYnSNMsxLNyDw0GFBDCTn7w34H9xg8g6TyXlI4j4XxK9I9ObTwZA UOt7Ry3a0HLd3J7ucEAFkatBB1/WGee6DECBzWY8oqQG8BoYyQ3erefK; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: David.Pilar@tietoenator.com, Ivo.Hajducek@tietoenator.com, simple@ietf.org Subject: [Simple] Re: Conflict in draft-ietf-simple-xcap-12 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Correct, this is a bug in the spec. Section 7.11 is incorrect. The behavior in this area changed later in the evolution of the spec, and the text in 7.11 is leftover. I will correct in auth48. -Jonathan R. Silvestr.Peknik@tietoenator.com wrote: > Hello, > > I have a problem with draft-ietf-simple-xcap-12. In my opinion following > parts of the draft are in conflict: > > 7.11 Conditional operations > ... > In another example, a client may wish to insert a new element into a > document, but wants to be sure that the insertion will only take > place if that element does not exist. In other words, the client > wants the PUT operation to be a creation, not a replacement. To > accomplish that, the client can insert the If-None-Match header field > into the PUT request, with a value of *. This tells the server to > reject the request with a 412 if resource exists. > ... > > 8.2.6. Conditional Processing > > A PUT request for an XCAP resource, like any other HTTP resource, can > be made conditional through usage of the If-Match and If-None-Match > header fields. For a replacement, these are processed as defined in > [6]. For an insertion of an element or attribute, conditional > operations are permitted. The entity tag that is used for the > procedures in [6] is the one for all of the resources within the same > document as the parent of the element or attribute being inserted. > One way to think of this is that, logically speaking, on receipt of > the PUT request, the XCAP server instantiates the etag for the > resource referenced by the request, and then applies the processing > of the request. Because of this behavior, it is not possible to > perform a conditional insert on an attribute or element conditioned > on the operation being an insertion and not a replacement. In other > words, a conditional PUT of an element or attribute with an If-None- > Match: * will always fail. > > > The former part says that I can use "If-None-Match: *" in PUT request to > ensure creation. The latter says that PUT request with "If-None-Match: > *" always fails. > > Could you please comment on this? > > Thank you, > > Silvestr Peknik > Software Specialist > TietoEnator Czech s.r.o. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 15:51:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmoc-0006WV-LF; Mon, 26 Feb 2007 15:51:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmnl-00049I-2s; Mon, 26 Feb 2007 15:50:29 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmnY-0005yw-GZ; Mon, 26 Feb 2007 15:50:29 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2F42726EEA; Mon, 26 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLmnK-0004z0-LQ; Mon, 26 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-19.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-19.txt Pages : 62 Date : 2007-2-26 This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-19.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-19.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-19.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: <2007-2-26113043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-26113043.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Feb 26 16:54:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnnM-00077x-Ge; Mon, 26 Feb 2007 16:54:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmq7-0001fn-BA for simple@ietf.org; Mon, 26 Feb 2007 15:52:55 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmpi-0006VV-6N for simple@ietf.org; Mon, 26 Feb 2007 15:52:55 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2007 12:52:29 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="764567535:sNHT49401448" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKqTM0011109; Mon, 26 Feb 2007 15:52:29 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKqGVZ002207; Mon, 26 Feb 2007 15:52:24 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:52:22 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:52:21 -0500 Message-ID: <45E34885.6000604@cisco.com> Date: Mon, 26 Feb 2007 15:52:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: joel.repiquet@tech-invite.com Subject: Re: [Simple] Presence document composition References: <47109.1169562679@tech-invite.com> In-Reply-To: <47109.1169562679@tech-invite.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Feb 2007 20:52:21.0761 (UTC) FILETIME=[02CCCF10:01C759E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1356; t=1172523149; x=1173387149; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Presence=20document=20composition |Sender:=20 |To:=20joel.repiquet@tech-invite.com; bh=yaXNGpRtb6VVCfb51Ok1MPad0+BouFjbsOVqBhIBdVg=; b=raSPNUo/mIxnr8P8LJagIJbbhymiwuiY9ZyMHrntb/QVo0rPdeNEBVOWR/Gk/2mlI5Q9J6gQ KXMeeYUsDUtNMJZHKfA2mrqyArqGZVeC3dkM7Ac1mYRaTQN7wRV40wtH; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Not sure anyone answered this, though the answer is probably clear from the new charter. Composition and presence-processing-model have been removed from the charter. It seems to be too premature for us to undertake this work. -Jonathan R. Joël Repiquet wrote: > There are two individual drafts related to presence document composition: > - draft-schulzrinne-simple-composition-02 > - rosenberg-simple-presence-processing-model-02 > > Both drafts have just expired. > > Just for knowing: > 1) is presence document composition still an ongoing work item in the > frame of the SIMPLE WG? > 2) how is the "composition" chapter in the presence-processing-model > draft related to the composition draft? in other words: is there a > common work on this topic? > > Thanks > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 16:54:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnnO-00079H-80; Mon, 26 Feb 2007 16:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmrH-0003dT-FE for simple@ietf.org; Mon, 26 Feb 2007 15:54:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmqn-0006Tk-Gc for simple@ietf.org; Mon, 26 Feb 2007 15:54:07 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 12:51:47 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="42775634:sNHT56552004" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKpkE4003173; Mon, 26 Feb 2007 15:51:46 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKpkOO023094; Mon, 26 Feb 2007 15:51:46 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:51:21 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:51:20 -0500 Message-ID: <45E34848.8010507@cisco.com> Date: Mon, 26 Feb 2007 15:51:20 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eduardo Martins Subject: Re: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:51:20.0965 (UTC) FILETIME=[DE901350:01C759E7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1214; t=1172523106; x=1173387106; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Is=20there=20any=20Document=20(and=20Namin g=20Conventions)=20to=20specify=0A=20AUIDs=20in=20XCAP=20Server? |Sender:=20 |To:=20Eduardo=20Martins=20; bh=9PUogdP2cUj4zg0t5yFUrN4d+bHAk2rZVFhEx6v1Rh4=; b=E/nFjolKEgpI3GqO0eV3kNaS0ksrWkxk5olKZbs4c2PdclBhlp+n+pn5FOCPU221F2zHVSs0 ydRtO5SAmIhCtv6esVGjsZWr6lwxIGQuy/V9YnCHDLJzQpWwHYkghrfb; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I don't understand the question. The xcaps-caps AUIDs are the AUIDs understood by the server, which would be either in the IETF tree or in the vendor proprietary tree. In the former case, the AUIDs are defined in their respective RFCs. In the latter case, they are proprietary, so there is no public definitions of what they mean. -Jonathan R. Eduardo Martins wrote: > Hi, is there any document definition for each of xcap-caps AUIDs (and a > path relative xcap root?), where all its properties are defined, or > should this kind of info, like the AUID's mimetype for example, be > unavailable externally? > > Regards > > Eduardo > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 17:49:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoeD-00038T-UC; Mon, 26 Feb 2007 17:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLodW-0002jy-Cd for simple@ietf.org; Mon, 26 Feb 2007 17:48:02 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLodP-00060P-KM for simple@ietf.org; Mon, 26 Feb 2007 17:48:02 -0500 Received: by an-out-0708.google.com with SMTP id d30so1094546and for ; Mon, 26 Feb 2007 14:47:55 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=QAx1o10HG9PbArXQtLwLEvRgHJfFlCy87HO1r4HhoZfJdu+sPyTOLlUoa4P5mQpuDrFWe1jzAvoZ5trvnvb3/tUigwkhy7fR14qyBxpQTAkk+4mTtlTbFa32bHsQtI0agAbztrcwrnnx809q+9to0b71qWwPH1IsAyGRgyhpubo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=fxbwox0FmpNXGpnhSFYaFGJ0KSLRmLtmdTklKAieHNN9UZMDCWl/VqLvXDLN8gSvFSILVbGYE7KRyIOJO1ANLJeHFW0i7lhEGgv0wk4ZCwWGd16RU93vXSGIdFPU/a91mF2EMUgctIG4u3Y6Jkw0HtCYA8R5b9ZYGTCIq3Xo32Q= Received: by 10.114.200.2 with SMTP id x2mr73588waf.1172530070737; Mon, 26 Feb 2007 14:47:50 -0800 (PST) Received: by 10.114.88.2 with HTTP; Mon, 26 Feb 2007 14:47:50 -0800 (PST) Message-ID: Date: Mon, 26 Feb 2007 22:47:50 +0000 From: "Eduardo Martins" To: simple@ietf.org Subject: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? In-Reply-To: MIME-Version: 1.0 References: <45E34848.8010507@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0026197393==" Errors-To: simple-bounces@ietf.org --===============0026197393== Content-Type: multipart/alternative; boundary="----=_Part_145_14518277.1172530070642" ------=_Part_145_14518277.1172530070642 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jonathan, I was looking for a document schema that would specify a App Usage in a XML file but I think it doesn't exist. If this existed it would be interesting to set a app usage (or maybe reuse the caps one) where all app usage documents could be stored in the xcap doc tree. Best regards, Eduardo Martins On 2/26/07, Jonathan Rosenberg wrote: > > I don't understand the question. The xcaps-caps AUIDs are the AUIDs > understood by the server, which would be either in the IETF tree or in > the vendor proprietary tree. In the former case, the AUIDs are defined > in their respective RFCs. In the latter case, they are proprietary, so > there is no public definitions of what they mean. > > -Jonathan R. > > Eduardo Martins wrote: > > > Hi, is there any document definition for each of xcap-caps AUIDs (and a > > path relative xcap root?), where all its properties are defined, or > > should this kind of info, like the AUID's mimetype for example, be > > unavailable externally? > > > > Regards > > > > Eduardo > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > ------=_Part_145_14518277.1172530070642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jonathan, I was looking for a document schema that would specify a App Usage in a XML file but I think it doesn't exist. If this existed it would be interesting to set a app usage (or maybe reuse the caps one) where all app usage documents could be stored in the xcap doc tree.

Best regards,

Eduardo Martins


On 2/26/07, Jonathan Rosenberg < jdrosen@cisco.com> wrote:
I don't understand the question. The xcaps-caps AUIDs are the AUIDs
understood by the server, which would be either in the IETF tree or in
the vendor proprietary tree. In the former case, the AUIDs are defined
in their respective RFCs. In the latter case, they are proprietary, so
there is no public definitions of what they mean.

-Jonathan R.

Eduardo Martins wrote:

> Hi, is there any document definition for each of xcap-caps AUIDs (and a
> path relative xcap root?), where all its properties are defined, or
> should this kind of info, like the AUID's mimetype for example, be
> unavailable externally?
>
> Regards
>
> Eduardo
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

------=_Part_145_14518277.1172530070642-- --===============0026197393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0026197393==-- From simple-bounces@ietf.org Mon Feb 26 17:53:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoj0-00078P-SK; Mon, 26 Feb 2007 17:53:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoiU-0006hf-UV for simple@ietf.org; Mon, 26 Feb 2007 17:53:10 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLoiH-0006qd-IE for simple@ietf.org; Mon, 26 Feb 2007 17:53:10 -0500 Received: by ug-out-1314.google.com with SMTP id 72so872859ugd for ; Mon, 26 Feb 2007 14:52:56 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=CNKYquMRWwHTa7izX0sePff85BiDJLpK8iDP7NOhe/W42ap2EtP6iI9bhSmrZVFPM9U1LTIsX7+CyWGrKe1i39cUvE/XMbWt5nrbIycQAA6xnLiVLh+tD7EN94ebQ7vBNYsCWPKs+hEno1bAbAx8BM3WsT0FBTVpWgCNichVZl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GEEBj6eyJYN2TRK60tSmqmyDDUmIsBoNKkWMn7l8t1mCXXmSnXupbRQvFhU8SHIToUUhxmGZ7wKhu5AZm0xlTK7XE1jYjSS+0t49rsGaxqc7BSsR7VVfAsXuGK6ZDVfoO67U8gkG0GkaUAlZKaFpy3VcCOUyYRKJx/L22ifvoA8= Received: by 10.114.202.15 with SMTP id z15mr1138835waf.1172530373625; Mon, 26 Feb 2007 14:52:53 -0800 (PST) Received: by 10.114.88.2 with HTTP; Mon, 26 Feb 2007 14:52:53 -0800 (PST) Message-ID: Date: Mon, 26 Feb 2007 22:52:53 +0000 From: "Eduardo Martins" To: "Jonathan Rosenberg" Subject: Re: [Simple] Re: Conflict in draft-ietf-simple-xcap-12 In-Reply-To: <45E346AC.4060404@cisco.com> MIME-Version: 1.0 References: <45E346AC.4060404@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2014303079==" Errors-To: simple-bounces@ietf.org --===============2014303079== Content-Type: multipart/alternative; boundary="----=_Part_253_23902222.1172530373539" ------=_Part_253_23902222.1172530373539 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Also, a little error in page 39: should be Best regards, Eduardo Martins On 2/26/07, Jonathan Rosenberg wrote: > > Correct, this is a bug in the spec. Section 7.11 is incorrect. The > behavior in this area changed later in the evolution of the spec, and > the text in 7.11 is leftover. I will correct in auth48. > > -Jonathan R. > > Silvestr.Peknik@tietoenator.com wrote: > > > Hello, > > > > I have a problem with draft-ietf-simple-xcap-12. In my opinion following > > parts of the draft are in conflict: > > > > 7.11 Conditional operations > > ... > > In another example, a client may wish to insert a new element into a > > document, but wants to be sure that the insertion will only take > > place if that element does not exist. In other words, the client > > wants the PUT operation to be a creation, not a replacement. To > > accomplish that, the client can insert the If-None-Match header field > > into the PUT request, with a value of *. This tells the server to > > reject the request with a 412 if resource exists. > > ... > > > > 8.2.6. Conditional Processing > > > > A PUT request for an XCAP resource, like any other HTTP resource, can > > be made conditional through usage of the If-Match and If-None-Match > > header fields. For a replacement, these are processed as defined in > > [6]. For an insertion of an element or attribute, conditional > > operations are permitted. The entity tag that is used for the > > procedures in [6] is the one for all of the resources within the same > > document as the parent of the element or attribute being inserted. > > One way to think of this is that, logically speaking, on receipt of > > the PUT request, the XCAP server instantiates the etag for the > > resource referenced by the request, and then applies the processing > > of the request. Because of this behavior, it is not possible to > > perform a conditional insert on an attribute or element conditioned > > on the operation being an insertion and not a replacement. In other > > words, a conditional PUT of an element or attribute with an If-None- > > Match: * will always fail. > > > > > > The former part says that I can use "If-None-Match: *" in PUT request to > > ensure creation. The latter says that PUT request with "If-None-Match: > > *" always fails. > > > > Could you please comment on this? > > > > Thank you, > > > > Silvestr Peknik > > Software Specialist > > TietoEnator Czech s.r.o. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > ------=_Part_253_23902222.1172530373539 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Also, a little error in page 39:

    <el1 att="second"/><el1 att="third">

should be

    <el1 att="second"/><el1 att="third"/>

Best regards,

Eduardo Martins

On 2/26/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
Correct, this is a bug in the spec. Section 7.11 is incorrect. The
behavior in this area changed later in the evolution of the spec, and
the text in 7.11 is leftover. I will correct in auth48.

-Jonathan R.

Silvestr.Peknik@tietoenator.com wrote:

> Hello,
>
> I have a problem with draft-ietf-simple-xcap-12. In my opinion following
> parts of the draft are in conflict:
>
> 7.11 Conditional operations
> ...
> In another example, a client may wish to insert a new element into a
>    document, but wants to be sure that the insertion will only take
>    place if that element does not exist.  In other words, the client
>    wants the PUT operation to be a creation, not a replacement.  To
>    accomplish that, the client can insert the If-None-Match header field
>    into the PUT request, with a value of *.  This tells the server to
>    reject the request with a 412 if resource exists.
> ...
>
> 8.2.6.  Conditional Processing
>
>    A PUT request for an XCAP resource, like any other HTTP resource, can
>    be made conditional through usage of the If-Match and If-None-Match
>    header fields.  For a replacement, these are processed as defined in
>    [6].  For an insertion of an element or attribute, conditional
>    operations are permitted.  The entity tag that is used for the
>    procedures in [6] is the one for all of the resources within the same
>    document as the parent of the element or attribute being inserted.
>    One way to think of this is that, logically speaking, on receipt of
>    the PUT request, the XCAP server instantiates the etag for the
>    resource referenced by the request, and then applies the processing
>    of the request.  Because of this behavior, it is not possible to
>    perform a conditional insert on an attribute or element conditioned
>    on the operation being an insertion and not a replacement.  In other
>    words, a conditional PUT of an element or attribute with an If-None-
>    Match: * will always fail.
>
>
> The former part says that I can use "If-None-Match: *" in PUT request to
> ensure creation. The latter says that PUT request with "If-None-Match:
> *" always fails.
>
> Could you please comment on this?
>
> Thank you,
>
> Silvestr Peknik
> Software Specialist
> TietoEnator Czech s.r.o.
>

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------=_Part_253_23902222.1172530373539-- --===============2014303079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2014303079==-- From simple-bounces@ietf.org Mon Feb 26 18:06:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLouX-0004x1-Sw; Mon, 26 Feb 2007 18:05:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLou9-0004io-Rv for simple@ietf.org; Mon, 26 Feb 2007 18:05:13 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLou6-0000F1-KC for simple@ietf.org; Mon, 26 Feb 2007 18:05:13 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2007 15:05:07 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="116325966:sNHT51293610" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1QN57ej013775; Mon, 26 Feb 2007 15:05:07 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1QN56ho012739; Mon, 26 Feb 2007 15:05:07 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 18:05:06 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 18:05:06 -0500 Message-ID: <45E367A1.1050209@cisco.com> Date: Mon, 26 Feb 2007 18:05:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eduardo Martins Subject: Re: [Simple] Re: Conflict in draft-ietf-simple-xcap-12 References: <45E346AC.4060404@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 23:05:06.0229 (UTC) FILETIME=[8DFE2E50:01C759FA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4130; t=1172531107; x=1173395107; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Re=3A=20Conflict=20in=20draft-ietf-simple- xcap-12 |Sender:=20; bh=RevuDv29X5/xVrIaULVENB2DEnHz9AfSXoqklY6oHdM=; b=Cb9L1Ga1SBQUiBhKz+P7Say1aWiyPQpvnsPE+dZjpdrD27Ex8lWpKwYIw+2vp+EYr2TsZ00B QmTbaWETCIgA9sSW7vbhN3U2EutANx0X3dYq8f8OKY/goSc+zJ1O4KDI; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org OK, I'll fix. Thanks, Jonathan R. Eduardo Martins wrote: > Also, a little error in page 39: > > > > should be > > > > Best regards, > > Eduardo Martins > > On 2/26/07, *Jonathan Rosenberg* > wrote: > > Correct, this is a bug in the spec. Section 7.11 is incorrect. The > behavior in this area changed later in the evolution of the spec, and > the text in 7.11 is leftover. I will correct in auth48. > > -Jonathan R. > > Silvestr.Peknik@tietoenator.com > wrote: > > > Hello, > > > > I have a problem with draft-ietf-simple-xcap-12. In my opinion > following > > parts of the draft are in conflict: > > > > 7.11 Conditional operations > > ... > > In another example, a client may wish to insert a new element into a > > document, but wants to be sure that the insertion will only take > > place if that element does not exist. In other words, the client > > wants the PUT operation to be a creation, not a replacement. To > > accomplish that, the client can insert the If-None-Match > header field > > into the PUT request, with a value of *. This tells the > server to > > reject the request with a 412 if resource exists. > > ... > > > > 8.2.6. Conditional Processing > > > > A PUT request for an XCAP resource, like any other HTTP > resource, can > > be made conditional through usage of the If-Match and > If-None-Match > > header fields. For a replacement, these are processed as > defined in > > [6]. For an insertion of an element or attribute, conditional > > operations are permitted. The entity tag that is used for the > > procedures in [6] is the one for all of the resources within > the same > > document as the parent of the element or attribute being inserted. > > One way to think of this is that, logically speaking, on > receipt of > > the PUT request, the XCAP server instantiates the etag for the > > resource referenced by the request, and then applies the > processing > > of the request. Because of this behavior, it is not possible to > > perform a conditional insert on an attribute or element > conditioned > > on the operation being an insertion and not a replacement. In > other > > words, a conditional PUT of an element or attribute with an > If-None- > > Match: * will always fail. > > > > > > The former part says that I can use "If-None-Match: *" in PUT > request to > > ensure creation. The latter says that PUT request with > "If-None-Match: > > *" always fails. > > > > Could you please comment on this? > > > > Thank you, > > > > Silvestr Peknik > > Software Specialist > > TietoEnator Czech s.r.o. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com > FAX: (973) > 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 18:08:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoxP-0006QP-8r; Mon, 26 Feb 2007 18:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLowq-00068E-5q for simple@ietf.org; Mon, 26 Feb 2007 18:08:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLowo-0000iU-Pd for simple@ietf.org; Mon, 26 Feb 2007 18:08:00 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2007 15:07:37 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="764589926:sNHT3335755592" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1QN7bcF014952; Mon, 26 Feb 2007 15:07:37 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1QN7InR002716; Mon, 26 Feb 2007 15:07:36 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 18:07:31 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 18:07:30 -0500 Message-ID: <45E36832.6040603@cisco.com> Date: Mon, 26 Feb 2007 18:07:30 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eduardo Martins Subject: Re: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? References: <45E34848.8010507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 23:07:30.0963 (UTC) FILETIME=[E442D630:01C759FA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2728; t=1172531257; x=1173395257; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Is=20there=20any=20Document=20(and=20Namin g=20Conventions)=20to=20specify=0A=20AUIDs=20in=20XCAP=20Server? |Sender:=20; bh=J9V3CERtMMjXAGF1Uks7RaS+KTpupihzJjezRHyszEs=; b=NV3XyHUQY6y9Bo+bO5Lyt0O1U1T/gjmBxDTWUpiA/cOPRxCJkK89lXNmVscIIOvLxB9IJTPm oIuXOVqrjJi4UXFgKrkOn9ge8IjrPM7PX6BC4PMlrpDJZmuFXYfDeTLl; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Are you talking about schema for the documents for a particular app usage? For example, xcap-list-usage has schema for resource lists and RLS services documents. Do you want an app usage that contains the schema for those? I still don't understand what you are asking for. -Jonathan R. Eduardo Martins wrote: > Hi Jonathan, I was looking for a document schema that would specify a > App Usage in a XML file but I think it doesn't exist. If this existed it > would be interesting to set a app usage (or maybe reuse the caps one) > where all app usage documents could be stored in the xcap doc tree. > > Best regards, > > Eduardo Martins > > > On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com > > wrote: > > I don't understand the question. The xcaps-caps AUIDs are the AUIDs > understood by the server, which would be either in the IETF tree or in > the vendor proprietary tree. In the former case, the AUIDs are defined > in their respective RFCs. In the latter case, they are proprietary, so > there is no public definitions of what they mean. > > -Jonathan R. > > Eduardo Martins wrote: > >> Hi, is there any document definition for each of xcap-caps AUIDs > (and a >> path relative xcap root?), where all its properties are defined, or >> should this kind of info, like the AUID's mimetype for example, be >> unavailable externally? >> >> Regards >> >> Eduardo >> >> >> > ------------------------------------------------------------------------ >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com > FAX: (973) > 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 18:18:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLp6M-0003OM-6K; Mon, 26 Feb 2007 18:17:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLp5o-0003Ad-Jv for simple@ietf.org; Mon, 26 Feb 2007 18:17:16 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLp5m-0002Ds-NI for simple@ietf.org; Mon, 26 Feb 2007 18:17:16 -0500 Received: by nz-out-0506.google.com with SMTP id z6so1406125nzd for ; Mon, 26 Feb 2007 15:17:14 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=paj2e6dqW9wltH/pmSeDrMlXfrdgnkoSahaxzZ0xpP495GMOIDxMD4RevtCvrbvrJcC48dC3IbjtoForb5g8nXfg6cxISTpsD6eB0ut+mP8txB7INwOE6jV+mpH4aPGtPGcxeiZ3fzb16+r/wJg6ZLHHme+kGBQ2xJSHnAmeK/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tEgIVd237uIzs0G1ijZfpzao55p/YcjuBtg80UgcbJvL0UeVYSFLFSmmiXWO16cBh+9EehgCAJu9alUkniFiwci8fA6Cf/AwQn9FNJh3fLmD+CsVNLghzzTwCg5X8VL1vbX0XNkts16JGVUHjqIszvpcRg1DdOoK4Uk20YMzG7Q= Received: by 10.115.107.1 with SMTP id j1mr147820wam.1172531833834; Mon, 26 Feb 2007 15:17:13 -0800 (PST) Received: by 10.114.88.2 with HTTP; Mon, 26 Feb 2007 15:17:13 -0800 (PST) Message-ID: Date: Mon, 26 Feb 2007 23:17:13 +0000 From: "Eduardo Martins" To: simple@ietf.org Subject: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? In-Reply-To: MIME-Version: 1.0 References: <45E34848.8010507@cisco.com> <45E36832.6040603@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1730354053==" Errors-To: simple-bounces@ietf.org --===============1730354053== Content-Type: multipart/alternative; boundary="----=_Part_558_29773425.1172531833782" ------=_Part_558_29773425.1172531833782 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Seems I can't explain it well, in my idea it would be a XML Schema that would define a XML document for specifying every App Usage. Maybe an example of what such a XML doc could be: IETF SIMPLE Presence Rules pres-rules urn:ietf:params:xml:ns:pres-rules application/auth-policy+xml ... Best regards, Eduardo Martins On 2/26/07, Jonathan Rosenberg wrote: > > Are you talking about schema for the documents for a particular app > usage? For example, xcap-list-usage has schema for resource lists and > RLS services documents. Do you want an app usage that contains the > schema for those? I still don't understand what you are asking for. > > -Jonathan R. > > Eduardo Martins wrote: > > > Hi Jonathan, I was looking for a document schema that would specify a > > App Usage in a XML file but I think it doesn't exist. If this existed it > > would be interesting to set a app usage (or maybe reuse the caps one) > > where all app usage documents could be stored in the xcap doc tree. > > > > Best regards, > > > > Eduardo Martins > > > > > > On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com > > > wrote: > > > > I don't understand the question. The xcaps-caps AUIDs are the AUIDs > > understood by the server, which would be either in the IETF tree or > in > > the vendor proprietary tree. In the former case, the AUIDs are > defined > > in their respective RFCs. In the latter case, they are proprietary, > so > > there is no public definitions of what they mean. > > > > -Jonathan R. > > > > Eduardo Martins wrote: > > > >> Hi, is there any document definition for each of xcap-caps AUIDs > > (and a > >> path relative xcap root?), where all its properties are defined, or > >> should this kind of info, like the AUID's mimetype for example, be > >> unavailable externally? > >> > >> Regards > >> > >> Eduardo > >> > >> > >> > > > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com > > FAX: (973) > > 952-5050 > > http://www.jdrosen.net PHONE: (973) > 952-5000 > > http://www.cisco.com > > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > ------=_Part_558_29773425.1172531833782 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Seems I can't explain it well, in my idea it would be a XML Schema that would define a XML document for specifying every App Usage. Maybe an example of what such a XML doc could be:

<app-usage>
    <description>IETF SIMPLE Presence Rules</description>
    <auid>pres-rules</auid>
    <default-document-namespace>urn:ietf:params:xml:ns:pres-rules</default-document-namespace>
    <mimetype>application/auth-policy+xml</mimetype>
    ...
</app-usage>

Best regards,

Eduardo Martins


On 2/26/07, Jonathan Rosenberg <jdrosen@cisco.com > wrote:
Are you talking about schema for the documents for a particular app
usage? For example, xcap-list-usage has schema for resource lists and
RLS services documents. Do you want an app usage that contains the
schema for those? I still don't understand what you are asking for.

-Jonathan R.

Eduardo Martins wrote:

> Hi Jonathan, I was looking for a document schema that would specify a
> App Usage in a XML file but I think it doesn't exist. If this existed it
> would be interesting to set a app usage (or maybe reuse the caps one)
> where all app usage documents could be stored in the xcap doc tree.
>
> Best regards,
>
> Eduardo Martins
>
>
> On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com
> <mailto:jdrosen@cisco.com>> wrote:
>
>     I don't understand the question. The xcaps-caps AUIDs are the AUIDs
>     understood by the server, which would be either in the IETF tree or in
>     the vendor proprietary tree. In the former case, the AUIDs are defined
>     in their respective RFCs. In the latter case, they are proprietary, so
>     there is no public definitions of what they mean.
>
>     -Jonathan R.
>
>     Eduardo Martins wrote:
>
>>  Hi, is there any document definition for each of xcap-caps AUIDs
>     (and a
>>  path relative xcap root?), where all its properties are defined, or
>>  should this kind of info, like the AUID's mimetype for example, be
>>  unavailable externally?
>>
>>  Regards
>>
>>  Eduardo
>>
>>
>>
>     ------------------------------------------------------------------------
>>
>>  _______________________________________________
>>  Simple mailing list
>>   Simple@ietf.org <mailto:Simple@ietf.org>
>>   https://www1.ietf.org/mailman/listinfo/simple
>
>     --
>     Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>     Cisco Fellow                                   Parsippany, NJ 07054-2711
>     Cisco Systems
>     jdrosen@cisco.com
>     <mailto:jdrosen@cisco.com>                              FAX:   (973)
>     952-5050
>     http://www.jdrosen.net                          PHONE: (973) 952-5000
>     http://www.cisco.com
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                               FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

------=_Part_558_29773425.1172531833782-- --===============1730354053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1730354053==-- From simple-bounces@ietf.org Mon Feb 26 19:31:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqDl-0004eo-Kj; Mon, 26 Feb 2007 19:29:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqCf-0006Ps-7n for simple@ietf.org; Mon, 26 Feb 2007 19:28:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmyP-0006wo-Ny for simple@ietf.org; Mon, 26 Feb 2007 16:02:13 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2007 12:57:27 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="116294797:sNHT49169259" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKvQ4S013534; Mon, 26 Feb 2007 15:57:26 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKuxOG024633; Mon, 26 Feb 2007 15:57:26 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:57:25 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:57:24 -0500 Message-ID: <45E349B4.9060009@cisco.com> Date: Mon, 26 Feb 2007 15:57:24 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] draft-ietf-simple-xcap: Can node selector separator be encoded? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:57:24.0978 (UTC) FILETIME=[B7880D20:01C759E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4599; t=1172523446; x=1173387446; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20draft-ietf-simple-xcap=3A=20Can=20node=20s elector=20separator=0A=20be=09encoded? |Sender:=20 |To:=20Silvestr.Peknik@tietoenator.com; bh=JPnxHRAPlDaDqjRx8iiG/cl6mXf+HgUXyNqiQ8pKFQ0=; b=C/xD+TS4U3dBOPSJ6YIq+U14M7VQx7TNiK0pDqHIYI19i5hg9Ng+mPr1dZI10g+41CN9YDgV Ilz9nqvSBbu6z+uEn0cUTz2/9oyMIuWokJGJ5wgX1SPxwWH9Jn/TD06V; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This is an old note, but an unresolved issue. XCAP just went into auth48 so we need to figure out what to do here. I do understand your point now; you could also escape it in the body and then double escape it in the URI, and this would work also. As you note, this assumes that everyone escapes these in the documents themselves, and that would need to be done for all usages that every have documents that contain xcap URI as references. Rather than make this broad requirement everywhere, I think its easier to add one sentence to xcap that says when there are multiple ~~, the first is the separator. Thanks, Jonathan R. Silvestr.Peknik@tietoenator.com wrote: > Hello, comments below. Thank you for the response. > > Silvestr > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Monday, December 11, 2006 8:59 PM >>To: Peknik Silvestr >>Cc: simple@ietf.org >>Subject: Re: [Simple] draft-ietf-simple-xcap: Can node selector > > separator > >>be encoded? >> >>Hmm, this is an issue I think. The XCAP server is supposed to unescape >>the URI and then look for the ~~ as the node selector separator. >>However, it will appear twice in the URI in this case - one of them as >>the content of the anchor attribute in the node selector. You can't >>double escape it, since the node matching rules aren't based on URI >>equality, they are based on string equality. > > > Silvestr: I am not sure why I cant double-escape it? I thought that I > have it encoded once in the document itself, and twice in the request > uri. So after one un-escaping, string comparison of the node selector in > uri and the value of the anchor attribute in the document would match. > > However clients will probably not escape the body, as there is no > indication in specifications that they should do so (afaik). > > I will try to get feedback from OMA on this issue. > > > >>I can think of a few solutions: >> >>1. xcap spec should be clarified to say that the FIRST instance of ~~ > > is > >>the node selector separator >> >>2. xcap-list usage should define an additional attribute of the >> element that can be used as a key for selection, like an > > "id" > >>attribute >> >> >>I'm inclined for #1, since this is much simpler and less of a change. >> >>Comments? >> >>-Jonathan R. >> >> >>Silvestr.Peknik@tietoenator.com wrote: >> >> >>>Hello, >>> >>>I am not sure about following part of the draft: >>> >>>6. URI Construction >>>... >>>The node selector separator is a path segment with a value of double >> >>tilde ("~~"), and SHOULD NOT be percent-encoded, as advised in Section > > 2.3 > >>of RFC 3986 [13]. URIs containing %7E%7E should be normalized to ~~ for >>comparison; they are equivalent. >> >>>... >>> >>>Does this mean that the server will treat %7E%7E as node selector >> >>separator? >> >>> >>>Background info: OMA-TS-XDM_Core specification which uses this draft > > says > >>that the node selector separator shall appear ONLY once. Consider > > following > >>example: >> >>>... >>> > anchor="http://test.com/resource-lists/users/xui/index/~~/foo"> > >>>... >>> >>>If i want to fetch the element based on the anchor value, > > I > >>need to encode /~~/. So I need to know if it is sufficient to encode it >>once (so in XCAP URI it will appear as /%7E%7E/) or do I need to encode > > it > >>twice (%257E%257E), in which case I'd need to have it encoded once in > > the > >>body as well. >> >>>I hope that is not too confusing. >>> >>>Thank you, >>> >>>Silvestr Peknik >>>Software Specialist >>>TietoEnator >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Cisco Fellow Parsippany, NJ > > 07054-2711 > >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 26 19:39:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqNU-0006b9-MQ; Mon, 26 Feb 2007 19:39:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqLz-0005kL-My; Mon, 26 Feb 2007 19:38:03 -0500 Received: from deliverator7.gatech.edu ([130.207.165.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLqLv-0006xa-8f; Mon, 26 Feb 2007 19:38:03 -0500 Received: from deliverator7.gatech.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7A34A1A88; Mon, 26 Feb 2007 19:37:58 -0500 (EST) (envelope-from christian@gatech.edu) Received: from mailprx4.gatech.edu (mailprx4.prism.gatech.edu [130.207.171.18]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp.mail.gatech.edu", Issuer "RSA Data Security, Inc." (verified OK)) by deliverator7.gatech.edu (Postfix) with ESMTP id 083451AE1; Mon, 26 Feb 2007 19:37:13 -0500 (EST) (envelope-from christian@gatech.edu) Received: from Christian2 (r82h200.res.gatech.edu [128.61.82.200]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (sasl: method=LOGIN, username=cmenkens3@mailprx4.gatech.edu, sender=n/a) by mailprx4.gatech.edu (Postfix) with ESMTP id 33BBA215F; Mon, 26 Feb 2007 19:37:12 -0500 (EST) (envelope-from christian@gatech.edu) From: "Christian M Menkens" To: Date: Mon, 26 Feb 2007 19:37:11 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdaB2q23rNZKLHMS2m2lTP7TqZCgw== Message-Id: <20070227003712.33BBA215F@mailprx4.gatech.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: rohc@ietf.org, sip-implementors@cs.columbia.edu Subject: [Simple] SIMPLE - Presence Dictionary compression X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1816432855==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1816432855== Content-Type: multipart/alternative; boundary="----=_NextPart_000_07B8_01C759DD.8375AC00" This is a multi-part message in MIME format. ------=_NextPart_000_07B8_01C759DD.8375AC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am currently working on evaluating SigComp for out IMS lab at our university and I saw that Miguel A. Garcia developed a new dictionary for Presence traffic. This looks really interesting and I am wondering if there is some compression/decompression software (test UA and sigcomp implementation etc) out there that can compress SIP traffic with that dictionary already. I already talked to developers from OpenSigComp and they said it will probably be part of a future implementation but for now I would need to implement it myself. Our project team would like to put more effort into analysing typical traffic and compression rates and I think there is not enough time to implement everything. I thought maybe someone is already working on that? Best, Christian ---------------------------------------------------- Christian M. Menkens Georgia Institute of Technology 251 10th Street, NW, G404 Atlanta, Georgia 30318 Phone: 404-206-3586 Mobile: 404-547-1953 christian@gatech.edu christian@menkens.at www.christianmenkens.at ------=_NextPart_000_07B8_01C759DD.8375AC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I am currently working on evaluating SigComp =
for out IMS lab at our university and I saw that Miguel A. Garcia =
developed a new dictionary for Presence traffic. This looks really =
interesting and I am wondering if there is some =
compression/decompression software (test UA and sigcomp implementation =
etc) out there that can compress SIP traffic with that dictionary =
already.
 
I already talked to developers from =
OpenSigComp and they said it will probably be part of a future =
implementation but for now I would need to implement it myself. =

 
Our project team would like to put more =
effort into analysing typical traffic and compression rates and I think =
there is not enough time to implement =
everything.
 
I thought maybe someone is already working on =
that?
 
Best,
 
Christian

 

--------------------------= --------------------------

Christian M. Menkens
Georgia Institute of Technology

251 10th Street, = NW, G404
Atlanta, = Georgia
30318
Phone: 404-206-3586
Mobile: 404-547-1953
christian@gatech.edu
christian@menkens.at<= /font>
www.christianmenkens.at

 

------=_NextPart_000_07B8_01C759DD.8375AC00-- --===============1816432855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1816432855==-- From simple-bounces@ietf.org Tue Feb 27 09:22:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3DO-000856-6Y; Tue, 27 Feb 2007 09:22:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3DM-00084v-Pe for simple@ietf.org; Tue, 27 Feb 2007 09:22:00 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3DL-0004Wg-5H for simple@ietf.org; Tue, 27 Feb 2007 09:22:00 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2007 06:21:59 -0800 X-IronPort-AV: i="4.14,226,1170662400"; d="scan'208"; a="467315641:sNHT52815200" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1RELwJ0030874; Tue, 27 Feb 2007 09:21:58 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1RELMOi029138; Tue, 27 Feb 2007 09:21:57 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 09:21:46 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 09:21:46 -0500 Message-ID: <45E43E79.9050408@cisco.com> Date: Tue, 27 Feb 2007 09:21:45 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eduardo Martins Subject: Re: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? References: <45E34848.8010507@cisco.com> <45E36832.6040603@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2007 14:21:46.0357 (UTC) FILETIME=[9C9FB250:01C75A7A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4593; t=1172586118; x=1173450118; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Is=20there=20any=20Document=20(and=20Namin g=20Conventions)=20to=20specify=0A=20AUIDs=20in=20XCAP=20Server? |Sender:=20 |To:=20Eduardo=20Martins=20; bh=wH4rM0JR79ECglYrpWMT0XqjvchHgHI7VJ+vFNJ9vW0=; b=IVT1TiZaiEUrMrQuEpDbzj5kVbrEn54B0u9yPAAo5eJHH4nfU7W2TvGWBlqgnoc/G7GVZzc5 Jzb7n+JlGbji8yyuU9sHnqQSrf3jI1ZwzjWn7MlaKyC4VLE/qGNcuBse; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org OK, though I'm not sure what it would be used for. What was your use case? -Jonathan R. Eduardo Martins wrote: > Seems I can't explain it well, in my idea it would be a XML Schema that > would define a XML document for specifying every App Usage. Maybe an > example of what such a XML doc could be: > > > IETF SIMPLE Presence Rules > pres-rules > > urn:ietf:params:xml:ns:pres-rules > application/auth-policy+xml > ... > > > Best regards, > > Eduardo Martins > > > On 2/26/07, * Jonathan Rosenberg* > wrote: > > Are you talking about schema for the documents for a particular app > usage? For example, xcap-list-usage has schema for resource lists and > RLS services documents. Do you want an app usage that contains the > schema for those? I still don't understand what you are asking for. > > -Jonathan R. > > Eduardo Martins wrote: > >> Hi Jonathan, I was looking for a document schema that would specify a >> App Usage in a XML file but I think it doesn't exist. If this > existed it >> would be interesting to set a app usage (or maybe reuse the caps one) >> where all app usage documents could be stored in the xcap doc tree. >> >> Best regards, >> >> Eduardo Martins >> >> >> On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com > >> >> wrote: >> >> I don't understand the question. The xcaps-caps AUIDs are the > AUIDs >> understood by the server, which would be either in the IETF > tree or in >> the vendor proprietary tree. In the former case, the AUIDs are > defined >> in their respective RFCs. In the latter case, they are > proprietary, so >> there is no public definitions of what they mean. >> >> -Jonathan R. >> >> Eduardo Martins wrote: >> >> > Hi, is there any document definition for each of xcap-caps AUIDs >> (and a >> > path relative xcap root?), where all its properties are defined, or >> > should this kind of info, like the AUID's mimetype for example, be >> > unavailable externally? >> > >> > Regards >> > >> > Eduardo >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/simple >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ > 07054-2711 >> Cisco Systems >> jdrosen@cisco.com >> > FAX: (973) >> 952-5050 >> http://www.jdrosen.net > PHONE: (973) 952-5000 >> http://www.cisco.com >> >> >> >> > ------------------------------------------------------------------------ > >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com > FAX: (973) > 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 27 09:46:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3as-0003Mf-Ik; Tue, 27 Feb 2007 09:46:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3ar-0003Ma-KQ for simple@ietf.org; Tue, 27 Feb 2007 09:46:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3aq-0007NQ-19 for simple@ietf.org; Tue, 27 Feb 2007 09:46:17 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2007 06:46:15 -0800 X-IronPort-AV: i="4.14,226,1170662400"; d="scan'208"; a="394182842:sNHT54625732" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1REkFWC020396; Tue, 27 Feb 2007 06:46:15 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1REkEnH003836; Tue, 27 Feb 2007 06:46:15 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 09:46:00 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 09:46:00 -0500 Message-ID: <45E44427.1070305@cisco.com> Date: Tue, 27 Feb 2007 09:45:59 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vrancken, Johnny" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Feb 2007 14:46:00.0318 (UTC) FILETIME=[FF4089E0:01C75A7D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4765; t=1172587575; x=1173451575; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Comments=20on=20presence-rules-08 |Sender:=20; bh=CzQs+JHtyB0vd6c5A3Ts/RS74kXwjynryFLo0DotDuc=; b=SxMpP/Dhdyc3EdcoUwxrSxesV61Ck86vwjAFk/+Ve09VbVhTbAIUUZIdHrlNgfnjblo9Vqpl NIuCbUqShqYSDzAEEQ+HFGaE6BsvaOg5pnuPfhSZmWDyg8EMckL62kRB; Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: simple@ietf.org Subject: [Simple] Re: Comments on presence-rules-08 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I just noticed this; my apologies. Responses inline. Vrancken, Johnny wrote: > Dear Jonathan, > > Here are a few comments / questions on > draft-ietf-simple-presence-rules-08.txt: > > §3.2.1 Subscription Handling, page 8 > In order to align with the terminology used in RFC 3857 / Figure 1 and > RFC 3858, the following changes are recommended: > for block: subscriptions are placed in the "terminated" state > (authorization policy / decision ="reject") > for polite-block & allow: subscriptions are placed in the "active" state > (authorization policy / decision ="accept") fixed. > > §3.2.1 Subscription Handling, page 9, last paragraph: > "If the sub-handling permission changes value to "polite-block" or > "allow", this causes an "approved" event to be generated into the state > machine for all affected subscriptions. " > > This is not completely true. If e.g. the sub-handling permission changes > from "allow" to "polite-block", or from "polite-block" to "allow", the > subscription is and remains in the "active" state and no event is generated. fixed. > > So if the sub-handling permission changes value to "polite-block" or > "allow", the processing depends on the state of the affected > subscriptions. Only if the subscription is in the "pending" state, the > subscription state changes and a NOTIFY is sent. There is no change in > state if the subscription is in the active, waiting or terminated state. fixed. > > §3.3 Transformations > Considering the statements in §3.3.1 and §3.3.2, you need both a fine > gained access permission (§3.3.2) and a corresponding coarse grained > access permission (§3.3.1)to grant access to presence attributes. > > So the most compact form of granting access of all presence attributes > to all watchers is the following rule: > > allow > > > > > > > correct. > > Question: is it a correct statement that a "false" valued boolean > permission serves no purpose unless combined with a > permission ? Right. But if is there, any other boolean permission has no further affect since you've basically already granted permission. > > I.e. the following rule without a or > statement doesn't grant anything. > > allow > > > > false > > You are correct, but I wouldn't say it this way. I'd say that if there is no permission granting access to elements, and if there is no permission granting access to the mood (whether it is by true or ), then mood will not appear. > > Question: is the following transformation in a single matching rule > > > true > > > semantically equivalent to the following 2 transformations in 2 matching > rules, or are these 2 transformations meaningless ? > > In Rule 1: > > > In Rule 2: > true > Assuming both rules match, yes. > > =========== > NITS: > Page 8: … Strictly speaking, it is not necessary to every RULESET TO > include an explicit block action > Page 9: … and the value of sub-handling that APPLIES to that > subscription is "CONFIRM", ... ("pending" to be replaced by "confirm" ) > > Page 17: … that used VALUED "TRUE" for some > attribute, say foo. > Page 18: … will be granted access to THE PRESENCE DATA OF all services > whose contact URI …. fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 27 09:48:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3ce-0006hO-19; Tue, 27 Feb 2007 09:48:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3cc-0006hJ-8R for simple@ietf.org; Tue, 27 Feb 2007 09:48:06 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3cb-0007cB-3o for simple@ietf.org; Tue, 27 Feb 2007 09:48:05 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1044695ugd for ; Tue, 27 Feb 2007 06:48:03 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pcj/1xXz1IYhh6L6BGEOJ3jmFhuXHQmaXw9W5KzzwfTjC5XIcRalD+y1ViDW8myE1A+7q4aVfWbkXOJ6Dx5Jzls1c1C1mlqAT4kSy4UkHQR15zdQw1quHNx7Ix8hxydEfuwemlrdWdyNGfLLPY+OVogUOC2LBy9dxwphNlNAM3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YHdiNiPBYrCzOe8E1MuwVYrss/Ry33zB9X5W8uh5UmjNKS+zZCIblQFgqxcUGtuVQ5+gFPxQ/yC5Qdxik5Q/7oElxn0fo+T1uoVIQFuk3oFHXTF1yV74OIR0jjNkdfoVm/G9mpwW+r9H6guWS8N9o6fhkiYMxFUA8EohpW4TNPw= Received: by 10.115.77.1 with SMTP id e1mr395490wal.1172587673070; Tue, 27 Feb 2007 06:47:53 -0800 (PST) Received: by 10.114.88.2 with HTTP; Tue, 27 Feb 2007 06:47:52 -0800 (PST) Message-ID: Date: Tue, 27 Feb 2007 14:47:52 +0000 From: "Eduardo Martins" To: "Jonathan Rosenberg" Subject: Re: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? In-Reply-To: <45E43E79.9050408@cisco.com> MIME-Version: 1.0 References: <45E34848.8010507@cisco.com> <45E36832.6040603@cisco.com> <45E43E79.9050408@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1564819784==" Errors-To: simple-bounces@ietf.org --===============1564819784== Content-Type: multipart/alternative; boundary="----=_Part_12573_31774516.1172587672971" ------=_Part_12573_31774516.1172587672971 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It's not much important and I don't miss it much, at the time I sent the first mail it just seemed to make sense, in a xml protocol that deals with xml documents, to have app usages specified by xml too. And have those app usage xml docs available in the public XCAP root. Anyway, I guess the app usage contraints, out of scope for schemas, would make those docs incomplete, regarding full app usage specification. For the XCAP Server, it would be great to implement an app usage just considering data on xml documents, this would mean it could be completely independent of app usages "installed". Best regards, Eduardo On 2/27/07, Jonathan Rosenberg wrote: > > OK, though I'm not sure what it would be used for. What was your use case? > > -Jonathan R. > > Eduardo Martins wrote: > > > Seems I can't explain it well, in my idea it would be a XML Schema that > > would define a XML document for specifying every App Usage. Maybe an > > example of what such a XML doc could be: > > > > > > IETF SIMPLE Presence Rules > > pres-rules > > > > > urn:ietf:params:xml:ns:pres-rules > > application/auth-policy+xml > > ... > > > > > > Best regards, > > > > Eduardo Martins > > > > > > On 2/26/07, * Jonathan Rosenberg* > > wrote: > > > > Are you talking about schema for the documents for a particular app > > usage? For example, xcap-list-usage has schema for resource lists > and > > RLS services documents. Do you want an app usage that contains the > > schema for those? I still don't understand what you are asking for. > > > > -Jonathan R. > > > > Eduardo Martins wrote: > > > >> Hi Jonathan, I was looking for a document schema that would specify a > >> App Usage in a XML file but I think it doesn't exist. If this > > existed it > >> would be interesting to set a app usage (or maybe reuse the caps one) > >> where all app usage documents could be stored in the xcap doc tree. > >> > >> Best regards, > >> > >> Eduardo Martins > >> > >> > >> On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com > > > >> >> wrote: > >> > >> I don't understand the question. The xcaps-caps AUIDs are the > > AUIDs > >> understood by the server, which would be either in the IETF > > tree or in > >> the vendor proprietary tree. In the former case, the AUIDs are > > defined > >> in their respective RFCs. In the latter case, they are > > proprietary, so > >> there is no public definitions of what they mean. > >> > >> -Jonathan R. > >> > >> Eduardo Martins wrote: > >> > >> > Hi, is there any document definition for each of xcap-caps AUIDs > >> (and a > >> > path relative xcap root?), where all its properties are defined, or > >> > should this kind of info, like the AUID's mimetype for example, be > >> > unavailable externally? > >> > > >> > Regards > >> > > >> > Eduardo > >> > > >> > > >> > > >> > > > ------------------------------------------------------------------------ > >> > > >> > _______________________________________________ > >> > Simple mailing list > >> > Simple@ietf.org > > > > >> > https://www1.ietf.org/mailman/listinfo/simple > >> > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > > 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com > >> > > FAX: > (973) > >> 952-5050 > >> http://www.jdrosen.net > > PHONE: (973) > 952-5000 > >> http://www.cisco.com > >> > >> > >> > >> > > > ------------------------------------------------------------------------ > > > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com > > FAX: (973) > > 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > ------=_Part_12573_31774516.1172587672971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It's not much important and I don't miss it much, at the time I sent the first mail it just seemed to make sense, in a xml protocol that deals with xml documents, to have app usages specified by xml too. And have those app usage xml docs available in the public XCAP root.

Anyway, I guess the app usage contraints, out of scope for schemas, would make those docs incomplete, regarding full app usage specification.

For  the XCAP Server, it would be great to implement an app usage just considering data on xml documents, this would mean it could be completely independent of app usages "installed".

Best regards,

Eduardo

On 2/27/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
OK, though I'm not sure what it would be used for. What was your use case?

-Jonathan R.

Eduardo Martins wrote:

> Seems I can't explain it well, in my idea it would be a XML Schema that
> would define a XML document for specifying every App Usage. Maybe an
> example of what such a XML doc could be:
>
> <app-usage>
>     <description>IETF SIMPLE Presence Rules</description>
>     <auid>pres-rules</auid>
>
> <default-document-namespace>urn:ietf:params:xml:ns:pres-rules</default-document-namespace>
>     <mimetype>application/auth-policy+xml</mimetype>
>     ...
> </app-usage>
>
> Best regards,
>
> Eduardo Martins
>
>
> On 2/26/07, * Jonathan Rosenberg* <jdrosen@cisco.com
> <mailto: jdrosen@cisco.com>> wrote:
>
>     Are you talking about schema for the documents for a particular app
>     usage? For example, xcap-list-usage has schema for resource lists and
>     RLS services documents. Do you want an app usage that contains the
>     schema for those? I still don't understand what you are asking for.
>
>     -Jonathan R.
>
>     Eduardo Martins wrote:
>
>>  Hi Jonathan, I was looking for a document schema that would specify a
>>  App Usage in a XML file but I think it doesn't exist. If this
>     existed it
>>  would be interesting to set a app usage (or maybe reuse the caps one)
>>  where all app usage documents could be stored in the xcap doc tree.
>>
>>  Best regards,
>>
>>  Eduardo Martins
>>
>>
>>  On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com
>     <mailto: jdrosen@cisco.com>
>>  <mailto:jdrosen@cisco.com <mailto:jdrosen@cisco.com>>> wrote:
>>
>>     I don't understand the question. The xcaps-caps AUIDs are the
>     AUIDs
>>     understood by the server, which would be either in the IETF
>     tree or in
>>     the vendor proprietary tree. In the former case, the AUIDs are
>     defined
>>     in their respective RFCs. In the latter case, they are
>     proprietary, so
>>     there is no public definitions of what they mean.
>>
>>     -Jonathan R.
>>
>>     Eduardo Martins wrote:
>>
>> >  Hi, is there any document definition for each of xcap-caps AUIDs
>>     (and a
>> >  path relative xcap root?), where all its properties are defined, or
>> >  should this kind of info, like the AUID's mimetype for example, be
>> >  unavailable externally?
>> >
>> >  Regards
>> >
>> >  Eduardo
>> >
>> >
>> >
>>
>     ------------------------------------------------------------------------
>> >
>> >  _______________________________________________
>> >  Simple mailing list
>> >   Simple@ietf.org <mailto:Simple@ietf.org>
>     <mailto: Simple@ietf.org <mailto:Simple@ietf.org>>
>> >   https://www1.ietf.org/mailman/listinfo/simple
>>
>>     --
>>     Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>     Cisco Fellow                                   Parsippany, NJ
>     07054-2711
>>     Cisco Systems
>>     jdrosen@cisco.com <mailto:jdrosen@cisco.com>
>>     <mailto:jdrosen@cisco.com
>     <mailto:jdrosen@cisco.com>>                              FAX:   (973)
>>     952-5050
>>     http://www.jdrosen.net
>     <http://www.jdrosen.net>                         PHONE: (973) 952-5000
>>     http://www.cisco.com
>>
>>
>>
>>
>     ------------------------------------------------------------------------
>
>>
>>  _______________________________________________
>>  Simple mailing list
>>  Simple@ietf.org <mailto:Simple@ietf.org>
>>  https://www1.ietf.org/mailman/listinfo/simple
>     <https://www1.ietf.org/mailman/listinfo/simple>
>
>     --
>     Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>     Cisco Fellow                                   Parsippany, NJ 07054-2711
>     Cisco Systems
>     jdrosen@cisco.com
>     <mailto: jdrosen@cisco.com>                              FAX:   (973)
>     952-5050
>     http://www.jdrosen.net                         PHONE: (973) 952-5000
>     http://www.cisco.com
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

------=_Part_12573_31774516.1172587672971-- --===============1564819784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1564819784==-- From simple-bounces@ietf.org Tue Feb 27 10:29:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4Fm-0000o2-Pz; Tue, 27 Feb 2007 10:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4Fl-0000nu-7t for simple@ietf.org; Tue, 27 Feb 2007 10:28:33 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4Fj-0002lW-TZ for simple@ietf.org; Tue, 27 Feb 2007 10:28:33 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 27 Feb 2007 07:28:31 -0800 X-IronPort-AV: i="4.14,226,1170662400"; d="scan'208"; a="764677841:sNHT47146944" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1RFSUkI031638 for ; Tue, 27 Feb 2007 10:28:30 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1RFSUOG017581 for ; Tue, 27 Feb 2007 10:28:30 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 10:28:21 -0500 Received: from [192.168.1.104] ([10.86.242.23]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 10:28:21 -0500 Message-ID: <45E44E14.5010000@cisco.com> Date: Tue, 27 Feb 2007 10:28:20 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2007 15:28:21.0158 (UTC) FILETIME=[E9B5F460:01C75A83] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1089; t=1172590110; x=1173454110; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20updated=20presence-rules=20specification |Sender:=20 |To:=20Simple=20WG=20; bh=inmoQEAYb0A5GIVSdvdSmMyb9xlEh3EgGg2ZqIS5ffI=; b=fluOUds5DCeVkDjTpwzBpqeznrJp3gj3wdoUP6DurvPGPs35IDFqUEqUzbCJIJUnHO6W9tqZ e04PCCcfL/F0oRn+Cd0lewc48mvpoZpIS7sONf3JgVRIarO+nQflS/nX; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Simple] updated presence-rules specification X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I've submitted a minor update to the presence-rules spec, based on GEN-ART reviews and comments on the list. Until the document appears, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-09.txt The specific changes are: * added paragraph in security considerations section warning about the non-obvious results of combining rules, and that UI designers should take it into consideration * moved RFC 3325 to normative references. This will require a downref exception. * changed reference to common policy to RFC 4745 * fixed minor bugs reported on the list I also verified the example documents and schemas against the final published schema for common-policy in RFC 4745. -JOnathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From ipatmmiuab@counselor.com Tue Feb 27 13:05:22 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6hW-0000Vv-J2 for simple-archive@lists.ietf.org; Tue, 27 Feb 2007 13:05:22 -0500 Received: from [86.55.40.138] (helo=[86.55.40.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6hV-0006sy-7I for simple-archive@lists.ietf.org; Tue, 27 Feb 2007 13:05:22 -0500 From: "SACVD" To: simple-archive@lists.ietf.org Subject: Surprises Date: Tue, 27 Feb 2007 10:05:13 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C75A56.C5C667B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdaVsXGxS3+dizVTlSToVwcMkstyQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <280797F645B01C7.59A7E52D7C@counselor.com> X-Spam-Score: 3.2 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0002_01C75A56.C5C667B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
LOMJ - LOM LOGISTICS INCORPORATED - MAKING MAJOR TECHNOLOGY BREAKTHROUGHS!

Signal: LOMJ
Opens: $0.85 +0.65 +325% - Trading On Tuesday Feb 27 2007!

2007/02/22 - NEWS - LOM Logistics, announces a landmark decision to initially release its proprietary live negotiating technology into virtually every industry worldwide accommodating everything from cars, boats, jewelry, real estate to books and even your kitchen sink. As well, the LOM will further advance its technology by implementing video and image components within its live negotiating engine, allowing its users to thoroughly evaluate merchandise, and other such offerings, before initiating live negotiations.

THE FLAME IS NOW LIT! IS LOMJ READY TO BLAZE HIGHER?
------=_NextPart_000_0002_01C75A56.C5C667B0-- From simple-bounces@ietf.org Tue Feb 27 15:51:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9HL-000108-A5; Tue, 27 Feb 2007 15:50:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9Gu-0000ur-4g; Tue, 27 Feb 2007 15:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM9Gt-0007y6-8A; Tue, 27 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 278F1328EC; Tue, 27 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HM9Gt-0001ev-1E; Tue, 27 Feb 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-interdomain-scaling-analysis-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --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 : Problem Statement for SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-simple-interdomain-scaling-analysis-00.txt Pages : 52 Date : 2007-2-27 The document analyses the traffic that is generated due to presence subscriptions between domains. It is shown that the amount of traffic can be extremely big. In addition to the very large traffic the document also analyses the affects of a large presence system on the memory footprint and the CPU load. Several suggested optimization to the SIMPLE protocol are analysed with the possible impact on the load. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-interdomain-scaling-analysis-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-interdomain-scaling-analysis-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: <2007-2-27141213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-interdomain-scaling-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-27141213.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Feb 27 18:51:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMC5y-00049S-Km; Tue, 27 Feb 2007 18:50:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMC5Z-0002sr-2l; Tue, 27 Feb 2007 18:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMC5Y-0006yj-Gu; Tue, 27 Feb 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6F3342ACC4; Tue, 27 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMC54-0007a5-5s; Tue, 27 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-09.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --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 : Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-notify-09.txt Pages : 15 Date : 2007-2-27 By default, presence delivered using the Presence Event Package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-09.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: <2007-2-27150644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-27150644.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Feb 27 19:06:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMCKI-0003ym-8O; Tue, 27 Feb 2007 19:05:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMCKG-0003yc-97 for simple@ietf.org; Tue, 27 Feb 2007 19:05:44 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMCK0-00068E-TB for simple@ietf.org; Tue, 27 Feb 2007 19:05:44 -0500 Received: by an-out-0708.google.com with SMTP id d30so1477413and for ; Tue, 27 Feb 2007 16:05:28 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Buv30QEjZ6kRcERP95vNE+0sz9HxtnIZKPB0UwdOU47OrUOA18IWTWLobPNH6ouKyq+P1c18n25zAlPzzgYrfgwMMTxNMkhEwpXRPcUiMNlFKaB/aVhOrSJK0lJcmoHjuymiqaaVzrl2PDgNvuF/JhFvEOO8rOF/PN9c9RQmOR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=oN/6/ZVWt2+67/cOY5Wh7IZO7QMeJlEW2u7HRW4nGU9H/fXIBdhcWtoEjfs8gFcxjP2C0d6osx+Erhk1JOqdYIPA0cVW8QbbK916X8yzYnlo07sS32trsczkpDQAFCKXwOJGJM7nr5JMkXvlRrduwbII01R+LvdcimT//+4htVA= Received: by 10.114.111.1 with SMTP id j1mr73925wac.1172621127524; Tue, 27 Feb 2007 16:05:27 -0800 (PST) Received: by 10.114.88.2 with HTTP; Tue, 27 Feb 2007 16:05:27 -0800 (PST) Message-ID: Date: Wed, 28 Feb 2007 00:05:27 +0000 From: "Eduardo Martins" To: "Jonathan Rosenberg" Subject: Re: [Simple] Re: Conflict in draft-ietf-simple-xcap-12 In-Reply-To: <45E367A1.1050209@cisco.com> MIME-Version: 1.0 References: <45E346AC.4060404@cisco.com> <45E367A1.1050209@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1677244181==" Errors-To: simple-bounces@ietf.org --===============1677244181== Content-Type: multipart/alternative; boundary="----=_Part_27838_7000736.1172621127477" ------=_Part_27838_7000736.1172621127477 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jonathan, found another error, this time in Section 7.7: As with element insertions and replacements, the GET(PUT(x))==x property introduces limitations on attribute insertions and replacements. It will not be possible to replace the attribute value of an attribute, when that attribute is the sole unique element identifier, and the URI contains a node selector that uses the previous value of the attribute to select the affected element. This is the use case in the example above. Instead, the element can be selected positionally, or its entire parent replaced. It should be "on attribute replacements" only. Regards, Eduardo Martins On 2/26/07, Jonathan Rosenberg wrote: > > OK, I'll fix. > > Thanks, > Jonathan R. > > Eduardo Martins wrote: > > > Also, a little error in page 39: > > > > > > > > should be > > > > > > > > Best regards, > > > > Eduardo Martins > > > > On 2/26/07, *Jonathan Rosenberg* > > wrote: > > > > Correct, this is a bug in the spec. Section 7.11 is incorrect. The > > behavior in this area changed later in the evolution of the spec, > and > > the text in 7.11 is leftover. I will correct in auth48. > > > > -Jonathan R. > > > > Silvestr.Peknik@tietoenator.com > > wrote: > > > > > Hello, > > > > > > I have a problem with draft-ietf-simple-xcap-12. In my opinion > > following > > > parts of the draft are in conflict: > > > > > > 7.11 Conditional operations > > > ... > > > In another example, a client may wish to insert a new element > into a > > > document, but wants to be sure that the insertion will only > take > > > place if that element does not exist. In other words, the > client > > > wants the PUT operation to be a creation, not a > replacement. To > > > accomplish that, the client can insert the If-None-Match > > header field > > > into the PUT request, with a value of *. This tells the > > server to > > > reject the request with a 412 if resource exists. > > > ... > > > > > > 8.2.6. Conditional Processing > > > > > > A PUT request for an XCAP resource, like any other HTTP > > resource, can > > > be made conditional through usage of the If-Match and > > If-None-Match > > > header fields. For a replacement, these are processed as > > defined in > > > [6]. For an insertion of an element or attribute, conditional > > > operations are permitted. The entity tag that is used for the > > > procedures in [6] is the one for all of the resources within > > the same > > > document as the parent of the element or attribute being > inserted. > > > One way to think of this is that, logically speaking, on > > receipt of > > > the PUT request, the XCAP server instantiates the etag for the > > > resource referenced by the request, and then applies the > > processing > > > of the request. Because of this behavior, it is not possible > to > > > perform a conditional insert on an attribute or element > > conditioned > > > on the operation being an insertion and not a replacement. In > > other > > > words, a conditional PUT of an element or attribute with an > > If-None- > > > Match: * will always fail. > > > > > > > > > The former part says that I can use "If-None-Match: *" in PUT > > request to > > > ensure creation. The latter says that PUT request with > > "If-None-Match: > > > *" always fails. > > > > > > Could you please comment on this? > > > > > > Thank you, > > > > > > Silvestr Peknik > > > Software Specialist > > > TietoEnator Czech s.r.o. > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com > > FAX: (973) > > 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > ------=_Part_27838_7000736.1172621127477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jonathan, found another error, this time in Section 7.7:

               As with element insertions and replacements, the GET(PUT(x))==x
               property introduces limitations on attribute insertions and
               replacements.  It will not be possible to replace the attribute value
               of an attribute, when that attribute is the sole unique element
               identifier, and the URI contains a node selector that uses the
               previous value of the attribute to select the affected element.  This
               is the use case in the example above.  Instead, the element can be
               selected positionally, or its entire parent replaced.

It should be "on attribute replacements" only.

Regards,

Eduardo Martins

On 2/26/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
OK, I'll fix.

Thanks,
Jonathan R.

Eduardo Martins wrote:

> Also, a little error in page 39:
>
>     <el1 att="second"/><el1 att="third">
>
> should be
>
>     <el1 att="second"/><el1 att="third"/>
>
> Best regards,
>
> Eduardo Martins
>
> On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com
> <mailto:jdrosen@cisco.com>> wrote:
>
>     Correct, this is a bug in the spec. Section 7.11 is incorrect. The
>     behavior in this area changed later in the evolution of the spec, and
>     the text in 7.11 is leftover. I will correct in auth48.
>
>     -Jonathan R.
>
>     Silvestr.Peknik@tietoenator.com
>     <mailto: Silvestr.Peknik@tietoenator.com> wrote:
>
>      > Hello,
>      >
>      > I have a problem with draft-ietf-simple-xcap-12. In my opinion
>     following
>      > parts of the draft are in conflict:
>      >
>      > 7.11 Conditional operations
>      > ...
>      > In another example, a client may wish to insert a new element into a
>      >    document, but wants to be sure that the insertion will only take
>      >    place if that element does not exist.  In other words, the client
>      >    wants the PUT operation to be a creation, not a replacement.  To
>      >    accomplish that, the client can insert the If-None-Match
>     header field
>      >    into the PUT request, with a value of *.  This tells the
>     server to
>      >    reject the request with a 412 if resource exists.
>      > ...
>      >
>      > 8.2.6.  Conditional Processing
>      >
>      >    A PUT request for an XCAP resource, like any other HTTP
>     resource, can
>      >    be made conditional through usage of the If-Match and
>     If-None-Match
>      >    header fields.  For a replacement, these are processed as
>     defined in
>      >    [6].  For an insertion of an element or attribute, conditional
>      >    operations are permitted.  The entity tag that is used for the
>      >    procedures in [6] is the one for all of the resources within
>     the same
>      >    document as the parent of the element or attribute being inserted.
>      >    One way to think of this is that, logically speaking, on
>     receipt of
>      >    the PUT request, the XCAP server instantiates the etag for the
>      >    resource referenced by the request, and then applies the
>     processing
>      >    of the request.  Because of this behavior, it is not possible to
>      >    perform a conditional insert on an attribute or element
>     conditioned
>      >    on the operation being an insertion and not a replacement.  In
>     other
>      >    words, a conditional PUT of an element or attribute with an
>     If-None-
>      >    Match: * will always fail.
>      >
>      >
>      > The former part says that I can use "If-None-Match: *" in PUT
>     request to
>      > ensure creation. The latter says that PUT request with
>     "If-None-Match:
>      > *" always fails.
>      >
>      > Could you please comment on this?
>      >
>      > Thank you,
>      >
>      > Silvestr Peknik
>      > Software Specialist
>      > TietoEnator Czech s.r.o.
>      >
>
>     --
>     Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>     Cisco Fellow                                   Parsippany, NJ 07054-2711
>     Cisco Systems
>     jdrosen@cisco.com
>     <mailto:jdrosen@cisco.com>                              FAX:   (973)
>     952-5050
>     http://www.jdrosen.net                         PHONE: (973) 952-5000
>     http://www.cisco.com
>
>     _______________________________________________
>     Simple mailing list
>     Simple@ietf.org <mailto:Simple@ietf.org>
>     https://www1.ietf.org/mailman/listinfo/simple
>
>

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

------=_Part_27838_7000736.1172621127477-- --===============1677244181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1677244181==-- From simple-bounces@ietf.org Wed Feb 28 01:56:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMIhv-0007sw-7C; Wed, 28 Feb 2007 01:54:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMIht-0007kz-9M for simple@ietf.org; Wed, 28 Feb 2007 01:54:33 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMIhr-00078P-OS for simple@ietf.org; Wed, 28 Feb 2007 01:54:33 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1S6pQgF010620 for ; Wed, 28 Feb 2007 08:51:37 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 08:54:22 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 08:54:18 +0200 Received: from [172.21.41.38] (esdhcp04138.research.nokia.com [172.21.41.38]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1S6oMea029233 for ; Wed, 28 Feb 2007 08:50:23 +0200 Message-ID: <45E4B4F0.1080606@nokia.com> Date: Wed, 28 Feb 2007 00:47:12 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2007 06:54:18.0291 (UTC) FILETIME=[4457B030:01C75B05] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070228085137-27E87BB0-24769B96/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Simple] A new draft on using ICE with MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi all, I've submitted a straw man proposal for using Interactive Connectivity Establishment (ICE) with MSRP. The idea is to have the ability to use the same NAT-traversal infrastructure with MSRP as with other media sessions. Until it appears at the I-D directories, copies can be fetched here: http://people.nokia.net/~aki/drafts/draft-niemi-simple-msrp-ice-00.txt http://people.nokia.net/~aki/drafts/draft-niemi-simple-msrp-ice-00.html Comments are most welcome. The draft is a little rough around the edges, apologies for that. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 28 02:39:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJOb-0005dR-LO; Wed, 28 Feb 2007 02:38:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJOY-0005We-Jm for simple@ietf.org; Wed, 28 Feb 2007 02:38:38 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMJOX-0005Ad-34 for simple@ietf.org; Wed, 28 Feb 2007 02:38:38 -0500 Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id 7405320A2E5; Wed, 28 Feb 2007 08:38:35 +0100 (CET) Received: by shell.iptel.org (sSMTP sendmail emulation); Wed, 28 Feb 2007 08:38:11 +0100 Date: Wed, 28 Feb 2007 08:38:34 +0100 From: Vaclav Kubart To: Jonathan Rosenberg Subject: Re: [Simple] updated presence-rules specification Message-ID: <20070228073832.GA3185@vencore.sip-server.net> References: <45E44E14.5010000@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E44E14.5010000@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello, I'm very sorry to repeat my question from November, but nobody responded and I haven't found a post in archives related to it: In the section 8.7. Naming Conventions of this draft is written, that a presence agent should look for ALL documents for user stored on XCAP server but as far as I understand the XCAP draft, there is no way how to enumerate these stored documents. Missed I something in one of these drafts? Is somewhere a description how this should be done? with regards, Vaclav Kubart On Tue, Feb 27, 2007 at 10:28:20AM -0500, Jonathan Rosenberg wrote: > I've submitted a minor update to the presence-rules spec, based on > GEN-ART reviews and comments on the list. Until the document appears, > you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-09.txt > > The specific changes are: > > * added paragraph in security considerations section warning about the > non-obvious results of combining rules, and that UI designers should > take it into consideration > > * moved RFC 3325 to normative references. This will require a downref > exception. > > * changed reference to common policy to RFC 4745 > > * fixed minor bugs reported on the list > > > I also verified the example documents and schemas against the final > published schema for common-policy in RFC 4745. > > -JOnathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 28 18:10:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXv9-0008DQ-FP; Wed, 28 Feb 2007 18:09:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXv8-0008DH-2Z for simple@ietf.org; Wed, 28 Feb 2007 18:09:14 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMXv6-0007D4-Ha for simple@ietf.org; Wed, 28 Feb 2007 18:09:14 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2007 18:09:12 -0500 X-IronPort-AV: i="4.14,232,1170651600"; d="scan'208"; a="114689509:sNHT59126204" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1SN9CjG019126; Wed, 28 Feb 2007 18:09:12 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1SN9BOK006921; Wed, 28 Feb 2007 18:09:12 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 18:09:04 -0500 Received: from [192.168.1.104] ([10.86.241.21]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 18:09:03 -0500 Message-ID: <45E60B8F.9020501@cisco.com> Date: Wed, 28 Feb 2007 18:09:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eduardo Martins Subject: Re: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? References: <45E34848.8010507@cisco.com> <45E36832.6040603@cisco.com> <45E43E79.9050408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2007 23:09:03.0718 (UTC) FILETIME=[705FA060:01C75B8D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7744; t=1172704152; x=1173568152; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Is=20there=20any=20Document=20(and=20Namin g=20Conventions)=20to=20specify=0A=20AUIDs=20in=20XCAP=20Server? |Sender:=20 |To:=20Eduardo=20Martins=20; bh=jS+cqV4ZiRp85QYFnxy2bHm4P0kb6Wt0DTAah7AWVPI=; b=PWBJaDZO2c3Hhe6q74lI5UFCPIv+0Jz/Kl4lfZ6fyhtEO9D7zX79HWPCmInOwlYFFC8IcNZA BxAcHf1sgONuVCCLRcE8thT40THd3u40VS0ctm8JqezeMTAxwje6ly+o; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Sure, but this is a localized configuration. You could choose to define app usages using your own proprietary XML format, and that would be fine. We have no requirements to exchange such documents between servers or from client to server; its merely a tool for configuration. -Jonathan R. Eduardo Martins wrote: > It's not much important and I don't miss it much, at the time I sent the > first mail it just seemed to make sense, in a xml protocol that deals > with xml documents, to have app usages specified by xml too. And have > those app usage xml docs available in the public XCAP root. > > Anyway, I guess the app usage contraints, out of scope for schemas, > would make those docs incomplete, regarding full app usage specification. > > For the XCAP Server, it would be great to implement an app usage just > considering data on xml documents, this would mean it could be > completely independent of app usages "installed". > > Best regards, > > Eduardo > > On 2/27/07, *Jonathan Rosenberg* > wrote: > > OK, though I'm not sure what it would be used for. What was your use > case? > > -Jonathan R. > > Eduardo Martins wrote: > > > Seems I can't explain it well, in my idea it would be a XML > Schema that > > would define a XML document for specifying every App Usage. Maybe an > > example of what such a XML doc could be: > > > > > > IETF SIMPLE Presence Rules > > pres-rules > > > > > urn:ietf:params:xml:ns:pres-rules > > application/auth-policy+xml > > ... > > > > > > Best regards, > > > > Eduardo Martins > > > > > > On 2/26/07, * Jonathan Rosenberg* > > >> wrote: > > > > Are you talking about schema for the documents for a > particular app > > usage? For example, xcap-list-usage has schema for resource > lists and > > RLS services documents. Do you want an app usage that > contains the > > schema for those? I still don't understand what you are > asking for. > > > > -Jonathan R. > > > > Eduardo Martins wrote: > > > >> Hi Jonathan, I was looking for a document schema that would > specify a > >> App Usage in a XML file but I think it doesn't exist. If this > > existed it > >> would be interesting to set a app usage (or maybe reuse the > caps one) > >> where all app usage documents could be stored in the xcap doc > tree. > >> > >> Best regards, > >> > >> Eduardo Martins > >> > >> > >> On 2/26/07, *Jonathan Rosenberg* < jdrosen@cisco.com > > > > > >> > >>> wrote: > >> > >> I don't understand the question. The xcaps-caps AUIDs are the > > AUIDs > >> understood by the server, which would be either in the IETF > > tree or in > >> the vendor proprietary tree. In the former case, the AUIDs are > > defined > >> in their respective RFCs. In the latter case, they are > > proprietary, so > >> there is no public definitions of what they mean. > >> > >> -Jonathan R. > >> > >> Eduardo Martins wrote: > >> > >> > Hi, is there any document definition for each of xcap-caps AUIDs > >> (and a > >> > path relative xcap root?), where all its properties are > defined, or > >> > should this kind of info, like the AUID's mimetype for > example, be > >> > unavailable externally? > >> > > >> > Regards > >> > > >> > Eduardo > >> > > >> > > >> > > >> > > > ------------------------------------------------------------------------ > >> > > >> > _______________________________________________ > >> > Simple mailing list > >> > Simple@ietf.org > > > > > >> > >> > https://www1.ietf.org/mailman/listinfo/simple > >> > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > > 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com > > > >> > > >> FAX: (973) > >> 952-5050 > >> http://www.jdrosen.net > > PHONE: (973) > 952-5000 > >> http://www.cisco.com > >> > >> > >> > >> > > > ------------------------------------------------------------------------ > > > >> > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/simple > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com > > > FAX: (973) > > 952-5050 > > http://www.jdrosen.net PHONE: (973) > 952-5000 > > http://www.cisco.com > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com > FAX: (973) > 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple