From simple-bounces@ietf.org Tue Jan 03 00:56:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfA0-0005h1-DM; Tue, 03 Jan 2006 00:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etf9y-0005gw-JE for simple@megatron.ietf.org; Tue, 03 Jan 2006 00:56:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03923 for ; Tue, 3 Jan 2006 00:55:24 -0500 (EST) Received: from david.siemens.com.cn ([194.138.202.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtfF5-0004ee-Av for simple@ietf.org; Tue, 03 Jan 2006 01:02:02 -0500 Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id k035u8P15295; Tue, 3 Jan 2006 13:56:09 +0800 (CST) Received: from pekw905a.cn001.siemens.net (localhost [127.0.0.1]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id k035w7t25184; Tue, 3 Jan 2006 13:58:07 +0800 (CST) Received: from PEKW910A.cn001.siemens.net ([139.24.236.125]) by pekw905a.cn001.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 13:56:10 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Simple] XCAP proposal on conditional inserts Date: Tue, 3 Jan 2006 13:56:09 +0800 Message-ID: <8E1B3F00C246044D90C9100CCDBB43E70120D01E@PEKW910A.cn001.siemens.net> Thread-Topic: [Simple] XCAP proposal on conditional inserts Thread-Index: AcYQKmSETMGA6qZZStmiXUd5W6ZGnA== From: "Hu Bo \(Cory\), SLC COM CD/MN R&D Core \(BJ\)" To: "Jonathan Rosenberg" , "Simple WG" X-OriginalArrivalTime: 03 Jan 2006 05:56:10.0509 (UTC) FILETIME=[658DA3D0:01C6102A] X-Spam-Score: 3.0 (+++) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi,Jonathan, My question is: How could client tell if the state("empty" or "not empty") of an element = is synchronized with server? if a client has a cache like: 1 2 While server has 1 Then client make a creation for el1[3] PUT test/el1[3] with 3 My understanding is: Without conditional insert, old xcap will fail this = attemp. By new definition it will succeed. Now the server copy is: 1 //index 1 3 //index 3 How to modify the index "3" element? PUT test/el1[2] OR PUT = test/el1[3]? I propose approach 1 working with some limitation like: For client and server, there shouldn't be an understanding that an empty = element is present unless it's the last one under an existing parent. That would mean: 1.Insert of an element after an empty one is not allowed. 2.deletion of an element will shift the index up. Regards Best Regards /Viele Gr=FC=DFe /Med venlig hilsen=20 Hu Bo SIEMENS Com Communications Group=20 Siemens Ltd. China=20 1# Building of SOFPA, A323 No.8 of Dong Bei Wang Xi Lu, Haidian District, 100094 Beijing, P.R.China Tel.: (+86)-10-6472-1888 (Ext. 7167)=20 E-mail: hu.bo@siemens.com >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 >Sent: Friday, December 30, 2005 5:38 AM >To: Simple WG >Subject: [Simple] XCAP proposal on conditional inserts > >At the last IETF meeting, I raised the possibility of fixing=20 >the current >conditional insert problem as another change to make to the spec while >we are editing it. The problem, to refresh everyones memory, is that >HTTP (and thus XCAP) allows for conditional operations on a resource >only if the resource being operated on exists. Thats because if it >doesn't exist, it doesn't have an etag. So, you can't insert an element >conditioned on the etag of the entire document and all of its=20 >components. > >So, if you really mean to insert this thing ONLY if the document is >unchanged, you'll need to do the insert "blindly", and then after its >done, you'll find out whether or not the insert was done against the >version you intended. If so, great. If not, you need to=20 >somehow undo the >change you just made. > >This is far from ideal, but a known issue, and documented in the spec >today. I've been increasingly concerned that this is just not going to >work well, as it substantially raises the bar for getting the system to >work reliably. > >I made a proposal at IETF to fix it, and some good comments were >provided. Based on that, here is my modified proposal for how to fix >this issue. > >An XCAP resource representing an XML element in a document is said to >exist if the element appears in the document, OR its parent appears in >the document. If the XCAP resource exists but doesn't appear in the >document, it is said to be empty. So, for example: > > > > > >test/el1 exists and isn't empty. test/el1/el2 exists but is empty. >test/el1/blah-blah exists but is empty. In fact, every single potential >child element of el1 exists - they're just all empty. Because=20 >they exist, >they all have etags, which are all equal to the document etag. Based on >this definition, I can now go and insert a new element, which isn't >technically an insertion, but rather a modification: I'm modifying the >element to change it from empty to a specific value. > >This does not apply to attributes, however. An attribute exists only if >its physically present in the document (the difficulty in getting this >mechanism to work with attributes was one of the issues raised=20 >at ietf). > >Now, there are some actual consequences to this change in definition: > >* A GET against one of these empty resources will not return a=20 >404 as it >does today. Rather, it would return a 200 OK, with a Content-Type of >application/xcap-el+xml and a Content-Length of zero. This indicates >that the resource is empty. > >So, based on the above example, GET test/el1/foobar would return a 200 >OK with Content-Length zero. > >* A GET against an element which doesnt exist WOULD return a 404. So, >for example, a GET of test/el1/foobar/nothere would return 404. > >* A DELETE of an element would be forbidden, and always return=20 >a 405. To >delete an element, you need to modify it to be empty. So,=20 >you'd do a PUT >with a Content-Length of 0. > >* We would no longer have a way to say, "insert this element into the >document if the element is not currently present in the document". In >the current spec, this is done by a PUT with If-None-Match: *. However, >with the proposed change, this condition would always fail, since the >element will now always exist. What we gain instead is the ability to >insert conditionally based on whether the document on the=20 >server matches >the one cached by the client. > >* There would no longer be a need for the xcap-diff document that is >returned in a 202 Created response. The reason this xcap-diff document >gets sent is to let the client know what the etag was prior to >insertion, so if it didn't match the cached copy, the client could try >to repair the error. Eliminating the need for this would remove the >dependency on xcap-diff, xml-patch-ops, and so on. > > >It is tempting to take a slightly different approach. Call the=20 >approach=20 >above "approach 1". The idea with approach 2 is to declare that, even=20 >though a resource doesn't exist, it has an etag, and that etag=20 >is equal=20 >to the document's etag, assuming the document does exist. Approach 2=20 >would work much like approach 1, except that: > >* A GET against a non-existent resource would be a 404, rather than a=20 >200 OK with CL of zero > >* A DELETE would be allowed > >Note however, that with approach 2, you still cannot support the=20 >operation that says, "insert this but only if this element doesn't=20 >already exist in the document". Approach 2 has the problem that it=20 >seriously bends (and possibly breaks), an underlying http assumption=20 >about the scope and meaning of etags. That might have odd and=20 >unpredicatable interactions with caching systems and other http=20 >intermediaries. For this reason, I wouldn't recommend it. > >So, I would like to make the concrete proposal of moving to=20 >approach 1.=20 >The main drawback I see is the loss of the ability to insert=20 >an element=20 >if an element with that same name/attribute already exist. > >Comments? > >-Jonathan R. > > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >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 Jan 03 23:49:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu0aX-00078k-J4; Tue, 03 Jan 2006 23:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu0aV-00078b-Sa for simple@megatron.ietf.org; Tue, 03 Jan 2006 23:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04208 for ; Tue, 3 Jan 2006 23:48:11 -0500 (EST) Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu0fq-0006iS-7R for simple@ietf.org; Tue, 03 Jan 2006 23:55:01 -0500 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id k04Bm06D012432 for simple@ietf.org; Wed, 4 Jan 2006 06:48:00 -0500 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by localhost.localdomain (8.13.4/8.12.9) with ESMTP id k04BlxGo012425 for ; Wed, 4 Jan 2006 06:47:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jan 2006 06:49:16 +0200 Message-ID: Thread-Topic: draft-ietf-simple-xml-patch-ops-00 - question regarding schema Thread-Index: AcYQ6jc/RyVFUGIdRlaZzWDJw9zVTA== From: "Anat Angel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [Simple] draft-ietf-simple-xml-patch-ops-00 - question regarding schema 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="===============1219607454==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1219607454== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C610EA.3735FB9C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C610EA.3735FB9C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi =20 Can you please clarify what is the expected behavior in the following case (for example): ... ? =20 According to the schema, this expression is legal. =20 Thanks, Anat. =20 ------_=_NextPart_001_01C610EA.3735FB9C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi

 

Can you please clarify what is the expected behavior in the following case = (for example):

<add sel=3D"tuple[@id=3D'1']" type=3D"node()(22)" > ... </add> ?

 

According to the schema, this expression is = legal.

 

Thanks,

Anat.

 

------_=_NextPart_001_01C610EA.3735FB9C-- --===============1219607454== 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 --===============1219607454==-- From simple-bounces@ietf.org Wed Jan 04 09:49:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9wu-0006uE-2o; Wed, 04 Jan 2006 09:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9ws-0006sm-GH; Wed, 04 Jan 2006 09:49:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09463; Wed, 4 Jan 2006 09:47:54 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuA2M-0002iU-Ke; Wed, 04 Jan 2006 09:54:51 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 04 Jan 2006 09:48:33 -0500 id 01588066.43BBE042.00007CC1 In-Reply-To: <43792C92.9060509@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Wed, 4 Jan 2006 09:48:56 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Henning, Sorry to bring this up again, but Hannes made me reread the text and I caught a nit. On Nov 14, 2005, at 7:32 PM, Henning Schulzrinne wrote: > I looked at RFC 3490 (IDNA) in more detail just now. For the > 'domain' attribute, I think we can simplify the comparison process > as follows: > > --- begin text --- > > Common policy MUST use UTF-8 to store domain names in 'id' domain > attributes. For non-IDNs, lower-case ASCII SHOULD be used. [ snip ]... Is "MUST use UTF-8" intended to purposefully rule out UTF-16, which all XML parsers are required to understand? That is fine if it is, but this would seem to then restrict the document to UTF-8. If this is a protocol requirement, it needs to be stated. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 04 23:46:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuN15-0004AQ-Nx; Wed, 04 Jan 2006 23:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuN13-0004AE-W6 for simple@megatron.ietf.org; Wed, 04 Jan 2006 23:46:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19496 for ; Wed, 4 Jan 2006 23:45:03 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuN6b-0001Mb-CO for simple@ietf.org; Wed, 04 Jan 2006 23:52:06 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 22:46:03 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 04 Jan 2006 22:46:03 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 22:46:02 -0600 Message-ID: From: "Thomson, Martin" To: Date: Wed, 4 Jan 2006 22:45:21 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 05 Jan 2006 04:46:02.0598 (UTC) FILETIME=[EE44E060:01C611B2] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: Expressing XML support for common-policy and extensions thread-index: AcYRstV/T+BgLDtkQ+GMh/YIhMYK9g== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Simple] Expressing XML support for common-policy and extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1482640787==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1482640787== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 QWZ0ZXIgcmVhZGluZyBKb25hdGhhbidzIGNvbW1vbi1wb2xpY3ktY2FwcyBkcmFmdCBbMV0gYW5k IHRoZSByZWxhdGVkIHByZXMtcG9saWN5LWNhcHMgWzJdIGFuZCBnZW9wcml2LXBvbGljeS1jYXBz IFszXSwgSSBjYW1lIHRvIHRoZSByZWFsaXphdGlvbiB0aGF0IHRoZSBzdWJzZXF1ZW50IGRvY3Vt ZW50cyBhbGwgZG8gZXhhY3RseSB0aGUgc2FtZSB0aGluZy4NCg0KT25jZSB0aGUgcHJvdG9jb2wg Y29tcG9uZW50cyByZWxhdGVkIHRvIFhDQVAgaGF2ZSBiZWVuIGRlYWx0IHdpdGgsIHRoZSBzcGVj aWZpY2F0aW9uIG9mIGEgZG9jdW1lbnQgZm9ybWF0IGFuZCBzY2hlbWEgaXMgbGFyZ2VseSBhIGNv cHktYW5kLXBhc3RlIGpvYi4gIFRoaXMgaXMgbmljZSBpbiBvbmUgcmVzcGVjdCAtIHRoZXNlIGRv Y3VtZW50cyBhcmUgdmVyeSBzaW1wbGUgYW5kIGVsZWdhbnQgLSBidXQgYSBsb25nIHRpbWUgc3Bl bnQgd2l0aCBjb2RlIHRyaWdnZXJzIHRoZSByZWZhY3RvcmluZyBuZXVyb25zLiAgV2hlcmUgYSBw YXR0ZXJuIGV4aXN0cywgdGhlcmUgaXMgcmVkdW5kYW50IGNvZGUuDQoNCkluIG9yZGVyIHRvIHVz ZSBjYXBhYmlsaXRpZXMsIGV2ZXJ5IGNvbW1vbi1wb2xpY3kgZXh0ZW5zaW9uIHJlcXVpcmVzIGEg bWF0Y2hpbmcgY2FwYWJpbGl0aWVzIHNwZWNpZmljYXRpb24uICBUaGF0IGV4dHJhIHNwZWNpZmlj YXRpb24gY29udGFpbnMgbGl0dGxlLCBvciBubywgYWRkaXRpb25hbCB2YWx1ZS4NCg0KV2l0aCB0 aGlzIHRob3VnaHQgaW4gbWluZCBJIGhhdmUgdGFrZW4gdGhlIHByb2JsZW0gYW5kIGFwcGxpZWQg YW4gYWRkaXRpb25hbCBsYXllciBvZiBhYnN0cmFjdGlvbiB0byBjcmVhdGUgYSBkb2N1bWVudCBm b3JtYXQgdGhhdCBzaG91bGQgYWRkcmVzcyBhbGwgZXh0ZW5zaW9ucy4gIEluIHNvbWUgd2F5LCB0 aGlzIGlzIGluc3BpcmVkIGJ5IHRoZSBlbGVnYW50IHNpbXBsaWNpdHkgb2YgU2NoZW1hdHJvbiBb NF0uICBJIGhvcGUgdGhhdCB0aGlzIG9uZSBkcmFmdCB3aWxsIHN1ZmZpY2Ugd2hlcmUgbWFueSB3 b3VsZCBoYXZlIGJlZW4gYmVmb3JlOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC10aG9tc29uLXNpbXBsZS1leHByZXNzaW5nLXhtbC1zdXBwb3J0LTAwLnR4dA0K DQpJIHRoaW5rIHRoYXQgdGhlIHNvbHV0aW9uIHJldGFpbnMgbXVjaCBvZiB0aGUgc2ltcGxpY2l0 eSBvZiB0aGUgb3JpZ2luYWwgb2ZmZXJpbmcsIHdoaWxlIHByb3ZpZGluZyBlbm91Z2ggZmxleGli aWxpdHkgdG8gYWNjb21tb2RhdGUgZnV0dXJlIGV4dGVuc2lvbnMuICBJIGFsc28gc3VzcGVjdCB0 aGF0IGl0IGNvdWxkIGJlIGVhc2llciB0byBpbXBsZW1lbnQsIGFuZCBpdCB3aWxsIGNlcnRhaW5s eSBiZSBlYXNpZXIgdG8gbWFpbnRhaW4uDQoNClNvLCBJJ2QgbGlrZSBzb21lIGZlZWRiYWNrLCBp ZiB5b3UgaGF2ZSB0aW1lIHRvIHJlYWQgdGhlIGRyYWZ0LiAgSXMgdGhpcyBhbiBhY2NlcHRhYmxl IHRyYWRlb2ZmIGJldHdlZW4gdGhlIHZhcmlvdXMgZmFjdG9ycyAoc2ltcGxpY2l0eSwgc3BlY2lm aWNhdGlvbiB3b3JrLCBldGMuLi4pPyAgSSBoYXZlIHNvbWUgaWRlYXMgb24gaG93IHRoaXMgY291 bGQgYmUgaW50ZWdyYXRlZCB3aXRoIHRoZSBleGlzdGluZyBjYXBhYmlsaXRpZXMgd29yaywgaXMg dGhhdCBhIGdvb2QgaWRlYT8NCg0KQ2hlZXJzLA0KTWFydGluDQoNClsxXSBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpbXBsZS1jb21tb24tcG9saWN5LWNh cHMtMDAudHh0DQpbMl0gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1zaW1wbGUtcHJlcy1wb2xpY3ktY2Fwcy0wMC50eHQNClszXSBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ndWVudGhlci1nZW9wcml2LXBvbGljeS1jYXBzLTAz LnR4dA0KWzRdIGh0dHA6Ly93d3cuc2NoZW1hdHJvbi5jb20vb3ZlcnZpZXcuaHRtbA0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3Ig dGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2Vk LCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlv dSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmlt bWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ug b2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============1482640787== 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 --===============1482640787==-- From simple-bounces@ietf.org Thu Jan 05 04:34:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRVg-0006c8-PU; Thu, 05 Jan 2006 04:34:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRVe-0006bw-CQ for simple@megatron.ietf.org; Thu, 05 Jan 2006 04:34:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17563 for ; Thu, 5 Jan 2006 04:32:57 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuRbI-0002aC-9P for simple@ietf.org; Thu, 05 Jan 2006 04:40:05 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k059XtEV027919; Thu, 5 Jan 2006 10:33:58 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k059XtSl027485; Thu, 5 Jan 2006 10:33:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 10:33:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Simple] Expressing XML support for common-policy and extensions Date: Thu, 5 Jan 2006 10:31:05 +0100 Message-ID: Thread-Topic: [Simple] Expressing XML support for common-policy and extensions Thread-Index: AcYRstV/T+BgLDtkQ+GMh/YIhMYK9gAJ1fLQ From: "Tschofenig, Hannes" To: "Thomson, Martin" , X-OriginalArrivalTime: 05 Jan 2006 09:33:55.0477 (UTC) FILETIME=[25B50C50:01C611DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org hi martin,=20 > After reading Jonathan's common-policy-caps draft [1] and the=20 > related pres-policy-caps [2] and geopriv-policy-caps [3], I=20 > came to the realization that the subsequent documents all do=20 > exactly the same thing. they are meant todo the same thing.=20 they just indicate capabilities with respect to the common policy, presence authorization policies and the geopriv policies.=20 >=20 > Once the protocol components related to XCAP have been dealt=20 > with, the specification of a document format and schema is=20 > largely a copy-and-paste job. This is nice in one respect -=20 > these documents are very simple and elegant - but a long time=20 > spent with code triggers the refactoring neurons. Where a=20 > pattern exists, there is redundant code. >=20 > In order to use capabilities, every common-policy extension=20 > requires a matching capabilities specification. That extra=20 > specification contains little, or no, additional value. each new document could just put these capabilities in the main document.=20 we could do the same.=20 >=20 > With this thought in mind I have taken the problem and=20 > applied an additional layer of abstraction to create a=20 > document format that should address all extensions. In some=20 > way, this is inspired by the elegant simplicity of Schematron=20 > [4]. I hope that this one draft will suffice where many=20 > would have been before: >=20 > http://www.ietf.org/internet-drafts/draft-thomson-simple-expre > ssing-xml-support-00.txt >=20 > I think that the solution retains much of the simplicity of=20 > the original offering, while providing enough flexibility to=20 > accommodate future extensions. I also suspect that it could=20 > be easier to implement, and it will certainly be easier to maintain. >=20 > So, I'd like some feedback, if you have time to read the=20 > draft. Is this an acceptable tradeoff between the various=20 > factors (simplicity, specification work, etc...)? I have=20 > some ideas on how this could be integrated with the existing=20 > capabilities work, is that a good idea? =20 i am not sure i like the idea. to me it seems like another way to complicate things. they are certainly many different ways to accomplish the same thing but why do we need to search for a more complicated solution when we have a simple one?=20 ciao hannes > Cheers, > Martin >=20 > [1]=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-common-p > olicy-caps-00.txt > [2]=20 > http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-pol > icy-caps-00.txt > [3]=20 > http://www.ietf.org/internet-drafts/draft-guenther-geopriv-pol > icy-caps-03.txt > [4] http://www.schematron.com/overview.html >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 05 11:37:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuY6t-0007OO-Mj; Thu, 05 Jan 2006 11:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuY6s-0007MU-66 for simple@megatron.ietf.org; Thu, 05 Jan 2006 11:37:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05979 for ; Thu, 5 Jan 2006 11:35:51 -0500 (EST) Received: from grerelbas03.net.external.hp.com ([192.6.111.87] helo=grerelbas03.bastion.europe.hp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYCZ-0000db-RZ for simple@ietf.org; Thu, 05 Jan 2006 11:43:01 -0500 Received: from idaexg11.emea.cpqcorp.net (idaexg11.emea.cpqcorp.net [16.16.5.24]) by grerelbas03.bastion.europe.hp.com (Postfix) with ESMTP id EE47C3409F for ; Thu, 5 Jan 2006 17:37:02 +0100 (CET) Received: from vbeexc02.emea.cpqcorp.net ([16.188.145.136]) by idaexg11.emea.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 17:37:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2006 17:37:02 +0100 Message-ID: Thread-Topic: MSRP responses in case of failure... Thread-Index: AcYSFj408TwGpfZ9RZmC7xE37riOLA== From: "Varroni, Didier" To: X-OriginalArrivalTime: 05 Jan 2006 16:37:02.0782 (UTC) FILETIME=[41B85DE0:01C61216] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Subject: [Simple] MSRP responses in case of failure... X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi all, The management of the MSRP responses in case of failure, is not really = clear, regarding the MSRP draft. And I have some question about it. According to 7.1.3 Generate Failure Reports : "If an MSRP endpoint receives a SEND request that it cannot process for = some reason, and the Failure-Report header field either was not present = in the original request, or had a value of "yes", it SHOULD simply = include the appropriate error code in the transaction response" Does it clearly means that, the REPORT request is not mandatory, when = an error has been detected, and a non 200 class response has been = already sent ???? on the same par : "If the endpoint receives a SEND request with a Failure-Report header = field value of "no", then it MUST NOT send a failure REPORT request, and = MUST NOT send a transaction response" .. once again, so a non 200 class response is not supposed to be sent, = even if a failure has been detected (in the case of failure-report set = to no)... More generally, does it mean that the failure-report (and = success-report s well) procedure could be performed either by response = or by REPORT request ??? Thanks for clarify these points=20 Didier Varroni=20 =09 =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 05 13:10:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZZI-0005OU-Io; Thu, 05 Jan 2006 13:10:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZZG-0005Nr-MY; Thu, 05 Jan 2006 13:10:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20651; Thu, 5 Jan 2006 13:09:14 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZey-0004nD-Ni; Thu, 05 Jan 2006 13:16:25 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k05IAMGt013804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jan 2006 13:10:23 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id k05IAIuf025166; Thu, 5 Jan 2006 13:10:22 -0500 Message-ID: <43BD4CD6.50400@cs.columbia.edu> Date: Thu, 05 Jan 2006 11:44:06 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> In-Reply-To: <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I don't feel strongly about this; my only gut feeling is that it is a good thing to reduce options that don't add value. As far as I know, the set of strings representable by UTF-8 is exactly the same as the one representable in UTF-16. What is the advantage of allowing UTF-16? (One disadvantage is that any comparison would have to convert to a common format if both are allowed.) >> Common policy MUST use UTF-8 to store domain names in 'id' domain >> attributes. For non-IDNs, lower-case ASCII SHOULD be used. > Is "MUST use UTF-8" intended to purposefully rule out UTF-16, which all > XML parsers are required to understand? That is fine if it is, but this > would seem to then restrict the document to UTF-8. If this is a > protocol requirement, it needs to be stated. > > -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 05 14:05:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaQS-0002ZI-FK; Thu, 05 Jan 2006 14:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaQP-0002V3-QP; Thu, 05 Jan 2006 14:05:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27970; Thu, 5 Jan 2006 14:04:10 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaW7-00074k-Tb; Thu, 05 Jan 2006 14:11:22 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 05 Jan 2006 14:04:35 -0500 id 0158808B.43BD6DC3.00004452 In-Reply-To: <43BD4CD6.50400@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Thu, 5 Jan 2006 14:04:58 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jan 5, 2006, at 11:44 AM, Henning Schulzrinne wrote: > I don't feel strongly about this; my only gut feeling is that it is > a good thing to reduce options that don't add value. As far as I > know, the set of strings representable by UTF-8 is exactly the same > as the one representable in UTF-16. What is the advantage of > allowing UTF-16? > > (One disadvantage is that any comparison would have to convert to a > common format if both are allowed.) Unless you foresee the development of special purpose XML parsers for this application, I can see no advantage to ruling out UTF-16. As for your stated disadvantage, which XML parsers pass raw bytes to the application instead of a common format? Admittedly there are gobs of XML parsers out there, but I've never seen one that does this. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 05 17:24:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EudX0-0005u7-A0; Thu, 05 Jan 2006 17:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EudWy-0005sL-Me for simple@megatron.ietf.org; Thu, 05 Jan 2006 17:24:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01710 for ; Thu, 5 Jan 2006 17:23:09 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eudck-000112-Bf for simple@ietf.org; Thu, 05 Jan 2006 17:30:22 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 16:24:04 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 05 Jan 2006 16:24:03 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 16:24:03 -0600 Message-ID: From: "Thomson, Martin" To: "Tschofenig, Hannes" Date: Thu, 5 Jan 2006 16:23:07 -0600 Subject: RE: [Simple] Expressing XML support for common-policy and extensions MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 05 Jan 2006 22:24:03.0317 (UTC) FILETIME=[BBB9E250:01C61246] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Simple] Expressing XML support for common-policy and extensions thread-index: AcYRstV/T+BgLDtkQ+GMh/YIhMYK9gAJ1fLQABnQY+A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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="===============1136560734==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1136560734== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpUaGFua3MgZm9yIHJlYWRpbmcgdGhlIGRyYWZ0IGFuZCBnaXZpbmcgbWUg c29tZSBmZWVkYmFjay4NCg0KSSBjYW4ndCBoZWxwIGJ1dCBmZWVsIHRoYXQgeW91IGhhdmUgbWlz c2VkIG15IHBvaW50LiAgWWVzIHRob3NlIGRvY3VtZW50cyBhcmUgbWVhbnQgdG8gZG8gdGhlIHNh bWUgdGhpbmcsIGJ1dCBJIHRoaW5rIGl0IGZhciBwcmVmZXJhYmxlIHRvIGhhdmUgdGhhdCB0aGlu ZyBkb25lIG9uY2UsIGluIGEgd2F5IHRoYXQgY2FuIGJlIHJlcGV0aXRpdmVseSBhcHBsaWVkLiAg VGhpcyBwcm9ibGVtIGV4aXN0cywgbm90IG9ubHkgZm9yIElFVEYgZXh0ZW5zaW9ucywgYnV0IGFs c28gdG8gZXh0ZW5zaW9ucyBpbnRyb2R1Y2VkIGJ5IG90aGVyIGJvZGllcyBhbmQgcHJpdmF0ZSB2 ZW5kb3JzLiAgU2ltcGx5IHNheWluZyB0aGF0IHRoZSB3b3JrIGNvdWxkIGJlIGluY2x1ZGVkIGlu IGFub3RoZXIgZG9jdW1lbnQgZG9kZ2VzIHRoZSBpc3N1ZS4gIA0KDQpXaXRoIHJlZ2FyZHMgdG8g Y29tcGxleGl0eSwgSSBiZWxpZXZlIHRoYXQgeW91IGhhdmUgYSB2YWxpZCBjb25jZXJuLCBidXQg dGhhdCBpcyBsaW1pdGVkIGluIGEgZmV3IHdheXMuDQoNCiAtIEJlY2F1c2UgdGhlIGxldmVsIG9m IGFic3RyYWN0aW9uIEkgY2hvc2UgaXMgcXVpdGUgZ2VuZXJhbCwgdGhpcyBzcGVjaWZpY2F0aW9u IGlzIHdyaXR0ZW4gaW4gYSB3YXkgdGhhdCBhZGRyZXNzZXMgYSB2ZXJ5IGxhcmdlIHByb2JsZW0g c3BhY2UuICBGb3IgdGhhdCByZWFzb24sIGl0IGhhcyB0byBjb3ZlciBhIGxhcmdlIGFtb3VudCBv ZiBjb3JuZXIgY2FzZXMuICBUaGlzIGlzIHRoZSBjYXNlIHdpdGggbWFueSBnZW5lcmFsaXplZCBz cGVjaWZpY2F0aW9ucy4gIEhvd2V2ZXIsIHdoZW4gdGhlc2Ugc3BlY2lmaWNhdGlvbnMgYXJlIGFw cGxpZWQsIHRoZSBjb21wbGV4aXR5IGlzIG9mdGVuIGludmlzaWJsZS4gIEZvciBpbnN0YW5jZSwg YmFzZWQgb24gbXkgZXhwZXJpZW5jZSB3aXRoIHRoZSBXU0RMIDIuMCBzcGVjLCBhdCBmaXJzdCBy ZWFkIGlzIGRhdW50aW5nLCBidXQgaXRzIGFwcGxpY2F0aW9uIGlzIHF1aXRlIHNpbXBsZSBhbmQg ZWxlZ2FudC4NCiAgIFRoaXMgZG9jdW1lbnQgaXMgYSBiYXNlLWxldmVsIHNwZWNpZmljYXRpb24g dGhhdCByZXF1aXJlcyBvdGhlciBzcGVjaWZpY2F0aW9ucyB0byBkZWZpbmUgaG93IGl0IGlzIHVz ZWQuICBUaGUgdXNpbmcgc3BlY2lmaWNhdGlvbiBjYW4gbGltaXQgdGhlIGZ1bmN0aW9uYWxpdHkg aW4gYW55IHdheSBuZWNlc3NhcnkgdG8gZGV0ZXJtaW5lIHRoZSBsZXZlbCBvZiBjb21wbGV4aXR5 IHRoYXQgaXMgZGVlbWVkIG5lY2Vzc2FyeS4gIFRoZSBYUGF0aCBwcm9maWxlIEkgZGVmaW5lZCBp cyBpbmNsdWRlZCBmb3IgdGhpcyByZWFzb24uDQogICBJZiB0aGlzIHdhcyBhcHBsaWVkIHRvIGNv bW1vbi1wb2xpY3ksIEkgY291bGQgc2VlIHRoYXQgbXVjaCBvZiB0aGUgY29tcGxleGl0eSBjb3Vs ZCBiZSByZW1vdmVkLCBzaW5jZSB0aGUgcmVxdWlyZW1lbnRzIGFyZW4ndCB2ZXJ5IGdyZWF0Lg0K DQogLSBUaGlzIGRvY3VtZW50IGVuYWJsZXMgYSAid3JpdGUgb25jZSIgc29mdHdhcmUgbW9kdWxl IC0geW91IHNob3VsZCBub3QgdW5kZXJlc3RpbWF0ZSB0aGUgYWR2YW50YWdlcyBvZiBub3QgaGF2 aW5nIHRvIHVwZGF0ZSBzb2Z0d2FyZS4gIEluIG15IGV4cGVyaWVuY2UsIG1hbnkgc29mdHdhcmUg ZGV2ZWxvcG1lbnQgaG91c2VzIGFyZSB3aWxsaW5nIHRvIGFjY2VwdCBhIHNtYWxsIGNvc3Qgb2Yg Y29tcGxleGl0eSB3aGVuIG90aGVyIGZhY3RvcnMgYXJlIGZhdm9yYWJsZTogZmVhdHVyZXMsIHJl dXNlLCBjb2RlIHNpemUsIHBlcmZvcm1hbmNlLCBhbmQgYXZhaWxhYmxlIHRoaXJkIHBhcnR5IGlt cGxlbWVudGF0aW9ucy4NCg0KVGEsDQpNYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBUc2Nob2ZlbmlnLCBIYW5uZXMgW21haWx0bzpoYW5uZXMudHNjaG9mZW5p Z0BzaWVtZW5zLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIDUgSmFudWFyeSAyMDA2IDg6MzEgUE0N Cj4gVG86IFRob21zb24sIE1hcnRpbjsgc2ltcGxlQGlldGYub3JnDQo+IFN1YmplY3Q6IEFXOiBb U2ltcGxlXSBFeHByZXNzaW5nIFhNTCBzdXBwb3J0IGZvciBjb21tb24tcG9saWN5IGFuZA0KPiBl eHRlbnNpb25zDQo+IA0KPiBoaSBtYXJ0aW4sDQo+IA0KPiA+IEFmdGVyIHJlYWRpbmcgSm9uYXRo YW4ncyBjb21tb24tcG9saWN5LWNhcHMgZHJhZnQgWzFdIGFuZCB0aGUNCj4gPiByZWxhdGVkIHBy ZXMtcG9saWN5LWNhcHMgWzJdIGFuZCBnZW9wcml2LXBvbGljeS1jYXBzIFszXSwgSQ0KPiA+IGNh bWUgdG8gdGhlIHJlYWxpemF0aW9uIHRoYXQgdGhlIHN1YnNlcXVlbnQgZG9jdW1lbnRzIGFsbCBk bw0KPiA+IGV4YWN0bHkgdGhlIHNhbWUgdGhpbmcuDQo+IA0KPiB0aGV5IGFyZSBtZWFudCB0b2Rv IHRoZSBzYW1lIHRoaW5nLg0KPiB0aGV5IGp1c3QgaW5kaWNhdGUgY2FwYWJpbGl0aWVzIHdpdGgg cmVzcGVjdCB0byB0aGUgY29tbW9uIHBvbGljeSwNCj4gcHJlc2VuY2UgYXV0aG9yaXphdGlvbiBw b2xpY2llcyBhbmQgdGhlIGdlb3ByaXYgcG9saWNpZXMuDQo+IA0KPiA+DQo+ID4gT25jZSB0aGUg cHJvdG9jb2wgY29tcG9uZW50cyByZWxhdGVkIHRvIFhDQVAgaGF2ZSBiZWVuIGRlYWx0DQo+ID4g d2l0aCwgdGhlIHNwZWNpZmljYXRpb24gb2YgYSBkb2N1bWVudCBmb3JtYXQgYW5kIHNjaGVtYSBp cw0KPiA+IGxhcmdlbHkgYSBjb3B5LWFuZC1wYXN0ZSBqb2IuICBUaGlzIGlzIG5pY2UgaW4gb25l IHJlc3BlY3QgLQ0KPiA+IHRoZXNlIGRvY3VtZW50cyBhcmUgdmVyeSBzaW1wbGUgYW5kIGVsZWdh bnQgLSBidXQgYSBsb25nIHRpbWUNCj4gPiBzcGVudCB3aXRoIGNvZGUgdHJpZ2dlcnMgdGhlIHJl ZmFjdG9yaW5nIG5ldXJvbnMuICBXaGVyZSBhDQo+ID4gcGF0dGVybiBleGlzdHMsIHRoZXJlIGlz IHJlZHVuZGFudCBjb2RlLg0KPiA+DQo+ID4gSW4gb3JkZXIgdG8gdXNlIGNhcGFiaWxpdGllcywg ZXZlcnkgY29tbW9uLXBvbGljeSBleHRlbnNpb24NCj4gPiByZXF1aXJlcyBhIG1hdGNoaW5nIGNh cGFiaWxpdGllcyBzcGVjaWZpY2F0aW9uLiAgVGhhdCBleHRyYQ0KPiA+IHNwZWNpZmljYXRpb24g Y29udGFpbnMgbGl0dGxlLCBvciBubywgYWRkaXRpb25hbCB2YWx1ZS4NCj4gDQo+IGVhY2ggbmV3 IGRvY3VtZW50IGNvdWxkIGp1c3QgcHV0IHRoZXNlIGNhcGFiaWxpdGllcyBpbiB0aGUgbWFpbg0K PiBkb2N1bWVudC4NCj4gd2UgY291bGQgZG8gdGhlIHNhbWUuDQo+IA0KPiA+DQo+ID4gV2l0aCB0 aGlzIHRob3VnaHQgaW4gbWluZCBJIGhhdmUgdGFrZW4gdGhlIHByb2JsZW0gYW5kDQo+ID4gYXBw bGllZCBhbiBhZGRpdGlvbmFsIGxheWVyIG9mIGFic3RyYWN0aW9uIHRvIGNyZWF0ZSBhDQo+ID4g ZG9jdW1lbnQgZm9ybWF0IHRoYXQgc2hvdWxkIGFkZHJlc3MgYWxsIGV4dGVuc2lvbnMuICBJbiBz b21lDQo+ID4gd2F5LCB0aGlzIGlzIGluc3BpcmVkIGJ5IHRoZSBlbGVnYW50IHNpbXBsaWNpdHkg b2YgU2NoZW1hdHJvbg0KPiA+IFs0XS4gIEkgaG9wZSB0aGF0IHRoaXMgb25lIGRyYWZ0IHdpbGwg c3VmZmljZSB3aGVyZSBtYW55DQo+ID4gd291bGQgaGF2ZSBiZWVuIGJlZm9yZToNCj4gPg0KPiA+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRob21zb24tc2ltcGxl LWV4cHJlDQo+ID4gc3NpbmcteG1sLXN1cHBvcnQtMDAudHh0DQo+ID4NCj4gPiBJIHRoaW5rIHRo YXQgdGhlIHNvbHV0aW9uIHJldGFpbnMgbXVjaCBvZiB0aGUgc2ltcGxpY2l0eSBvZg0KPiA+IHRo ZSBvcmlnaW5hbCBvZmZlcmluZywgd2hpbGUgcHJvdmlkaW5nIGVub3VnaCBmbGV4aWJpbGl0eSB0 bw0KPiA+IGFjY29tbW9kYXRlIGZ1dHVyZSBleHRlbnNpb25zLiAgSSBhbHNvIHN1c3BlY3QgdGhh dCBpdCBjb3VsZA0KPiA+IGJlIGVhc2llciB0byBpbXBsZW1lbnQsIGFuZCBpdCB3aWxsIGNlcnRh aW5seSBiZSBlYXNpZXIgdG8gbWFpbnRhaW4uDQo+ID4NCj4gPiBTbywgSSdkIGxpa2Ugc29tZSBm ZWVkYmFjaywgaWYgeW91IGhhdmUgdGltZSB0byByZWFkIHRoZQ0KPiA+IGRyYWZ0LiAgSXMgdGhp cyBhbiBhY2NlcHRhYmxlIHRyYWRlb2ZmIGJldHdlZW4gdGhlIHZhcmlvdXMNCj4gPiBmYWN0b3Jz IChzaW1wbGljaXR5LCBzcGVjaWZpY2F0aW9uIHdvcmssIGV0Yy4uLik/ICBJIGhhdmUNCj4gPiBz b21lIGlkZWFzIG9uIGhvdyB0aGlzIGNvdWxkIGJlIGludGVncmF0ZWQgd2l0aCB0aGUgZXhpc3Rp bmcNCj4gPiBjYXBhYmlsaXRpZXMgd29yaywgaXMgdGhhdCBhIGdvb2QgaWRlYT8NCj4gDQo+IGkg YW0gbm90IHN1cmUgaSBsaWtlIHRoZSBpZGVhLiB0byBtZSBpdCBzZWVtcyBsaWtlIGFub3RoZXIg d2F5IHRvDQo+IGNvbXBsaWNhdGUgdGhpbmdzLiB0aGV5IGFyZSBjZXJ0YWlubHkgbWFueSBkaWZm ZXJlbnQgd2F5cyB0byBhY2NvbXBsaXNoDQo+IHRoZSBzYW1lIHRoaW5nIGJ1dCB3aHkgZG8gd2Ug bmVlZCB0byBzZWFyY2ggZm9yIGEgbW9yZSBjb21wbGljYXRlZA0KPiBzb2x1dGlvbiB3aGVuIHdl IGhhdmUgYSBzaW1wbGUgb25lPw0KPiANCj4gY2lhbw0KPiBoYW5uZXMNCj4gDQo+ID4gQ2hlZXJz LA0KPiA+IE1hcnRpbg0KPiA+DQo+ID4gWzFdDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zaW1wbGUtY29tbW9uLXANCj4gPiBvbGljeS1jYXBzLTAw LnR4dA0KPiA+IFsyXQ0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtc2ltcGxlLXByZXMtcG9sDQo+ID4gaWN5LWNhcHMtMDAudHh0DQo+ID4gWzNdDQo+ ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ3VlbnRoZXItZ2Vv cHJpdi1wb2wNCj4gPiBpY3ktY2Fwcy0wMy50eHQNCj4gPiBbNF0gaHR0cDovL3d3dy5zY2hlbWF0 cm9uLmNvbS9vdmVydmlldy5odG1sDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25s eSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2Ug cHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3Jp Z2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVk Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============1136560734== 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 --===============1136560734==-- From simple-bounces@ietf.org Fri Jan 06 04:51:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuoFU-0006MA-Bd; Fri, 06 Jan 2006 04:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuoFR-0006Kn-LZ; Fri, 06 Jan 2006 04:51:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19458; Fri, 6 Jan 2006 04:49:44 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuoLI-0004Cl-Dn; Fri, 06 Jan 2006 04:57:05 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k069lDGt024831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jan 2006 04:50:58 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id k069lCsT028646; Fri, 6 Jan 2006 04:47:13 -0500 Message-ID: <43BE3ADB.2020305@cs.columbia.edu> Date: Fri, 06 Jan 2006 04:39:39 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> In-Reply-To: <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org How do XML parsers pass back string elements to the application? > Unless you foresee the development of special purpose XML parsers for > this application, I can see no advantage to ruling out UTF-16. As for > your stated disadvantage, which XML parsers pass raw bytes to the > application instead of a common format? Admittedly there are gobs of > XML parsers out there, but I've never seen one that does this. > > -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 06 08:44:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eurt5-0004Mh-Px; Fri, 06 Jan 2006 08:44:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eurt3-0004M7-Gf; Fri, 06 Jan 2006 08:44:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02082; Fri, 6 Jan 2006 08:42:53 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euryw-00021Q-9G; Fri, 06 Jan 2006 08:50:15 -0500 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 06 Jan 2006 08:43:24 -0500 id 0158808F.43BE73FC.00001B73 In-Reply-To: <43BE3ADB.2020305@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> <43BE3ADB.2020305@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Fri, 6 Jan 2006 08:43:45 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Usually they pass back the element content as a unicode compatible string or an array of unicode compatible characters, and the application does not need to make a distinction between UTF-8 and UTF-16. Some languages have native Unicode support, but in cases where that is not true special types are defined to represent xml character data. -andy On Jan 6, 2006, at 4:39 AM, Henning Schulzrinne wrote: > How do XML parsers pass back string elements to the application? > >> Unless you foresee the development of special purpose XML parsers >> for this application, I can see no advantage to ruling out >> UTF-16. As for your stated disadvantage, which XML parsers pass >> raw bytes to the application instead of a common format? >> Admittedly there are gobs of XML parsers out there, but I've never >> seen one that does this. >> -andy > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 06 08:55:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eus4O-00008p-9Q; Fri, 06 Jan 2006 08:55:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eus4L-00008A-8Z; Fri, 06 Jan 2006 08:55:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02596; Fri, 6 Jan 2006 08:54:32 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EusAF-0002Kr-0t; Fri, 06 Jan 2006 09:01:55 -0500 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 06 Jan 2006 08:55:13 -0500 id 0158808F.43BE76C1.00001DD3 In-Reply-To: <43BD4CD6.50400@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <3F3FB8D9-E0DA-46E7-AC10-6C00819E6A3A@hxr.us> From: Andrew Newton Date: Fri, 6 Jan 2006 08:55:35 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy 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="===============0068707716==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0068707716== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-7637-1136555721-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-7637-1136555721-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 5, 2006, at 11:44 AM, Henning Schulzrinne wrote: > I don't feel strongly about this; my only gut feeling is that it is > a good thing to reduce options that don't add value. As far as I > know, the set of strings representable by UTF-8 is exactly the same > as the one representable in UTF-16. What is the advantage of > allowing UTF-16? > > (One disadvantage is that any comparison would have to convert to a > common format if both are allowed.) BTW, from BCP 70, last paragraph in Section 5.1: Restricting XML data to only be expressed in UTF-8 is an additional syntactic restriction (see Section 4.3) which, depending on circumstances, might add additional implementation complexity. -andy --=_zeke.ecotroph.net-7637-1136555721-0001-2 Content-Type: text/html; charset=iso-8859-1 X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.52.1 Content-Transfer-Encoding: quoted-printable
On Jan 5, 2006, at 11= :44 AM, Henning Schulzrinne wrote:

I don't feel strongly about this; my only gut feeling is that it is = a good thing to reduce options that don't add value. As far as I know, t= he set of strings representable by UTF-8 is exactly the same as the one = representable in UTF-16. What is the advantage of allowing UTF-16?


=A0 =A0Restricting XML data to only= be expressed in UTF-8 is an additional
=A0=A0 syntactic restr= iction (see Section 4.3) which, depending on
=A0=A0 circumstan= ces, might add additional implementation complexity.

-andy
--=_zeke.ecotroph.net-7637-1136555721-0001-2-- --===============0068707716== 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 --===============0068707716==-- From simple-bounces@ietf.org Fri Jan 06 09:23:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EusUo-0000YC-PU; Fri, 06 Jan 2006 09:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EusUm-0000XP-SE; Fri, 06 Jan 2006 09:23:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04421; Fri, 6 Jan 2006 09:21:52 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eusaf-00039H-VH; Fri, 06 Jan 2006 09:29:15 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k06EMTGt018889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jan 2006 09:22:47 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id k06EMS8C032195; Fri, 6 Jan 2006 09:22:29 -0500 Message-ID: <43BE7D46.1030908@cs.columbia.edu> Date: Fri, 06 Jan 2006 09:23:02 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> <43BE3ADB.2020305@cs.columbia.edu> <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> In-Reply-To: <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org FWIW, I just picked the first XML application that came to mind, in PHP. It doesn't support UTF-16. Source: http://de.php.net/xml and http://de.php.net/manual/en/ref.xml.php#xml.encoding From all I can tell for PHP, it represents strings in their 'native' (byte) representation, so that if you have two XML documents, one using 8859-1 and one UTF-8, you need to convert between them to compare literal strings outside the ASCII range. (http://de.php.net/manual/en/language.types.string.php) I don't see why restricting character sets to UTF-8 complicates processing. Andrew Newton wrote: > Usually they pass back the element content as a unicode compatible > string or an array of unicode compatible characters, and the application > does not need to make a distinction between UTF-8 and UTF-16. Some > languages have native Unicode support, but in cases where that is not > true special types are defined to represent xml character data. > > -andy > > On Jan 6, 2006, at 4:39 AM, Henning Schulzrinne wrote: > >> How do XML parsers pass back string elements to the application? >> >>> Unless you foresee the development of special purpose XML parsers for >>> this application, I can see no advantage to ruling out UTF-16. As >>> for your stated disadvantage, which XML parsers pass raw bytes to the >>> application instead of a common format? Admittedly there are gobs of >>> XML parsers out there, but I've never seen one that does this. >>> -andy >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 06 10:13:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutHz-0006l7-6k; Fri, 06 Jan 2006 10:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutHr-0006kX-Ta; Fri, 06 Jan 2006 10:13:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07129; Fri, 6 Jan 2006 10:12:35 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EutNl-0004Yz-G1; Fri, 06 Jan 2006 10:19:58 -0500 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 06 Jan 2006 10:13:04 -0500 id 0158808F.43BE8900.00002D11 In-Reply-To: <43BE7D46.1030908@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> <43BE3ADB.2020305@cs.columbia.edu> <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> <43BE7D46.1030908@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Fri, 6 Jan 2006 10:13:26 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org If it doesn't support UTF-16 as the source encoding, it is not compliant with the XML standard. BTW, thanks for the reference point with PHP. I started looking around to see what various parsers using languages without native Unicode do. Both libxml2 and Xerces-C define datatypes for xml character data. libxml2 always hands the application UTF-8 but it supports UTF-16 as a source encoding (making one draw the conclusion that it transcodes to UTF-8 when UTF-8 is not the source encoding). Expat does the same, but there is a compile-time option to have the parser hand the application UTF-16 instead of UTF-8. From what I can tell, PHP is the exception and not the rule. -andy On Jan 6, 2006, at 9:23 AM, Henning Schulzrinne wrote: > FWIW, I just picked the first XML application that came to mind, in > PHP. It doesn't support UTF-16. Source: http://de.php.net/xml and > http://de.php.net/manual/en/ref.xml.php#xml.encoding > > From all I can tell for PHP, it represents strings in their > 'native' (byte) representation, so that if you have two XML > documents, one using 8859-1 and one UTF-8, you need to convert > between them to compare literal strings outside the ASCII range. > (http://de.php.net/manual/en/language.types.string.php) > > I don't see why restricting character sets to UTF-8 complicates > processing. > > Andrew Newton wrote: >> Usually they pass back the element content as a unicode compatible >> string or an array of unicode compatible characters, and the >> application does not need to make a distinction between UTF-8 and >> UTF-16. Some languages have native Unicode support, but in cases >> where that is not true special types are defined to represent xml >> character data. >> -andy >> On Jan 6, 2006, at 4:39 AM, Henning Schulzrinne wrote: >>> How do XML parsers pass back string elements to the application? >>> >>>> Unless you foresee the development of special purpose XML >>>> parsers for this application, I can see no advantage to ruling >>>> out UTF-16. As for your stated disadvantage, which XML parsers >>>> pass raw bytes to the application instead of a common format? >>>> Admittedly there are gobs of XML parsers out there, but I've >>>> never seen one that does this. >>>> -andy >>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 06 11:02:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euu3L-0001xb-Hy; Fri, 06 Jan 2006 11:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euu3J-0001x2-Ju; Fri, 06 Jan 2006 11:02:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10589; Fri, 6 Jan 2006 11:01:36 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euu9D-00069O-Fm; Fri, 06 Jan 2006 11:09:00 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k06G2iGt005394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jan 2006 11:02:44 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id k06G2glV032414; Fri, 6 Jan 2006 11:02:43 -0500 Message-ID: <43BE94BD.9010507@cs.columbia.edu> Date: Fri, 06 Jan 2006 11:03:09 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> <43BE3ADB.2020305@cs.columbia.edu> <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> <43BE7D46.1030908@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=%%XGAUGE%%%%IGAUGE%%, Probability=%%PROB%%, Report='%%HITS%%' X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org At least, it's not a general problem... I still fail to see the practical advantage of allowing UTF-16, given that we control the input and that this is not general text, but rather strings with a very specific purpose. Andrew Newton wrote: > If it doesn't support UTF-16 as the source encoding, it is not compliant > with the XML standard. > > BTW, thanks for the reference point with PHP. I started looking around > to see what various parsers using languages without native Unicode do. > Both libxml2 and Xerces-C define datatypes for xml character data. > libxml2 always hands the application UTF-8 but it supports UTF-16 as a > source encoding (making one draw the conclusion that it transcodes to > UTF-8 when UTF-8 is not the source encoding). Expat does the same, but > there is a compile-time option to have the parser hand the application > UTF-16 instead of UTF-8. From what I can tell, PHP is the exception and > not the rule. > > -andy > > On Jan 6, 2006, at 9:23 AM, Henning Schulzrinne wrote: > >> FWIW, I just picked the first XML application that came to mind, in >> PHP. It doesn't support UTF-16. Source: http://de.php.net/xml and >> http://de.php.net/manual/en/ref.xml.php#xml.encoding >> >> From all I can tell for PHP, it represents strings in their 'native' >> (byte) representation, so that if you have two XML documents, one >> using 8859-1 and one UTF-8, you need to convert between them to >> compare literal strings outside the ASCII range. >> (http://de.php.net/manual/en/language.types.string.php) >> >> I don't see why restricting character sets to UTF-8 complicates >> processing. >> >> Andrew Newton wrote: >>> Usually they pass back the element content as a unicode compatible >>> string or an array of unicode compatible characters, and the >>> application does not need to make a distinction between UTF-8 and >>> UTF-16. Some languages have native Unicode support, but in cases >>> where that is not true special types are defined to represent xml >>> character data. >>> -andy >>> On Jan 6, 2006, at 4:39 AM, Henning Schulzrinne wrote: >>>> How do XML parsers pass back string elements to the application? >>>> >>>>> Unless you foresee the development of special purpose XML parsers >>>>> for this application, I can see no advantage to ruling out UTF-16. >>>>> As for your stated disadvantage, which XML parsers pass raw bytes >>>>> to the application instead of a common format? Admittedly there >>>>> are gobs of XML parsers out there, but I've never seen one that >>>>> does this. >>>>> -andy >>>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 06 11:27:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuuRD-0003gj-8X; Fri, 06 Jan 2006 11:27:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuuR9-0003g6-1R; Fri, 06 Jan 2006 11:27:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11978; Fri, 6 Jan 2006 11:26:13 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuuX2-0006oY-3T; Fri, 06 Jan 2006 11:33:38 -0500 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 06 Jan 2006 11:26:44 -0500 id 0158802A.43BE9A44.00003B81 In-Reply-To: <43BE94BD.9010507@cs.columbia.edu> References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> <43BE3ADB.2020305@cs.columbia.edu> <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> <43BE7D46.1030908@cs.columbia.edu> <43BE94BD.9010507@cs.columbia.edu> Mime-Version: 1.0 Message-Id: From: Andrew Newton Date: Fri, 6 Jan 2006 11:27:06 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'GEOPRIV WG' , Simple WG Subject: [Simple] Re: [Geopriv] Domain identifier in common policy 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="===============0413322959==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0413322959== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-15235-1136564821-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-15235-1136564821-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jan 6, 2006, at 11:03 AM, Henning Schulzrinne wrote: > I still fail to see the practical advantage of allowing UTF-16, > given that we control the input and that this is not general text, > but rather strings with a very specific purpose. 1) How does the application know that the source encoding was UTF-16? Or asked another way, how does the application know the source encoding was not UTF-8? Most can look at the XML declaration, but in the passing of the element content where this is actually relevant they may not be able to tell. This type of detection is extra logic and seems unnecessary if the application can handle both. Also, on platforms that would output UTF-16, it is extra logic to force them to transcode to UTF-8, which is also unnecessary since the receiver of that output must understand UTF-16. 2) What practical advantage is there to disallowing UTF-16? -andy --=_zeke.ecotroph.net-15235-1136564821-0001-2 Content-Type: text/html; charset=iso-8859-1 X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.52.1 Content-Transfer-Encoding: quoted-printable
On Jan 6, 2006, at 11= :03 AM, Henning Schulzrinne wrote:

I still fail to see the practical advantage of allowing UTF-16, give= n that we control the input and that this is not general text, but rathe= r strings with a very specific purpose.

1) How does the application know that the source encoding was UTF= -16?=A0 Or asked another way, how does the application know the source e= ncoding was not UTF-8?=A0 Most can look at the XML declaration, but in t= he passing of the element content where this is actually relevant they m= ay not be able to tell. This type of detection is extra logic and seems = unnecessary if the application can handle both.=A0 Also, on platforms th= at would output UTF-16, it is extra logic to force them to transcode to = UTF-8, which is also unnecessary since the receiver of that output must = understand UTF-16.

2) What practical advantage is there to disallowing UTF-16?
<= DIV>
-andy
<= /HTML> --=_zeke.ecotroph.net-15235-1136564821-0001-2-- --===============0413322959== 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 --===============0413322959==-- From simple-bounces@ietf.org Fri Jan 06 11:58:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euuv4-0001Ah-PL; Fri, 06 Jan 2006 11:58:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euuv3-0001A8-AG for simple@megatron.ietf.org; Fri, 06 Jan 2006 11:58:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14537 for ; Fri, 6 Jan 2006 11:57:08 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euv0x-0007vQ-Cx for simple@ietf.org; Fri, 06 Jan 2006 12:04:32 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k06GwCwQ025368; Fri, 6 Jan 2006 17:58:12 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k06GwCbT019025; Fri, 6 Jan 2006 17:58:12 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 17:58:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Simple] Expressing XML support for common-policy and extensions Date: Fri, 6 Jan 2006 17:58:11 +0100 Message-ID: Thread-Topic: [Simple] Expressing XML support for common-policy and extensions Thread-Index: AcYRstV/T+BgLDtkQ+GMh/YIhMYK9gAJ1fLQABnQY+AAHnBC8A== From: "Tschofenig, Hannes" To: "Thomson, Martin" X-OriginalArrivalTime: 06 Jan 2006 16:58:11.0529 (UTC) FILETIME=[605D8B90:01C612E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org hi martin,=20 =20 > Hi Hannes, >=20 > Thanks for reading the draft and giving me some feedback. >=20 > I can't help but feel that you have missed my point. Yes=20 > those documents are meant to do the same thing, but I think=20 > it far preferable to have that thing done once, in a way that=20 > can be repetitively applied. This problem exists, not only=20 > for IETF extensions, but also to extensions introduced by=20 > other bodies and private vendors. Simply saying that the=20 > work could be included in another document dodges the issue. =20 my comment regarding including the content into another document was meant to address the aspect of having one additional document per authorization policy document.=20 we could also move the "capability" stuff into the respective document.=20 to me it seems that the approach suggested by jonathan was simple enough to deal with this extensibility functionality. my goal is to try to keep things as simple as possible. with the approach was exercised once and can be used with additional extensions. so far there aren't too many extensions. hence, there is no problem of dealing with extensions of other organizations and private vendors. the authorization policies developed in geopriv are not meant to offer a generic policy mechanism, such as xacml, to keep it as simple as possible.=20 >=20 > With regards to complexity, I believe that you have a valid=20 > concern, but that is limited in a few ways. >=20 > - Because the level of abstraction I chose is quite general,=20 > this specification is written in a way that addresses a very=20 > large problem space. For that reason, it has to cover a=20 > large amount of corner cases. This is the case with many=20 > generalized specifications. However, when these=20 > specifications are applied, the complexity is often=20 > invisible. For instance, based on my experience with the=20 > WSDL 2.0 spec, at first read is daunting, but its application=20 > is quite simple and elegant. > This document is a base-level specification that requires=20 > other specifications to define how it is used. The using=20 > specification can limit the functionality in any way=20 > necessary to determine the level of complexity that is deemed=20 > necessary. The XPath profile I defined is included for this reason. > If this was applied to common-policy, I could see that=20 > much of the complexity could be removed, since the=20 > requirements aren't very great. >=20 > - This document enables a "write once" software module - you=20 > should not underestimate the advantages of not having to=20 > update software. In my experience, many software development=20 > houses are willing to accept a small cost of complexity when=20 > other factors are favorable: features, reuse, code size,=20 > performance, and available third party implementations. i don't see that the other approach requires a complex implementation instead./=20 ciao hannes >=20 > Ta, > Martin >=20 > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Thursday, 5 January 2006 8:31 PM > > To: Thomson, Martin; simple@ietf.org > > Subject: AW: [Simple] Expressing XML support for common-policy and > > extensions > >=20 > > hi martin, > >=20 > > > After reading Jonathan's common-policy-caps draft [1] and the > > > related pres-policy-caps [2] and geopriv-policy-caps [3], I > > > came to the realization that the subsequent documents all do > > > exactly the same thing. > >=20 > > they are meant todo the same thing. > > they just indicate capabilities with respect to the common policy, > > presence authorization policies and the geopriv policies. > >=20 > > > > > > Once the protocol components related to XCAP have been dealt > > > with, the specification of a document format and schema is > > > largely a copy-and-paste job. This is nice in one respect - > > > these documents are very simple and elegant - but a long time > > > spent with code triggers the refactoring neurons. Where a > > > pattern exists, there is redundant code. > > > > > > In order to use capabilities, every common-policy extension > > > requires a matching capabilities specification. That extra > > > specification contains little, or no, additional value. > >=20 > > each new document could just put these capabilities in the main > > document. > > we could do the same. > >=20 > > > > > > With this thought in mind I have taken the problem and > > > applied an additional layer of abstraction to create a > > > document format that should address all extensions. In some > > > way, this is inspired by the elegant simplicity of Schematron > > > [4]. I hope that this one draft will suffice where many > > > would have been before: > > > > > > http://www.ietf.org/internet-drafts/draft-thomson-simple-expre > > > ssing-xml-support-00.txt > > > > > > I think that the solution retains much of the simplicity of > > > the original offering, while providing enough flexibility to > > > accommodate future extensions. I also suspect that it could > > > be easier to implement, and it will certainly be easier=20 > to maintain. > > > > > > So, I'd like some feedback, if you have time to read the > > > draft. Is this an acceptable tradeoff between the various > > > factors (simplicity, specification work, etc...)? I have > > > some ideas on how this could be integrated with the existing > > > capabilities work, is that a good idea? > >=20 > > i am not sure i like the idea. to me it seems like another way to > > complicate things. they are certainly many different ways=20 > to accomplish > > the same thing but why do we need to search for a more complicated > > solution when we have a simple one? > >=20 > > ciao > > hannes > >=20 > > > Cheers, > > > Martin > > > > > > [1] > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-common-p > > > olicy-caps-00.txt > > > [2] > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-pol > > > icy-caps-00.txt > > > [3] > > > http://www.ietf.org/internet-drafts/draft-guenther-geopriv-pol > > > =09 > > > [4] http://www.schematron.com/overview.html >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 06 13:09:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euw2F-0004kj-OK; Fri, 06 Jan 2006 13:09:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euw2D-0004kX-KN for simple@megatron.ietf.org; Fri, 06 Jan 2006 13:09:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19267 for ; Fri, 6 Jan 2006 13:08:37 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Euw87-0001dY-3V for simple@ietf.org; Fri, 06 Jan 2006 13:16:01 -0500 Received: (qmail invoked by alias); 06 Jan 2006 18:09:35 -0000 Received: from dslb-084-057-224-168.pools.arcor-ip.net (EHLO hive) [84.57.224.168] by mail.gmx.net (mp031) with SMTP; 06 Jan 2006 19:09:35 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Andrew Newton Subject: Re: [Simple] Re: [Geopriv] Domain identifier in common policy Date: Fri, 06 Jan 2006 19:10:10 +0100 Message-ID: References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> In-Reply-To: <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> X-Mailer: Forte Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA19267 Cc: geopriv@ietf.org, Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org * Andrew Newton wrote: >> I don't feel strongly about this; my only gut feeling is that it is =20 >> a good thing to reduce options that don't add value. As far as I =20 >> know, the set of strings representable by UTF-8 is exactly the same =20 >> as the one representable in UTF-16. What is the advantage of =20 >> allowing UTF-16? >> >> (One disadvantage is that any comparison would have to convert to a =20 >> common format if both are allowed.) > >Unless you foresee the development of special purpose XML parsers for =20 >this application, I can see no advantage to ruling out UTF-16. As =20 >for your stated disadvantage, which XML parsers pass raw bytes to the =20 >application instead of a common format? Admittedly there are gobs of =20 >XML parsers out there, but I've never seen one that does this. Note that e.g. RFC 3920 defines exactly this restriction. --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 09 06:29:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvvDU-00009r-5e; Mon, 09 Jan 2006 06:29:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvvDS-00009M-Le for simple@megatron.ietf.org; Mon, 09 Jan 2006 06:29:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06996 for ; Mon, 9 Jan 2006 06:28:15 -0500 (EST) Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvvJv-0001JN-Rk for simple@ietf.org; Mon, 09 Jan 2006 06:36:16 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp6.clb.oleane.net with ESMTP id k09BTDDX018617 for ; Mon, 9 Jan 2006 12:29:14 +0100 Message-Id: <200601091129.k09BTDDX018617@smtp6.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 9 Jan 2006 12:28:15 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcYVD8gmN9UYjWAAS3+GIItGnv1V4Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Simple] TVoDSL Conference/Exhibition 2006 - Paris - France 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="===============0844404985==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0844404985== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05D9_01C61518.2A393B30" This is a multi-part message in MIME format. ------=_NextPart_000_05D9_01C61518.2A393B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The third edition of the TVoDSL conference/exhibition will start next January 24. It is still time to register to the very first worldwide event in the IPTV realm. Get all details at: http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm ------=_NextPart_000_05D9_01C61518.2A393B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The third edition = of the TVoDSL conference/exhibition will start next January 24.
It is still time to register to the very first = worldwide event in the IPTV realm.

Get all details = at:

http://w= ww.upperside.fr/tvodsl2006/tvodsl2006intro.htm

 

 

 

------=_NextPart_000_05D9_01C61518.2A393B30-- --===============0844404985== 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 --===============0844404985==-- From simple-bounces@ietf.org Mon Jan 09 06:52:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evva4-00056F-QL; Mon, 09 Jan 2006 06:52:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evva1-000562-1V for simple@megatron.ietf.org; Mon, 09 Jan 2006 06:52:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08476 for ; Mon, 9 Jan 2006 06:51:33 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvvgU-0001ya-1Z for simple@ietf.org; Mon, 09 Jan 2006 06:59:35 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k09BmNBN027139; Mon, 9 Jan 2006 13:48:26 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 13:52:45 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Jan 2006 13:52:45 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k09Bqjl02383; Mon, 9 Jan 2006 13:52:45 +0200 (EET) Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id EDC8793BA5; Mon, 9 Jan 2006 13:52:44 +0200 (EET) Message-ID: <43C24E52.5020603@nokia.com> Date: Mon, 09 Jan 2006 13:51:46 +0200 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Anat Angel Subject: Re: [Simple] draft-ietf-simple-xml-patch-ops-00 - question regarding schema References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2006 11:52:45.0998 (UTC) FILETIME=[34BCACE0:01C61513] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Anat Angel wrote: >Hi > > > >Can you please clarify what is the expected behavior in the following >case (for example): > > ... ? > > > >According to the schema, this expression is legal. > > > >Thanks, > >Anat. > > > > This is a good point, the positional selection is a leftover, so it will be removed from the next version (text node patching will be removed as well) . The positional selection is not needed as it overlaps e.g. with pos="before/after" selection. Also it may be very messy to implement because some libraries separate text nodes and CDATA nodes from each other making selections unnecessary complex. Also the model isn't very consistent in this case. thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 09 10:06:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvybT-0000tU-VJ; Mon, 09 Jan 2006 10:06:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvybQ-0000sQ-Cc for simple@megatron.ietf.org; Mon, 09 Jan 2006 10:06:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20189 for ; Mon, 9 Jan 2006 10:05:13 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evyhu-0007O1-Tu for simple@ietf.org; Mon, 09 Jan 2006 10:13:16 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k09F218g032200; Mon, 9 Jan 2006 17:02:02 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 17:06:17 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Jan 2006 17:06:18 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k09F6Gl10504; Mon, 9 Jan 2006 17:06:16 +0200 (EET) Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id 19A0C93B82; Mon, 9 Jan 2006 17:06:16 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id 032B42E3; Mon, 9 Jan 2006 17:06:15 +0200 (EET) Subject: Re: [Simple] XCAP proposal on conditional inserts From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <43B45720.8090007@cisco.com> References: <43B45720.8090007@cisco.com> Content-Type: text/plain Date: Mon, 09 Jan 2006 17:06:15 +0200 Message-Id: <1136819175.3341.76.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2006 15:06:18.0143 (UTC) FILETIME=[3E1D62F0:01C6152E] X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Thu, 2005-12-29 at 16:37 -0500, ext Jonathan Rosenberg wrote: > At the last IETF meeting, I raised the possibility of fixing the current > conditional insert problem as another change to make to the spec while > we are editing it. The problem, to refresh everyones memory, is that > HTTP (and thus XCAP) allows for conditional operations on a resource > only if the resource being operated on exists. Thats because if it > doesn't exist, it doesn't have an etag. So, you can't insert an element > conditioned on the etag of the entire document and all of its components. > > So, if you really mean to insert this thing ONLY if the document is > unchanged, you'll need to do the insert "blindly", and then after its > done, you'll find out whether or not the insert was done against the > version you intended. If so, great. If not, you need to somehow undo the > change you just made. > > This is far from ideal, but a known issue, and documented in the spec > today. I've been increasingly concerned that this is just not going to > work well, as it substantially raises the bar for getting the system to > work reliably. > > I made a proposal at IETF to fix it, and some good comments were > provided. Based on that, here is my modified proposal for how to fix > this issue. > > An XCAP resource representing an XML element in a document is said to > exist if the element appears in the document, OR its parent appears in > the document. If the XCAP resource exists but doesn't appear in the > document, it is said to be empty. So, for example: > > > > > > test/el1 exists and isn't empty. test/el1/el2 exists but is empty. > test/el1/blah-blah exists but is empty. In fact, every single potential > child element of el1 exists - they're just all empty. Because they exist, > they all have etags, which are all equal to the document etag. Based on > this definition, I can now go and insert a new element, which isn't > technically an insertion, but rather a modification: I'm modifying the > element to change it from empty to a specific value. > > This does not apply to attributes, however. An attribute exists only if > its physically present in the document (the difficulty in getting this > mechanism to work with attributes was one of the issues raised at ietf). > > Now, there are some actual consequences to this change in definition: > > * A GET against one of these empty resources will not return a 404 as it > does today. Rather, it would return a 200 OK, with a Content-Type of > application/xcap-el+xml and a Content-Length of zero. This indicates > that the resource is empty. > > So, based on the above example, GET test/el1/foobar would return a 200 > OK with Content-Length zero. > > * A GET against an element which doesnt exist WOULD return a 404. So, > for example, a GET of test/el1/foobar/nothere would return 404. > > * A DELETE of an element would be forbidden, and always return a 405. To > delete an element, you need to modify it to be empty. So, you'd do a PUT > with a Content-Length of 0. > > * We would no longer have a way to say, "insert this element into the > document if the element is not currently present in the document". In > the current spec, this is done by a PUT with If-None-Match: *. However, > with the proposed change, this condition would always fail, since the > element will now always exist. What we gain instead is the ability to > insert conditionally based on whether the document on the server matches > the one cached by the client. > > * There would no longer be a need for the xcap-diff document that is > returned in a 202 Created response. The reason this xcap-diff document > gets sent is to let the client know what the etag was prior to > insertion, so if it didn't match the cached copy, the client could try > to repair the error. Eliminating the need for this would remove the > dependency on xcap-diff, xml-patch-ops, and so on. > I'd truly love to see conditional inserts, However, having "empty" elements from xml pov is really weird. Also after an element delete, the response should contain the doc ETag (or the parent element ETag) so that conditional operations could be used easily and consistently (and dependency to xcap-diff, etc. can be dropped). > > It is tempting to take a slightly different approach. Call the approach > above "approach 1". The idea with approach 2 is to declare that, even > though a resource doesn't exist, it has an etag, and that etag is equal > to the document's etag, assuming the document does exist. Approach 2 > would work much like approach 1, except that: > > * A GET against a non-existent resource would be a 404, rather than a > 200 OK with CL of zero > > * A DELETE would be allowed > > Note however, that with approach 2, you still cannot support the > operation that says, "insert this but only if this element doesn't > already exist in the document". Approach 2 has the problem that it > seriously bends (and possibly breaks), an underlying http assumption > about the scope and meaning of etags. That might have odd and > unpredicatable interactions with caching systems and other http > intermediaries. For this reason, I wouldn't recommend it. > approach 2 is what I implemented first. If-None-Match: * was not in a usage scope at all. Certainly there are (some) twisting of http ETags in this case (or using ETags of different resources). However, as said, approach 1 does the same thing to xml which is imo worse than approach 2. The need for caching of XCAP resources is imo rare (tls used or authenticated requests mostly) and error prone (interdependencies). Unpredictable interactions might appear with delete, but only with broken proxies with put, I'd assume ? > So, I would like to make the concrete proposal of moving to approach 1. > The main drawback I see is the loss of the ability to insert an element > if an element with that same name/attribute already exist. > > Comments? > > -Jonathan R. > > So this issue is all about what's an xcap resource ?. As e.g. Lisa has noted that moving all selections to the query parameter would be more compatible with WebDAV (also locking). However, rfc3986 says that query component contains non-hierarchical data. So all in all some bending/twisting seems to be needed unless the current approach is used. So unfortunately there are several, far from prefect options, but I don't like approach 1. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 09 11:22:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzmT-0006jT-7g; Mon, 09 Jan 2006 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzmR-0006jA-BU for simple@megatron.ietf.org; Mon, 09 Jan 2006 11:21:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28747 for ; Mon, 9 Jan 2006 11:20:40 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evzsw-0002W4-R7 for simple@ietf.org; Mon, 09 Jan 2006 11:28:44 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k09G38sU016909; Mon, 9 Jan 2006 18:03:09 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 18:03:05 +0200 Received: from [10.162.253.215] ([10.162.253.215]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Jan 2006 18:03:05 +0200 Message-ID: <43C28939.6070704@nokia.com> Date: Mon, 09 Jan 2006 18:03:05 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] XCAP proposal on conditional inserts References: <43B45720.8090007@cisco.com> In-Reply-To: <43B45720.8090007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2006 16:03:05.0954 (UTC) FILETIME=[2D541420:01C61536] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Jonathan, ext Jonathan Rosenberg wrote: > It is tempting to take a slightly different approach. Call the approach > above "approach 1". The idea with approach 2 is to declare that, even > though a resource doesn't exist, it has an etag, and that etag is equal > to the document's etag, assuming the document does exist. Approach 2 > would work much like approach 1, except that: > > * A GET against a non-existent resource would be a 404, rather than a > 200 OK with CL of zero > > * A DELETE would be allowed > > Note however, that with approach 2, you still cannot support the > operation that says, "insert this but only if this element doesn't > already exist in the document". I think that's OK. The most important thing is the ability to be safe from modifying an element someone else PUT in the meantime, by doing an insert. I think clients will in most cases work with cached copies anyway. And it's enough to be able to condition changes to the entire document using the etags, not so much of single elements. > Approach 2 has the problem that it > seriously bends (and possibly breaks), an underlying http assumption > about the scope and meaning of etags. That might have odd and > unpredicatable interactions with caching systems and other http > intermediaries. For this reason, I wouldn't recommend it. But XCAP already instructs clients to use the no-cache directive, and probably PUTs are anyway authenticated. These should be quite strong indicators to any HTTP intermediaries that they should not cache these XCAP requests. > So, I would like to make the concrete proposal of moving to approach 1. > The main drawback I see is the loss of the ability to insert an element > if an element with that same name/attribute already exist. > > Comments? I like approach 2. In an ideal world, I'd prefer the node-selector as a query string (as discussed back in Nov 04), but I can live with approach 2 since it demonstrates similar good properties like returning a 404 for a non-existent node. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 09 22:03:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9nW-0004Ov-C6; Mon, 09 Jan 2006 22:03:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9nU-0004Nr-6l for simple@megatron.ietf.org; Mon, 09 Jan 2006 22:03:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25486 for ; Mon, 9 Jan 2006 22:02:25 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew9u4-0000iv-Ig for simple@ietf.org; Mon, 09 Jan 2006 22:10:35 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISU00BGJWP1YR@szxga01-in.huawei.com> for simple@ietf.org; Tue, 10 Jan 2006 11:07:49 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISU00FNLWP1BA@szxga01-in.huawei.com> for simple@ietf.org; Tue, 10 Jan 2006 11:07:49 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISU0063SWY361@szxml01-in.huawei.com> for simple@ietf.org; Tue, 10 Jan 2006 11:13:15 +0800 (CST) Date: Tue, 10 Jan 2006 10:58:35 +0800 From: Xiao Wang To: "'Simple WG'" Message-id: <00ad01c61591$bfc70410$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Subject: [Simple] comments of draft-ietf-simple-event-list-07 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="===============1077992399==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1077992399== Content-type: multipart/alternative; boundary="Boundary_(ID_VaJmH9W0rqsEVMtlQH3faA)" This is a multi-part message in MIME format. --Boundary_(ID_VaJmH9W0rqsEVMtlQH3faA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hello, all There has some doubt need to clarify. 1. How to do with the failure responses of a resource in resource list by RLS? Subscribe a single resource, notifier MAY return 4xx ---- 6xx, at this time notifier did not create subscription(refer to RFC3265),. 2. Why did allow contain zero in XML Syntax? My understanding is the sip uri which point to the resource list in server may be zero. Is right? 3. About RLS Foking, I think if not any requirements or applications need it, maybe not allow Forking result send to UA, that is so complex to forking and how to free dialog by fork with UA. Xiao --Boundary_(ID_VaJmH9W0rqsEVMtlQH3faA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hello, all

 

There has some doubt need to clarify.

 

1.       How to do with the failure responses of a resource in resource list by RLS?

Subscribe a single resource, notifier MAY return 4xx ---- 6xx,

at this time notifier did not create subscription(refer to RFC3265),.

 

2.  Why did allow contain zero <resource> in XML Syntax?

         My understanding is the sip uri which point to the resource list in server may be zero. Is right?

 

3.       About RLS Foking, I think if not any requirements or applications need it, maybe not allow Forking

result send to UA, that is so complex to forking and how to free dialog by fork with UA.

 

 

 

Xiao

 

--Boundary_(ID_VaJmH9W0rqsEVMtlQH3faA)-- --===============1077992399== 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 --===============1077992399==-- From simple-bounces@ietf.org Tue Jan 10 06:56:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwI6c-00069l-L2; Tue, 10 Jan 2006 06:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwI6b-00068e-5Y for simple@megatron.ietf.org; Tue, 10 Jan 2006 06:56:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24555 for ; Tue, 10 Jan 2006 06:54:39 -0500 (EST) From: Amitkumar.Goel@infineon.com Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwIDC-0006FM-E1 for simple@ietf.org; Tue, 10 Jan 2006 07:02:54 -0500 Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149]) by smtp3.infineon.com with ESMTP; 10 Jan 2006 19:55:41 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse211.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Jan 2006 19:55:41 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jan 2006 17:25:40 +0530 Message-ID: Thread-Topic: MSRP Report Model Thread-Index: AcYV3Mby4x2pHkW8R0arSrCsjVwWpg== To: X-OriginalArrivalTime: 10 Jan 2006 11:55:41.0395 (UTC) FILETIME=[C7B1E230:01C615DC] X-Spam-Score: 0.4 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Simple] MSRP Report Model 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="===============1913549356==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1913549356== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C615DC.C6F55E6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C615DC.C6F55E6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 This is regarding MSRP Report Model. MSRP draft says receiver MUST send REPORT (success/failure) depending upon the "Success-Report" and "Failure-Report" header field values in the SEND request. But in case receiver does not want to generate the reports, there should be a way /some ways of indicating the same (may be this was already discussed earlier, but I am not aware of). There can be many reasons for the receiver not to generate REPORT for incoming SEND request.=20 =20 1. Congestion on the receiver side =20 2. Service Provider may charge for per unit data transferred.=20 3. Due to some security or privacy reason =20 We MAY consider two solutions: 1. Negotiate Sending Reports during session setup and/or 2. Sender may be informed via transaction status messages indicating that receiver shall not generate the report. =20 =20 Regards, Amit Kumar Goel Infineon Technology, Bangalore ------_=_NextPart_001_01C615DC.C6F55E6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi All,
 
This=20 is regarding MSRP Report Model. MSRP draft says receiver  MUST send REPORT  (success/failure) depending = upon=20 the "Success-Report" and "Failure-Report" header field values in = the SEND=20 request.  But in case receiver does not want to generate the  reports, there should be a  way /some ways of = indicating the=20 same (may be this was already discussed = earlier,=20 but I am not aware of). There can be = many=20 reasons  for the = receiver not to=20 generate REPORT for incoming SEND request. =
 
1. Congestion on the = receiver=20 side  
2. Service Provider may charge for = per unit=20 data transferred. 
3. Due to some security or privacy=20 reason
 
We MAY consider=20 two solutions:
1. = Negotiate Sending=20 Reports during session setup and/or
2. Sender may be informed via transaction status messages indicating  that receiver shall not generate=20 the report.
 
 
Regards,
Amit Kumar Goel
Infineon=20 Technology,
Bangalore
------_=_NextPart_001_01C615DC.C6F55E6E-- --===============1913549356== 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 --===============1913549356==-- From simple-bounces@ietf.org Tue Jan 10 08:02:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwJ9F-0004gs-H2; Tue, 10 Jan 2006 08:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwJ9D-0004gE-Go for simple@megatron.ietf.org; Tue, 10 Jan 2006 08:02:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28895 for ; Tue, 10 Jan 2006 08:01:27 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwJFu-0008HT-VN for simple@ietf.org; Tue, 10 Jan 2006 08:09:43 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0AD0nHM005777; Tue, 10 Jan 2006 15:00:51 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 15:02:39 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 15:02:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] WGLC: User Agent Capability Extension to PIDF (prescaps) Date: Tue, 10 Jan 2006 15:02:38 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F01D15BA2@esebe103.NOE.Nokia.com> In-Reply-To: Thread-Topic: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps) Thread-Index: AcX3M7PPG7hMCvBAT16HHhd/kjWQxALYyJNABNHXaRA= To: X-OriginalArrivalTime: 10 Jan 2006 13:02:39.0066 (UTC) FILETIME=[2269D3A0:01C615E6] X-Spam-Score: 0.3 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable Cc: krisztian.kiss@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, Thanks Mary for very detailed review.=20 Comments inline: > >Potential issues: >---------------- > >- Section 8. How do the security considerations discussed in RFC 3840=20 >apply to the use of these feature tags in the PIDF? >You have one general statement in the 2nd sentence of the first=20 >paragraph and this would seem a good place to discuss this. Regarding the considerations for media feature tags ID only references existing media feature tags and so I don't think that discussion should be repeated. I think we could add a sentence saying that if PUA is going to reveal sensitive information about the presentity it should obtain permission from the user. Proposal: " If the PUA is publishing sensitive information using this extension, it SHOULD obtain a permission from a user. =20 " >- Section 8. You have as a SHOULD stength the use of a transport=20 >protocol that provides some level of protection, however, what's the=20 >impact if such a protocol is not used? Ok, how about adding follow text: " If such security measures are not used, eavesdroppers can learn sensitive information about the user. It may be possible for a third party to modify the user's presence information. This can lead to a situation that users receiving presentity's presence information can take incorrect actions based on false information. " >Editorial nits: >--------------- > >- Title: Although the title is already quite long, I would think it=20 >would be useful to have SIP in there (i.e. Session Initiation Protocol >(SIP) User Agent Capability Extension to Presence Information Data=20 >Format (PIDF)) Yes, makes it bit long but I am fine in adding it. >- Abstract: again, I think SIP should be mentioned somewhere in the=20 >abstract. Actually, I think you can replace the use of "RFC3840" in=20 >the >abstract with "SIP user agent". This is consistent with not using >references to the IMPP RFCs in the abstract, as well.=20 Ok, will do >- Introduction, 1st para, 6th sentence: insert "a" between "taken" and=20 >"very", i.e. the sentence should read: > "It has taken a very minimalistic approach to support such=20 >operations." ok >- Introduction, 1st para, last sentence. I would suggest to replace=20 >the reference to "RFC3863" to "PIDF", as you did earlier in the=20 >paragraph for reference [4]. It's confusing to have a combination of=20 >ways for referring to the same document in this document. For readers=20 >that aren't as familiar with this area, it could be confusing. ok >- Section 1.1, page 4, 4th sentence. "represent" should be=20 >"represents" Ok >- Section 1.1, page 5, last para of that section: "would contained" >should be either "would contain" or "contained". ok >- Section 3.2.1, page 6, 3rd sentence: "This element can=20 >contain following..." should be changed to normative language=20 >"This element MAY contain any of the following..." (I'm=20 >assuming this rewording keeps the same intent?) If I remember correctly there was some time ago a discussion that we should not use duplicate normative statements. This is already normative in XML schema. Using MAY here would only duplicate that. >- Section 3.2.9, 2nd para, page 8: the reference to the MIME=20 >spec [19] seems normative to this document, but it's listed as=20 >an informative reference. Shouldn't it be a normative dependency? =20 Right, will be fixed >- Section 3.2.11, last para, page 9: The sentence on IANA=20 >registration is a bit awkward. I would suggest rewording FROM:=20 >" Any value that is register to IANA to SIP Media Feature Tag > Registration Tree as sip.class media feature tag can be used as a > value of an extension element. If appropriate value is not > registered it SHOULD be registed as defined in RFC3840 [6]." >TO: > "Any value that is registered with IANA for the SIP Media Feature Tag > Registration Tree as a sip.class media feature tag can be used as a > value of an extension element. If the appropriate value is not > registered it SHOULD be registed as defined in RFC3840 [6]. ok >- General comment: the previous comment also applies to=20 >sections 3.2.12 and 3.2.19 ok >- section 3.2.12, page 9, 1st para: "can only receive..."=20 >should be "only receive" for consistency with the rest of the=20 >parts of that sentence. ok >- Sections 3.2.14 and 3.2.16, last paragraph. The sentence on=20 >IANA registration should change from:=20 >" Any value that is register to IANA to SIP Event types namespace > registry can be used as a value of an extension element." >to: >" Any value that is registered with IANA for the SIP Event=20 >types namespace > registry can be used as a value of an extension element." ok >- Section 3.2.15.3: I would remove the "Value of" from the=20 >following sentence (or preface the sentence with "The"): > "Value of the "value" attribute is > used to indicate the exact supported priority value. ok >- Section 3.2.17, 3rd paragraph, page 10: add "" to=20 >thie list of elements.=20 ok >- Section 3.3, 1st paragraph, 1st sentence: add "the" before "dynamic" >and "PIDF"=20 ok >- Section 3.3, 2nd paragraph: there seems to be a formatting=20 >problem with the namespace identifier (i.e. shouldn't the=20 >"urn:" be part of the >element?) Yes, it should >- Section 3.3.2, 1st paragraph, 1st sentence: "point or=20 >contact" should be "point of contact" (2nd occurrence). ok >- Section 3.3.2, 1ast paragraph, last sentence: "If appropriate..." >should be "If the appropriate..." ok - Mikko > >Mary > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 10 09:30:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKVk-00020d-Bs; Tue, 10 Jan 2006 09:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKVh-00020X-Ol for simple@megatron.ietf.org; Tue, 10 Jan 2006 09:30:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06652 for ; Tue, 10 Jan 2006 09:28:45 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwKcQ-0002yR-Cb for simple@ietf.org; Tue, 10 Jan 2006 09:37:02 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2006 09:29:51 -0500 X-IronPort-AV: i="3.99,351,1131339600"; d="scan'208"; a="79908825:sNHT33307716" 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 k0AETj6L004148; Tue, 10 Jan 2006 09:29:49 -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.211); Tue, 10 Jan 2006 09:29:54 -0500 Received: from [161.44.79.59] ([161.44.79.59]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 09:29:47 -0500 Message-ID: <43C3C4DA.9010708@cisco.com> Date: Tue, 10 Jan 2006 09:29:46 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com Subject: Re: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps) References: <8B1D53AEF7B03449A6D3771B3B7F850F01D15BA2@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F01D15BA2@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2006 14:29:47.0834 (UTC) FILETIME=[4F0081A0:01C615F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: krisztian.kiss@nokia.com, mary.barnes@nortel.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org mikko.lonnfors@nokia.com wrote: >>- Section 8. How do the security considerations discussed in RFC 3840 >>apply to the use of these feature tags in the PIDF? They don't. The security considerations in 3840 really speak to the various contexts in which callee capability feature tags, attached to Contact headers, may move around in SIP messages. There really is no meaningful discussion of the security issues of any particular feature tag - just a general discussion of treating all feature tags in the aggregate as sensitive data. In the context of the current draft, the feature tags of 3840 become generalized presence elements. There are already sufficient security considerations regarding the sensitive nature of presence data in general. I don't see how adding more generalities would be helpful. IMO, taken as a whole, the prescaps elements cannot be said to present any new issues over the elements introduced in RPIDS. This is complicated by the fact that PIDF and its extensions is simply a data format that may be used in many places. One can start to enumerate those places (e.g. PUBLISH and NOTIFY) but the list will always be partial. I believe the security considerations regarding presence information should be dealt with as a whole, not piecemeal. Paul >>You have one general statement in the 2nd sentence of the first >>paragraph and this would seem a good place to discuss this. > > Regarding the considerations for media feature tags ID only references > existing media feature tags and so I don't think that discussion should > be repeated. > I think we could add a sentence saying that if PUA is going to reveal > sensitive information about the presentity it should obtain permission > from the user. > > Proposal: > " > If the PUA is publishing sensitive information using this extension, it > SHOULD obtain a permission from a user. > " _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 10 18:14:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSgy-00041j-Dz; Tue, 10 Jan 2006 18:14:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSgw-00041c-Ip for simple@megatron.ietf.org; Tue, 10 Jan 2006 18:14:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18090 for ; Tue, 10 Jan 2006 18:12:55 -0500 (EST) From: krisztian.kiss@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSnj-0003uG-N1 for simple@ietf.org; Tue, 10 Jan 2006 18:21:16 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0ANCDOh013099; Wed, 11 Jan 2006 01:12:16 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 01:14:09 +0200 Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 17:14:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] XCAP proposal on conditional inserts Date: Tue, 10 Jan 2006 15:14:03 -0800 Message-ID: In-Reply-To: <43C28939.6070704@nokia.com> Thread-Topic: [Simple] XCAP proposal on conditional inserts Thread-Index: AcYVO8ng6vA+iamIR2SQVOZy8FKz2gA9knwQ To: , X-OriginalArrivalTime: 10 Jan 2006 23:14:06.0265 (UTC) FILETIME=[8DB02290:01C6163B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi All, Without adding further support for one or the other proposed approach, I just want to point out the urgent need to solve this (and other outstanding) issue(s) related to XCAP. Specifications in other foras (like OMA) are dependent on the simple-xcap draft and waiting for xcap to change back to RFC Ed queue status. Thanks, Krisztian >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of ext Aki Niemi >Sent: Monday, January 09, 2006 8:03 AM >To: ext Jonathan Rosenberg >Cc: Simple WG >Subject: Re: [Simple] XCAP proposal on conditional inserts > >Hi Jonathan, > >ext Jonathan Rosenberg wrote: >> It is tempting to take a slightly different approach. Call the=20 >> approach above "approach 1". The idea with approach 2 is to declare=20 >> that, even though a resource doesn't exist, it has an etag, and that=20 >> etag is equal to the document's etag, assuming the document does=20 >> exist. Approach 2 would work much like approach 1, except that: >>=20 >> * A GET against a non-existent resource would be a 404,=20 >rather than a=20 >> 200 OK with CL of zero >>=20 >> * A DELETE would be allowed >>=20 >> Note however, that with approach 2, you still cannot support the=20 >> operation that says, "insert this but only if this element doesn't=20 >> already exist in the document". > >I think that's OK. The most important thing is the ability to=20 >be safe from modifying an element someone else PUT in the=20 >meantime, by doing an insert. I think clients will in most=20 >cases work with cached copies anyway. And it's enough to be=20 >able to condition changes to the entire document using the=20 >etags, not so much of single elements. > >> Approach 2 has the problem that it >> seriously bends (and possibly breaks), an underlying http assumption=20 >> about the scope and meaning of etags. That might have odd and=20 >> unpredicatable interactions with caching systems and other http=20 >> intermediaries. For this reason, I wouldn't recommend it. > >But XCAP already instructs clients to use the no-cache=20 >directive, and probably PUTs are anyway authenticated. These=20 >should be quite strong indicators to any HTTP intermediaries=20 >that they should not cache these XCAP requests. > >> So, I would like to make the concrete proposal of moving to=20 >approach 1.=20 >> The main drawback I see is the loss of the ability to insert an=20 >> element if an element with that same name/attribute already exist. >>=20 >> Comments? > >I like approach 2. In an ideal world, I'd prefer the=20 >node-selector as a query string (as discussed back in Nov 04),=20 >but I can live with approach >2 since it demonstrates similar good properties like returning=20 >a 404 for a non-existent node. > >Cheers, >Aki > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 11 07:05:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwejJ-0008Tc-8N; Wed, 11 Jan 2006 07:05:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwejH-0008Sb-JT for simple@megatron.ietf.org; Wed, 11 Jan 2006 07:05:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06088 for ; Wed, 11 Jan 2006 07:04:07 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EweqB-0000C0-Bq for simple@ietf.org; Wed, 11 Jan 2006 07:12:35 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0BC5KTZ004113 for ; Wed, 11 Jan 2006 06:05:21 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Jan 2006 12:05:20 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290743@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: simple@ietf.org Subject: RE: [Simple] XCAP proposal on conditional inserts Date: Wed, 11 Jan 2006 12:05:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I concur - we need the fix now and the document back in approval. regards Keith > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of krisztian.kiss@nokia.com > Sent: 10 January 2006 23:14 > To: jdrosen@cisco.com; simple@ietf.org > Subject: RE: [Simple] XCAP proposal on conditional inserts > > > Hi All, > > Without adding further support for one or the other proposed > approach, I > just want to point out the urgent need to solve this (and other > outstanding) issue(s) related to XCAP. Specifications in other foras > (like OMA) are dependent on the simple-xcap draft and waiting for xcap > to change back to RFC Ed queue status. > > Thanks, > Krisztian > > >-----Original Message----- > >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > >On Behalf Of ext Aki Niemi > >Sent: Monday, January 09, 2006 8:03 AM > >To: ext Jonathan Rosenberg > >Cc: Simple WG > >Subject: Re: [Simple] XCAP proposal on conditional inserts > > > >Hi Jonathan, > > > >ext Jonathan Rosenberg wrote: > >> It is tempting to take a slightly different approach. Call the > >> approach above "approach 1". The idea with approach 2 is > to declare > >> that, even though a resource doesn't exist, it has an > etag, and that > >> etag is equal to the document's etag, assuming the document does > >> exist. Approach 2 would work much like approach 1, except that: > >> > >> * A GET against a non-existent resource would be a 404, > >rather than a > >> 200 OK with CL of zero > >> > >> * A DELETE would be allowed > >> > >> Note however, that with approach 2, you still cannot support the > >> operation that says, "insert this but only if this element doesn't > >> already exist in the document". > > > >I think that's OK. The most important thing is the ability to > >be safe from modifying an element someone else PUT in the > >meantime, by doing an insert. I think clients will in most > >cases work with cached copies anyway. And it's enough to be > >able to condition changes to the entire document using the > >etags, not so much of single elements. > > > >> Approach 2 has the problem that it > >> seriously bends (and possibly breaks), an underlying http > assumption > >> about the scope and meaning of etags. That might have odd and > >> unpredicatable interactions with caching systems and other http > >> intermediaries. For this reason, I wouldn't recommend it. > > > >But XCAP already instructs clients to use the no-cache > >directive, and probably PUTs are anyway authenticated. These > >should be quite strong indicators to any HTTP intermediaries > >that they should not cache these XCAP requests. > > > >> So, I would like to make the concrete proposal of moving to > >approach 1. > >> The main drawback I see is the loss of the ability to insert an > >> element if an element with that same name/attribute already exist. > >> > >> Comments? > > > >I like approach 2. In an ideal world, I'd prefer the > >node-selector as a query string (as discussed back in Nov 04), > >but I can live with approach > >2 since it demonstrates similar good properties like returning > >a 404 for a non-existent node. > > > >Cheers, > >Aki > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 11 11:06:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiUP-00078m-L5; Wed, 11 Jan 2006 11:06:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiUN-00078I-Bs for simple@megatron.ietf.org; Wed, 11 Jan 2006 11:06:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22580 for ; Wed, 11 Jan 2006 11:04:59 -0500 (EST) Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwibG-0007Pz-Qa for simple@ietf.org; Wed, 11 Jan 2006 11:13:29 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp3.clb.oleane.net with ESMTP id k0BG5xpQ016457 for ; Wed, 11 Jan 2006 17:06:05 +0100 Message-Id: <200601111606.k0BG5xpQ016457@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 11 Jan 2006 17:05:03 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYWyMfr4DEEOYdBTpOKywNMlhPigA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [Simple] International SIP Conference / WiMAX Summit 2006 - Paris - France 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="===============1364997273==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1364997273== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0331_01C616D1.2A0CB690" This is a multi-part message in MIME format. ------=_NextPart_000_0331_01C616D1.2A0CB690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The International SIP conference and the WiMAX Summit will start next February 21st in Paris. The two events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access. The early registration 10% discount will end in one week. Get all details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get all details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0331_01C616D1.2A0CB690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 The = International SIP conference and the WiMAX Summit will start next February 21st in Paris. The two events are = co-organised and will bring any necessary information on VoIP, mobility convergence and = wireless broadband access.

 

The early registration 10% discount will end = in one week.

 

Get all details on International SIP = at:

http://www.upp= erside.fr/sip2006/sip2006intro.htm

 

Get all details on the WiMAX Summit = at:

http://www= .upperside.fr/wimax2006/wimax2006intro.htm

 

 

 

------=_NextPart_000_0331_01C616D1.2A0CB690-- --===============1364997273== 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 --===============1364997273==-- From simple-bounces@ietf.org Wed Jan 11 13:15:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkVL-0000yh-3h; Wed, 11 Jan 2006 13:15:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkVI-0000wl-HP for simple@megatron.ietf.org; Wed, 11 Jan 2006 13:15:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01467 for ; Wed, 11 Jan 2006 13:14:04 -0500 (EST) 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 1EwkcE-0002xv-EQ for simple@ietf.org; Wed, 11 Jan 2006 13:22:35 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2006 10:15:13 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0BIFCjt016022; Wed, 11 Jan 2006 10:15:12 -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.211); Wed, 11 Jan 2006 13:15:12 -0500 Received: from [161.44.55.129] ([161.44.55.129]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 13:15:12 -0500 Message-ID: <43C54B2F.9050103@cisco.com> Date: Wed, 11 Jan 2006 13:15:11 -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: "Hu Bo \(Cory\), SLC COM CD/MN R&D Core \(BJ\)" Subject: Re: [Simple] XCAP proposal on conditional inserts References: <8E1B3F00C246044D90C9100CCDBB43E70120D01E@PEKW910A.cn001.siemens.net> In-Reply-To: <8E1B3F00C246044D90C9100CCDBB43E70120D01E@PEKW910A.cn001.siemens.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 18:15:12.0082 (UTC) FILETIME=[F67EBB20:01C616DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Responses inline. Hu Bo (Cory), SLC COM CD/MN R&D Core (BJ) wrote: > Hi,Jonathan, > > My question is: > How could client tell if the state("empty" or "not empty") of an element is synchronized with server? > > if a client has a cache like: > > 1 > 2 > > While server has > > 1 > > Then client make a creation for el1[3] > PUT test/el1[3] with > 3 > My understanding is: Without conditional insert, old xcap will fail this attemp. By new definition it will succeed. In the current model, this request will succeed if it is not conditioned. If its conditioned based on a wildcard etag (*) or the current document etag, then in the current model it would fail. In the proposed model, the request would succeed if it is not conditioned. If it is conditioned based on the wildcard etag or the current document etag, it would succeed. For other etag values it would fail. > Now the server copy is: > > 1 //index 1 > 3 //index 3 > No - 2 should still be there. > How to modify the index "3" element? PUT test/el1[2] OR PUT test/el1[3]? Assuming you start with the document above (which, as I said, would not be whats there), it would be PUT test/el1[2]. > I propose approach 1 working with some limitation like: > For client and server, there shouldn't be an understanding that an empty element is present unless it's the last one under an existing parent. > That would mean: > 1.Insert of an element after an empty one is not allowed. Right. This is true in the current spec. > 2.deletion of an element will shift the index up. I'm not sure what you mean by "index". -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 Thu Jan 12 13:18:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex71z-0001kf-Jl; Thu, 12 Jan 2006 13:18:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex71x-0001kL-Mx for simple@megatron.ietf.org; Thu, 12 Jan 2006 13:18:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05044 for ; Thu, 12 Jan 2006 13:17:16 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex797-0003tE-9r for simple@ietf.org; Thu, 12 Jan 2006 13:26:01 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0CIIPP25612; Thu, 12 Jan 2006 13:18:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps) Date: Thu, 12 Jan 2006 12:18:24 -0600 Message-ID: Thread-Topic: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps) Thread-Index: AcX3M7PPG7hMCvBAT16HHhd/kjWQxALYyJNABNHXaRAAcZJ6AA== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Cc: krisztian.kiss@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Your proposed changes look fine to me.=20 Mary -----Original Message----- From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com]=20 Sent: Tuesday, January 10, 2006 7:03 AM To: Barnes, Mary [RICH2:B601:EXCH] Cc: simple@ietf.org; krisztian.kiss@nokia.com Subject: RE: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps) Hi, Thanks Mary for very detailed review.=20 Comments inline: > >Potential issues: >---------------- > >- Section 8. How do the security considerations discussed in RFC 3840=20 >apply to the use of these feature tags in the PIDF? >You have one general statement in the 2nd sentence of the first=20 >paragraph and this would seem a good place to discuss this. Regarding the considerations for media feature tags ID only references existing media feature tags and so I don't think that discussion should be repeated. I think we could add a sentence saying that if PUA is going to reveal sensitive information about the presentity it should obtain permission from the user. Proposal: " If the PUA is publishing sensitive information using this extension, it SHOULD obtain a permission from a user. =20 " >- Section 8. You have as a SHOULD stength the use of a transport=20 >protocol that provides some level of protection, however, what's the=20 >impact if such a protocol is not used? Ok, how about adding follow text: " If such security measures are not used, eavesdroppers can learn sensitive information about the user. It may be possible for a third party to modify the user's presence information. This can lead to a situation that users receiving presentity's presence information can take incorrect actions based on false information. " >Editorial nits: >--------------- > >- Title: Although the title is already quite long, I would think it=20 >would be useful to have SIP in there (i.e. Session Initiation Protocol >(SIP) User Agent Capability Extension to Presence Information Data=20 >Format (PIDF)) Yes, makes it bit long but I am fine in adding it. >- Abstract: again, I think SIP should be mentioned somewhere in the=20 >abstract. Actually, I think you can replace the use of "RFC3840" in=20 >the >abstract with "SIP user agent". This is consistent with not using >references to the IMPP RFCs in the abstract, as well.=20 Ok, will do >- Introduction, 1st para, 6th sentence: insert "a" between "taken" and=20 >"very", i.e. the sentence should read: > "It has taken a very minimalistic approach to support such=20 >operations." ok >- Introduction, 1st para, last sentence. I would suggest to replace=20 >the reference to "RFC3863" to "PIDF", as you did earlier in the=20 >paragraph for reference [4]. It's confusing to have a combination of=20 >ways for referring to the same document in this document. For readers=20 >that aren't as familiar with this area, it could be confusing. ok >- Section 1.1, page 4, 4th sentence. "represent" should be=20 >"represents" Ok >- Section 1.1, page 5, last para of that section: "would contained" >should be either "would contain" or "contained". ok >- Section 3.2.1, page 6, 3rd sentence: "This element can=20 >contain following..." should be changed to normative language=20 >"This element MAY contain any of the following..." (I'm=20 >assuming this rewording keeps the same intent?) If I remember correctly there was some time ago a discussion that we should not use duplicate normative statements. This is already normative in XML schema. Using MAY here would only duplicate that. >- Section 3.2.9, 2nd para, page 8: the reference to the MIME=20 >spec [19] seems normative to this document, but it's listed as=20 >an informative reference. Shouldn't it be a normative dependency? =20 Right, will be fixed >- Section 3.2.11, last para, page 9: The sentence on IANA=20 >registration is a bit awkward. I would suggest rewording FROM:=20 >" Any value that is register to IANA to SIP Media Feature Tag > Registration Tree as sip.class media feature tag can be used as a > value of an extension element. If appropriate value is not > registered it SHOULD be registed as defined in RFC3840 [6]." >TO: > "Any value that is registered with IANA for the SIP Media Feature Tag > Registration Tree as a sip.class media feature tag can be used as a > value of an extension element. If the appropriate value is not > registered it SHOULD be registed as defined in RFC3840 [6]. ok >- General comment: the previous comment also applies to=20 >sections 3.2.12 and 3.2.19 ok >- section 3.2.12, page 9, 1st para: "can only receive..."=20 >should be "only receive" for consistency with the rest of the=20 >parts of that sentence. ok >- Sections 3.2.14 and 3.2.16, last paragraph. The sentence on=20 >IANA registration should change from:=20 >" Any value that is register to IANA to SIP Event types namespace > registry can be used as a value of an extension element." >to: >" Any value that is registered with IANA for the SIP Event=20 >types namespace > registry can be used as a value of an extension element." ok >- Section 3.2.15.3: I would remove the "Value of" from the=20 >following sentence (or preface the sentence with "The"): > "Value of the "value" attribute is > used to indicate the exact supported priority value. ok >- Section 3.2.17, 3rd paragraph, page 10: add "" to=20 >thie list of elements.=20 ok >- Section 3.3, 1st paragraph, 1st sentence: add "the" before "dynamic" >and "PIDF"=20 ok >- Section 3.3, 2nd paragraph: there seems to be a formatting=20 >problem with the namespace identifier (i.e. shouldn't the=20 >"urn:" be part of the >element?) Yes, it should >- Section 3.3.2, 1st paragraph, 1st sentence: "point or=20 >contact" should be "point of contact" (2nd occurrence). ok >- Section 3.3.2, 1ast paragraph, last sentence: "If appropriate..." >should be "If the appropriate..." ok - Mikko > >Mary > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 13 04:00:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExKn9-0003EV-9g; Fri, 13 Jan 2006 04:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExKn8-0003EL-4D for simple@megatron.ietf.org; Fri, 13 Jan 2006 04:00:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14070 for ; Fri, 13 Jan 2006 03:58:51 -0500 (EST) Received: from david.sha.siemens.com.cn ([210.22.95.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExKuI-0001iu-Dv for simple@ietf.org; Fri, 13 Jan 2006 04:07:45 -0500 Received: from mail.sha.siemens.com.cn (mail.sha.siemens.com.cn [194.138.237.116]) by david.sha.siemens.com.cn (8.11.7/8.11.7) with ESMTP id k0D8xiO17631; Fri, 13 Jan 2006 16:59:45 +0800 (CST) Received: from pekw905a.cn001.siemens.net (localhost [127.0.0.1]) by mail.sha.siemens.com.cn (8.11.7/8.11.7) with ESMTP id k0D91Vt23676; Fri, 13 Jan 2006 17:01:31 +0800 (CST) Received: from PEKW910A.cn001.siemens.net ([139.24.236.125]) by pekw905a.cn001.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 16:59:15 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP proposal on conditional inserts Date: Fri, 13 Jan 2006 16:59:15 +0800 Message-ID: <8E1B3F00C246044D90C9100CCDBB43E7012DD03F@PEKW910A.cn001.siemens.net> Thread-Topic: [Simple] XCAP proposal on conditional inserts Thread-Index: AcYYH6Dxujvssd0cQJ2VsdmtLcrH1A== From: "Hu Bo \(Cory\), SLC COM CD/MN R&D Core \(BJ\)" To: "Jonathan Rosenberg" , "Simple WG" X-OriginalArrivalTime: 13 Jan 2006 08:59:15.0718 (UTC) FILETIME=[A1610260:01C6181F] X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks for response=20 I read again and guess my thought was that if the concept "empty elements" were imported in xcap model, that might confuse the existing understanding on client side. Please see some questions inline: >Jonathan Rosenberg wrote: > >Responses inline. > >Hu Bo (Cory), SLC COM CD/MN R&D Core (BJ) wrote: > >> Hi,Jonathan, >>=20 >> My question is: >> How could client tell if the state("empty" or "not empty")=20 >of an element is synchronized with server? >>=20 >> if a client has a cache like: >> >> 1 >> 2 >> >> While server has >> >> 1 >> >> Then client make a creation for el1[3] >> PUT test/el1[3] with >> 3 >> My understanding is: Without conditional insert, old xcap=20 >will fail this attemp. By new definition it will succeed. > >In the current model, this request will succeed if it is not=20 >conditioned.=20 In draft-ietf-simple-xcap-08 page 36 line 14: If a position is indicated, the server MUST insert the element so that it is in the "earliest nth" position. Earliest nth position means that it MUST be inserted so that there are n-1 elements before it with the same element name, and for all insertion positions where this is true, it is inserted such that as many sibling elements appear after it as possible. My understanding is the request PUT test/el1[3] will fail, if there's only one element under on server side. >If its conditioned based on a wildcard etag (*) or the=20 >current document etag, then in the current model it would fail. > >In the proposed model, the request would succeed if it is not=20 >conditioned. If it is conditioned based on the wildcard etag or the=20 >current document etag, it would succeed. For other etag values=20 >it would=20 >fail. > > >> Now the server copy is: >> >> 1 //index 1 >> 3 //index 3 >> > >No - 2 should still be there. How come? Assume we start with server document: 1 + request PUT test/el1[3] My understanding in the proposed model(approach 1) the result would be 1 //postion 1 //postion 2 there is an empty element 3 //postion 3 > >> How to modify the position "3" element? PUT test/el1[2] OR PUT=20 >test/el1[3]? > >Assuming you start with the document above (which, as I said,=20 >would not=20 >be whats there), it would be PUT test/el1[2]. > >> I propose approach 1 working with some limitation like: >> For client and server, there shouldn't be an understanding=20 >that an empty element is present unless it's the last one=20 >under an existing parent. >> That would mean: >> 1.Insert of an element after an empty one is not allowed. > >Right. This is true in the current spec. > >> 2.deletion of an element will shift the index up. > >I'm not sure what you mean by "index". Sorry about the confusing expression, I meant position. > >-Jonathan R. >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >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 Jan 13 10:53:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRFE-0003eF-Ek; Fri, 13 Jan 2006 10:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRFC-0003bq-AH for simple@megatron.ietf.org; Fri, 13 Jan 2006 10:53:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15940 for ; Fri, 13 Jan 2006 10:52:15 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExRMT-0000V7-7f for simple@ietf.org; Fri, 13 Jan 2006 11:01:13 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 456C2A34; Fri, 13 Jan 2006 16:53:24 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 16:53:23 +0100 Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 16:53:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP proposal on conditional inserts Date: Fri, 13 Jan 2006 16:53:22 +0100 Message-ID: <2DC267ED40568D4F9AA4F5DF955AF16AB3CAFF@esealmw107.eemea.ericsson.se> Thread-Topic: [Simple] XCAP proposal on conditional inserts Thread-Index: AcYVOUuw0IMN5YsRRnCQkedr2x2kJQDHKKEg From: "Anders Lindgren C \(HF/EAB\)" To: "Aki Niemi" , "ext Jonathan Rosenberg" X-OriginalArrivalTime: 13 Jan 2006 15:53:23.0869 (UTC) FILETIME=[7C07F4D0:01C61859] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Aki and others, As I see the main requirement is to be able to use the document's etag , when creating a new element inside a document in order to be able to handle inserts from different clients towards the same document. Another requirement is as I see it to keep the solution as "understandable" as possible I therefore like the ideas of approach 2 to keep error messages like 404 when trying to fetch a non-existing element and to be able to do DELETE of the element the same way as I do DELETE of a document.=20 Cheers Anders=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Aki Niemi Sent: den 9 januari 2006 17:03 To: ext Jonathan Rosenberg Cc: Simple WG Subject: Re: [Simple] XCAP proposal on conditional inserts Hi Jonathan, ext Jonathan Rosenberg wrote: > It is tempting to take a slightly different approach. Call the=20 > approach above "approach 1". The idea with approach 2 is to declare=20 > that, even though a resource doesn't exist, it has an etag, and that=20 > etag is equal to the document's etag, assuming the document does=20 > exist. Approach 2 would work much like approach 1, except that: >=20 > * A GET against a non-existent resource would be a 404, rather than a=20 > 200 OK with CL of zero >=20 > * A DELETE would be allowed >=20 > Note however, that with approach 2, you still cannot support the=20 > operation that says, "insert this but only if this element doesn't=20 > already exist in the document". I think that's OK. The most important thing is the ability to be safe from modifying an element someone else PUT in the meantime, by doing an insert. I think clients will in most cases work with cached copies anyway. And it's enough to be able to condition changes to the entire document using the etags, not so much of single elements. > Approach 2 has the problem that it > seriously bends (and possibly breaks), an underlying http assumption=20 > about the scope and meaning of etags. That might have odd and=20 > unpredicatable interactions with caching systems and other http=20 > intermediaries. For this reason, I wouldn't recommend it. But XCAP already instructs clients to use the no-cache directive, and probably PUTs are anyway authenticated. These should be quite strong indicators to any HTTP intermediaries that they should not cache these XCAP requests. > So, I would like to make the concrete proposal of moving to approach 1.=20 > The main drawback I see is the loss of the ability to insert an=20 > element if an element with that same name/attribute already exist. >=20 > Comments? I like approach 2. In an ideal world, I'd prefer the node-selector as a query string (as discussed back in Nov 04), but I can live with approach 2 since it demonstrates similar good properties like returning a 404 for a non-existent node. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 15 16:35:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFXA-0000iP-MF; Sun, 15 Jan 2006 16:35:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFX6-0000h7-Ub; Sun, 15 Jan 2006 16:35:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16927; Sun, 15 Jan 2006 16:34:05 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFet-0003vC-EX; Sun, 15 Jan 2006 16:43:32 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 15:35:14 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 15 Jan 2006 15:35:13 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 15:35:13 -0600 Message-ID: From: "Thomson, Martin" To: "Randall Gellens" , "Geopriv WG" , "Simple WG" Date: Sun, 15 Jan 2006 15:34:29 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 15 Jan 2006 21:35:13.0083 (UTC) FILETIME=[914D28B0:01C61A1B] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Domain identifier in common policy Thread-Index: AcYYr1hr1esXTrAZQ+ev1DS5jFZHUABa4DQA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Allison Mankin , Henning Schulzrinne Subject: [Simple] RE: [Geopriv] Domain identifier in common policy 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="===============1698833637==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1698833637== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Content-Transfer-Encoding: base64 SSB0ZW5kIHRvIGFncmVlIHdpdGggQW5keSAtIHBhcnRpY3VsYXJseSBnaXZlbiB0aGUgcmVjb21t ZW5kYXRpb25zIGluIFJGQyAzNDcwLiAgV2hlcmUgcGFyc2VycyBNVVNUIHN1cHBvcnQgYm90aCwg YWRkaW5nIHRoaXMgYWRkaXRpb25hbCByZXN0cmljdGlvbiBpcyBsaWtlbHkgdG8gY29tcGxpY2F0 ZSBtYXR0ZXJzIHVubmVjZXNzYXJpbHkuDQoNCk0NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBnZW9wcml2LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpnZW9wcml2LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBSYW5kYWxsIEdlbGxlbnMNCj4gU2VudDog U2F0dXJkYXksIDE0IEphbnVhcnkgMjAwNiAxOjAxIFBNDQo+IFRvOiBHZW9wcml2IFdHOyBTaW1w bGUgV0cNCj4gQ2M6IEhlbm5pbmcgU2NodWx6cmlubmU7IEFsbGlzb24gTWFua2luOyBBbmRyZXcg TmV3dG9uDQo+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gRG9tYWluIGlkZW50aWZpZXIgaW4gY29t bW9uIHBvbGljeQ0KPiANCj4gSSB0aGluayB3ZSBuZWVkIHRvIHJlc29sdmUgdGhlIGlzc3VlIG9m IHNheWluZyAiTVVTVCB1c2UgVVRGLTgiIChhbmQNCj4gaGVuY2UgZGlzYWxsb3dpbmcgVVRGLTE2 KSBvciBub3QuDQo+IA0KPiBQbGVhc2UgcmVwbHkgYnkgRnJpZGF5IEphbnVhcnkgMjAgaWYgeW91 IGZlZWwgc3Ryb25nbHkgdGhhdCB3ZSBuZWVkDQo+IHRvIGFkZCB0aGUgcmVzdHJpY3Rpb246ICJD b21tb24gcG9saWN5IE1VU1QgdXNlIFVURi04IHRvIHN0b3JlIGRvbWFpbg0KPiBuYW1lcyBpbiAn aWQnIGRvbWFpbiBhdHRyaWJ1dGVzIi4gIElmIHRoZXJlIGlzIG5vIGNvbnNlbnN1cyB0byBhZGQN Cj4gdGhpcyByZXN0cmljdGlvbiwgd2Ugd29uJ3QuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBH ZW9wcml2QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2dlb3ByaXYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlz IG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNv bnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9y bWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1 bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1698833637== 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 --===============1698833637==-- From simple-bounces@ietf.org Mon Jan 16 11:49:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXYK-0002aE-9b; Mon, 16 Jan 2006 11:49:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXYG-0002XV-QC for simple@megatron.ietf.org; Mon, 16 Jan 2006 11:49:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26852 for ; Mon, 16 Jan 2006 11:48:28 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyXgC-0001FJ-BK for simple@ietf.org; Mon, 16 Jan 2006 11:58:06 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2006 08:49:41 -0800 X-IronPort-AV: i="3.99,373,1131350400"; d="scan'208"; a="249256721:sNHT31610676" 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 k0GGneQJ021592; Mon, 16 Jan 2006 08:49:40 -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.211); Mon, 16 Jan 2006 11:49:40 -0500 Received: from [192.168.1.102] ([10.86.242.60]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 11:49:39 -0500 Message-ID: <43CBCEA3.2080906@cisco.com> Date: Mon, 16 Jan 2006 11:49:39 -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: Aki Niemi Subject: Re: [Simple] XCAP proposal on conditional inserts References: <43B45720.8090007@cisco.com> <43C28939.6070704@nokia.com> In-Reply-To: <43C28939.6070704@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2006 16:49:40.0010 (UTC) FILETIME=[D79B70A0:01C61ABC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org inline. Aki Niemi wrote: > Hi Jonathan, > > ext Jonathan Rosenberg wrote: > >> It is tempting to take a slightly different approach. Call the >> approach above "approach 1". The idea with approach 2 is to declare >> that, even though a resource doesn't exist, it has an etag, and that >> etag is equal to the document's etag, assuming the document does >> exist. Approach 2 would work much like approach 1, except that: >> >> * A GET against a non-existent resource would be a 404, rather than a >> 200 OK with CL of zero >> >> * A DELETE would be allowed >> >> Note however, that with approach 2, you still cannot support the >> operation that says, "insert this but only if this element doesn't >> already exist in the document". > > > I think that's OK. The most important thing is the ability to be safe > from modifying an element someone else PUT in the meantime, by doing an > insert. I think clients will in most cases work with cached copies > anyway. And it's enough to be able to condition changes to the entire > document using the etags, not so much of single elements. Since posting this, it has occurred to me that you can still do "insert this but only if this element doesn't already exist in the document" for most cases. Thats because the selector would not be just on the element name, but on some attribute too. So for example: then if you do: PUT .../list/entry[@uri="sip:aki@domain1/com"] If-None-Match:* this insertion would only be done if that specific entry wasn't there. -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 Mon Jan 16 12:09:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXr7-0007p4-SV; Mon, 16 Jan 2006 12:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXr5-0007oz-Ta for simple@megatron.ietf.org; Mon, 16 Jan 2006 12:09:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28469 for ; Mon, 16 Jan 2006 12:07:55 -0500 (EST) Received: from seldrel01.sonyericsson.com ([212.209.106.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyXz0-0001vo-9E for simple@ietf.org; Mon, 16 Jan 2006 12:17:33 -0500 Received: from (212.209.106.2) by seldrel01.sonyericsson.com via smtp id 565f_d2398b3a_86b2_11da_9316_0002b3a9a21a; Mon, 16 Jan 2006 18:09:15 +0100 Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 18:08:56 +0100 Received: from seldcon01.corpusers.net ([10.129.0.26]) by seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 18:08:56 +0100 Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by seldcon01.corpusers.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 18:08:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jan 2006 18:08:56 +0100 Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF041BED69@SELDMSX01.corpusers.net> Thread-Topic: draft-ietf-simple-event-list-07.txt Thread-Index: AcYav4id9+z8LcSqSByL1gFS+dSckw== From: "Hyttfors, Per" To: , X-OriginalArrivalTime: 16 Jan 2006 17:08:56.0951 (UTC) FILETIME=[8932A070:01C61ABF] X-Spam-Score: 0.6 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: simple@ietf.org Subject: [Simple] draft-ietf-simple-event-list-07.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: , Content-Type: multipart/mixed; boundary="===============0915356477==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0915356477== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61ABF.88B38227" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61ABF.88B38227 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, so I know that the draft already is in the RFC queue, and that this comment probably is to late. But is there a specific reason behind the attribute "language" for the "note" element in the Event Notification Extension for Resource Lists when there already is a way to express this with the xml:lang attribute? Why make it possible to express this in two ways? http://www.w3.org/TR/REC-xml/#sec-lang-tag Regards, Per Hyttfors Per Hyttfors=20 ___________________________________________________________=20 Development Engineer - Messaging Application Development=20 Sony Ericsson Mobile Communications AB=20 SE-221 88 Lund, Sweden=20 +46 46 2126534=20 per.hyttfors@sonyericsson.com (MSN/E-mail)=20 ___________________________________________________________=20 The information in this email, and attachment(s) thereto, is strictly confidential and may be legally privileged. It is intended solely for the named recipient(s), and access to this e-mail, or any attachment(s) thereto, by anyone else is unauthorized. Violations hereof may result in legal actions. Any attachment(s) to this e-mail has been checked for viruses, but please rely on your own virus-checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications in the matter concerned. If you do not consent to us storing your name and address for above stated purpose, please notify the sender promptly. Also, if you are not the intended recipient please inform the sender by replying to this transmission, and delete the e-mail, its attachment(s), and any copies of it without, disclosing it. ------_=_NextPart_001_01C61ABF.88B38227 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-simple-event-list-07.txt <note = language=3D"">

Ok, so I know that the draft = already is in the RFC queue, and that this comment probably is to = late.

But is there a specific reason = behind the attribute "language" for the "note" = element in the Event Notification Extension for Resource Lists when = there already is a way to express this with the xml:lang attribute? Why = make it possible to express this in two ways?

http://www.w3.org/TR/REC-xml/#sec-lang-tag


Regards,

Per Hyttfors


Per = Hyttfors
________________________________________________________= ___
Development Engineer - = Messaging Application Development
Sony = Ericsson Mobile Communications AB
SE-221 88 Lund, = Sweden
+46 46 2126534
per.hyttfors@sonyericsson.com (MSN/E-mail)
________________________________________________________= ___
The information in this email, and attachment(s) = thereto, is strictly confidential and may be legally privileged. It is = intended solely for the named recipient(s), and access to this e-mail, = or any attachment(s) thereto, by anyone else is unauthorized. Violations = hereof may result in legal actions. Any attachment(s) to this e-mail has = been checked for viruses, but please rely on your own virus-checker and = procedures. If you contact us by e-mail, we will store your name and = address to facilitate communications in the matter concerned. If you do = not consent to us storing your name and address for above stated = purpose, please notify the sender promptly. Also, if you are not the = intended recipient please inform the sender by replying to this = transmission, and delete the e-mail, its attachment(s), and any copies = of it without, disclosing it.


------_=_NextPart_001_01C61ABF.88B38227-- --===============0915356477== 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 --===============0915356477==-- From simple-bounces@ietf.org Mon Jan 16 17:29:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eycqq-00013B-1v; Mon, 16 Jan 2006 17:29:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eycqo-00011k-NE for simple@megatron.ietf.org; Mon, 16 Jan 2006 17:29:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21318 for ; Mon, 16 Jan 2006 17:27:58 -0500 (EST) Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eycyo-0006Z2-0q for simple@ietf.org; Mon, 16 Jan 2006 17:37:39 -0500 Received: from [71.254.17.114] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12911253 for simple@ietf.org; Mon, 16 Jan 2006 15:25:51 -0700 Message-Id: <6.2.1.2.0.20060116172221.02ee2b30@mail.stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 16 Jan 2006 17:28:54 -0500 To: Simple WG From: "Joel M. Halpern" Subject: Re: [Simple] XCAP proposal on conditional inserts In-Reply-To: <43CBCEA3.2080906@cisco.com> References: <43B45720.8090007@cisco.com> <43C28939.6070704@nokia.com> <43CBCEA3.2080906@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Unless I am completely confused, this does not work. The semantics of if-none-match * was that the PUT operation is only done if nothing matches any etag value. With the old semantics, this worked for PUT because if the element was new, there was no etag, so "non-match *". With the new semantics, there is an etag for the non-existant element. Given that there is an etag, the if-none-match * will fail. Hence, there would be no way, as far as I understand the proposed change, to do an insert that fails if the element is already there. It seemed to me that this was important. For many changes to a document, it does not matter what else has been done to the document as long as the given entry is not there. For example, if I have a buddy list, with information about each buddy, I would not want to overwrite a buddy that is already there by accident. But as long as the given buddy is not in the given list, I don't care what else I (or someone else) might have done to that same list, or other lists in the document. Maybe I'm confused (I am not building cell phone applications) but it seems to me to be of comparable or higher frequency for me to want to know if this element is present rather than wanting to know if I have the most current document. [This does assume that the phone does not automatically check the etag when it starts, and fetch the newest document all the time. Such fetching would be a potential waste of bandwidth. However, if such fetching is assumed, then one comes to different conclusions about the likelihood of needing a different check.] Yours, Joel At 11:49 AM 1/16/2006, Jonathan Rosenberg wrote: >Since posting this, it has occurred to me that you can still do "insert >this but only if this element doesn't already exist in the document" for >most cases. Thats because the selector would not be just on the element >name, but on some attribute too. So for example: > > > > > > >then if you do: > >PUT .../list/entry[@uri="sip:aki@domain1/com"] >If-None-Match:* > >this insertion would only be done if that specific entry wasn't there. > >-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 Mon Jan 16 18:04:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EydOR-0002jx-EX; Mon, 16 Jan 2006 18:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EydOP-0002js-HX for simple@megatron.ietf.org; Mon, 16 Jan 2006 18:04:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23580 for ; Mon, 16 Jan 2006 18:02:41 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EydWQ-0008D3-3I for simple@ietf.org; Mon, 16 Jan 2006 18:12:22 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0GN3vM4006581; Tue, 17 Jan 2006 01:03:58 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 01:03:41 +0200 Received: from [10.162.253.108] ([10.162.253.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Jan 2006 01:03:40 +0200 Message-ID: <43CC264C.8060304@nokia.com> Date: Tue, 17 Jan 2006 01:03:40 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext Joel M. Halpern" Subject: Re: [Simple] XCAP proposal on conditional inserts References: <43B45720.8090007@cisco.com> <43C28939.6070704@nokia.com> <43CBCEA3.2080906@cisco.com> <6.2.1.2.0.20060116172221.02ee2b30@mail.stevecrocker.com> In-Reply-To: <6.2.1.2.0.20060116172221.02ee2b30@mail.stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2006 23:03:41.0079 (UTC) FILETIME=[1786D270:01C61AF1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Inline. ext Joel M. Halpern wrote: > Unless I am completely confused, this does not work. > The semantics of if-none-match * was that the PUT operation is only done > if nothing matches any etag value. > With the old semantics, this worked for PUT because if the element was > new, there was no etag, so "non-match *". > With the new semantics, there is an etag for the non-existant element. > Given that there is an etag, the if-none-match * will fail. Right. The way I see things is that very rarely can you actually do these "blind" conditional inserts. Often the data you insert has dependencies on other data elsewhere in the document, which means that clients updating it need the latest, full document copy, and need to condition the request for this full document being unchanged. As an example, you simply cannot add an action to a common policy document rule without being fully aware of what the conditions part of that rule contains, or what other rules there are in the ruleset. Also, if the client is inserting an element into a strictly flat list, like Jonathan's example below, I don't think you necessarily need to make the PUT conditional at all. So what if the element existed already; the element would simply be re-written, but what is so bad about that? All in all, I view the ability to condition an insert over the changes of the complete document more important than the ability to do this "blind" conditional insert. > Hence, there would be no way, as far as I understand the proposed > change, to do an insert that fails if the element is already there. It > seemed to me that this was important. > For many changes to a document, it does not matter what else has been > done to the document as long as the given entry is not there. > For example, if I have a buddy list, with information about each buddy, > I would not want to overwrite a buddy that is already there by > accident. But as long as the given buddy is not in the given list, I > don't care what else I (or someone else) might have done to that same > list, or other lists in the document. Perhaps a way to avoid this is to split a potentially huge AU so that the various parts of the document are actually separate documents. Then whenever a GET is required, at least it is only to small portion of the document. To generalize, any parts of the application data that have no interdependency can be specified as different documents, with different etags scope. > Maybe I'm confused (I am not building cell phone applications) but it > seems to me to be of comparable or higher frequency for me to want to > know if this element is present rather than wanting to know if I have > the most current document. [This does assume that the phone does not > automatically check the etag when it starts, and fetch the newest > document all the time. Such fetching would be a potential waste of > bandwidth. However, if such fetching is assumed, then one comes to > different conclusions about the likelihood of needing a different check.] I'm sure some amount of fetching is required in any case. It is then a question of the relative frequency and size of the fetches. I'm inclined to say that for buddy list management either the data is fairly static (I don't generally muck with my buddy list more than a few times per year, after an initial bootstrapping phase), or has a high level of interdependency of the data elements (authorization policy being an example of this). Cheers, Aki > Yours, > Joel > > At 11:49 AM 1/16/2006, Jonathan Rosenberg wrote: >> Since posting this, it has occurred to me that you can still do "insert >> this but only if this element doesn't already exist in the document" for >> most cases. Thats because the selector would not be just on the element >> name, but on some attribute too. So for example: >> >> >> >> >> >> >> then if you do: >> >> PUT .../list/entry[@uri="sip:aki@domain1/com"] >> If-None-Match:* >> >> this insertion would only be done if that specific entry wasn't there. >> >> -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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 17 17:30:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyzLl-0005ME-U5; Tue, 17 Jan 2006 17:30:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exaom-0003ZI-At; Fri, 13 Jan 2006 21:07:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07653; Fri, 13 Jan 2006 21:05:38 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExawB-00012C-Hf; Fri, 13 Jan 2006 21:14:41 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0E26U4I031463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2006 18:06:30 -0800 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0E26QYg022245; Fri, 13 Jan 2006 18:06:27 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> <43BE3ADB.2020305@cs.columbia.edu> <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> <43BE7D46.1030908@cs.columbia.edu> <43BE94BD.9010507@cs.columbia.edu> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 13 Jan 2006 18:00:32 -0800 To: Geopriv WG , Simple WG From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Tue, 17 Jan 2006 17:30:45 -0500 Cc: Henning Schulzrinne , Allison Mankin Subject: [Simple] Re: [Geopriv] Domain identifier in common policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I think we need to resolve the issue of saying "MUST use UTF-8" (and hence disallowing UTF-16) or not. Please reply by Friday January 20 if you feel strongly that we need to add the restriction: "Common policy MUST use UTF-8 to store domain names in 'id' domain attributes". If there is no consensus to add this restriction, we won't. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 20 06:56:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezusi-0007gP-N0; Fri, 20 Jan 2006 06:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezush-0007fv-2u for simple@megatron.ietf.org; Fri, 20 Jan 2006 06:56:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05096 for ; Fri, 20 Jan 2006 06:55:10 -0500 (EST) Received: from smtp7.clb.oleane.net ([213.56.31.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezv1Q-0000zT-5L for simple@ietf.org; Fri, 20 Jan 2006 07:05:40 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp7.clb.oleane.net with ESMTP id k0KBuP2O026360 for ; Fri, 20 Jan 2006 12:56:28 +0100 Message-Id: <200601201156.k0KBuP2O026360@smtp7.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 20 Jan 2006 12:55:18 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYduGHjV3DaqwMRQEWOdGS54+aqXw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [Simple] WiMAX Summit - International SIP conference - Paris - France 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="===============0423198804==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0423198804== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0121_01C61DC0.C3E18160" This is a multi-part message in MIME format. ------=_NextPart_000_0121_01C61DC0.C3E18160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WiMAX Summit and the International SIP conference will jointly open their doors in one month, on February 21st, in Paris. Everything you must know about broadband wireless access, VoIP and convergence will be delivered by operators and key technical players. An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their solutions. Get details on International SIP at: http://www.upperside.fr/sip2006/sip2006intro.htm Get details on the WiMAX Summit at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0121_01C61DC0.C3E18160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WiMAX Summit and the International SIP = conference will jointly open their doors in one month, on February 21st, in = Paris.

Everything you must know about broadband = wireless access, VoIP and convergence will be delivered by operators and key = technical players.

An exhibition, close to the two conferences, welcome industrials wishing to demonstrate their = solutions.

 

Get details on International SIP = at:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

Get details on the WiMAX Summit = at:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

 

------=_NextPart_000_0121_01C61DC0.C3E18160-- --===============0423198804== 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 --===============0423198804==-- From simple-bounces@ietf.org Fri Jan 20 21:23:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F08P8-0000ro-8V; Fri, 20 Jan 2006 21:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F08P6-0000q1-LV for simple@megatron.ietf.org; Fri, 20 Jan 2006 21:23:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22267 for ; Fri, 20 Jan 2006 21:21:33 -0500 (EST) From: krisztian.kiss@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F08Xx-00082c-Az for simple@ietf.org; Fri, 20 Jan 2006 21:32:09 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0L2KXvT013733; Sat, 21 Jan 2006 04:20:35 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jan 2006 04:22:47 +0200 Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 20:22:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] WGLC: User Agent Capability Extension to PIDF (prescaps) Date: Fri, 20 Jan 2006 18:22:41 -0800 Message-ID: In-Reply-To: Thread-Topic: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps) Thread-Index: AcX3M7PPG7hMCvBAT16HHhd/kjWQxALYyJNABNHXaRAAcZJ6AAGfRJ/A To: , X-OriginalArrivalTime: 21 Jan 2006 02:22:45.0777 (UTC) FILETIME=[90C61810:01C61E31] X-Spam-Score: 0.3 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi All, I just submitted the post-WGLC version. Until it appears in the repository you can fetch a copy from... HTML: http://free.x3.hu/krkiss/draft-ietf-simple-prescaps-ext-06.html TXT: http://free.x3.hu/krkiss/draft-ietf-simple-prescaps-ext-06.txt Hopefully we can start IETF Last Call with this version. Cheers, Krisztian=20 >-----Original Message----- >From: ext Mary Barnes [mailto:mary.barnes@nortel.com]=20 >Sent: Thursday, January 12, 2006 10:18 AM >To: Lonnfors Mikko (Nokia-TP-MSW/Helsinki) >Cc: simple@ietf.org; Kiss Krisztian (Nokia-TP/SanDiego) >Subject: RE: [Simple] WGLC: User Agent Capability Extension to=20 >PIDF (prescaps) > >Your proposed changes look fine to me.=20 > >Mary > >-----Original Message----- >From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com] >Sent: Tuesday, January 10, 2006 7:03 AM >To: Barnes, Mary [RICH2:B601:EXCH] >Cc: simple@ietf.org; krisztian.kiss@nokia.com >Subject: RE: [Simple] WGLC: User Agent Capability Extension to PIDF >(prescaps) > > >Hi, > >Thanks Mary for very detailed review.=20 >Comments inline: > >> >>Potential issues: >>---------------- >> >>- Section 8. How do the security considerations discussed in=20 >RFC 3840=20 >>apply to the use of these feature tags in the PIDF? >>You have one general statement in the 2nd sentence of the first=20 >>paragraph and this would seem a good place to discuss this. > >Regarding the considerations for media feature tags ID only references >existing media feature tags and so I don't think that discussion should >be repeated. >I think we could add a sentence saying that if PUA is going to reveal >sensitive information about the presentity it should obtain permission >from the user. > >Proposal: >" >If the PUA is publishing sensitive information using this extension, it > SHOULD obtain a permission from a user. =20 >" > >>- Section 8. You have as a SHOULD stength the use of a transport=20 >>protocol that provides some level of protection, however, what's the=20 >>impact if such a protocol is not used? > >Ok, how about adding follow text: >" > If such > security measures are not used, eavesdroppers can learn sensitive > information about the user. It may be possible for a third party to > modify the user's presence information. This can lead to a=20 >situation > that users receiving presentity's presence information can take > incorrect actions based on false information. >" > > >>Editorial nits: >>--------------- >> >>- Title: Although the title is already quite long, I would think it=20 >>would be useful to have SIP in there (i.e. Session Initiation Protocol >>(SIP) User Agent Capability Extension to Presence Information Data=20 >>Format (PIDF)) > >Yes, makes it bit long but I am fine in adding it. > >>- Abstract: again, I think SIP should be mentioned somewhere in the=20 >>abstract. Actually, I think you can replace the use of "RFC3840" in=20 >>the >>abstract with "SIP user agent". This is consistent with not using >>references to the IMPP RFCs in the abstract, as well.=20 > >Ok, will do > >>- Introduction, 1st para, 6th sentence: insert "a" between=20 >"taken" and=20 >>"very", i.e. the sentence should read: >> "It has taken a very minimalistic approach to support such=20 >>operations." > >ok > >>- Introduction, 1st para, last sentence. I would suggest to replace=20 >>the reference to "RFC3863" to "PIDF", as you did earlier in the=20 >>paragraph for reference [4]. It's confusing to have a combination of=20 >>ways for referring to the same document in this document. =20 >For readers=20 >>that aren't as familiar with this area, it could be confusing. > >ok > >>- Section 1.1, page 4, 4th sentence. "represent" should be=20 >>"represents" > >Ok > >>- Section 1.1, page 5, last para of that section: "would contained" >>should be either "would contain" or "contained". > >ok > >>- Section 3.2.1, page 6, 3rd sentence: "This element can=20 >>contain following..." should be changed to normative language=20 >>"This element MAY contain any of the following..." (I'm=20 >>assuming this rewording keeps the same intent?) > >If I remember correctly there was some time ago a discussion that we >should not use duplicate normative statements. This is already=20 >normative >in XML schema. Using MAY here would only duplicate that. > >>- Section 3.2.9, 2nd para, page 8: the reference to the MIME=20 >>spec [19] seems normative to this document, but it's listed as=20 >>an informative reference. Shouldn't it be a normative dependency? =20 > >Right, will be fixed > >>- Section 3.2.11, last para, page 9: The sentence on IANA=20 >>registration is a bit awkward. I would suggest rewording FROM:=20 >>" Any value that is register to IANA to SIP Media Feature Tag >> Registration Tree as sip.class media feature tag can be used as a >> value of an extension element. If appropriate value is not >> registered it SHOULD be registed as defined in RFC3840 [6]." >>TO: >> "Any value that is registered with IANA for the SIP Media=20 >Feature Tag >> Registration Tree as a sip.class media feature tag can be used as a >> value of an extension element. If the appropriate value is not >> registered it SHOULD be registed as defined in RFC3840 [6]. > >ok > >>- General comment: the previous comment also applies to=20 >>sections 3.2.12 and 3.2.19 > >ok > >>- section 3.2.12, page 9, 1st para: "can only receive..."=20 >>should be "only receive" for consistency with the rest of the=20 >>parts of that sentence. > >ok > >>- Sections 3.2.14 and 3.2.16, last paragraph. The sentence on=20 >>IANA registration should change from:=20 >>" Any value that is register to IANA to SIP Event types namespace >> registry can be used as a value of an extension element." >>to: >>" Any value that is registered with IANA for the SIP Event=20 >>types namespace >> registry can be used as a value of an extension element." > >ok > >>- Section 3.2.15.3: I would remove the "Value of" from the=20 >>following sentence (or preface the sentence with "The"): >> "Value of the "value" attribute is >> used to indicate the exact supported priority value. > >ok > >>- Section 3.2.17, 3rd paragraph, page 10: add "" to=20 >>thie list of elements.=20 > >ok > >>- Section 3.3, 1st paragraph, 1st sentence: add "the" before "dynamic" >>and "PIDF"=20 > >ok > >>- Section 3.3, 2nd paragraph: there seems to be a formatting=20 >>problem with the namespace identifier (i.e. shouldn't the=20 >>"urn:" be part of the >>element?) > >Yes, it should > >>- Section 3.3.2, 1st paragraph, 1st sentence: "point or=20 >>contact" should be "point of contact" (2nd occurrence). > >ok > >>- Section 3.3.2, 1ast paragraph, last sentence: "If appropriate..." >>should be "If the appropriate..." > >ok > >- Mikko > >> >>Mary >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 23 02:25:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0w58-0005EE-GF; Mon, 23 Jan 2006 02:25:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0w56-0005E6-7B for simple@megatron.ietf.org; Mon, 23 Jan 2006 02:25:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24004 for ; Mon, 23 Jan 2006 02:24:10 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0wEP-0003aO-2a for simple@ietf.org; Mon, 23 Jan 2006 02:35:17 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Jan 2006 08:25:31 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0N7PP5m028437 for ; Mon, 23 Jan 2006 08:25:29 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Jan 2006 08:25:27 +0100 Received: from [10.10.10.44] ([10.61.80.70]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 22 Jan 2006 23:25:27 -0800 Message-ID: <43D484E7.6060502@cisco.com> Date: Mon, 23 Jan 2006 02:25: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: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2006 07:25:27.0692 (UTC) FILETIME=[2EF1E4C0:01C61FEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Simple] updated data model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I just submitted an update to the presence data model spec. The changes reflect IESG discuss comments, the GEN-ART review comments, and other nit comments received during last call. The non-trivial changes are: * added internationalization considerations section * added discussion on privacy to the security considerations section * updated schema so that note element can appear more than once; this is needed to support internationalization, so multiple different languages for the note can appear * updated definitions of status and characteristics to be clearer * clarified the relationship with rfc3863 and rfc2778 * removed reference to enum dip indicator as a sign that a tel URI is a phone number on the pstn * updated XMPP URI reference to the new IRI spec * removed example of 'roaming status' as a bad example of presence data for a cell phone, and changed to signal strength * clarified that the ordering of the device and person elements underneath presence is not important 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 Mon Jan 23 18:50:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1BRx-0004kF-Fa; Mon, 23 Jan 2006 18:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1BRj-0004ep-Tf; Mon, 23 Jan 2006 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05195; Mon, 23 Jan 2006 18:48:33 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1BbA-0003cR-CQ; Mon, 23 Jan 2006 18:59:49 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F1BRi-0007OV-5M; Mon, 23 Jan 2006 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: Mon, 23 Jan 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-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: , Sender: simple-bounces@ietf.org 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) User Agent Capability Extension to Presence Information Data Format (PIDF) Author(s) : M. Lonnfors, K. Kiss Filename : draft-ietf-simple-prescaps-ext-06.txt Pages : 29 Date : 2006-1-23 Interoperation of instant messaging and presence systems has been defined in the IMPP working group. The IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. This memo defines an extension to represent SIP User Agent capabilities in the Presence Information Document Format (PIDF) compliant presence documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-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-prescaps-ext-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-prescaps-ext-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: <2006-1-23163507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-prescaps-ext-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-prescaps-ext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-23163507.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 Jan 23 18:50:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1BSK-0004qV-2f; Mon, 23 Jan 2006 18:50:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1BRl-0004fk-SR; Mon, 23 Jan 2006 18:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05210; Mon, 23 Jan 2006 18:48:35 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1BbA-0003cf-LW; Mon, 23 Jan 2006 18:59:49 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F1BRi-0007PC-De; Mon, 23 Jan 2006 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: Mon, 23 Jan 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-data-model-07.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : A Data Model for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-data-model-07.txt Pages : 35 Date : 2006-1-23 This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-07.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-presence-data-model-07.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-presence-data-model-07.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: <2006-1-23173852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-data-model-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-data-model-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-23173852.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 Fri Jan 27 03:23:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Osz-00043Y-Ic; Fri, 27 Jan 2006 03:23:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Osx-000437-NV for simple@megatron.ietf.org; Fri, 27 Jan 2006 03:23:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17949 for ; Fri, 27 Jan 2006 03:21:39 -0500 (EST) From: krisztian.kiss@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2P33-00057m-Sx for simple@ietf.org; Fri, 27 Jan 2006 03:33:39 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0R8KPnP004877 for ; Fri, 27 Jan 2006 10:20:27 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 10:23:01 +0200 Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 02:22:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2006 00:22:44 -0800 Message-ID: Thread-Topic: schema issue in pres-rules Thread-Index: AcYg1nPw2QrUx3hATwaIH8hDFbAh6QCQnRsA To: X-OriginalArrivalTime: 27 Jan 2006 08:22:59.0428 (UTC) FILETIME=[E1FE0240:01C6231A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Subject: [Simple] schema issue in pres-rules X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I am sorry if this issue has been already brought up for draft-ietf-simple-presence-rules-04: has the following schema associated: Here, the minOccurs and maxOccurs definitions state that there can be zero or more child elements. No problem here. However, for provide-devices the schema contains: The schema should have the same minOccurs and maxOccurs definitions as for . The same is true for : Thanks, Krisztian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 27 10:18:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VMv-0000dK-UP; Fri, 27 Jan 2006 10:18:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VMu-0000cb-DB for simple@megatron.ietf.org; Fri, 27 Jan 2006 10:18:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18216 for ; Fri, 27 Jan 2006 10:16:57 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VWx-0002fb-5L for simple@ietf.org; Fri, 27 Jan 2006 10:29:01 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 94DD91944A0 for ; Fri, 27 Jan 2006 16:18:07 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:16:54 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <425c00d7d1ff5ab207914471b876a631@telio.no> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Hisham Khartabil Date: Fri, 27 Jan 2006 16:18:14 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 27 Jan 2006 15:16:54.0820 (UTC) FILETIME=[B50A1640:01C62354] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Simple] IMDN issue #7: Delivery as a notification X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I am continuing with the issue count that Eric Burger started and therefore have issue number 7 as the first one. The draft only refers to read reports but does not talk about delivery reports. While that makes some sense for MSRP. It does not make sense for page-mode IMs using the SIP MESSAGE request. The 200 OK for MESSAGE does not indicate delivery, therefore a IMDN indicating actual delivery success or failure is needed to be in this draft. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 27 10:18:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VMy-0000dx-9l; Fri, 27 Jan 2006 10:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VMw-0000dY-2P for simple@megatron.ietf.org; Fri, 27 Jan 2006 10:18:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18223 for ; Fri, 27 Jan 2006 10:17:00 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VX5-0002fx-R5 for simple@ietf.org; Fri, 27 Jan 2006 10:29:05 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 1CE4E1944A9 for ; Fri, 27 Jan 2006 16:18:23 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:17:10 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <875ecb0c33f150bfd5be78ef98dac39f@telio.no> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Hisham Khartabil Date: Fri, 27 Jan 2006 16:18:30 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 27 Jan 2006 15:17:10.0357 (UTC) FILETIME=[BE4CD850:01C62354] X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [Simple] IMDN issue #8: List-Action, Original-From and Original-Message-ID X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I don't think the List-Action header is needed. The Original-From header and Original-Message-ID may not be needed also. this depends on how we define the behaviour of the IM exploder to be. To summarise: - List-Action header is used to indicate if a B2BUA or UAS is to do the reporting - Original-From allows a UAS to know there to send the notification if there was a B2BUA like an exploder on the path. - Original-Message-ID allows a UAS to indicate to the UAC the message-ID of the original message that the notification is for. This is also when a B2BUA is involved. All 3 headers are above to help the case that a UAC chooses for the UAS to send the notifications directly instead of the B2BUA generating them indicating the B2BUA's receipt of the message. I would design it as follows: - UAC indicates, in the IM, its wish to receive an IMDN - B2BUA forwards the IM with the necessary original-from and original-message-id headers (if needed) - the UAS generates the IMDN and sends it just like it would send an IM to the UAC. For MSRP, it would be just like a SEND request in the other direction. For SIP MESSAGE, it would use the from (or original-from) and to headers in the incoming IM to create the MESSAGE request in the reverse direction. Same applies for message-id. - If it was not possible for the B2BUA to reach the UAS, it would generate its own IMDNs for that IM. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 27 10:18:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VNK-0000gz-By; Fri, 27 Jan 2006 10:18:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VNI-0000gr-Eg for simple@megatron.ietf.org; Fri, 27 Jan 2006 10:18:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18258 for ; Fri, 27 Jan 2006 10:17:23 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VXS-0002gz-7o for simple@ietf.org; Fri, 27 Jan 2006 10:29:27 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id A2BAB1944A0 for ; Fri, 27 Jan 2006 16:18:45 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:17:32 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <78739e8d56c9ce6136974da8834b7fcd@telio.no> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Hisham Khartabil Date: Fri, 27 Jan 2006 16:18:52 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 27 Jan 2006 15:17:32.0943 (UTC) FILETIME=[CBC331F0:01C62354] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Simple] IMDN issue #9: related to issue #2 keeping state X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The draft says: "It is RECOMMENDED that a Requesting UAC not notify the user if the Requesting UAC receives an IMDN that does not correlate to a message the Requesting UAC sent." This is not correct anymore since we agreed that, in Eric's words, "The UAC *ALWAYS* can decide how much state, and what state, to keep. That is an implementation issue beyond the protocol." Therefore, we cannot recommend that a UAC not notify the user if there is a IMDN it cannot correlate with an IM. Humans are better judges and can correlate an IMDN with an IM, even after machine removes state. Remember this is for page-mode messaging as well, not just session mode. I believe this also applies to B2BUAs where the draft says: "If the B2BUA receives an IMDN that does not match an existing Message-ID, the B2BUA MUST discard the IMDN." Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 27 10:19:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VNT-0000jE-4j; Fri, 27 Jan 2006 10:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VNR-0000ie-E6 for simple@megatron.ietf.org; Fri, 27 Jan 2006 10:19:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18270 for ; Fri, 27 Jan 2006 10:17:32 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VXb-0002hO-PZ for simple@ietf.org; Fri, 27 Jan 2006 10:29:37 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 33C9C1944A9 for ; Fri, 27 Jan 2006 16:18:55 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:17:42 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <4b3cef6131010e4756f7973e7092b15e@telio.no> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Hisham Khartabil Date: Fri, 27 Jan 2006 16:19:02 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 27 Jan 2006 15:17:42.0415 (UTC) FILETIME=[D16881F0:01C62354] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Simple] IMDN issue #10: More than one IMDN for an IM X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The draft states: "The Reporting UAS MUST NOT send more than one final IMDN in response to an IMDN request. That is, once an IMDN has been issued on behalf of a recipient, no further IMDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. For example, if the user reads and then deletes the message, the UAS will send a single read notification. The delete operation in this case will not generate an additional IMDN." I do not agree. I would like to know when the message is delivered, then when the message is read and when whatever future state we come up with for an IM happens. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 27 10:19:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VNc-0000l1-BP; Fri, 27 Jan 2006 10:19:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VNb-0000kt-0V for simple@megatron.ietf.org; Fri, 27 Jan 2006 10:19:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18282 for ; Fri, 27 Jan 2006 10:17:42 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VXk-0002hY-AG for simple@ietf.org; Fri, 27 Jan 2006 10:29:46 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 87A221944A0 for ; Fri, 27 Jan 2006 16:19:03 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 16:17:50 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Hisham Khartabil Date: Fri, 27 Jan 2006 16:19:10 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 27 Jan 2006 15:17:50.0809 (UTC) FILETIME=[D6695490:01C62354] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Simple] IMDN issue #11: Subject header in IMDN message X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Draft states: "The Reporting UAS MUST copy the incoming CPIM Subject: header as the IMDN CPIM Subject: header." What is the rationale. I don't see a reason for this. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 27 18:50:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2dMd-00045y-Ne; Fri, 27 Jan 2006 18:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2dLy-0003u7-86; Fri, 27 Jan 2006 18:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27054; Fri, 27 Jan 2006 18:48:31 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2dWA-0003uX-Lj; Fri, 27 Jan 2006 19:00:40 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2dLt-000684-Uv; Fri, 27 Jan 2006 18:50:01 -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: Fri, 27 Jan 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xml-patch-ops-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Author(s) : J. Urpalainen Filename : draft-ietf-simple-xml-patch-ops-01.txt Pages : 22 Date : 2006-1-27 Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. Updates to this data require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of XML documents. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , and directives a set of patches can then be applied to update an existing XML document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-01.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-xml-patch-ops-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xml-patch-ops-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-27155449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xml-patch-ops-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xml-patch-ops-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-27155449.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 Jan 30 06:05:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Wr5-0000rQ-2e; Mon, 30 Jan 2006 06:05:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Wr3-0000qf-D3 for simple@megatron.ietf.org; Mon, 30 Jan 2006 06:05:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13958 for ; Mon, 30 Jan 2006 06:04:10 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3X1g-00085r-3t for simple@ietf.org; Mon, 30 Jan 2006 06:16:52 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0UB0es0006956 for ; Mon, 30 Jan 2006 13:00:43 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 13:05:41 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Jan 2006 13:05:36 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k0UB5Z300998 for ; Mon, 30 Jan 2006 13:05:35 +0200 (EET) Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 99AD293B6A for ; Mon, 30 Jan 2006 13:05:35 +0200 (EET) Message-ID: <43DDF2FF.1020501@nokia.com> Date: Mon, 30 Jan 2006 13:05:35 +0200 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xml-patch-ops-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2006 11:05:36.0632 (UTC) FILETIME=[18FA6F80:01C6258D] X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext simple-bounces@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 : An Extensible Markup Language (XML) Patch > Operations Framework Utilizing XML Path > Language (XPath) Selectors > Author(s) : J. Urpalainen > Filename : draft-ietf-simple-xml-patch-ops-01.txt > Pages : 22 > Date : 2006-1-27 > >Extensible Markup Language (XML) documents are widely used as > containers for the exchange and storage of arbitrary data in today's > systems. Updates to this data require transporting of the entire XML > document between hosts, unless there's a mechanism that allows > exchanging only the updates of XML documents. This document > describes an XML patch framework utilizing XML Path language (XPath) > selectors. These selector values and updated new data content > constitute the basis of patch operations described in this document. > > In addition to them, with basic , and > directives a set of patches can then be applied to update an existing > XML document. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-01.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-xml-patch-ops-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-simple-xml-patch-ops-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >------------------------------------------------------------------------ > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > Changes since 00-version: -Removed text patching which can be done separately if there's enough need for it. However, with document oriented models a operation and text patching combined with move seems to be a necessity to produce really size-efficient diff documents. As one can imagine, the complexity of such a process e.g. an auto diffing tool, increases a lot compared to this very basic set described in this i-d. -Fixed schema: removed unnecessary default values for attributes, added "prepend" option, fixed "before/after" selections. -Text nits: some restructuring of the document, added some descriptive text how e.g. namespace mangling has to be implemented in practice. Various small nits to fix possible "holes". I'd really appreciate comments (and btw. open source implementation will be updated shortly) br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 30 15:35:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fkF-00028w-JA; Mon, 30 Jan 2006 15:35:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fkD-00025F-7k for simple@megatron.ietf.org; Mon, 30 Jan 2006 15:35:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25323 for ; Mon, 30 Jan 2006 15:33:37 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3fuq-0000ze-T9 for simple@ietf.org; Mon, 30 Jan 2006 15:46:26 -0500 X-IronPort-AV: i="4.01,236,1136178000"; d="scan'208"; a="27206309:sNHT45187416" Received: from mail pickup service by seabridge.Brooktrout.com with Microsoft SMTPSVC; Mon, 30 Jan 2006 15:35:39 -0500 x-pp-smtpvs: 1 x-pp-fromip: 204.176.75.121 x-pp-sclvalue: -1 Received: from ATLANTIS.Brooktrout.com ([204.176.75.121]) by seabridge.Brooktrout.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 15:35:38 -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] IMDN issue #10: More than one IMDN for an IM Date: Mon, 30 Jan 2006 15:35:10 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470219AE61@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] IMDN issue #10: More than one IMDN for an IM Thread-Index: AcYjVauslK66EGnFQ1CM065rmQxH7QChtj9w From: "Burger, Eric" To: "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 30 Jan 2006 20:35:38.0842 (UTC) FILETIME=[BB1583A0:01C625DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org REPORT method tells you the IM was received. ACK of the MESSAGE tells you the IM was received. IMDN is for user-level read, not transport. This is the distinction between user-level (IMDN, MDN) and transport-level (MESSAGE, ACK, SMTP DSN) reporting. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil Sent: Friday, January 27, 2006 10:19 AM To: Simple WG Subject: [Simple] IMDN issue #10: More than one IMDN for an IM The draft states: "The Reporting UAS MUST NOT send more than one final IMDN in response to an IMDN request. That is, once an IMDN has been issued on behalf of a recipient, no further IMDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. For example, if the user reads and then deletes the message, the UAS will send a single read notification. The delete operation in this case will not generate an additional IMDN." I do not agree. I would like to know when the message is delivered,=20 then when the message is read and when whatever future state we come up=20 with for an IM happens. Regards, 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 Mon Jan 30 15:35:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fkN-0002Du-Pi; Mon, 30 Jan 2006 15:35:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fkM-0002Dn-6U for simple@megatron.ietf.org; Mon, 30 Jan 2006 15:35:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25341 for ; Mon, 30 Jan 2006 15:33:58 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3fvB-000107-Tb for simple@ietf.org; Mon, 30 Jan 2006 15:46:46 -0500 X-IronPort-AV: i="4.01,236,1136178000"; d="scan'208"; a="27206333:sNHT41886792" Received: from mail pickup service by seabridge.Brooktrout.com with Microsoft SMTPSVC; Mon, 30 Jan 2006 15:36:05 -0500 x-pp-smtpvs: 1 x-pp-fromip: 204.176.75.121 x-pp-sclvalue: -1 Received: from ATLANTIS.Brooktrout.com ([204.176.75.121]) by seabridge.Brooktrout.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 15:36:04 -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] IMDN issue #11: Subject header in IMDN message Date: Mon, 30 Jan 2006 15:35:36 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470219AE64@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] IMDN issue #11: Subject header in IMDN message Thread-Index: AcYjVtWDQSTV1xHCRdSxxlQAqL+P8gChdj3g From: "Burger, Eric" To: "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 30 Jan 2006 20:36:04.0405 (UTC) FILETIME=[CA521E50:01C625DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Correlation, but I agree, it doesn't matter because we ship the Message-ID around. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil Sent: Friday, January 27, 2006 10:19 AM To: Simple WG Subject: [Simple] IMDN issue #11: Subject header in IMDN message Draft states: "The Reporting UAS MUST copy the incoming CPIM Subject: header as the IMDN CPIM Subject: header." What is the rationale. I don't see a reason for this. Regards, 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 Mon Jan 30 15:36:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fl7-0002GE-9e; Mon, 30 Jan 2006 15:36:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fl6-0002Fq-H1 for simple@megatron.ietf.org; Mon, 30 Jan 2006 15:36:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25389 for ; Mon, 30 Jan 2006 15:34:36 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3fvn-00010x-Bt for simple@ietf.org; Mon, 30 Jan 2006 15:47:24 -0500 X-IronPort-AV: i="4.01,236,1136178000"; d="scan'208"; a="27206359:sNHT40490136" Received: from mail pickup service by seabridge.Brooktrout.com with Microsoft SMTPSVC; Mon, 30 Jan 2006 15:36:43 -0500 x-pp-smtpvs: 1 x-pp-fromip: 204.176.75.121 x-pp-sclvalue: -1 Received: from ATLANTIS.Brooktrout.com ([204.176.75.121]) by seabridge.Brooktrout.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 15:36:42 -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] IMDN issue #7: Delivery as a notification Date: Mon, 30 Jan 2006 15:36:14 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470219AE68@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] IMDN issue #7: Delivery as a notification Thread-Index: AcYjVbk8tzkMy43fReGY3AJVupLtAwChxATg From: "Burger, Eric" To: "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 30 Jan 2006 20:36:42.0609 (UTC) FILETIME=[E1179610:01C625DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org If 200 OK doesn't note delivery, what does it convey? -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil Sent: Friday, January 27, 2006 10:18 AM To: Simple WG Subject: [Simple] IMDN issue #7: Delivery as a notification I am continuing with the issue count that Eric Burger started and=20 therefore have issue number 7 as the first one. The draft only refers to read reports but does not talk about delivery=20 reports. While that makes some sense for MSRP. It does not make sense=20 for page-mode IMs using the SIP MESSAGE request. The 200 OK for MESSAGE=20 does not indicate delivery, therefore a IMDN indicating actual delivery=20 success or failure is needed to be in this draft. Regards, 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 Mon Jan 30 15:37:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fmM-0002Pi-RB; Mon, 30 Jan 2006 15:37:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fmL-0002PQ-3T for simple@megatron.ietf.org; Mon, 30 Jan 2006 15:37:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25469 for ; Mon, 30 Jan 2006 15:35:52 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3fx1-00012p-PO for simple@ietf.org; Mon, 30 Jan 2006 15:48:41 -0500 X-IronPort-AV: i="4.01,236,1136178000"; d="scan'208"; a="27206421:sNHT51408360" Received: from mail pickup service by seabridge.Brooktrout.com with Microsoft SMTPSVC; Mon, 30 Jan 2006 15:37:58 -0500 x-pp-smtpvs: 1 x-pp-fromip: 204.176.75.121 x-pp-sclvalue: -1 Received: from ATLANTIS.Brooktrout.com ([204.176.75.121]) by seabridge.Brooktrout.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 15:37:58 -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] IMDN issue #9: related to issue #2 keeping state Date: Mon, 30 Jan 2006 15:37:30 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470219AE6C@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] IMDN issue #9: related to issue #2 keeping state Thread-Index: AcYjVfwP5VSsQJIZQ72T0ZwxLc9t/wChu5Og From: "Burger, Eric" To: "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 30 Jan 2006 20:37:58.0283 (UTC) FILETIME=[0E3285B0:01C625DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The idea is to nip the well-known spam method of generating MDN (IMDN in our case) as a means to push unwanted information to the human user. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil Sent: Friday, January 27, 2006 10:19 AM To: Simple WG Subject: [Simple] IMDN issue #9: related to issue #2 keeping state The draft says: "It is RECOMMENDED that a Requesting UAC not notify the user if the Requesting UAC receives an IMDN that does not correlate to a message the Requesting UAC sent." This is not correct anymore since we agreed that, in Eric's words, "The=20 UAC *ALWAYS* can decide how much state, and what state, to keep. That=20 is an implementation issue beyond the protocol." Therefore, we cannot recommend that a UAC not notify the user if there=20 is a IMDN it cannot correlate with an IM. Humans are better judges and=20 can correlate an IMDN with an IM, even after machine removes state.=20 Remember this is for page-mode messaging as well, not just session=20 mode. I believe this also applies to B2BUAs where the draft says: "If the B2BUA receives an IMDN that does not match an existing Message-ID, the B2BUA MUST discard the IMDN." Regards, 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 Tue Jan 31 03:40:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3r3S-0005QB-9P; Tue, 31 Jan 2006 03:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3r3Q-0005NC-Df for simple@megatron.ietf.org; Tue, 31 Jan 2006 03:40:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25305 for ; Tue, 31 Jan 2006 03:38:23 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3rEJ-00021k-Qd for simple@ietf.org; Tue, 31 Jan 2006 03:51:18 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 50FE0194480 for ; Tue, 31 Jan 2006 09:39:39 +0100 (CET) Received: from [192.168.1.106] ([192.168.1.106]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 09:38:24 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470219AE68@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470219AE68@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21632230994a5af75404ad8cdf0c0618@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] IMDN issue #7: Delivery as a notification Date: Tue, 31 Jan 2006 09:39:48 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 31 Jan 2006 08:38:24.0355 (UTC) FILETIME=[B2F1AB30:01C62641] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org It indicates delivery to the next hop, not end to end delivery. IM Server/Exploder +------+ +------+ +-------+ | UA1 | | | | UA2 | +--+---+ +--+---+ +---+---+ | | | | MESSAGE | | |---------------------->| | | | MESSAGE | | 200 |------------------------->| |<----------------------| | | | | | | 4xx | | |<-------------------------| | | | | | | | | | | | | | | | | | | | | | Hisham On Jan 30, 2006, at 9:36 PM, Burger, Eric wrote: > If 200 OK doesn't note delivery, what does it convey? > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Hisham Khartabil > Sent: Friday, January 27, 2006 10:18 AM > To: Simple WG > Subject: [Simple] IMDN issue #7: Delivery as a notification > > I am continuing with the issue count that Eric Burger started and > therefore have issue number 7 as the first one. > > The draft only refers to read reports but does not talk about delivery > reports. While that makes some sense for MSRP. It does not make sense > for page-mode IMs using the SIP MESSAGE request. The 200 OK for MESSAGE > does not indicate delivery, therefore a IMDN indicating actual delivery > success or failure is needed to be in this draft. > > Regards, > 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 Tue Jan 31 03:45:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3r8L-0006xq-OS; Tue, 31 Jan 2006 03:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3r8F-0006up-C4 for simple@megatron.ietf.org; Tue, 31 Jan 2006 03:45:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25504 for ; Tue, 31 Jan 2006 03:43:14 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3rJ3-00028M-9d for simple@ietf.org; Tue, 31 Jan 2006 03:56:09 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 1FFAB194494 for ; Tue, 31 Jan 2006 09:44:41 +0100 (CET) Received: from [192.168.1.106] ([192.168.1.106]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 09:43:26 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470219AE6C@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470219AE6C@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6be2dd2c9f2bca551106c67af8bcd79d@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] IMDN issue #9: related to issue #2 keeping state Date: Tue, 31 Jan 2006 09:44:50 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 31 Jan 2006 08:43:26.0184 (UTC) FILETIME=[66D91E80:01C62642] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This draft is not the place to try to eliminate SPIM, imo. I have presented a scenario earlier where not notifying the user is not feasible. I'll paste a portion of that discussion below, but please refer to the thread on issue 2 for a complete picture. >>> 2) I think most applications are going to be impacted worse by the >>> bandwidth issue of sending the whole message back in the IMDN than >>> they would be by keeping state for short periods. This is also an >>> issue when using SIP MESSAGE, due to the low size limits in RFC3428. >> >> How does your phone work today with SMS? It does not need any >> correlation information between the receipt reports and the messages >> in the sent box. Your email client is the same, if there is a match >> of the message-id, great. If there is not, the delivery report is >> stand alone and it leaves it for the human user to correlate the MDN >> and the message. > > My SMS client doesn't do receipt requests. But my old phone did. On > that one, I just got back something saying that message to X was > delivered. I I had more than one messages to X, I could not tell which > one. Certainly, it can do that without keeping state. That's all I'm asking for. Hisham On Jan 30, 2006, at 9:37 PM, Burger, Eric wrote: > The idea is to nip the well-known spam method of generating MDN (IMDN > in > our case) as a means to push unwanted information to the human user. > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Hisham Khartabil > Sent: Friday, January 27, 2006 10:19 AM > To: Simple WG > Subject: [Simple] IMDN issue #9: related to issue #2 keeping state > > The draft says: > > "It is RECOMMENDED that a Requesting UAC not notify the user if the > Requesting UAC receives an IMDN that does not correlate to a > message > the Requesting UAC sent." > > This is not correct anymore since we agreed that, in Eric's words, "The > UAC *ALWAYS* can decide how much state, and what state, to keep. That > is an implementation issue beyond the protocol." > > Therefore, we cannot recommend that a UAC not notify the user if there > is a IMDN it cannot correlate with an IM. Humans are better judges and > can correlate an IMDN with an IM, even after machine removes state. > Remember this is for page-mode messaging as well, not just session > mode. > > I believe this also applies to B2BUAs where the draft says: > > "If the B2BUA receives an IMDN that does not match an existing > Message-ID, the B2BUA MUST discard the IMDN." > > Regards, > 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 Tue Jan 31 03:58:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rLW-0001Aw-Tt; Tue, 31 Jan 2006 03:58:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rLT-00018R-Jr for simple@megatron.ietf.org; Tue, 31 Jan 2006 03:58:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26486 for ; Tue, 31 Jan 2006 03:56:55 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3rWG-0002j7-RN for simple@ietf.org; Tue, 31 Jan 2006 04:09:50 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0V8wNTV006378; Tue, 31 Jan 2006 10:58:26 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 10:58:08 +0200 Received: from [172.21.35.13] ([172.21.35.13]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 31 Jan 2006 10:58:08 +0200 Message-ID: <43DF269F.2030008@nokia.com> Date: Tue, 31 Jan 2006 10:58:07 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext Burger, Eric" Subject: Re: [Simple] IMDN issue #10: More than one IMDN for an IM References: <330A23D8336C0346B5C1A5BB196666470219AE61@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB196666470219AE61@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2006 08:58:08.0460 (UTC) FILETIME=[74B9C0C0:01C62644] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Burger, Eric wrote: > REPORT method tells you the IM was received. > ACK of the MESSAGE tells you the IM was received. No it doesn't, if it is a 202. For that you need a delivery report that is sent when the message actually gets forwarded to the final recipient. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 31 04:11:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rYK-0004Ru-Ne; Tue, 31 Jan 2006 04:11:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rYH-0004MZ-J8 for simple@megatron.ietf.org; Tue, 31 Jan 2006 04:11:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27550 for ; Tue, 31 Jan 2006 04:10:16 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3rjD-0003Ea-1c for simple@ietf.org; Tue, 31 Jan 2006 04:23:11 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id EB79C194497 for ; Tue, 31 Jan 2006 10:11:42 +0100 (CET) Received: from [192.168.1.106] ([192.168.1.106]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 10:10:28 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470219AE61@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470219AE61@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] IMDN issue #10: More than one IMDN for an IM Date: Tue, 31 Jan 2006 10:11:52 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 31 Jan 2006 09:10:28.0324 (UTC) FILETIME=[2DB80A40:01C62646] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I dont understand your point here. what ACK for the message? do you mean 200 ok? While 200 ok is transport level delivery, IMDN is user level delivery notification. A GW, for example, can generate a 2xx response before it has been guaranteed that the final recipient has actually received the message. Hisham On Jan 30, 2006, at 9:35 PM, Burger, Eric wrote: > REPORT method tells you the IM was received. > ACK of the MESSAGE tells you the IM was received. > > IMDN is for user-level read, not transport. This is the distinction > between user-level (IMDN, MDN) and transport-level (MESSAGE, ACK, SMTP > DSN) reporting. > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Hisham Khartabil > Sent: Friday, January 27, 2006 10:19 AM > To: Simple WG > Subject: [Simple] IMDN issue #10: More than one IMDN for an IM > > The draft states: > > "The Reporting UAS MUST NOT send more than one final IMDN in response > to an IMDN request. That is, once an IMDN has been issued on > behalf > of a recipient, no further IMDNs may be issued on behalf of that > recipient, even if another disposition is performed on the message. > For example, if the user reads and then deletes the message, the > UAS > will send a single read notification. The delete operation in this > case will not generate an additional IMDN." > > I do not agree. I would like to know when the message is delivered, > then when the message is read and when whatever future state we come up > with for an IM happens. > > Regards, > 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 Tue Jan 31 06:37:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tpP-0007f5-Bx; Tue, 31 Jan 2006 06:37:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tpN-0007dy-C9 for simple@megatron.ietf.org; Tue, 31 Jan 2006 06:37:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07771 for ; Tue, 31 Jan 2006 06:36:06 -0500 (EST) Received: from smtp11.clb.oleane.net ([213.56.31.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3u0K-0007qA-TR for simple@ietf.org; Tue, 31 Jan 2006 06:49:01 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp11.clb.oleane.net with ESMTP id k0VBb7Af019108 for ; Tue, 31 Jan 2006 12:37:30 +0100 Message-Id: <200601311137.k0VBb7Af019108@smtp11.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 31 Jan 2006 12:37:22 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYmWrMPi7sEVl7gS82UNxJ8eQCXtA== X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Simple] International SIP/WiMAX Summit - Paris - France 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="===============1293496400==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1293496400== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01C62663.151B5B50" This is a multi-part message in MIME format. ------=_NextPart_000_00C0_01C62663.151B5B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit More than 500 participants will attend International SIP and the WiMAX Summit next February 21st to 24th in Paris. Registration is still open for both events. The 7th edition of the International SIP conference program is mainly dedicated to IMS architectures and Peer-to-Peer communications: http://www.upperside.fr/sip2006/sip2006intro.htm The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant operators: http://www.upperside.fr/wimax2006/wimax2006intro.htm Close to the conference rooms an exhibition welcomes industrials involved in VoIP and wireless broadband access. ------=_NextPart_000_00C0_01C62663.151B5B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

More than 500 participants will attend = International = SIP and the WiMAX Summit next February 21st to 24th in = Paris.

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           =

Registration is still open for both = events.

 

The 7th edition of the International SIP = conference program is mainly dedicated to IMS architectures = and Peer-to-Peer communications:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

The 3rd WiMAX Summit is largely devoted to case studies presented by both incumbent and new entrant = operators:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

Close to the conference rooms an exhibition = welcomes industrials involved in VoIP and wireless broadband = access.

 

------=_NextPart_000_00C0_01C62663.151B5B50-- --===============1293496400== 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 --===============1293496400==-- From simple-bounces@ietf.org Tue Jan 31 12:11:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3z2s-0008EL-Vp; Tue, 31 Jan 2006 12:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3z2k-0008AZ-Pz; Tue, 31 Jan 2006 12:11:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07560; Tue, 31 Jan 2006 12:10:15 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zDl-0003ai-Jh; Tue, 31 Jan 2006 12:23:13 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F3z2j-0006yg-Vr; Tue, 31 Jan 2006 12:11:49 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 31 Jan 2006 12:11:49 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: simple chair , Internet Architecture Board , simple mailing list , RFC Editor Subject: [Simple] Protocol Action: 'A Data Model for Presence' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The IESG has approved the following document: - 'A Data Model for Presence ' as a Proposed Standard This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact person is Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-07.txt Technical Summary This document builds on the model defined in RFC 2778 clarifying the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging Leveraging Presence Extensions (SIMPLE) presence agents. In particular, the document clarifies what a tuple models and provides guidance on mapping real-world communications systems into a presence document. Working Group Summary This document has been through many extensive working group discussions. It reflects well forged compromise, and a strong working group consensus. Protocol Quality Hisham Khartabil was the PROTO shepherd for this document. Ted Hardie reviewed the document for the IESG. Interoperable exchange of presence documents based on this model has been seen at several of the SIP Interoperability Test Events (SIPITs). Note to RFC Editor OLD: RFC 2778 [5] defines a model and terminology for describing systems that provide presence information. RFC 3863 [1] defines an XML document format for representing presence information. NEW: RFC 2778 [8] defines a model and terminology for describing systems that provide presence information. RFC 3863 [1] defines an XML [5] [6] [7] document format for representing presence information. Please add the following normative references, and renumber the subsequent references. The "NEW" section presumes RFC 2778 will be [8] after this renumbering. [5] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004. [6] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004. [7] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 31 16:17:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42sw-0004QX-SO; Tue, 31 Jan 2006 16:17:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42su-0004Q6-UE for simple@megatron.ietf.org; Tue, 31 Jan 2006 16:17:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00549 for ; Tue, 31 Jan 2006 16:16:19 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F433v-00068S-Ux for simple@ietf.org; Tue, 31 Jan 2006 16:29:21 -0500 X-IronPort-AV: i="4.01,242,1136178000"; d="scan'208"; a="27278891:sNHT43606608" 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] IMDN issue #10: More than one IMDN for an IM Date: Tue, 31 Jan 2006 16:18:28 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470219B7A7@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] IMDN issue #10: More than one IMDN for an IM Thread-Index: AcYmRnCYrGSVVq6ZRHO3hzVyBSb3SgAX8ipQ From: "Burger, Eric" To: "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I'll buy the argument, if we said that every IM generates an IMDN. Given the scenarios Hisham and Aki have posted, the sender has no way of knowing whether or not there are intermediaries. This is why every IM must request an IMDN, unless the sender does not care. This issue also says that SIP was the wrong choice for IM transport. We're hacking hacks on hacks to implement transport layer features. Yes, it will work to use IMDN for what in the normal SIP world would be a final response. Does this pass muster with the Internet architecture, however? -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, January 31, 2006 4:12 AM To: Burger, Eric Cc: Simple WG Subject: Re: [Simple] IMDN issue #10: More than one IMDN for an IM I dont understand your point here. what ACK for the message? do you=20 mean 200 ok? While 200 ok is transport level delivery, IMDN is user level delivery=20 notification. A GW, for example, can generate a 2xx response before it=20 has been guaranteed that the final recipient has actually received the=20 message. Hisham On Jan 30, 2006, at 9:35 PM, Burger, Eric wrote: > REPORT method tells you the IM was received. > ACK of the MESSAGE tells you the IM was received. > > IMDN is for user-level read, not transport. This is the distinction > between user-level (IMDN, MDN) and transport-level (MESSAGE, ACK, SMTP > DSN) reporting. > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > Behalf > Of Hisham Khartabil > Sent: Friday, January 27, 2006 10:19 AM > To: Simple WG > Subject: [Simple] IMDN issue #10: More than one IMDN for an IM > > The draft states: > > "The Reporting UAS MUST NOT send more than one final IMDN in response > to an IMDN request. That is, once an IMDN has been issued on=20 > behalf > of a recipient, no further IMDNs may be issued on behalf of that > recipient, even if another disposition is performed on the message. > For example, if the user reads and then deletes the message, the=20 > UAS > will send a single read notification. The delete operation in this > case will not generate an additional IMDN." > > I do not agree. I would like to know when the message is delivered, > then when the message is read and when whatever future state we come up > with for an IM happens. > > Regards, > 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