From simple-bounces@ietf.org Tue Oct 04 03:42:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EMhRP-0002up-Ky; Tue, 04 Oct 2005 03:42:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EMhRN-0002uh-TW
	for simple@megatron.ietf.org; Tue, 04 Oct 2005 03:42:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02895
	for <simple@ietf.org>; Tue, 4 Oct 2005 03:42:20 -0400 (EDT)
From: Martin.Hynar@tietoenator.com
Received: from ebb04.tietoenator.com ([194.142.141.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMha0-0000OB-AT
	for simple@ietf.org; Tue, 04 Oct 2005 03:51:17 -0400
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-2"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 4 Oct 2005 09:40:59 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F763@carrera.eu.tieto.com>
Thread-Topic: xcap diff format in SIP notify message
Thread-Index: AcXItvZe/1DUB5BDQNm7ZfCalBYDGA==
To: <simple@ietf.org>
X-OriginalArrivalTime: 04 Oct 2005 07:41:39.0222 (UTC)
	FILETIME=[0E2B5B60:01C5C8B7]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] xcap diff format in SIP notify message
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Hi all,

Few weeks ago I sent the question to the SIMPLE mailing list but I =
haven't obtained any response. However, it is very important for me so I =
am asking again.

I am solving now the problem with communication using xcap-diff format =
specified in xcap-package-03. What is the issue:

1. The server carries XML document.
2. A client requests to be notified about changes in this document with =
xcap-diff.
3. The document is replaced with new content begining from the root =
(XCAP PUT with no ETag -> replacement of the content)
4. The server tries to notify the client with message of the format

HEADERS
<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<xcap-diff xmlns=3D"urn:ietf:params:xml:ns:xcap-diff" =
xcap-root=3D"http://localhost/xcap/xcap/">

  <document =
doc-selector=3D"resource-lists/users/sip:user@domain.com/doc"
            new-etag=3D"aaaaa"
            previous-etag=3D"bbbbb">

  <replace-element element=3D"/">
    <![CDATA[<?xml version=3D"1.0" encoding=3D"UTF-8"?>

      <resource-lists xmlns=3D"urn:ietf:params:xml:ns:resource-lists"

                      =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">

        <list name=3D"list_name">

          ...

        </list>  =20

      </resource-lists>]]>
  </replace-element>

</document>

</xcap-diff>

The question is whether the value "/" of attribute "element" is correct?

Another problem is that I don't know what message should be sent in case =
of deletion of the document. In that case I am sending reference =
document with equal new-etag and prevoius-etag to let client refetch the =
document. Is this behaviour correct?

Best regards,

 Martin Hynar



Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
E-mail martin.hynar@tietoenator.com

Technologicka 372/2
CZ-708 00 Ostrava

www.tietoenator.com

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



From simple-bounces@ietf.org Thu Oct 06 04:17:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENQwp-0008P2-6v; Thu, 06 Oct 2005 04:17:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQwn-0008N0-FG
	for simple@megatron.ietf.org; Thu, 06 Oct 2005 04:17:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16676
	for <simple@ietf.org>; Thu, 6 Oct 2005 04:17:47 -0400 (EDT)
Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENR5p-0003W9-Of
	for simple@ietf.org; Thu, 06 Oct 2005 04:27:11 -0400
Received: from cs.helsinki.fi (pehesaari-17.cs.helsinki.fi [128.214.10.226])
	(AUTH: PLAIN leggio, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by mail.cs.helsinki.fi with esmtp; Thu, 06 Oct 2005 11:17:44 +0300
	id 0008FECD.4344DDA8.000060B5
Message-ID: <4344DDA8.3000303@cs.helsinki.fi>
Date: Thu, 06 Oct 2005 11:17:44 +0300
From: Simone Leggio <simone.leggio@cs.helsinki.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040315
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Subject: [Simple] Connection to/from a foreign relay
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Dear all,

let's suppose Alice wants to send an MSRP SEND message to Bob, using a 
relay C.

According to the draft, Alice opens a TLS connection to her relay, 
authenticates and everything is nice.

Now, she sends a SEND message. How to proceed next? How is the SEND 
message forwarded to Bob?

I mean, by which side is the TCP/TLS connection between Alice's relay 
and Bob opened?

Does the relay opens a connection to Bob, or is it Bob who opens a 
connection to the relay, possibly when he parses the SDP body of the 
INVITE and sees that a relay is in use?
Thank you,

	Simone Leggio

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



From simple-bounces@ietf.org Thu Oct 06 08:03:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENUSi-0000xl-2y; Thu, 06 Oct 2005 08:03:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENUSg-0000xY-Mr
	for simple@megatron.ietf.org; Thu, 06 Oct 2005 08:02:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27593
	for <simple@ietf.org>; Thu, 6 Oct 2005 08:02:57 -0400 (EDT)
Received: from gw15.rotuaari.net ([212.50.147.115] helo=gw15.virtues.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENUbl-00045B-8I
	for simple@ietf.org; Thu, 06 Oct 2005 08:12:21 -0400
Received: from AllIPIBM1 (unknown [212.50.147.101])
	by gw15.virtues.local (Postfix) with ESMTP id 7540FE464D;
	Thu,  6 Oct 2005 15:02:46 +0300 (EEST)
From: "Jussi Ala-Kurikka" <jussi.ala-kurikka@oulu.fi>
To: <simple@ietf.org>
Date: Thu, 6 Oct 2005 15:02:48 +0300
Organization: MediaTeam/University of Oulu
Message-ID: <001101c5ca6d$de92b610$da29140a@AllIPIBM1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcXKTSMRCdnk3KwaRsmP4XvbSxXtfQAAaNbQAAe5ilA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Subject: [Simple] PIDFConn draft
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

In current PIDF and its extensions, there are limited ways of expressing
features related to a network interface that receives packets sent to a
communication address (inside a <contact> element). It could be hard to map
the relative priorities of different communication addresses into decimal
numbers, and there could be a need for providing more information. I
participated in discussions in the Paris IETF about this issue and there
seemed to be a consensus that it should be discussed on the SIMPLE mailing
list.

Yesterday I submitted the first version of the PIDFConn draft which helps in
providing specific information related to a communication address. PIDFConn
is available at
http://www.ietf.org/internet-drafts/draft-ala-kurikka-simple-pidfconn-00.txt
.

The authors welcome your comments. Hopefully PIDFConn arises discussion
about whether we need to extend PIDF with these things (and to what extent),
if not more.

BR,
Jussi
____________________________________________________________________
Jussi Ala-Kurikka, Researcher
MediaTeam Oulu Group, University of Oulu Erkki Koiso-Kanttilan katu 3,
FIN-90014 University of Oulu, Finland
e-mail: jussi.ala-kurikka@ee.oulu.fi, http://www.mediateam.oulu.fi tel.
+358-8-5532811, fax +358-8-5532534



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



From simple-bounces@ietf.org Thu Oct 06 13:12:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENZIR-0007hY-Qx; Thu, 06 Oct 2005 13:12:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZIO-0007go-F5
	for simple@megatron.ietf.org; Thu, 06 Oct 2005 13:12:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15716
	for <simple@ietf.org>; Thu, 6 Oct 2005 13:12:37 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENZRU-0000fl-Ca
	for simple@ietf.org; Thu, 06 Oct 2005 13:22:06 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 06 Oct 2005 10:12:29 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j96HBxv4018948;
	Thu, 6 Oct 2005 10:12:26 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 6 Oct 2005 13:12:24 -0400
Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 13:12:23 -0400
Message-ID: <43455AF7.3030100@cisco.com>
Date: Thu, 06 Oct 2005 13:12:23 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jussi Ala-Kurikka <jussi.ala-kurikka@oulu.fi>
Subject: Re: [Simple] PIDFConn draft
References: <001101c5ca6d$de92b610$da29140a@AllIPIBM1>
In-Reply-To: <001101c5ca6d$de92b610$da29140a@AllIPIBM1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Oct 2005 17:12:23.0801 (UTC)
	FILETIME=[1E5AEE90:01C5CA99]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Jussi,

I just took a quick look.

I find the logical data model quite confusing. You put the connectivity 
element in the devcaps, but then you need to link it back to the service 
tuples that it supports. Meanwhile service tuples need to link to the 
device elements that they are bound to.

If the goal is to help a watcher to decide when/if to communicate based 
on the predicted characteristics of the connection, then it must be 
possible to determine how the way it connects determines which 
connectivity will apply. This can only happen if the contact is 
associated with a single connectivity.

In the existing extended pidf model, a service tuple can have only one 
contact, but can be bound to any number of devices. So there is a 
potential for ambiguity in your extension.

Why don't you just associate your connectivity extension with a tuple 
rather than with a device?

	Paul

Jussi Ala-Kurikka wrote:
> In current PIDF and its extensions, there are limited ways of expressing
> features related to a network interface that receives packets sent to a
> communication address (inside a <contact> element). It could be hard to map
> the relative priorities of different communication addresses into decimal
> numbers, and there could be a need for providing more information. I
> participated in discussions in the Paris IETF about this issue and there
> seemed to be a consensus that it should be discussed on the SIMPLE mailing
> list.
> 
> Yesterday I submitted the first version of the PIDFConn draft which helps in
> providing specific information related to a communication address. PIDFConn
> is available at
> http://www.ietf.org/internet-drafts/draft-ala-kurikka-simple-pidfconn-00.txt
> .
> 
> The authors welcome your comments. Hopefully PIDFConn arises discussion
> about whether we need to extend PIDF with these things (and to what extent),
> if not more.
> 
> BR,
> Jussi
> ____________________________________________________________________
> Jussi Ala-Kurikka, Researcher
> MediaTeam Oulu Group, University of Oulu Erkki Koiso-Kanttilan katu 3,
> FIN-90014 University of Oulu, Finland
> e-mail: jussi.ala-kurikka@ee.oulu.fi, http://www.mediateam.oulu.fi tel.
> +358-8-5532811, fax +358-8-5532534
> 
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

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



From simple-bounces@ietf.org Thu Oct 06 16:56:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENcnO-0007Fx-6c; Thu, 06 Oct 2005 16:56:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcnM-0007Fn-N5
	for simple@megatron.ietf.org; Thu, 06 Oct 2005 16:56:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15727
	for <simple@ietf.org>; Thu, 6 Oct 2005 16:56:50 -0400 (EDT)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENcwT-00080f-1j
	for simple@ietf.org; Thu, 06 Oct 2005 17:06:20 -0400
Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j96KuRSA047296
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 6 Oct 2005 15:56:29 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C9CB7280-5CAE-472C-A458-62D4DA37BCEA@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Date: Thu, 6 Oct 2005 15:56:25 -0500
To: Simple WG <simple@ietf.org>
X-Mailer: Apple Mail (2.734)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Subject: [Simple] -00s
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

All -

The deadline for pre-approving WG -00s is approaching.

I don't think we're expecting any new simple -00s this time - if you
disagree, please let me know asap.

Thanks,

RjS

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



From simple-bounces@ietf.org Thu Oct 06 18:33:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENeIp-0004bC-4D; Thu, 06 Oct 2005 18:33:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENeIn-0004az-5W
	for simple@megatron.ietf.org; Thu, 06 Oct 2005 18:33:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23401
	for <simple@ietf.org>; Thu, 6 Oct 2005 18:33:21 -0400 (EDT)
Received: from mail2.microsoft.com ([131.107.3.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENeRx-00047h-3R
	for simple@ietf.org; Thu, 06 Oct 2005 18:42:54 -0400
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.2499); 
	Thu, 6 Oct 2005 15:33:14 -0700
Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by
	mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 6 Oct 2005 15:33:14 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 6 Oct 2005 15:33:12 -0700
Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC24707A41062@RED-MSG-43.redmond.corp.microsoft.com>
Thread-Topic: Adding a telephone number to a basic PIDF document
thread-index: AcXKxe+rtC6xhK3qTpS9+XHR4uGFTw==
From: "Tim Rang" <timrang@microsoft.com>
To: "Simple WG" <simple@ietf.org>
X-OriginalArrivalTime: 06 Oct 2005 22:33:14.0180 (UTC)
	FILETIME=[F079A840:01C5CAC5]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 441f623df000f14368137198649cb083
Subject: [Simple] Adding a telephone number to a basic PIDF document
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1406110660=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1406110660==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5CAC5.F02FCA79"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5CAC5.F02FCA79
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

My apologies if I have addressed this to the wrong alias, but I am
having a PIDF problem which I need help with.  My goal is to add a user
specified phone number to an existing PIDF document format.  I do not
wish to make a SIP endpoint available for A/V calls, just to tell people
how to dial my PSTN number.  My starting point is a basic PIDF document
like the following-

=20

<presence xmlns=3D"urn:ietf:params:xml:ns:pidf"
xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"=20

xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid" =
entity=3D"sip:foo@bar.com">

  <tuple id=3D"0">

    <status>

      <basic>open</basic>

      <ep:activities>

        <ep:activity>away</ep:activity>

      </ep:activities>

    </status>

  </tuple>

  <ci:display-name>Foo Bar</ci:display-name>

</presence>

=20

Excluding the option of vcard, I assume that I need to add this phone as
a device.  So I add a device tuple.  Since I have nothing more reliable
to use than the telephone number, it is used in both the id attribute
and the deviceID element.  Draft-ietf-simple-presence-data-model-05
doesn't state explicitly as far as I can tell, but reading between the
lines I don't think I can have a device without an associated deviceID
element pointing to it from a service.  I also assume that the 'note'
element for device is interpreted differently from a note for person or
under the 'presence' root so that the note is merely a descriptor of the
device.  I only assume this because I don't see a better candidate for
describing the device.  Assuming that, my original document is modified
as follows-

=20

<presence xmlns=3D"urn:ietf:params:xml:ns:pidf"
xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"=20

xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid"
xmlns:dm=3D"urn:ietf:params:xml:ns:pidf:data-model"
entity=3D"sip:foo@bar.com">

  <tuple id=3D"0">

    <status>

      <basic>open</basic>

      <ep:activities>

        <ep:activity>away</ep:activity>

      </ep:activities>

    </status>

  <dm:deviceID>tel:+4255551234</dm:deviceID>
 </tuple>

  <ci:display-name>Foo Bar</ci:display-name>

 <dm:device id=3D"4255551234">
   <dm:deviceID>urn:tel:+4255551234</dm:deviceID>
   <dm:note>Home Phone</dm:note>
 </dm:device>

</presence>

=20

Is this how other folks are implementing this?

=20

Thanks for your feedback,

Tim Rang


------_=_NextPart_001_01C5CAC5.F02FCA79
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>My apologies if I have addressed this to the wrong =
alias,
but I am having a PIDF problem which I need help with.&nbsp; My goal is =
to add
a user specified phone number to an existing PIDF document format. =
&nbsp;I do
not wish to make a SIP endpoint available for A/V calls, just to tell =
people
how to dial my PSTN number. &nbsp;My starting point is a basic PIDF =
document
like the following-<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&lt;presence =
xmlns=3D&quot;urn:ietf:params:xml:ns:pidf&quot; =
xmlns:ep=3D&quot;urn:ietf:params:xml:ns:pidf:status:rpid-status&quot;
xmlns:et=3D&quot;urn:ietf:params:xml:ns:pidf:rpid-tuple&quot; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:.5in'><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>xmlns:ci=3D&quot;urn:ietf:pa=
rams:xml:ns:pidf:cipid&quot;
entity=3D&quot;sip:foo@bar.com&quot;&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; &lt;tuple =
id=3D&quot;0&quot;&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp; =
&lt;status&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;basic&gt;open&lt;/basic&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;ep:activities&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;ep:activity&gt;away&lt;/ep:activity&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/ep:activities&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp; =
&lt;/status&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; &lt;/tuple&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; &lt;ci:display-name&gt;Foo
Bar&lt;/ci:display-name&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&lt;/presence&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Excluding the option of vcard, I assume that I need =
to add
this phone as a device.&nbsp; So I add a device tuple.&nbsp; Since I =
have
nothing more reliable to use than the telephone number, it is used in =
both the
id attribute and the deviceID element.&nbsp; =
Draft-ietf-simple-presence-data-model-05
doesn&#8217;t state explicitly as far as I can tell, but reading between =
the
lines I don&#8217;t think I can have a device without an associated =
deviceID
element pointing to it from a service.&nbsp; I also assume that the =
&#8216;note&#8217;
element for device is interpreted differently from a note for person or =
under
the &#8216;presence&#8217; root so that the note is merely a descriptor =
of the
device.&nbsp; I only assume this because I don&#8217;t see a better =
candidate
for describing the device.&nbsp; Assuming that, my original document is
modified as follows-<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&lt;presence =
xmlns=3D&quot;urn:ietf:params:xml:ns:pidf&quot; =
xmlns:ep=3D&quot;urn:ietf:params:xml:ns:pidf:status:rpid-status&quot;
xmlns:et=3D&quot;urn:ietf:params:xml:ns:pidf:rpid-tuple&quot; =
<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>xmlns:ci=3D&quot;urn:ietf:params:xml:ns:pidf:c=
ipid&quot; <b><font
color=3Dred><span =
style=3D'color:red;font-weight:bold'>xmlns:dm=3D&quot;urn:ietf:params:xml=
:ns:pidf:data-model&quot;</span></font></b> =
entity=3D&quot;sip:foo@bar.com&quot;&gt;<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; &lt;tuple =
id=3D&quot;0&quot;&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp; =
&lt;status&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;basic&gt;open&lt;/basic&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;ep:activities&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;ep:activity&gt;away&lt;/ep:activity&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/ep:activities&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp; =
&lt;/status&gt;<o:p></o:p></span></font></p>

<pre><b><font size=3D2 color=3Dred face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
color:red;font-weight:bold'>&nbsp; =
&lt;dm:deviceID&gt;tel:+4255551234&lt;/dm:deviceID&gt;<o:p></o:p></span><=
/font></b></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
</span></font><font
face=3DArial><span =
style=3D'font-family:Arial'>&lt;/tuple&gt;</span></font><b><font
color=3Dred><span =
style=3D'color:red;font-weight:bold'><o:p></o:p></span></font></b></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; &lt;ci:display-name&gt;Foo
Bar&lt;/ci:display-name&gt;<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;<b><font
color=3Dred><span style=3D'color:red;font-weight:bold'>&lt;dm:device =
id=3D&quot;4255551234&quot;&gt;<o:p></o:p></span></font></b></span></font=
></pre><pre><b><font
size=3D2 color=3Dred face=3D"Courier New"><span =
style=3D'font-size:10.0pt;color:red;
font-weight:bold'>&nbsp;&nbsp; =
&lt;dm:deviceID&gt;urn:tel:+4255551234&lt;/dm:deviceID&gt;<o:p></o:p></sp=
an></font></b></pre><pre><b><font
size=3D2 color=3Dred face=3D"Courier New"><span =
style=3D'font-size:10.0pt;color:red;
font-weight:bold'>&nbsp; &nbsp;&lt;dm:note&gt;Home =
Phone&lt;/dm:note&gt;<o:p></o:p></span></font></b></pre><pre><b><font
size=3D2 color=3Dred face=3D"Courier New"><span =
style=3D'font-size:10.0pt;color:red;
font-weight:bold'> &lt;/dm:device&gt;<o:p></o:p></span></font></b></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&lt;/presence&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Is this how other folks are implementing =
this?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Thanks for your feedback,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Tim Rang<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C5CAC5.F02FCA79--


--===============1406110660==
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

--===============1406110660==--




From simple-bounces@ietf.org Thu Oct 06 19:26:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENf83-0005FZ-L2; Thu, 06 Oct 2005 19:26:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENf82-0005FP-Vb
	for simple@megatron.ietf.org; Thu, 06 Oct 2005 19:26:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26633
	for <simple@ietf.org>; Thu, 6 Oct 2005 19:26:19 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENfHE-0006Nu-2o
	for simple@ietf.org; Thu, 06 Oct 2005 19:35:52 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 06 Oct 2005 16:26:14 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.97,184,1125903600"; 
	d="scan'208"; a="12736442:sNHT23958696"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j96NQBBa011928; 
	Thu, 6 Oct 2005 19:26:11 -0400 (EDT)
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);
	Thu, 6 Oct 2005 19:26:11 -0400
Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 19:26:10 -0400
Message-ID: <4345B292.70506@cisco.com>
Date: Thu, 06 Oct 2005 19:26:10 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Rang <timrang@microsoft.com>
Subject: Re: [Simple] Adding a telephone number to a basic PIDF document
References: <1BEC4DA05ABCD34FACFCFC82086AC24707A41062@RED-MSG-43.redmond.corp.microsoft.com>
In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC24707A41062@RED-MSG-43.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
X-OriginalArrivalTime: 06 Oct 2005 23:26:10.0716 (UTC)
	FILETIME=[55D695C0:01C5CACD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA26633
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Tim,

I wouldn't do it the way you propose.

I would simply add an extra <tuple> with a <contact> containing the=20
telephone number as a tel: uri. You can also identify it as a different=20
device if you wish. I believe you may do that as a deviceID in the tuple=20
*without* also including <device>.

But I am confused about your intent. It looks like you intend to have=20
one tuple even without the phone number. (Since you are from MS I am=20
pretty sure you must plan to have a PC in here.) But then I am confused=20
because your tuple is open but has no contact - so it isn't *very* open.

If my assumption is right, I would expect something like:

<presence xmlns=3D"urn:ietf:params:xml:ns:pidf"=20
xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"=20
xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"

xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid"=20
xmlns:dm=3D"urn:ietf:params:xml:ns:pidf:data-model" entity=3D"sip:foo@bar=
.com">
   <tuple id=3D"0">
     <status>
       <basic>closed</basic>
       <ep:activities>
         <ep:activity>away</ep:activity>
       </ep:activities>
     </status>
     <dm:deviceID>your-pc</dm:deviceID>
   </tuple>
   <tuple id=3D"1">
     <status>
       <basic>open</basic>
       <ep:activities>
         <ep:activity>away</ep:activity>
       </ep:activities>
     </status>
     <contact>tel:+4255551234</contact>
     <dm:deviceID>tel:+4255551234</dm:deviceID>
   </tuple>
</presence>

You could of course put in <device> as well if you want, but I don't see=20
any need here.

	Paul

Tim Rang wrote:
> My apologies if I have addressed this to the wrong alias, but I am=20
> having a PIDF problem which I need help with.  My goal is to add a user=
=20
> specified phone number to an existing PIDF document format.  I do not=20
> wish to make a SIP endpoint available for A/V calls, just to tell peopl=
e=20
> how to dial my PSTN number.  My starting point is a basic PIDF document=
=20
> like the following-
>=20
> =20
>=20
> <presence xmlns=3D"urn:ietf:params:xml:ns:pidf"=20
> xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"=20
> xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"
>=20
> xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid" entity=3D"sip:foo@bar.co=
m">
>=20
>   <tuple id=3D"0">
>=20
>     <status>
>=20
>       <basic>open</basic>
>=20
>       <ep:activities>
>=20
>         <ep:activity>away</ep:activity>
>=20
>       </ep:activities>
>=20
>     </status>
>=20
>   </tuple>
>=20
>   <ci:display-name>Foo Bar</ci:display-name>
>=20
> </presence>
>=20
> =20
>=20
> Excluding the option of vcard, I assume that I need to add this phone a=
s=20
> a device.  So I add a device tuple.  Since I have nothing more reliable=
=20
> to use than the telephone number, it is used in both the id attribute=20
> and the deviceID element.  Draft-ietf-simple-presence-data-model-05=20
> doesn=92t state explicitly as far as I can tell, but reading between th=
e=20
> lines I don=92t think I can have a device without an associated deviceI=
D=20
> element pointing to it from a service.  I also assume that the =91note=92=
=20
> element for device is interpreted differently from a note for person or=
=20
> under the =91presence=92 root so that the note is merely a descriptor o=
f the=20
> device.  I only assume this because I don=92t see a better candidate fo=
r=20
> describing the device.  Assuming that, my original document is modified=
=20
> as follows-
>=20
> =20
>=20
> <presence xmlns=3D"urn:ietf:params:xml:ns:pidf"=20
> xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"=20
> xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"
>=20
> xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid" *xmlns:dm=3D"urn:ietf:pa=
rams:xml:ns:pidf:data-model"* entity=3D"sip:foo@bar.com">
>=20
>   <tuple id=3D"0">
>=20
>     <status>
>=20
>       <basic>open</basic>
>=20
>       <ep:activities>
>=20
>         <ep:activity>away</ep:activity>
>=20
>       </ep:activities>
>=20
>     </status>
>=20
> *  <dm:deviceID>tel:+4255551234</dm:deviceID>*
>=20
>  </tuple>**
>=20
>   <ci:display-name>Foo Bar</ci:display-name>
>=20
>  *<dm:device id=3D"4255551234">*
>=20
> *   <dm:deviceID>urn:tel:+4255551234</dm:deviceID>*
>=20
> *   <dm:note>Home Phone</dm:note>*
>=20
> * </dm:device>*
>=20
> </presence>
>=20
> =20
>=20
> Is this how other folks are implementing this?
>=20
> =20
>=20
> Thanks for your feedback,
>=20
> Tim Rang
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

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



From simple-bounces@ietf.org Thu Oct 06 21:35:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENh9I-0006iE-5F; Thu, 06 Oct 2005 21:35:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENh9G-0006hy-A2
	for simple@megatron.ietf.org; Thu, 06 Oct 2005 21:35:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01755
	for <simple@ietf.org>; Thu, 6 Oct 2005 21:35:44 -0400 (EDT)
Received: from mail2.microsoft.com ([131.107.3.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENhIS-0002yT-Gn
	for simple@ietf.org; Thu, 06 Oct 2005 21:45:17 -0400
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.2499); 
	Thu, 6 Oct 2005 18:35:35 -0700
Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by
	mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 6 Oct 2005 18:35:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] Adding a telephone number to a basic PIDF document
Date: Thu, 6 Oct 2005 18:35:35 -0700
Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC247650AB5@RED-MSG-43.redmond.corp.microsoft.com>
Thread-Topic: [Simple] Adding a telephone number to a basic PIDF document
thread-index: AcXKzWNz52k28OBvTcCDeWUWAJmrgQADr30Z
References: <1BEC4DA05ABCD34FACFCFC82086AC24707A41062@RED-MSG-43.redmond.corp.microsoft.com>
	<4345B292.70506@cisco.com>
From: "Tim Rang" <timrang@microsoft.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 07 Oct 2005 01:35:36.0031 (UTC)
	FILETIME=[6A539EF0:01C5CADF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Content-Transfer-Encoding: quoted-printable
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Thanks Paul.  Would it be fair to say that devices are generally only =
used when multiple services need to be represented together? =20
=20
Back to your question regarding the missing contact element, it looks =
like I have something else I need to clear up.  The schema in RFC 3863 =
makes contact an optional element for tuple.  I figured that if the =
contact is omitted, then it should be simply derived from either the =
subscription request URI, or the entity attribute.  If that is not the =
case, and the contact element really is optional, then what does it mean =
to have a tuple with no contact?=20

Tim

________________________________

From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Thu 10/6/2005 4:26 PM
To: Tim Rang
Cc: Simple WG
Subject: Re: [Simple] Adding a telephone number to a basic PIDF document



Tim,

I wouldn't do it the way you propose.

I would simply add an extra <tuple> with a <contact> containing the
telephone number as a tel: uri. You can also identify it as a different
device if you wish. I believe you may do that as a deviceID in the tuple
*without* also including <device>.

But I am confused about your intent. It looks like you intend to have
one tuple even without the phone number. (Since you are from MS I am
pretty sure you must plan to have a PC in here.) But then I am confused
because your tuple is open but has no contact - so it isn't *very* open.

If my assumption is right, I would expect something like:

<presence xmlns=3D"urn:ietf:params:xml:ns:pidf"
xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"

xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid"
xmlns:dm=3D"urn:ietf:params:xml:ns:pidf:data-model" =
entity=3D"sip:foo@bar.com">
   <tuple id=3D"0">
     <status>
       <basic>closed</basic>
       <ep:activities>
         <ep:activity>away</ep:activity>
       </ep:activities>
     </status>
     <dm:deviceID>your-pc</dm:deviceID>
   </tuple>
   <tuple id=3D"1">
     <status>
       <basic>open</basic>
       <ep:activities>
         <ep:activity>away</ep:activity>
       </ep:activities>
     </status>
     <contact>tel:+4255551234</contact>
     <dm:deviceID>tel:+4255551234</dm:deviceID>
   </tuple>
</presence>

You could of course put in <device> as well if you want, but I don't see
any need here.

        Paul

Tim Rang wrote:
> My apologies if I have addressed this to the wrong alias, but I am
> having a PIDF problem which I need help with.  My goal is to add a =
user
> specified phone number to an existing PIDF document format.  I do not
> wish to make a SIP endpoint available for A/V calls, just to tell =
people
> how to dial my PSTN number.  My starting point is a basic PIDF =
document
> like the following-
>
>=20
>
> <presence xmlns=3D"urn:ietf:params:xml:ns:pidf"
> xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"
> xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"
>
> xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid" =
entity=3D"sip:foo@bar.com">
>
>   <tuple id=3D"0">
>
>     <status>
>
>       <basic>open</basic>
>
>       <ep:activities>
>
>         <ep:activity>away</ep:activity>
>
>       </ep:activities>
>
>     </status>
>
>   </tuple>
>
>   <ci:display-name>Foo Bar</ci:display-name>
>
> </presence>
>
>=20
>
> Excluding the option of vcard, I assume that I need to add this phone =
as
> a device.  So I add a device tuple.  Since I have nothing more =
reliable
> to use than the telephone number, it is used in both the id attribute
> and the deviceID element.  Draft-ietf-simple-presence-data-model-05
> doesn't state explicitly as far as I can tell, but reading between the
> lines I don't think I can have a device without an associated deviceID
> element pointing to it from a service.  I also assume that the 'note'
> element for device is interpreted differently from a note for person =
or
> under the 'presence' root so that the note is merely a descriptor of =
the
> device.  I only assume this because I don't see a better candidate for
> describing the device.  Assuming that, my original document is =
modified
> as follows-
>
>=20
>
> <presence xmlns=3D"urn:ietf:params:xml:ns:pidf"
> xmlns:ep=3D"urn:ietf:params:xml:ns:pidf:status:rpid-status"
> xmlns:et=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple"
>
> xmlns:ci=3D"urn:ietf:params:xml:ns:pidf:cipid" =
*xmlns:dm=3D"urn:ietf:params:xml:ns:pidf:data-model"* =
entity=3D"sip:foo@bar.com">
>
>   <tuple id=3D"0">
>
>     <status>
>
>       <basic>open</basic>
>
>       <ep:activities>
>
>         <ep:activity>away</ep:activity>
>
>       </ep:activities>
>
>     </status>
>
> *  <dm:deviceID>tel:+4255551234</dm:deviceID>*
>
>  </tuple>**
>
>   <ci:display-name>Foo Bar</ci:display-name>
>
>  *<dm:device id=3D"4255551234">*
>
> *   <dm:deviceID>urn:tel:+4255551234</dm:deviceID>*
>
> *   <dm:note>Home Phone</dm:note>*
>
> * </dm:device>*
>
> </presence>
>
>=20
>
> Is this how other folks are implementing this?
>
>=20
>
> Thanks for your feedback,
>
> Tim Rang
>
>
> =
------------------------------------------------------------------------
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple



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



From simple-bounces@ietf.org Fri Oct 07 00:14:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENjcb-00085O-DZ; Fri, 07 Oct 2005 00:14:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENjcY-00084n-QZ
	for simple@megatron.ietf.org; Fri, 07 Oct 2005 00:14:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07890
	for <simple@ietf.org>; Fri, 7 Oct 2005 00:14:07 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENjlm-0000Hr-LM
	for simple@ietf.org; Fri, 07 Oct 2005 00:23:42 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 06 Oct 2005 21:14:02 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.97,185,1125903600"; 
	d="scan'208"; a="12747215:sNHT21856092"
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 j974DxQl011793; 
	Fri, 7 Oct 2005 00:13:59 -0400 (EDT)
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);
	Fri, 7 Oct 2005 00:13:58 -0400
Received: from [192.168.1.100] ([10.86.242.54]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 00:13:58 -0400
Message-ID: <4345F606.7010000@cisco.com>
Date: Fri, 07 Oct 2005 00:13:58 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Tim Rang <timrang@microsoft.com>
Subject: Re: [Simple] Adding a telephone number to a basic PIDF document
References: <1BEC4DA05ABCD34FACFCFC82086AC24707A41062@RED-MSG-43.redmond.corp.microsoft.com>	<4345B292.70506@cisco.com>
	<1BEC4DA05ABCD34FACFCFC82086AC247650AB5@RED-MSG-43.redmond.corp.microsoft.com>
In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC247650AB5@RED-MSG-43.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Oct 2005 04:13:58.0491 (UTC)
	FILETIME=[8A3BF2B0:01C5CAF5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: Paul Kyzivat <pkyzivat@cisco.com>, Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Firstly, I agree with Paul, that if you want to have a way to tell a 
watcher, "here is a phone number to call me on the telephone", this is 
represented by a service in the data model, whose contact is a tel URI.

More below.

Tim Rang wrote:
> Thanks Paul.  Would it be fair to say that devices are generally only
> used when multiple services need to be represented together?

Devices serve many roles, one of which is as a correlator for services. 
They also serve to convey attributes which are, in fact, attributes of a 
physical device - geo-location, for example.

> 
> Back to your question regarding the missing contact element, it looks
> like I have something else I need to clear up.  The schema in RFC
> 3863 makes contact an optional element for tuple.  I figured that if
> the contact is omitted, then it should be simply derived from either
> the subscription request URI, or the entity attribute.  If that is
> not the case, and the contact element really is optional, then what
> does it mean to have a tuple with no contact?

No. If contact is not present, it means that the presentity wishes to 
indicate that the service is available, but a contact for reaching it is 
not being provided.

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

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



From simple-bounces@ietf.org Fri Oct 07 05:58:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENozO-0007mm-NK; Fri, 07 Oct 2005 05:58:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENozM-0007lL-0C
	for simple@megatron.ietf.org; Fri, 07 Oct 2005 05:58:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07774
	for <simple@ietf.org>; Fri, 7 Oct 2005 05:58:01 -0400 (EDT)
Received: from mail68.messagelabs.com ([193.109.255.67])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENp8c-000680-AH
	for simple@ietf.org; Fri, 07 Oct 2005 06:07:38 -0400
X-VirusChecked: Checked
X-Env-Sender: Phil.Young@anite.com
X-Msg-Ref: server-2.tower-68.messagelabs.com!1128679073!80443041!1
X-StarScan-Version: 5.4.15; banners=anite.com,-,-
X-Originating-IP: [62.255.240.193]
Received: (qmail 9332 invoked from network); 7 Oct 2005 09:57:53 -0000
Received: from unknown (HELO mailgate.anitetelecoms.com) (62.255.240.193)
	by server-2.tower-68.messagelabs.com with SMTP;
	7 Oct 2005 09:57:53 -0000
Received: by SVR001039 with Internet Mail Service (5.5.2653.19)
	id <SKD9L8NB>; Fri, 7 Oct 2005 10:52:16 +0100
Message-ID: <EB36A63BBE94DA489D4C80D2F48B1607052E1920@SVR001042>
From: "Young, Phil" <Phil.Young@anite.com>
To: "IETF SIMPLE Mailing List (simple@ietf.org)" <simple@ietf.org>
Date: Fri, 7 Oct 2005 10:53:27 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Subject: [Simple] Question regarding constraint upon optional "name"
	attribute of < list> element
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1496006237=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1496006237==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5CB24.F72BC830"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5CB24.F72BC830
Content-Type: text/plain

Hello,

The internet draft "draft-ietf-simple-xcap-list-usage-05"  states in section
3.4.5:

The "name" attribute in a <list> element MUST be unique amongst
      all other "name" attributes of <list> elements within the same
      parent element.  Uniqueness is determined by case sensitive string
      comparison.

However, in the Resource-lists schema the name attribute is optional.
Can/should such a constraint be imposed where the attribute is optional ?

Many thanks,

Phil Young 
Anite Telecoms 
Anite Telecoms Ltd, Ancells Business Park, Harvest Crescent, Fleet,
Hampshire, GU51 2UZ, UK 
Tel:+44 (0)1252 775354 
Fax:+44 (0)1252 775299 
E-mail: <mailto:phil.young@anite.com
www: <http://www.anite.com/telecoms> 

 



Scanned for viruses by MessageLabs. The integrity and security of this message cannot be guaranteed. This email is intended for the named recipient only, and may contain confidential information and proprietary material. Any unauthorised use or disclosure is prohibited.
------_=_NextPart_001_01C5CB24.F72BC830
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Question regarding constraint upon optional &quot;name&quot; attribute of &lt;list&gt; element</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello,</FONT>
</P>

<P><FONT SIZE=2>The internet draft &quot;draft-ietf-simple-xcap-list-usage-05&quot;&nbsp; states in section 3.4.5:</FONT>
</P>

<P><FONT SIZE=2>The &quot;name&quot; attribute in a &lt;list&gt; element MUST be unique amongst</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all other &quot;name&quot; attributes of &lt;list&gt; elements within the same</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; parent element.&nbsp; Uniqueness is determined by case sensitive string</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; comparison.</FONT>
</P>

<P><FONT SIZE=2>However, in the Resource-lists schema the name attribute is optional.</FONT>
<BR><FONT SIZE=2>Can/should such a constraint be imposed where the attribute is optional ?</FONT>
</P>

<P><FONT SIZE=2>Many thanks,</FONT>
</P>

<P><FONT SIZE=2>Phil Young </FONT>
<BR><FONT SIZE=2>Anite Telecoms </FONT>
<BR><FONT SIZE=2>Anite Telecoms Ltd, Ancells Business Park, Harvest Crescent, Fleet, Hampshire, GU51 2UZ, UK </FONT>
<BR><FONT SIZE=2>Tel:+44 (0)1252 775354 </FONT>
<BR><FONT SIZE=2>Fax:+44 (0)1252 775299 </FONT>
<BR><FONT SIZE=2>E-mail: &lt;<A HREF="mailto:phil.young@anite.com">mailto:phil.young@anite.com</A></FONT>
<BR><FONT SIZE=2>www: &lt;<A HREF="http://www.anite.com/telecoms" TARGET="_blank">http://www.anite.com/telecoms</A>&gt; </FONT>
</P>

<P><FONT SIZE=2>&nbsp;</FONT>
</P>


<BR>
Scanned for viruses by MessageLabs. The integrity and security of this message cannot be guaranteed. This email is intended for the named recipient only, and may contain confidential information and proprietary material. Any unauthorised use or disclosure is prohibited.<BR>
</BODY>
</HTML>

------_=_NextPart_001_01C5CB24.F72BC830--


--===============1496006237==
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

--===============1496006237==--




From simple-bounces@ietf.org Fri Oct 07 09:02:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENrrQ-0007Dx-Dk; Fri, 07 Oct 2005 09:02:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrrO-0007BL-B8
	for simple@megatron.ietf.org; Fri, 07 Oct 2005 09:02:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16373
	for <simple@ietf.org>; Fri, 7 Oct 2005 09:02:00 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ENs0g-00059A-6P
	for simple@ietf.org; Fri, 07 Oct 2005 09:11:39 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 07 Oct 2005 06:01:51 -0700
X-IronPort-AV: i="3.97,186,1125903600"; 
	d="scan'208"; a="349344650:sNHT27616044"
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 j97D1453028546;
	Fri, 7 Oct 2005 06:01:49 -0700 (PDT)
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);
	Fri, 7 Oct 2005 09:01:39 -0400
Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:01:38 -0400
Message-ID: <434671B2.4000900@cisco.com>
Date: Fri, 07 Oct 2005 09:01:38 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Rang <timrang@microsoft.com>
Subject: Re: [Simple] Adding a telephone number to a basic PIDF document
References: <1BEC4DA05ABCD34FACFCFC82086AC24707A41062@RED-MSG-43.redmond.corp.microsoft.com>
	<4345B292.70506@cisco.com>
	<1BEC4DA05ABCD34FACFCFC82086AC247650AB5@RED-MSG-43.redmond.corp.microsoft.com>
In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC247650AB5@RED-MSG-43.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Oct 2005 13:01:38.0483 (UTC)
	FILETIME=[410F5830:01C5CB3F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Tim Rang wrote:
> Thanks Paul.  Would it be fair to say that devices are generally only used when multiple services need to be represented together?  

Well, I'm still trying to understand all the implications of the 
<device> element, but here is my opinion. It was split off so that info 
that is inherently and necessarily common to all services sharing a 
device is represented once. But having done that, if you have such 
information, then you need the <device> element to represent it even if 
there is only one service using the device.

But, if you have no properties for the device, then you don't need the 
<device> element, even if there are multiple services sharing the device 
- it is enough to name the device(s) each service uses.

> Back to your question regarding the missing contact element, it looks like I have something else I need to clear up.  The schema in RFC 3863 makes contact an optional element for tuple.  I figured that if the contact is omitted, then it should be simply derived from either the subscription request URI, or the entity attribute.  If that is not the case, and the contact element really is optional, then what does it mean to have a tuple with no contact? 

Well, my understanding is that the <contact> element is the thing that 
tells you how to establish communication with the service. IMO nothing 
else serves that purpose. It is optional for the case when the the 
service is not reachable and/or you don't want to tell the watcher how 
to reach it. So I wouldn't be surprised to see it missing when the 
status is closed, but I do find it a little bit surprising when the 
status is open.

	Paul

> Tim
> 
> ________________________________
> 
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thu 10/6/2005 4:26 PM
> To: Tim Rang
> Cc: Simple WG
> Subject: Re: [Simple] Adding a telephone number to a basic PIDF document
> 
> 
> 
> Tim,
> 
> I wouldn't do it the way you propose.
> 
> I would simply add an extra <tuple> with a <contact> containing the
> telephone number as a tel: uri. You can also identify it as a different
> device if you wish. I believe you may do that as a deviceID in the tuple
> *without* also including <device>.
> 
> But I am confused about your intent. It looks like you intend to have
> one tuple even without the phone number. (Since you are from MS I am
> pretty sure you must plan to have a PC in here.) But then I am confused
> because your tuple is open but has no contact - so it isn't *very* open.
> 
> If my assumption is right, I would expect something like:
> 
> <presence xmlns="urn:ietf:params:xml:ns:pidf"
> xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status"
> xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
> 
> xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
> xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" entity="sip:foo@bar.com">
>    <tuple id="0">
>      <status>
>        <basic>closed</basic>
>        <ep:activities>
>          <ep:activity>away</ep:activity>
>        </ep:activities>
>      </status>
>      <dm:deviceID>your-pc</dm:deviceID>
>    </tuple>
>    <tuple id="1">
>      <status>
>        <basic>open</basic>
>        <ep:activities>
>          <ep:activity>away</ep:activity>
>        </ep:activities>
>      </status>
>      <contact>tel:+4255551234</contact>
>      <dm:deviceID>tel:+4255551234</dm:deviceID>
>    </tuple>
> </presence>
> 
> You could of course put in <device> as well if you want, but I don't see
> any need here.
> 
>         Paul
> 
> Tim Rang wrote:
> 
>>My apologies if I have addressed this to the wrong alias, but I am
>>having a PIDF problem which I need help with.  My goal is to add a user
>>specified phone number to an existing PIDF document format.  I do not
>>wish to make a SIP endpoint available for A/V calls, just to tell people
>>how to dial my PSTN number.  My starting point is a basic PIDF document
>>like the following-
>>
>>
>>
>><presence xmlns="urn:ietf:params:xml:ns:pidf"
>>xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status"
>>xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
>>
>>xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid" entity="sip:foo@bar.com">
>>
>>  <tuple id="0">
>>
>>    <status>
>>
>>      <basic>open</basic>
>>
>>      <ep:activities>
>>
>>        <ep:activity>away</ep:activity>
>>
>>      </ep:activities>
>>
>>    </status>
>>
>>  </tuple>
>>
>>  <ci:display-name>Foo Bar</ci:display-name>
>>
>></presence>
>>
>>
>>
>>Excluding the option of vcard, I assume that I need to add this phone as
>>a device.  So I add a device tuple.  Since I have nothing more reliable
>>to use than the telephone number, it is used in both the id attribute
>>and the deviceID element.  Draft-ietf-simple-presence-data-model-05
>>doesn't state explicitly as far as I can tell, but reading between the
>>lines I don't think I can have a device without an associated deviceID
>>element pointing to it from a service.  I also assume that the 'note'
>>element for device is interpreted differently from a note for person or
>>under the 'presence' root so that the note is merely a descriptor of the
>>device.  I only assume this because I don't see a better candidate for
>>describing the device.  Assuming that, my original document is modified
>>as follows-
>>
>>
>>
>><presence xmlns="urn:ietf:params:xml:ns:pidf"
>>xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status"
>>xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
>>
>>xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid" *xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"* entity="sip:foo@bar.com">
>>
>>  <tuple id="0">
>>
>>    <status>
>>
>>      <basic>open</basic>
>>
>>      <ep:activities>
>>
>>        <ep:activity>away</ep:activity>
>>
>>      </ep:activities>
>>
>>    </status>
>>
>>*  <dm:deviceID>tel:+4255551234</dm:deviceID>*
>>
>> </tuple>**
>>
>>  <ci:display-name>Foo Bar</ci:display-name>
>>
>> *<dm:device id="4255551234">*
>>
>>*   <dm:deviceID>urn:tel:+4255551234</dm:deviceID>*
>>
>>*   <dm:note>Home Phone</dm:note>*
>>
>>* </dm:device>*
>>
>></presence>
>>
>>
>>
>>Is this how other folks are implementing this?
>>
>>
>>
>>Thanks for your feedback,
>>
>>Tim Rang
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Simple mailing list
>>Simple@ietf.org
>>https://www1.ietf.org/mailman/listinfo/simple
> 
> 

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



From simple-bounces@ietf.org Fri Oct 07 16:23:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENykC-0007Sd-Jj; Fri, 07 Oct 2005 16:23:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENykA-0007Oy-VR
	for simple@megatron.ietf.org; Fri, 07 Oct 2005 16:23:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20939
	for <simple@ietf.org>; Fri, 7 Oct 2005 16:23:00 -0400 (EDT)
Received: from mail2.microsoft.com ([131.107.3.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENytV-0002Ac-U1
	for simple@ietf.org; Fri, 07 Oct 2005 16:32:43 -0400
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.2499); 
	Fri, 7 Oct 2005 13:22:52 -0700
Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by
	mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 7 Oct 2005 13:22:52 -0700
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] Adding a telephone number to a basic PIDF document
Date: Fri, 7 Oct 2005 13:22:50 -0700
Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC24707A8EB20@RED-MSG-43.redmond.corp.microsoft.com>
Thread-Topic: [Simple] Adding a telephone number to a basic PIDF document
thread-index: AcXK9aXYwPphMhC8SEOZXSpdPqcVNgAhi65g
From: "Tim Rang" <timrang@microsoft.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>
X-OriginalArrivalTime: 07 Oct 2005 20:22:52.0044 (UTC)
	FILETIME=[E4882CC0:01C5CB7C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: quoted-printable
Cc: Paul Kyzivat <pkyzivat@cisco.com>, Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

1 question inline-

> -----Original Message-----
> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On
Behalf
> Of Jonathan Rosenberg
> Sent: Thursday, October 06, 2005 9:14 PM
> To: Tim Rang
> Cc: Paul Kyzivat; Simple WG
> Subject: Re: [Simple] Adding a telephone number to a basic PIDF
document
>=20
> Firstly, I agree with Paul, that if you want to have a way to tell a
> watcher, "here is a phone number to call me on the telephone", this is
> represented by a service in the data model, whose contact is a tel
URI.
>=20
> More below.
>=20
> Tim Rang wrote:
> > Thanks Paul.  Would it be fair to say that devices are generally
only
> > used when multiple services need to be represented together?
>=20
> Devices serve many roles, one of which is as a correlator for
services.
> They also serve to convey attributes which are, in fact, attributes of
a
> physical device - geo-location, for example.
>=20
> >
> > Back to your question regarding the missing contact element, it
looks
> > like I have something else I need to clear up.  The schema in RFC
> > 3863 makes contact an optional element for tuple.  I figured that if
> > the contact is omitted, then it should be simply derived from either
> > the subscription request URI, or the entity attribute.  If that is
> > not the case, and the contact element really is optional, then what
> > does it mean to have a tuple with no contact?
>=20
> No. If contact is not present, it means that the presentity wishes to
> indicate that the service is available, but a contact for reaching it
is
> not being provided.

[Tim Rang] What is the value of allowing that?  If a presence document's
purpose is to convey ability and willingness to communicate, then what
am I saying by showing a watcher a service which is effectively blocked
from that watcher by the omission of the contact?  If I don't want a
watcher to contact me at a service, I would just not let them see it at
all. =20

Is there a practical application for this and if not, why not require
the contact element always be present for services? =20

Thanks,
Tim


>=20
> -Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   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
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

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



From simple-bounces@ietf.org Fri Oct 07 17:11:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENzVV-0008I7-1o; Fri, 07 Oct 2005 17:11:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ENzVT-0008Gl-Ur
	for simple@megatron.ietf.org; Fri, 07 Oct 2005 17:11:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24935
	for <simple@ietf.org>; Fri, 7 Oct 2005 17:11:53 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENzep-0004hg-ME
	for simple@ietf.org; Fri, 07 Oct 2005 17:21:36 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2005 17:11:46 -0400
X-IronPort-AV: i="3.97,188,1125892800"; 
	d="scan'208"; a="73335348:sNHT24909040"
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 j97LBKRB015396; 
	Fri, 7 Oct 2005 17:11:44 -0400 (EDT)
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);
	Fri, 7 Oct 2005 17:11:42 -0400
Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 17:11:41 -0400
Message-ID: <4346E48D.2040408@cisco.com>
Date: Fri, 07 Oct 2005 17:11:41 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Rang <timrang@microsoft.com>
Subject: Re: [Simple] Adding a telephone number to a basic PIDF document
References: <1BEC4DA05ABCD34FACFCFC82086AC24707A8EB20@RED-MSG-43.redmond.corp.microsoft.com>
In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC24707A8EB20@RED-MSG-43.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Oct 2005 21:11:41.0617 (UTC)
	FILETIME=[B6B18A10:01C5CB83]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Tim Rang wrote:

>>>like I have something else I need to clear up.  The schema in RFC
>>>3863 makes contact an optional element for tuple.  I figured that if
>>>the contact is omitted, then it should be simply derived from either
>>>the subscription request URI, or the entity attribute.  If that is
>>>not the case, and the contact element really is optional, then what
>>>does it mean to have a tuple with no contact?
>>
>>No. If contact is not present, it means that the presentity wishes to
>>indicate that the service is available, but a contact for reaching it
>>is not being provided.
> 
> [Tim Rang] What is the value of allowing that?  If a presence document's
> purpose is to convey ability and willingness to communicate, then what
> am I saying by showing a watcher a service which is effectively blocked
> from that watcher by the omission of the contact?  If I don't want a
> watcher to contact me at a service, I would just not let them see it at
> all.  
> 
> Is there a practical application for this and if not, why not require
> the contact element always be present for services?  

Well, if you want to build a system that does this, that is fine. Nobody 
is saying you MUST create tuples with no contact.

I see value in describing the capabilies of a service that is not 
currently available. At least then a watcher might decide to check back 
later.

	Paul

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



From simple-bounces@ietf.org Fri Oct 07 18:30:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EO0jM-0002Ka-61; Fri, 07 Oct 2005 18:30:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EO0jK-0002KS-RG
	for simple@megatron.ietf.org; Fri, 07 Oct 2005 18:30:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00121
	for <simple@ietf.org>; Fri, 7 Oct 2005 18:30:15 -0400 (EDT)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO0si-0007lQ-2M
	for simple@ietf.org; Fri, 07 Oct 2005 18:40:00 -0400
Received: from [192.168.1.103] (c-24-1-44-191.hsd1.tx.comcast.net
	[24.1.44.191]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j97MUBT8061290
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 7 Oct 2005 17:30:12 -0500 (CDT) (envelope-from ben@nostrum.com)
In-Reply-To: <29ac328c05090707084d516342@mail.gmail.com>
References: <29ac328c05090707084d516342@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <75CDB793-561C-4F0F-8590-14B844129D5F@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] [MSRP] problem on send chuck message using MSRP
Date: Fri, 7 Oct 2005 17:30:14 -0500
To: Cheney Stallman <zodist@gmail.com>
X-Mailer: Apple Mail (2.734)
Received-SPF: pass (nostrum.com: 24.1.44.191 is authenticated by a trusted
	mechanism)
X-Spam-Score: 4.6 (++++)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Bob's client would, after some period of time defined by local  
policy, either drop the message or warn Bob of a problem. I suspect  
the local policy will often be something like "life of the session",  
but some endpoints might have a reason to make it shorter.

If Alice really needs to make sure all chunks are delivered, she  
requests delivery reports. But in your example, that does not matter  
because Alice never sent the missing chunk.


On Sep 7, 2005, at 9:08 AM, Cheney Stallman wrote:

> I occur a problem when send chuck message using MSRP.
>
> As protocol allow me send the chunk message without order.
> for example, alice send 10000byte to bob.
> First time alice fill Byte-Range is `1-2048/10000' ,
> then alice send Byte-Range as 2100-4096/10000 next time.
> and alice never send the Byte-Range of 2049-2099.
> there is a hole between two chunk.
> there is a problem as following:
> bob how to deal this fragement message?
> thanks in advanced.
>
> -- 
> _______________________________
> Reply mail in one business day.
> Email: zodist@gmail.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 Fri Oct 07 21:14:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EO3Hx-0003Th-7S; Fri, 07 Oct 2005 21:14:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EO3Hu-0003Ta-UN
	for simple@megatron.ietf.org; Fri, 07 Oct 2005 21:14:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09258
	for <simple@ietf.org>; Fri, 7 Oct 2005 21:14:08 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO3RI-0005Qi-QE
	for simple@ietf.org; Fri, 07 Oct 2005 21:23:54 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2005 21:14:01 -0400
X-IronPort-AV: i="3.97,189,1125892800"; 
	d="scan'208"; a="73343076:sNHT24688560"
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 j981DwQl014590; 
	Fri, 7 Oct 2005 21:13:59 -0400 (EDT)
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);
	Fri, 7 Oct 2005 21:13:58 -0400
Received: from [192.168.1.100] ([10.86.240.27]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 21:13:57 -0400
Message-ID: <43471D54.301@cisco.com>
Date: Fri, 07 Oct 2005 21:13:56 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Tim Rang <timrang@microsoft.com>
Subject: Re: [Simple] Adding a telephone number to a basic PIDF document
References: <1BEC4DA05ABCD34FACFCFC82086AC24707A8EB20@RED-MSG-43.redmond.corp.microsoft.com>
In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC24707A8EB20@RED-MSG-43.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Oct 2005 01:13:57.0789 (UTC)
	FILETIME=[8EED5CD0:01C5CBA5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: Paul Kyzivat <pkyzivat@cisco.com>, Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Tim Rang wrote:


>>No. If contact is not present, it means that the presentity wishes to
>>indicate that the service is available, but a contact for reaching it
> 
> is
> 
>>not being provided.
> 
> 
> [Tim Rang] What is the value of allowing that?  If a presence document's
> purpose is to convey ability and willingness to communicate, then what
> am I saying by showing a watcher a service which is effectively blocked
> from that watcher by the omission of the contact?  If I don't want a
> watcher to contact me at a service, I would just not let them see it at
> all.  

I can imagine applications where I'd like to tell someone I'm on the 
phone, or have IM, but not necessarily give them the opportunity to 
contact me.

> 
> Is there a practical application for this and if not, why not require
> the contact element always be present for services?  

PIDF made it optional, and this was debated extensively during the 
development of PIDF as I recall (then again, most everything there was 
debated extensively....). Anyway, the current data model says nothing at 
all about omitting contact, and it should. I'll put some text in for 
that in the next revision.

Thanks,
Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Sat Oct 08 01:20:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EO77o-0005tb-4X; Sat, 08 Oct 2005 01:20:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EO77l-0005qq-WF
	for simple@megatron.ietf.org; Sat, 08 Oct 2005 01:19:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18286
	for <simple@ietf.org>; Sat, 8 Oct 2005 01:19:57 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO7HC-0003gj-L6
	for simple@ietf.org; Sat, 08 Oct 2005 01:29:43 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 08 Oct 2005 01:19:15 -0400
X-IronPort-AV: i="3.97,189,1125892800"; 
	d="scan'208"; a="73348467:sNHT27342594"
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 j985JDQl010814
	for <simple@ietf.org>; Sat, 8 Oct 2005 01:19:13 -0400 (EDT)
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);
	Sat, 8 Oct 2005 01:19:12 -0400
Received: from [192.168.1.100] ([10.86.240.27]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Oct 2005 01:19:12 -0400
Message-ID: <434756D0.6070708@cisco.com>
Date: Sat, 08 Oct 2005 01:19:12 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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 <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Oct 2005 05:19:12.0438 (UTC)
	FILETIME=[D18A9D60:01C5CBC7]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Content-Transfer-Encoding: 7bit
Subject: [Simple] A proposal for fixing the xcap schema problem and related
	issues
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Folks,

There was some debate about a month back about a problem identified in 
XCAP regarding namespace handling, coming out of some experiences in 
OMA. The specific mail that reported this problem can be found here:

http://www1.ietf.org/mail-archive/web/simple/current/msg05675.html

The quick summary is that, for implementations that don't normally store 
the entire XML document locally on the client, a GET or PUT of a 
fragment of the document is problematic, since the in-scope namespace 
bindings for that fragment won't be known. This makes it impossible to 
interpret the results of a GET, or to formulate the namespace prefixes 
in the content of the PUT so the resulting document is valid.

Several options were proposed, including OMA-specific fixes, revising 
xcap, or defining some extensions. I'd like to make a concrete proposal 
on how to move forward here.

Firstly, I think this problem needs to be addressed in IETF, and needs 
to be fixed in a way that is not specific to the OMA use cases. It has 
been an objective of xcap from its start that it be possible to perform 
manipulations on a document without the full document cached. Section 
5.10 of the -07 xcap draft talks about schema design guidelines that 
allow for xcap to work without having the document cached, for example. 
The problem reported by Per Hyttfors will affect any usage for which 
non-caching operation is needed, and will make any such usage cumbersome 
if not impossible. As such, it is not OMA specific, and I consider it a 
bug in the specification.

For this reason, my proposal is to ask IESG to remove xcap from the 
rfc-editor queue, so that I can issue an update to the draft that fixes 
this problem.

My proposal to fix the problem is to follow the recommendation made by Jari:

http://www.ietf.org/mail-archive/web/simple/current/msg05710.html

I would update the grammar of the node selector to allow for 
namespace::*. Such a selector would select the namespace bindings in 
scope for the element in question. xcap would define a format for 
encoding those namespace bindings; basically, an xml fragment body with 
one element, the local name of the element in question, with xmlns and 
xmlns: attributes for each of the namespaces in scope, including the 
default.

For example, consider this document:

    <?xml version="1.0" encoding="UTF-8"?>
    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <service uri="sip:marketing at example.com">
       <a:list name="marketing">
         <a:entry uri="sip:joe at example.com"/>
         <a:entry uri="sip:sudhir at example.com"/>
       </a:list>
       <packages>
         <package>presence</package>
       </packages>
     </service>
    </rls-services>

The following query:

GET 
http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/namespaces::*

would return:

    <service xmlns="urn:ietf:params:xml:ns:rls-services"
       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>


This fixes the problem by allowing the client to get the in-scope 
bindings, and cache them, so they can be used to interpret subsequent 
GETs, and then used to create the namespace prefixes for elements in 
subsequent PUTs. Of course, the client needs to be sure that the cached 
namespace bindings havent changed prior to the PUT; the mechanisms in 
section 7.10 of XCAP apply here as normal.

I did investigate a few other solutions to the problem. In particular, I 
looked to see if the XML fragment interchange:

http://www.w3.org/TR/xml-fragment

could be used as a solution. The idea is that you could GET an element, 
and if you specify the MIME type for a "fragment with context format" in 
the Accept header, the server could return the element along with its 
context instead. Turns out, the XML format defined in the TR above only 
defines the fragment CONTEXT; there is no w3c-defined mechanism to 
convey an element along with its context. As such, we'd have to define 
it ourselves. I'd rather not do that, since its something better suited 
for w3c to do. I'd also rather stick with xpath-based approaches, rather 
than introduce yet another new piece of XML technology for this one problem.

Several other problems have been reported with the xcap specification 
since its approval, and I would propose that these also be addressed 
while I am revising the document. Specifically:


1. XCAP currently doesn't allow extensibility for the node-selector 
itself. This means that, as currently defined, we couldn't even formally 
define the above fix as an extension, even if we wanted to. Other 
possible node-selector extensions, such as:

http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-multiple-00.txt

would also not be formally possible as extensions.

This is relatively easy to fix; it requires the grammar for 
node-selector to add points of extensibility, and for some text to 
indicate that servers reject, with a 404, expressions they don't 
understand. Extensions to xcap that define a new node-selector would 
define an extension name for themselves. A client can then discover 
support for this new extension using the xcap-caps document as currently 
defined.

2. Jari has reported some areas of underspecification around insertions. 
In particular, how insertions are done relative to whitespace and 
comments. The proposal would be to add some text that specifies that in 
these cases, element insertions happen before whitespaces or comments.

3. XCAPs usage of directory structures between the username and the ~~ 
is very underspecified, and some interop problems have been reported. 
The lack of an ability to create sub-directories further complicates 
this. I'd propose to fix this by making it a responsibility of the 
application usage to define a well-known convention for constructing 
this component of the document selector, and recommend that no 
sub-directories be used at all. Rather, just documents right in the 
user's home directory. Furthermore, for application usages with just a 
single document, that this document be called "index".

4. A couple of nits have been reported, the worst of which are some 
extraneous double-quotes in the xmlns() xpointer expressions. I'd fix 
these too.



I would propose we limit the changes to xcap to these five items (the 
main problem plus the four above), and no more.

I don't know if the scope of changes here require a re-do of both WGLC 
and IETF last call, and/or re-do of approval from IESG. I would hope 
not, but this is something we need to discuss with Ted.

If the working group agrees with this direction, I will commit to a 
revision of xcap with these changes prior to the non-00 deadline for 
Vancouver. As such, please reply with comments ASAP, since time is 
running out (October 24!).

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Sat Oct 08 01:27:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EO7F4-0008Q4-97; Sat, 08 Oct 2005 01:27:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EO7F0-0008Pz-6S
	for simple@megatron.ietf.org; Sat, 08 Oct 2005 01:27:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18672
	for <simple@ietf.org>; Sat, 8 Oct 2005 01:27:25 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO7OQ-0003vW-9Q
	for simple@ietf.org; Sat, 08 Oct 2005 01:37:11 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 08 Oct 2005 01:27:17 -0400
X-IronPort-AV: i="3.97,189,1125892800"; 
	d="scan'208"; a="73348632:sNHT23593588"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j985REBa018837
	for <simple@ietf.org>; Sat, 8 Oct 2005 01:27:14 -0400 (EDT)
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);
	Sat, 8 Oct 2005 01:27:14 -0400
Received: from [192.168.1.100] ([10.86.240.27]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Oct 2005 01:27:13 -0400
Message-ID: <434758B0.7070205@cisco.com>
Date: Sat, 08 Oct 2005 01:27:12 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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 <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Oct 2005 05:27:13.0653 (UTC)
	FILETIME=[F05E3250:01C5CBC8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Subject: [Simple] an incremental step forward for xcap-diff and patch-ops
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Since the last IETF meeting, we havent yet resolved this issue of how to 
represent the changes in an XML document that are included in the 
xcap-diff format. The current draft uses an xcap change log type of 
format. The previous version used Jari's patch-ops, which has been 
contentious. The current mechanism doesnt work, due to some issues with 
CDATA encapsulation.

Xcap itself has a dependency on xcap-diff. Not for conveying the changes 
in XML document, but rather, for conveying etags. That aspect of the 
spec has been stable and uncontentious.

In order to at least break the dependencies and allow base xcap to move 
forward (though we have some work to do per my previous note), I'd 
propose to split the current xcap-diff draft in two. One part, which 
remains a working group item, defines just the format for representing 
the etag changes. The schema would define a point of extensibility for 
conveying the actual changes in the xml document, but not define a 
solution. I would then issue an individual -00 document with an xcap 
change-log type of format that could be used for this.

This would allow us to conclude on xcap-diff, and separately debate just 
the piece of it that describes the changes themself.

Comments?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Sat Oct 08 10:21:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EOFa4-000330-Hr; Sat, 08 Oct 2005 10:21:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EOFa2-00032s-CO
	for simple@megatron.ietf.org; Sat, 08 Oct 2005 10:21:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23412
	for <simple@ietf.org>; Sat, 8 Oct 2005 10:21:40 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOFjX-0000mV-6C
	for simple@ietf.org; Sat, 08 Oct 2005 10:31:32 -0400
Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net
	[141.153.174.94]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	j98ELDIX007031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 8 Oct 2005 10:21:14 -0400 (EDT)
Message-ID: <4347D5EB.6010204@cs.columbia.edu>
Date: Sat, 08 Oct 2005 10:21:31 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues (directory)
References: <434756D0.6070708@cisco.com>
In-Reply-To: <434756D0.6070708@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


> 3. XCAPs usage of directory structures between the username and the ~~ 
> is very underspecified, and some interop problems have been reported. 
> The lack of an ability to create sub-directories further complicates 
> this. I'd propose to fix this by making it a responsibility of the 
> application usage to define a well-known convention for constructing 
> this component of the document selector, and recommend that no 
> sub-directories be used at all. Rather, just documents right in the 
> user's home directory. Furthermore, for application usages with just a 
> single document, that this document be called "index".

Would it make sense to use the AUID as the file name? This avoids having 
to maintain and avoid collisions in yet another namespace that looks 
similar.

Example:

PUT /bill/resource-lists

In addition, the user name part is currently underspecified. There seems 
to be an implicit assumption that one XCAP server server serves exactly 
one domain, so that somehow the 'bill' above is related to whatever host 
the server runs on. (In the examples, this would be 
bill@xcap.example.com, but that's probably not what's intended.)

We have enough of a configuration mess at our hands without adding more 
unspecified linkages that must be resolved through some unknown 
mechanism that may or may not be universally deployed. I think the most 
sensible mechanism is to use the same NAPTR/SRV mechanism, even though 
that's not part of the standard HTTP resolution mechanism.

Henning

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



From simple-bounces@ietf.org Sat Oct 08 10:46:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EOFyC-0002qC-FI; Sat, 08 Oct 2005 10:46:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EOFy9-0002lT-0F
	for simple@megatron.ietf.org; Sat, 08 Oct 2005 10:46:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24681
	for <simple@ietf.org>; Sat, 8 Oct 2005 10:46:32 -0400 (EDT)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOG7b-0001LZ-Kz
	for simple@ietf.org; Sat, 08 Oct 2005 10:56:25 -0400
Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com)
	by execdsl.com (CommuniGate Pro SMTP 4.2.7)
	with ESMTP id 12653288; Sat, 08 Oct 2005 08:45:44 -0600
Message-Id: <6.2.1.2.0.20051008102154.02f14100@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sat, 08 Oct 2005 10:46:08 -0400
To: Jonathan Rosenberg <jdrosen@cisco.com>, Simple WG <simple@ietf.org>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and
	related issues
In-Reply-To: <434756D0.6070708@cisco.com>
References: <434756D0.6070708@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I would normally be reluctant to pull anything off of the RFC-Editor queue.
However, your comment (not reproduced below) that the current grammar makes 
extension impossible probably means we need at least some repair so that we 
can fix problems we find later.

With regard to the specific solution proposed, I have a couple of minor 
questions:

1) If the element the client is targeting is from some namespace (I believe 
definitionally true) doesn't the client need to fetch progressive namespace 
bindings in order to be able to ask the final binding question 
properly?  Or can the client make simplifying assumptions that are good 
enough to get the binding, but not good enough to write replacement elements?

2) With regard to the specific syntax, I think that if we use it we will 
need some more explanation.  Looking at the XPath spec, it becomes clear 
that namespace::* is the alternative to asking about a specific 
namespace.  In our usage that specific form is not needed.  The limited 
syntax is somewhat odd (no problem for computers, but humans will look and 
ask "why the *?)  So I would recommend that we put in some explanatory text 
as to what the meaning of the syntax is, without the reader needing to go 
look at the XPath specification.

3) If I am reading things right, we are inventing the syntax to return for 
a namespace::* reference in an XCAP specifier.  The example makes clear 
what the expected syntax is.  I think this is the right syntax.  We will 
however need to clearly describe that.  (I looked through the XPath 
specification, and the result of a namespace::* is defined only in terms of 
the logical structure.  And that structure is actually a collection of 
namespace nodes without the parent element. And the namespace nodes are 
simply the logical pair of local part for the namespace prefix and a 
string-value of the namespace URI.)

Yours,
Joel M. Halpern

At 01:19 AM 10/8/2005, Jonathan Rosenberg wrote:
>My proposal to fix the problem is to follow the recommendation made by Jari:
>
>http://www.ietf.org/mail-archive/web/simple/current/msg05710.html
>
>I would update the grammar of the node selector to allow for namespace::*. 
>Such a selector would select the namespace bindings in scope for the 
>element in question. xcap would define a format for encoding those 
>namespace bindings; basically, an xml fragment body with one element, the 
>local name of the element in question, with xmlns and xmlns: attributes 
>for each of the namespaces in scope, including the default.
>
>For example, consider this document:
>
>    <?xml version="1.0" encoding="UTF-8"?>
>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>     <service uri="sip:marketing at example.com">
>       <a:list name="marketing">
>         <a:entry uri="sip:joe at example.com"/>
>         <a:entry uri="sip:sudhir at example.com"/>
>       </a:list>
>       <packages>
>         <package>presence</package>
>       </packages>
>     </service>
>    </rls-services>
>
>The following query:
>
>GET 
>http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/namespaces::*
>
>would return:
>
>    <service xmlns="urn:ietf:params:xml:ns:rls-services"
>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>


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



From simple-bounces@ietf.org Tue Oct 11 07:18:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPI8u-0004fk-1W; Tue, 11 Oct 2005 07:18:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPI8s-0004ff-H4
	for simple@megatron.ietf.org; Tue, 11 Oct 2005 07:17:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14955
	for <simple@ietf.org>; Tue, 11 Oct 2005 07:17:56 -0400 (EDT)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPIIx-0004vy-Pk
	for simple@ietf.org; Tue, 11 Oct 2005 07:28:24 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9BBErMZ007597; Tue, 11 Oct 2005 14:14:55 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Oct 2005 14:17:40 +0300
Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by
	esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 11 Oct 2005 14:17:39 +0300
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
	j9BBHdL08846; Tue, 11 Oct 2005 14:17:39 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 0166593B6A; Tue, 11 Oct 2005 14:17:39 +0300 (EEST)
Message-ID: <434B9F52.3030206@nokia.com>
Date: Tue, 11 Oct 2005 14:17:38 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues
References: <434756D0.6070708@cisco.com>
In-Reply-To: <434756D0.6070708@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Oct 2005 11:17:39.0741 (UTC)
	FILETIME=[6421DCD0:01C5CE55]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

It is unfortunate that we have to fix these bugs, but it is still imo 
better than to start xcap-bis. Some comments inline.

ext Jonathan Rosenberg wrote:

> Folks,
>
> There was some debate about a month back about a problem identified in 
> XCAP regarding namespace handling, coming out of some experiences in 
> OMA. The specific mail that reported this problem can be found here:
>
> http://www1.ietf.org/mail-archive/web/simple/current/msg05675.html
>
> The quick summary is that, for implementations that don't normally 
> store the entire XML document locally on the client, a GET or PUT of a 
> fragment of the document is problematic, since the in-scope namespace 
> bindings for that fragment won't be known. This makes it impossible to 
> interpret the results of a GET, or to formulate the namespace prefixes 
> in the content of the PUT so the resulting document is valid.
>
> Several options were proposed, including OMA-specific fixes, revising 
> xcap, or defining some extensions. I'd like to make a concrete 
> proposal on how to move forward here.
>
> Firstly, I think this problem needs to be addressed in IETF, and needs 
> to be fixed in a way that is not specific to the OMA use cases. It has 
> been an objective of xcap from its start that it be possible to 
> perform manipulations on a document without the full document cached. 
> Section 5.10 of the -07 xcap draft talks about schema design 
> guidelines that allow for xcap to work without having the document 
> cached, for example. The problem reported by Per Hyttfors will affect 
> any usage for which non-caching operation is needed, and will make any 
> such usage cumbersome if not impossible. As such, it is not OMA 
> specific, and I consider it a bug in the specification.
>
> For this reason, my proposal is to ask IESG to remove xcap from the 
> rfc-editor queue, so that I can issue an update to the draft that 
> fixes this problem.
>
> My proposal to fix the problem is to follow the recommendation made by 
> Jari:
>
> http://www.ietf.org/mail-archive/web/simple/current/msg05710.html
>
> I would update the grammar of the node selector to allow for 
> namespace::*. Such a selector would select the namespace bindings in 
> scope for the element in question. xcap would define a format for 
> encoding those namespace bindings; basically, an xml fragment body 
> with one element, the local name of the element in question, with 
> xmlns and xmlns: attributes for each of the namespaces in scope, 
> including the default.
>
> For example, consider this document:
>
>    <?xml version="1.0" encoding="UTF-8"?>
>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>     <service uri="sip:marketing at example.com">
>       <a:list name="marketing">
>         <a:entry uri="sip:joe at example.com"/>
>         <a:entry uri="sip:sudhir at example.com"/>
>       </a:list>
>       <packages>
>         <package>presence</package>
>       </packages>
>     </service>
>    </rls-services>
>
> The following query:
>
> GET 
> http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/namespaces::* 
>
>
typo namespace::*

> would return:
>
>    <service xmlns="urn:ietf:params:xml:ns:rls-services"
>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>
out-of-scope comment, but I'd rather remove all references to 
schema-instance hints from any of the example instance documents.

>
> This fixes the problem by allowing the client to get the in-scope 
> bindings, and cache them, so they can be used to interpret subsequent 
> GETs, and then used to create the namespace prefixes for elements in 
> subsequent PUTs. Of course, the client needs to be sure that the 
> cached namespace bindings havent changed prior to the PUT; the 
> mechanisms in section 7.10 of XCAP apply here as normal.
>
> I did investigate a few other solutions to the problem. In particular, 
> I looked to see if the XML fragment interchange:
>
> http://www.w3.org/TR/xml-fragment
>
> could be used as a solution. The idea is that you could GET an 
> element, and if you specify the MIME type for a "fragment with context 
> format" in the Accept header, the server could return the element 
> along with its context instead. Turns out, the XML format defined in 
> the TR above only defines the fragment CONTEXT; there is no 
> w3c-defined mechanism to convey an element along with its context. As 
> such, we'd have to define it ourselves. I'd rather not do that, since 
> its something better suited for w3c to do. I'd also rather stick with 
> xpath-based approaches, rather than introduce yet another new piece of 
> XML technology for this one problem.
>
> Several other problems have been reported with the xcap specification 
> since its approval, and I would propose that these also be addressed 
> while I am revising the document. Specifically:
>
>
> 1. XCAP currently doesn't allow extensibility for the node-selector 
> itself. This means that, as currently defined, we couldn't even 
> formally define the above fix as an extension, even if we wanted to. 
> Other possible node-selector extensions, such as:
>
> http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-multiple-00.txt
>
> would also not be formally possible as extensions.
>
> This is relatively easy to fix; it requires the grammar for 
> node-selector to add points of extensibility, and for some text to 
> indicate that servers reject, with a 404, expressions they don't 
> understand. Extensions to xcap that define a new node-selector would 
> define an extension name for themselves. A client can then discover 
> support for this new extension using the xcap-caps document as 
> currently defined.
>
> 2. Jari has reported some areas of underspecification around 
> insertions. In particular, how insertions are done relative to 
> whitespace and comments. The proposal would be to add some text that 
> specifies that in these cases, element insertions happen before 
> whitespaces or comments.
>
There's actually two issues here: one with positional inserts and 
secondly whitespace text node handling in general. While I proposed that 
new element inserts should be put at the first possible position, 
there's at least one corner case that should be clearly specified, i.e.:
<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <person/>
</presence>
When you e.g. add <device> with put .../presence/device the current spec 
clearly mandates that <device> is the last child of  <presence>. 
However, if you put ../presence/device[1] the interpretation might be 
that <device> is the first child of <presence>. Whatever the model 
adopted in xcap, it should just be clearly expressed what's the meaning. 
A second example is when you'll put ../presence/tuple[3], using the 
first possible position imo seems to be the most reasonable, i.e. ending 
up with:
<presence>
  <tuple id="p1"/>
  <tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
Now I am assuming that xcap cannot put several siblings at the same time 
and there's not any magic handling of whitespace text nodes.  Then we 
might want to delete .../presence/tuple[@id="p1"]. XPath datamodel says 
that a text node cannot have another text node as a sibling node. So we 
should end up having a doc like this:
<presence>
  
  <tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
so the two whitespace text nodes have been catenated together. Then 
again we could delete the first text node child of <presence> with 
delete .../presence/text()[1] ending up with:
<presence><tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
or we could have replaced the first text node with put 
../presence/text()[1]  (pl: linefeed with two spaces):
<presence>
  <tuple id="p2"/><tuple id="p3"/>
  <!-- comment -->
  <person/>
</presence>
This would mean adding text() function to the BNF. However, I cannot 
imagine any reasonable way to add a whitespace text node between those 
two tuples. So I am NOT proposing to add text() function to the BNF,  
just trying to clarify the issue. And what's the issue actually ?  The 
canonical format of the document must be predictable, this means that 
some whitespace text nodes are meaningful (xml:space="preserve" is the 
default btw.). So I am just proposing that xcap spec just describes this 
issue, too.

> 3. XCAPs usage of directory structures between the username and the ~~ 
> is very underspecified, and some interop problems have been reported. 
> The lack of an ability to create sub-directories further complicates 
> this. I'd propose to fix this by making it a responsibility of the 
> application usage to define a well-known convention for constructing 
> this component of the document selector, and recommend that no 
> sub-directories be used at all. Rather, just documents right in the 
> user's home directory. Furthermore, for application usages with just a 
> single document, that this document be called "index".
>
Actually in my reference implementation I've have done this "automatic" 
sub-directory creation (in users "home" dir) and I still havn't figured 
it out whether there are any issues out there or not. Of course e.g. 
webdav has mkcol method for this.

> 4. A couple of nits have been reported, the worst of which are some 
> extraneous double-quotes in the xmlns() xpointer expressions. I'd fix 
> these too.
>
>
good. Also it might be worth noting that within location steps 
apostrophes (') can be used too (like in XPath).

>
> I would propose we limit the changes to xcap to these five items (the 
> main problem plus the four above), and no more.
>
> I don't know if the scope of changes here require a re-do of both WGLC 
> and IETF last call, and/or re-do of approval from IESG. I would hope 
> not, but this is something we need to discuss with Ted.
>
I'll also hope that these fixes can be done with the easiest possible 
effort.

> If the working group agrees with this direction, I will commit to a 
> revision of xcap with these changes prior to the non-00 deadline for 
> Vancouver. As such, please reply with comments ASAP, since time is 
> running out (October 24!).
>
> Thanks,
> Jonathan R.

thanks,
Jari

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



From simple-bounces@ietf.org Tue Oct 11 07:27:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPIHt-0006PR-GH; Tue, 11 Oct 2005 07:27:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIHs-0006P8-DV
	for simple@megatron.ietf.org; Tue, 11 Oct 2005 07:27:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15403
	for <simple@ietf.org>; Tue, 11 Oct 2005 07:27:15 -0400 (EDT)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPIRy-0005CA-F4
	for simple@ietf.org; Tue, 11 Oct 2005 07:37:42 -0400
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
	j9BBOCuE021100; Tue, 11 Oct 2005 14:24:15 +0300
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Oct 2005 14:27:13 +0300
Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 11 Oct 2005 14:27:12 +0300
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
	j9BBRCL10538; Tue, 11 Oct 2005 14:27:12 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 32E3693B75; Tue, 11 Oct 2005 14:27:12 +0300 (EEST)
Message-ID: <434BA190.2020304@nokia.com>
Date: Tue, 11 Oct 2005 14:27:12 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] an incremental step forward for xcap-diff and patch-ops
References: <434758B0.7070205@cisco.com>
In-Reply-To: <434758B0.7070205@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Oct 2005 11:27:12.0717 (UTC)
	FILETIME=[B9A70FD0:01C5CE56]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Jonathan Rosenberg wrote:

> Since the last IETF meeting, we havent yet resolved this issue of how 
> to represent the changes in an XML document that are included in the 
> xcap-diff format. The current draft uses an xcap change log type of 
> format. The previous version used Jari's patch-ops, which has been 
> contentious. The current mechanism doesnt work, due to some issues 
> with CDATA encapsulation.
>
> Xcap itself has a dependency on xcap-diff. Not for conveying the 
> changes in XML document, but rather, for conveying etags. That aspect 
> of the spec has been stable and uncontentious.
>
> In order to at least break the dependencies and allow base xcap to 
> move forward (though we have some work to do per my previous note), 
> I'd propose to split the current xcap-diff draft in two. One part, 
> which remains a working group item, defines just the format for 
> representing the etag changes. The schema would define a point of 
> extensibility for conveying the actual changes in the xml document, 
> but not define a solution. I would then issue an individual -00 
> document with an xcap change-log type of format that could be used for 
> this.
>
> This would allow us to conclude on xcap-diff, and separately debate 
> just the piece of it that describes the changes themself.
>
> Comments?
>
> Thanks,
> Jonathan R.

The other option would be to define the ETag changes content type in the 
base xcap spec, which can be as simple as <etags xmlns="urn:foo" 
prev="xxx" new="yyy"/> and continue xcap-diff as usual.
br,
Jari

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



From simple-bounces@ietf.org Tue Oct 11 08:25:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPJCe-0004gY-V4; Tue, 11 Oct 2005 08:25:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJCc-0004eo-7u
	for simple@megatron.ietf.org; Tue, 11 Oct 2005 08:25:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19241
	for <simple@ietf.org>; Tue, 11 Oct 2005 08:25:52 -0400 (EDT)
Received: from theater-sate.de ([81.169.138.67]
	helo=h93074.serverkompetenz.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPJMh-00075A-BB
	for simple@ietf.org; Tue, 11 Oct 2005 08:36:20 -0400
Received: from coyote (coyote.mmweg.RWTH-Aachen.DE [134.130.118.117])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by h93074.serverkompetenz.net (Postfix) with ESMTP id 6A65424C0A
	for <simple@ietf.org>; Tue, 11 Oct 2005 14:25:40 +0200 (CEST)
From: Sebastian Ley <sebastian@withouthat.org>
To: simple@ietf.org
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and
	related issues
Date: Tue, 11 Oct 2005 14:25:38 +0200
User-Agent: KMail/1.8.2
References: <434756D0.6070708@cisco.com> <434B9F52.3030206@nokia.com>
In-Reply-To: <434B9F52.3030206@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510111425.38605.sebastian@withouthat.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

* Jari Urpalainen wrote:

> Actually in my reference implementation I've have done this "automatic"
> sub-directory creation (in users "home" dir) and I still havn't figured
> it out whether there are any issues out there or not.

I think in that case the specification needs to clarify if there may be a 
document and a subdirectory with the same name in a given directory.

Since the concept of a directory is borrowed from filesystems that does not 
seem to make sense, but non-filesystem implementations might have no problem 
having a directory and a document with the same name. And since the document 
selector in XCAP always selects a document and never a directory there is no 
ambiguity there either.

In an implementation I mapped the whole document-selector to a key in an XML 
database. In that case there may be very well a directory and a document with 
the same name in a given directory. When doing a filesystem implementation, 
that gets rather difficult though...

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

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



From simple-bounces@ietf.org Tue Oct 11 18:25:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPSZL-0008Mi-Oy; Tue, 11 Oct 2005 18:25:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPSZK-0008KU-PP
	for simple@megatron.ietf.org; Tue, 11 Oct 2005 18:25:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07427
	for <simple@ietf.org>; Tue, 11 Oct 2005 18:25:55 -0400 (EDT)
Received: from marauder.andrew.com ([198.17.217.129])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPSjV-0003cI-N2
	for simple@ietf.org; Tue, 11 Oct 2005 18:36:30 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 17:25:46 -0500
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
	E-mail Filter (4.7); Tue, 11 Oct 2005 17:25:45 -0500
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 17:24:18 -0500
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC0D17BC84@aopex5.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Jari Urpalainen" <jari.urpalainen@nokia.com>,
	"ext Jonathan Rosenberg" <jdrosen@cisco.com>
Date: Tue, 11 Oct 2005 17:22:41 -0500
Subject: RE: [Simple] A proposal for fixing the xcap schema problem and
	relatedissues
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 11 Oct 2005 22:24:18.0179 (UTC)
	FILETIME=[850F2530:01C5CEB2]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: [Simple] A proposal for fixing the xcap schema problem and
	relatedissues
Thread-Index: AcXOVg9eNjvDAgWAROKLd0kHYp6HqgAWopzA
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0765903226=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============0765903226==
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
Content-Transfer-Encoding: base64

SmFyaSwNCg0KQXBvbG9naWVzLCBJIGRvbid0IHdhbnQgdG8gc2xvdyB0aGlzIGRvd24sIGJ1dCB5
b3VyIGNvbW1lbnRzIG9uIHRleHQoKSB0cmlnZ2VyZWQgYSBmZXcgdGhvdWdodHMuDQoNCkRvIHlv
dSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gc3RhdGUgcmVhc29ucyBmb3Igbm90
IGluY2x1ZGluZyB0aGlzIGZ1bmN0aW9uYWxpdHkgKGJvZHkgb2YgcmVxdWVzdHMgd291bGQgYmUg
dGV4dC9wbGFpbiByYXRoZXIgdGhhbiBhcHBsaWNhdGlvbi94bWwsIHdoaWNoIHdvdWxkIGhhdmUg
dG8gYmUgcXVvdGVkIHVwb24gaW5zZXJ0aW9uKSwgYW5kIHRoZSBsaW1pdGF0aW9ucyBvZiBub3Qg
YmVpbmcgYWJsZSB0byB1c2UgdGV4dCgpIChyZXF1aXJpbmcgdGhlIGVuY2xvc2luZyBlbGVtZW50
IGZvciBhbGwgdGV4dCBjaGFuZ2VzKS4gIA0KDQpGdXJ0aGVyLCBpcyB0aGUgZm9sbG93aW5nIHR5
cGUgb2YgdXNlIGNhc2UgdmFsaWQ/DQoNCjxwcmVzZW5jZT4NCiAgIDxub3RlIHhtbDppZD0ic29t
ZS1pZCI+U29tZSB0ZXh0PC9ub3RlPg0KPC9wcmVzZW5jZT4NCg0KUFVUIC4uLi9+fi9wcmVzZW5j
ZS9ub3RlL3RleHQoKVsxXQ0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQoNClRoaXMgdGV4dCBy
ZXBsYWNlcyB0aGUgb3JpZ2luYWwuICBUaGlzIGNvbnRhaW5zIFhNTCBjb21tZW50cyB0aGF0DQpu
ZWVkIHRvIGJlIHF1b3RlZCA8IS0tIG91Y2ggLS0+Lg0KDQoNCg0KTWlnaHQgYmUgd29ydGggbm90
aW5nIHRoYXQgaWYgdGhlIHRleHQoKSBmdW5jdGlvbiBpc24ndCBwcm92aWRlZCBhbmQgYSB1c2Vy
IG9ubHkgd2FudHMgdG8gdXBkYXRlIHRoZSB0ZXh0LiAgSWYgdGhleSBkb24ndCBrbm93IGFsbCB0
aGUgYXNzb2NpYXRlZCBhdHRyaWJ1dGVzIG9uIHRoZSBlbGVtZW50LCB0aGV5IG5lZWQgdG8gZmV0
Y2ggdGhlIGVsZW1lbnQgYmVmb3JlIHVwZGF0aW5nIGl0cyBjb250ZW50cy4NCg0KQ2hlZXJzLA0K
TWFydGluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaW1wbGUtYm91bmNl
c0BpZXRmLm9yZyBbbWFpbHRvOnNpbXBsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
SmFyaSBVcnBhbGFpbmVuDQpTZW50OiBUdWVzZGF5LCAxMSBPY3RvYmVyIDIwMDUgOToxOCBQTQ0K
VG86IGV4dCBKb25hdGhhbiBSb3NlbmJlcmcNCkNjOiBTaW1wbGUgV0cNClN1YmplY3Q6IFJlOiBb
U2ltcGxlXSBBIHByb3Bvc2FsIGZvciBmaXhpbmcgdGhlIHhjYXAgc2NoZW1hIHByb2JsZW0gYW5k
IHJlbGF0ZWRpc3N1ZXMNCg0KSXQgaXMgdW5mb3J0dW5hdGUgdGhhdCB3ZSBoYXZlIHRvIGZpeCB0
aGVzZSBidWdzLCBidXQgaXQgaXMgc3RpbGwgaW1vIA0KYmV0dGVyIHRoYW4gdG8gc3RhcnQgeGNh
cC1iaXMuIFNvbWUgY29tbWVudHMgaW5saW5lLg0KDQouLi48c25pcD4uLi4NCiAgDQogIDx0dXBs
ZSBpZD0icDIiLz48dHVwbGUgaWQ9InAzIi8+DQogIDwhLS0gY29tbWVudCAtLT4NCiAgPHBlcnNv
bi8+DQo8L3ByZXNlbmNlPg0Kc28gdGhlIHR3byB3aGl0ZXNwYWNlIHRleHQgbm9kZXMgaGF2ZSBi
ZWVuIGNhdGVuYXRlZCB0b2dldGhlci4gVGhlbiANCmFnYWluIHdlIGNvdWxkIGRlbGV0ZSB0aGUg
Zmlyc3QgdGV4dCBub2RlIGNoaWxkIG9mIDxwcmVzZW5jZT4gd2l0aCANCmRlbGV0ZSAuLi4vcHJl
c2VuY2UvdGV4dCgpWzFdIGVuZGluZyB1cCB3aXRoOg0KPHByZXNlbmNlPjx0dXBsZSBpZD0icDIi
Lz48dHVwbGUgaWQ9InAzIi8+DQogIDwhLS0gY29tbWVudCAtLT4NCiAgPHBlcnNvbi8+DQo8L3By
ZXNlbmNlPg0Kb3Igd2UgY291bGQgaGF2ZSByZXBsYWNlZCB0aGUgZmlyc3QgdGV4dCBub2RlIHdp
dGggcHV0IA0KLi4vcHJlc2VuY2UvdGV4dCgpWzFdICAocGw6IGxpbmVmZWVkIHdpdGggdHdvIHNw
YWNlcyk6DQo8cHJlc2VuY2U+DQogIDx0dXBsZSBpZD0icDIiLz48dHVwbGUgaWQ9InAzIi8+DQog
IDwhLS0gY29tbWVudCAtLT4NCiAgPHBlcnNvbi8+DQo8L3ByZXNlbmNlPg0KVGhpcyB3b3VsZCBt
ZWFuIGFkZGluZyB0ZXh0KCkgZnVuY3Rpb24gdG8gdGhlIEJORi4gSG93ZXZlciwgSSBjYW5ub3Qg
DQppbWFnaW5lIGFueSByZWFzb25hYmxlIHdheSB0byBhZGQgYSB3aGl0ZXNwYWNlIHRleHQgbm9k
ZSBiZXR3ZWVuIHRob3NlIA0KdHdvIHR1cGxlcy4gU28gSSBhbSBOT1QgcHJvcG9zaW5nIHRvIGFk
ZCB0ZXh0KCkgZnVuY3Rpb24gdG8gdGhlIEJORiwgIA0KanVzdCB0cnlpbmcgdG8gY2xhcmlmeSB0
aGUgaXNzdWUuIEFuZCB3aGF0J3MgdGhlIGlzc3VlIGFjdHVhbGx5ID8gIFRoZSANCmNhbm9uaWNh
bCBmb3JtYXQgb2YgdGhlIGRvY3VtZW50IG11c3QgYmUgcHJlZGljdGFibGUsIHRoaXMgbWVhbnMg
dGhhdCANCnNvbWUgd2hpdGVzcGFjZSB0ZXh0IG5vZGVzIGFyZSBtZWFuaW5nZnVsICh4bWw6c3Bh
Y2U9InByZXNlcnZlIiBpcyB0aGUgDQpkZWZhdWx0IGJ0dy4pLiBTbyBJIGFtIGp1c3QgcHJvcG9z
aW5nIHRoYXQgeGNhcCBzcGVjIGp1c3QgZGVzY3JpYmVzIHRoaXMgDQppc3N1ZSwgdG9vLg0KDQo8
c25pcD4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1l
c3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRh
aW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0
aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0
aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1
dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd



--===============0765903226==
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

--===============0765903226==--



From simple-bounces@ietf.org Wed Oct 12 02:34:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPaCU-0000E1-7v; Wed, 12 Oct 2005 02:34:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaCR-0000DA-LL
	for simple@megatron.ietf.org; Wed, 12 Oct 2005 02:34:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29921
	for <simple@ietf.org>; Wed, 12 Oct 2005 02:34:49 -0400 (EDT)
Received: from mgw-ext02.nokia.com ([131.228.20.94])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPaMg-0007go-Ov
	for simple@ietf.org; Wed, 12 Oct 2005 02:45:28 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9C6YEtV024063; Wed, 12 Oct 2005 09:34:16 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Oct 2005 09:34:07 +0300
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 12 Oct 2005 09:34:05 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j9C6Y6j26916; Wed, 12 Oct 2005 09:34:06 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id AE86093B6A; Wed, 12 Oct 2005 09:34:06 +0300 (EEST)
Message-ID: <434CAE5E.4030705@nokia.com>
Date: Wed, 12 Oct 2005 09:34:06 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ext Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and
	relatedissues
References: <AF9FCF3C02DB264EAF9872DFB6040FCC0D17BC84@aopex5.andrew.com>
In-Reply-To: <AF9FCF3C02DB264EAF9872DFB6040FCC0D17BC84@aopex5.andrew.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Oct 2005 06:34:05.0775 (UTC)
	FILETIME=[F16E6DF0:01C5CEF6]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Thomson, Martin wrote:

>Jari,
>
>Apologies, I don't want to slow this down, but your comments on text() triggered a few thoughts.
>
>Do you think that it would be helpful to state reasons for not including this functionality (body of requests would be text/plain rather than application/xml, which would have to be quoted upon insertion), and the limitations of not being able to use text() (requiring the enclosing element for all text changes).  
>
>Further, is the following type of use case valid?
>
><presence>
>   <note xml:id="some-id">Some text</note>
></presence>
>
>PUT .../~~/presence/note/text()[1]
>Content-Type: text/plain
>
>This text replaces the original.  This contains XML comments that
>need to be quoted <!-- ouch -->.
>
>
>
>Might be worth noting that if the text() function isn't provided and a user only wants to update the text.  If they don't know all the associated attributes on the element, they need to fetch the element before updating its contents.
>
>Cheers,
>Martin
>  
>
We have had some disputes in the past what is the level of flexibility 
of the xcap bnf. There are quite many cases which could also be used in 
xcap (and e.g. xml-patch-ops has text() for this particular reason): 
element value comparisons, comments etc.  However, of course it adds 
also some minor complexity to the protocol and these kind of things can 
easily be added later as an xcap extension if so desired. I do not 
definitely want to open Pandora's box here, just to fix clear bugs and 
have the rfc ready.
br,
Jari

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



From simple-bounces@ietf.org Wed Oct 12 02:58:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPaZK-0006fd-K7; Wed, 12 Oct 2005 02:58:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaZI-0006fY-KT
	for simple@megatron.ietf.org; Wed, 12 Oct 2005 02:58:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00972
	for <simple@ietf.org>; Wed, 12 Oct 2005 02:58:26 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPajX-0008Gm-Vt
	for simple@ietf.org; Wed, 12 Oct 2005 03:09:05 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9C6uU1s018482; Wed, 12 Oct 2005 09:56:33 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Oct 2005 09:58:18 +0300
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 12 Oct 2005 09:58:16 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j9C6wHj01082; Wed, 12 Oct 2005 09:58:17 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id A365393B6A; Wed, 12 Oct 2005 09:58:17 +0300 (EEST)
Message-ID: <434CB409.1020603@nokia.com>
Date: Wed, 12 Oct 2005 09:58:17 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Sebastian Ley <sebastian@withouthat.org>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and	related
	issues
References: <434756D0.6070708@cisco.com> <434B9F52.3030206@nokia.com>
	<200510111425.38605.sebastian@withouthat.org>
In-Reply-To: <200510111425.38605.sebastian@withouthat.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Oct 2005 06:58:16.0849 (UTC)
	FILETIME=[5256C010:01C5CEFA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Sebastian Ley wrote:

>* Jari Urpalainen wrote:
>
>  
>
>>Actually in my reference implementation I've have done this "automatic"
>>sub-directory creation (in users "home" dir) and I still havn't figured
>>it out whether there are any issues out there or not.
>>    
>>
>
>I think in that case the specification needs to clarify if there may be a 
>document and a subdirectory with the same name in a given directory.
>
>Since the concept of a directory is borrowed from filesystems that does not 
>seem to make sense, but non-filesystem implementations might have no problem 
>having a directory and a document with the same name. And since the document 
>selector in XCAP always selects a document and never a directory there is no 
>ambiguity there either.
>
>In an implementation I mapped the whole document-selector to a key in an XML 
>database. In that case there may be very well a directory and a document with 
>the same name in a given directory. When doing a filesystem implementation, 
>that gets rather difficult though...
>
>Regards,
>Sebastian
>
>  
>
Yes there are filesystems that certainly disallows having the same file 
& directory names. However, I have thought that this is more like an 
implementation issue but you are right it is certainly worth mentioning 
if it were allowed.

As a side question (for curiosity reasons), how does the xml db you are 
using store xml prolog data, e.g. xml entities ?
thanks,
Jari

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



From simple-bounces@ietf.org Thu Oct 13 02:55:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPx0C-000342-Np; Thu, 13 Oct 2005 02:55:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPx0B-00031d-Ij
	for simple@megatron.ietf.org; Thu, 13 Oct 2005 02:55:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27754
	for <simple@ietf.org>; Thu, 13 Oct 2005 02:55:38 -0400 (EDT)
Received: from [203.101.112.21] (helo=mail2.sonimtech.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPxAc-0000zL-1t
	for simple@ietf.org; Thu, 13 Oct 2005 03:06:32 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 Oct 2005 12:28:30 +0530
Message-ID: <E7F5A43EEB6E7C42A08C041BDEB90A5305B08F@mail2.sonimtech.com>
Thread-Topic: Re: A proposal for fixing the xcap schema problem and related
	issues
Thread-Index: AcXPw4SToPjF+kU7QnCtoOTfbbmSOg==
From: "Ramalakshmi V. Gunturi" <ramagv@sonimtech.com>
To: <simple@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


With reference to the earlier mail =
http://www1.ietf.org/mail-archive/web/simple/current/msg05810.html,

>>>>>>>>>>>>>> Quoting from the earlier mail >>>>>>>>>>>>>.

I would update the grammar of the node selector to allow for=20
namespace::*. Such a selector would select the namespace bindings in=20
scope for the element in question. xcap would define a format for=20
encoding those namespace bindings; basically, an xml fragment body with=20
one element, the local name of the element in question, with xmlns and=20
xmlns: attributes for each of the namespaces in scope, including the=20
default.

For example, consider this document:

    <?xml version=3D"1.0" encoding=3D"UTF-8"?>
    <rls-services xmlns=3D"urn:ietf:params:xml:ns:rls-services"
       xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
     <service uri=3D"sip:marketing at example.com">
       <a:list name=3D"marketing">
         <a:entry uri=3D"sip:joe at example.com"/>
         <a:entry uri=3D"sip:sudhir at example.com"/>
       </a:list>
       <packages>
         <package>presence</package>
       </packages>
     </service>
    </rls-services>

The following query:

GET=20
http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/names=
paces::*

would return:

    <service xmlns=3D"urn:ietf:params:xml:ns:rls-services"
       xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"/>


This fixes the problem by allowing the client to get the in-scope=20
bindings, and cache them, so they can be used to interpret subsequent=20
GETs, and then used to create the namespace prefixes for elements in=20
subsequent PUTs. Of course, the client needs to be sure that the cached=20
namespace bindings havent changed prior to the PUT; the mechanisms in=20
section 7.10 of XCAP apply here as normal.

<<<<<<<<<<<<<< end quoting from earlier mail <<<<<<<<<<<<<<<<<

As per my understanding, the above approach needs the whole request =
formation part to be done at runtime. Please correct me If I am wrong.=20

My question is that, If we want to identify and define the parameters =
that make up each request in a xml document, and then define another =
XSLT document to transform the request from the fomer XML document to an =
XCAP format, we will need to use standard parsers and transformers.

In this scenario, for put requests with xml fragments having namespaces, =
 the parser throws an error because in the payload there is no =
definition of namespace.
ex:
	fergus wants to add foo to his accept list.

				PUT =
http://xcap.example.com/services/org.openmobilealliance.poc-rules/users/s=
ip:fergus@example.com/pocrules/~~/cr:ruleset/cr: =
rule[@id=3D"accept"]/cr:conditions/cp:identity/cp:entry?xmlns(cr=3D"urn:i=
etf:params:xml:ns:commonpolicy")xmlns(cp=3D"urn:oma:params:xml:ns:commonp=
olicy") HTTP/1.1
=20
		<cp:entry id=3D"sip:foo@example.com" />

So when this payload in defined in the XSLT document and the XSL =
Transformer (javax.xml.transform.TransformerFactory) is used for =
generating the XCAP request, the transformer throws out an error saying =
"cp:entry not bound to parent", because as per the xml rules, the name =
space is not defined within the payload.

How do we overcome these type of issues ??



Thanks & Regards,
Rama


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



From simple-bounces@ietf.org Thu Oct 13 06:13:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQ05D-0005tU-9Z; Thu, 13 Oct 2005 06:13:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ05C-0005tP-H7
	for simple@megatron.ietf.org; Thu, 13 Oct 2005 06:13:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07246
	for <simple@ietf.org>; Thu, 13 Oct 2005 06:13:02 -0400 (EDT)
From: ac2491@cs.columbia.edu
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ0Fe-0006RZ-9G
	for simple@ietf.org; Thu, 13 Oct 2005 06:23:57 -0400
Received: from hydra.cs.columbia.edu
	(IDENT:83M1kSrmYinlobrUikRDKp3a4Racr73L@hydra.cs.columbia.edu
	[128.59.16.129])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9DAD0sw007401
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT)
	for <simple@ietf.org>; Thu, 13 Oct 2005 06:13:00 -0400 (EDT)
Received: from webmail.cs.columbia.edu
	(IDENT:a4ueMFX+WHU0zgZ3zThVduASCp4Hwucu@localhost [127.0.0.1])
	by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id j9DACxah010439; 
	Thu, 13 Oct 2005 06:12:59 -0400
Received: from 24.199.92.69 (SquirrelMail authenticated user ac2491)
	by webmail.cs.columbia.edu with HTTP;
	Thu, 13 Oct 2005 06:13:00 -0400 (EDT)
Message-ID: <32835.24.199.92.69.1129198380.squirrel@webmail.cs.columbia.edu>
Date: Thu, 13 Oct 2005 06:13:00 -0400 (EDT)
To: simple@ietf.org
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716,
	NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
	__HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
X-Spam-Score: 2.1 (++)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 8bit
Cc: jdrosen at <cisco.com@cs.columbia.edu>
Subject: [Simple] XCAP draft questions
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

Some very basic doubts.
1. How is the user first created in the xcap server?
"PUT /services/resource-lists/users/bill HTTP/1.1"
Will this associate a directory name-service "bill" in the xcap server
Or
"PUT /services/resource-lists/users/bill/fr.xml HTTP/1.1"
will this associate a directory name-service "bill" in the xcap server.
It has been recommended not to create sub-directories (in specific case of
a file system) for the document selector and create a single file.
Maybe the use of term "directory" at places is a bit mis-leading.

2. In example in Section 6.4
<ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
should be
<ns2:baz xmlns:baz="urn:test:namespace2-uri"/>
Looks like a typo.

3. As mentioned earlier the schema instance hints if removed would be nice.

4. In case of positional inserts, if a position specified is more than the
existing node count, should this be treated as an error case or should
insert happen at the last location?

Regards
-Anurag

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



From simple-bounces@ietf.org Fri Oct 14 03:46:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQKGp-0003Wr-Dv; Fri, 14 Oct 2005 03:46:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQKGo-0003Vy-88
	for simple@megatron.ietf.org; Fri, 14 Oct 2005 03:46:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23776
	for <simple@ietf.org>; Fri, 14 Oct 2005 03:46:20 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQKRT-0002ty-Kj
	for simple@ietf.org; Fri, 14 Oct 2005 03:57:28 -0400
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
	j9E7kLRx007843; Fri, 14 Oct 2005 10:46:21 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 14 Oct 2005 10:46:22 +0300
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 14 Oct 2005 10:46:21 +0300
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
Subject: RE: [Simple] A proposal for fixing the xcap schema problem and
	relatedissues
Date: Fri, 14 Oct 2005 10:46:19 +0300
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816C3A@esebe101.NOE.Nokia.com>
Thread-Topic: [Simple] A proposal for fixing the xcap schema problem and
	relatedissues
Thread-Index: AcXLyF3NdoeaWRNQSOOkSnRJ1Mk6ngEypOZg
To: <jdrosen@cisco.com>, <simple@ietf.org>
X-OriginalArrivalTime: 14 Oct 2005 07:46:21.0725 (UTC)
	FILETIME=[5EAF64D0:01C5D093]
X-Spam-Score: 2.3 (++)
X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I support the idea of pulling XCAP out of the RFC ed's queue and fixing =
the problems identified below. It would be important not expand the =
discussion to any more new features, though. Those should be done as =
separate extensions.

Markus

> -----Original Message-----
> From: simple-bounces@ietf.org=20
> [mailto:simple-bounces@ietf.org]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 08 October, 2005 08:19
> To: Simple WG
> Subject: [Simple] A proposal for fixing the xcap schema problem and
> relatedissues
>=20
>=20
> Folks,
>=20
> There was some debate about a month back about a problem=20
> identified in=20
> XCAP regarding namespace handling, coming out of some experiences in=20
> OMA. The specific mail that reported this problem can be found here:
>=20
> http://www1.ietf.org/mail-archive/web/simple/current/msg05675.html
>=20
> The quick summary is that, for implementations that don't=20
> normally store=20
> the entire XML document locally on the client, a GET or PUT of a=20
> fragment of the document is problematic, since the in-scope namespace=20
> bindings for that fragment won't be known. This makes it=20
> impossible to=20
> interpret the results of a GET, or to formulate the namespace=20
> prefixes=20
> in the content of the PUT so the resulting document is valid.
>=20
> Several options were proposed, including OMA-specific fixes, revising=20
> xcap, or defining some extensions. I'd like to make a=20
> concrete proposal=20
> on how to move forward here.
>=20
> Firstly, I think this problem needs to be addressed in IETF,=20
> and needs=20
> to be fixed in a way that is not specific to the OMA use=20
> cases. It has=20
> been an objective of xcap from its start that it be possible=20
> to perform=20
> manipulations on a document without the full document cached. Section=20
> 5.10 of the -07 xcap draft talks about schema design guidelines that=20
> allow for xcap to work without having the document cached,=20
> for example.=20
> The problem reported by Per Hyttfors will affect any usage for which=20
> non-caching operation is needed, and will make any such usage=20
> cumbersome=20
> if not impossible. As such, it is not OMA specific, and I=20
> consider it a=20
> bug in the specification.
>=20
> For this reason, my proposal is to ask IESG to remove xcap from the=20
> rfc-editor queue, so that I can issue an update to the draft=20
> that fixes=20
> this problem.
>=20
> My proposal to fix the problem is to follow the=20
> recommendation made by Jari:
>=20
> http://www.ietf.org/mail-archive/web/simple/current/msg05710.html
>=20
> I would update the grammar of the node selector to allow for=20
> namespace::*. Such a selector would select the namespace bindings in=20
> scope for the element in question. xcap would define a format for=20
> encoding those namespace bindings; basically, an xml fragment=20
> body with=20
> one element, the local name of the element in question, with=20
> xmlns and=20
> xmlns: attributes for each of the namespaces in scope, including the=20
> default.
>=20
> For example, consider this document:
>=20
>     <?xml version=3D"1.0" encoding=3D"UTF-8"?>
>     <rls-services xmlns=3D"urn:ietf:params:xml:ns:rls-services"
>        xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
>        xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
>      <service uri=3D"sip:marketing at example.com">
>        <a:list name=3D"marketing">
>          <a:entry uri=3D"sip:joe at example.com"/>
>          <a:entry uri=3D"sip:sudhir at example.com"/>
>        </a:list>
>        <packages>
>          <package>presence</package>
>        </packages>
>      </service>
>     </rls-services>
>=20
> The following query:
>=20
> GET=20
> http://xcap-root.com/rls-services/users/joe/~~/rls-services/se
> rvice/namespaces::*
>=20
> would return:
>=20
>     <service xmlns=3D"urn:ietf:params:xml:ns:rls-services"
>        xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
>        xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"/>
>=20
>=20
> This fixes the problem by allowing the client to get the in-scope=20
> bindings, and cache them, so they can be used to interpret subsequent=20
> GETs, and then used to create the namespace prefixes for elements in=20
> subsequent PUTs. Of course, the client needs to be sure that=20
> the cached=20
> namespace bindings havent changed prior to the PUT; the mechanisms in=20
> section 7.10 of XCAP apply here as normal.
>=20
> I did investigate a few other solutions to the problem. In=20
> particular, I=20
> looked to see if the XML fragment interchange:
>=20
> http://www.w3.org/TR/xml-fragment
>=20
> could be used as a solution. The idea is that you could GET=20
> an element,=20
> and if you specify the MIME type for a "fragment with context=20
> format" in=20
> the Accept header, the server could return the element along with its=20
> context instead. Turns out, the XML format defined in the TR=20
> above only=20
> defines the fragment CONTEXT; there is no w3c-defined mechanism to=20
> convey an element along with its context. As such, we'd have=20
> to define=20
> it ourselves. I'd rather not do that, since its something=20
> better suited=20
> for w3c to do. I'd also rather stick with xpath-based=20
> approaches, rather=20
> than introduce yet another new piece of XML technology for=20
> this one problem.
>=20
> Several other problems have been reported with the xcap specification=20
> since its approval, and I would propose that these also be addressed=20
> while I am revising the document. Specifically:
>=20
>=20
> 1. XCAP currently doesn't allow extensibility for the node-selector=20
> itself. This means that, as currently defined, we couldn't=20
> even formally=20
> define the above fix as an extension, even if we wanted to. Other=20
> possible node-selector extensions, such as:
>=20
> http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-mult
> iple-00.txt
>=20
> would also not be formally possible as extensions.
>=20
> This is relatively easy to fix; it requires the grammar for=20
> node-selector to add points of extensibility, and for some text to=20
> indicate that servers reject, with a 404, expressions they don't=20
> understand. Extensions to xcap that define a new node-selector would=20
> define an extension name for themselves. A client can then discover=20
> support for this new extension using the xcap-caps document=20
> as currently=20
> defined.
>=20
> 2. Jari has reported some areas of underspecification around=20
> insertions.=20
> In particular, how insertions are done relative to whitespace and=20
> comments. The proposal would be to add some text that=20
> specifies that in=20
> these cases, element insertions happen before whitespaces or comments.
>=20
> 3. XCAPs usage of directory structures between the username=20
> and the ~~=20
> is very underspecified, and some interop problems have been reported.=20
> The lack of an ability to create sub-directories further complicates=20
> this. I'd propose to fix this by making it a responsibility of the=20
> application usage to define a well-known convention for constructing=20
> this component of the document selector, and recommend that no=20
> sub-directories be used at all. Rather, just documents right in the=20
> user's home directory. Furthermore, for application usages=20
> with just a=20
> single document, that this document be called "index".
>=20
> 4. A couple of nits have been reported, the worst of which are some=20
> extraneous double-quotes in the xmlns() xpointer expressions. I'd fix=20
> these too.
>=20
>=20
>=20
> I would propose we limit the changes to xcap to these five items (the=20
> main problem plus the four above), and no more.
>=20
> I don't know if the scope of changes here require a re-do of=20
> both WGLC=20
> and IETF last call, and/or re-do of approval from IESG. I would hope=20
> not, but this is something we need to discuss with Ted.
>=20
> If the working group agrees with this direction, I will commit to a=20
> revision of xcap with these changes prior to the non-00 deadline for=20
> Vancouver. As such, please reply with comments ASAP, since time is=20
> running out (October 24!).
>=20
> Thanks,
> Jonathan R.
> --=20
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   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
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>=20

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



From simple-bounces@ietf.org Fri Oct 14 10:50:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQQtA-0002Qx-98; Fri, 14 Oct 2005 10:50:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQQsl-00028I-Kx; Fri, 14 Oct 2005 10:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14971;
	Fri, 14 Oct 2005 10:49:59 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EQR3U-0005lF-0W; Fri, 14 Oct 2005 11:01:08 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EQQsj-0003Sq-Bg; Fri, 14 Oct 2005 10:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EQQsj-0003Sq-Bg@newodin.ietf.org>
Date: Fri, 14 Oct 2005 10:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-12.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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		: The Message Session Relay Protocol
	Author(s)	: B. Campbell, et al.
	Filename	: draft-ietf-simple-message-sessions-12.txt
	Pages		: 57
	Date		: 2005-10-14
	
This document describes the Message Session Relay Protocol, a
   protocol for transmitting a series of related instant messages in the
   context of a session.  Message sessions are treated like any other
   media stream when set up via a rendezvous or session set up protocol
   such as the Session Initiation Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-12.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-message-sessions-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-message-sessions-12.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: <2005-10-14093922.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-message-sessions-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-message-sessions-12.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-14093922.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From simple-bounces@ietf.org Tue Oct 18 05:36:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERntf-0007wB-3c; Tue, 18 Oct 2005 05:36:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERntd-0007vw-PA
	for simple@megatron.ietf.org; Tue, 18 Oct 2005 05:36:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16911
	for <simple@ietf.org>; Tue, 18 Oct 2005 05:36:29 -0400 (EDT)
Received: from smtp13.clb.oleane.net ([213.56.31.49])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERo58-0007Jk-5r
	for simple@ietf.org; Tue, 18 Oct 2005 05:48:31 -0400
Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be
	forged)) (authenticated)
	by smtp13.clb.oleane.net with ESMTP id j9I9aKm8004702
	for <simple@ietf.org>; Tue, 18 Oct 2005 11:36:22 +0200
Message-Id: <200510180936.j9I9aKm8004702@smtp13.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <simple@ietf.org>
Date: Tue, 18 Oct 2005 11:36:14 +0200
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: AcXTx2GjCmvrCRF3QgaPq7dT/VODmQ==
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Subject: [Simple] International SIP 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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0154237487=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0154237487==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0030_01C5D3D8.27023560"

This is a multi-part message in MIME format.

------=_NextPart_000_0030_01C5D3D8.27023560
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The International SIP conference /exhibition will be held in Paris next
February 21-24, 2006.

 <http://www.upperside.fr/sip2006/sip2006program.htm> The SIP 2006 program
is mainly dedicated to Peer-to-Peer communications, IMS architectures, SIP
mobility and deployment examples. 

 

Get all details on the following link:

 <http://www.upperside.fr/sip2006/sip2006program.htm>
http://www.upperside.fr/sip2006/sip2006program.htm

 

 


------=_NextPart_000_0030_01C5D3D8.27023560
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The International SIP conference /exhibition =
will be
held in <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Paris</st1:place></st1:City>
next February 21-24, 2006.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"http://www.upperside.fr/sip2006/sip2006program.htm"
title=3D"http://www.upperside.fr/sip2006/sip2006program.htm"><font =
color=3Dblack
title=3D"http://www.upperside.fr/sip2006/sip2006program.htm"><span =
lang=3DEN-GB
style=3D'color:black'>The SIP 2006 =
program</span></font></a></span></font><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>
is mainly dedicated to <strong><b><font face=3DArial><span =
style=3D'font-family:
Arial'>Peer-to-Peer</span></font></b></strong> communications, =
<strong><b><font
face=3DArial><span style=3D'font-family:Arial'>IMS =
architectures</span></font></b></strong>,
<strong><b><font face=3DArial><span style=3D'font-family:Arial'>SIP =
mobility</span></font></b></strong>
and <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>deployment</span></font></b></strong>
examples. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Get all details on the following =
link:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"http://www.upperside.fr/sip2006/sip2006program.htm"
title=3D"http://www.upperside.fr/sip2006/sip2006program.htm"><span =
lang=3DEN-GB>http://www.upperside.fr/sip2006/sip2006program.htm</span></a=
></span></font><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0030_01C5D3D8.27023560--



--===============0154237487==
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

--===============0154237487==--





From simple-bounces@ietf.org Wed Oct 19 06:07:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESAqd-0006pQ-Kr; Wed, 19 Oct 2005 06:07:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESAqb-0006pB-Iq
	for simple@megatron.ietf.org; Wed, 19 Oct 2005 06:07:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03920
	for <simple@ietf.org>; Wed, 19 Oct 2005 06:06:53 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESB2D-0005tW-Rl
	for simple@ietf.org; Wed, 19 Oct 2005 06:19:08 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	D23FE4F004A; Wed, 19 Oct 2005 10:12:00 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 19 Oct 2005 10:11:21 +0200
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 19 Oct 2005 10:11:20 +0200
Received: from 147.214.118.216 ([147.214.118.216]) by
	esealmw105.eemea.ericsson.se ([153.88.200.68]) via Exchange
	Front-End Server mail.eemea.ericsson.se ([153.88.254.168]) with
	Microsoft Exchange Server HTTP-DAV ; Wed, 19 Oct 2005 08:10:13 +0000
Received: from Caliope by mail.eemea.ericsson.se; 19 Oct 2005 10:11:18 +0200
From: Ignacio =?ISO-8859-1?Q?M=E1s?= "Ivars (KI/EAB)"
	<ignacio.mas.ivars@ericsson.com>
To: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Organization: Ericsson Research
Date: Wed, 19 Oct 2005 10:11:18 +0200
Message-Id: <1129709478.4892.25.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
X-OriginalArrivalTime: 19 Oct 2005 08:11:20.0987 (UTC)
	FILETIME=[B0615EB0:01C5D484]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: quoted-printable
Cc: simple@ietf.org,
	=?ISO-8859-1?Q?Torbj=F6rn?= Einarsson <torbjorn.einarsson@ericsson.com>
Subject: [Simple] [MSRP v 12] Small nits
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi!

Some small nits we have found in the MSRP v12 draft.

1)The example on page 8 has 23 bytes and not 25 if you count the ASCII
characters in the phrase. Is a CR/LF counted perhaps? But then you
should not count it according to 2) below

2) In 7.1, page 17, line 10, it says "If a body is present, the end-line
must ..." which should probably be "If a body is present, the body
must ....".=20

3) End of 7.1.1 on page 20. Last sentence before 7.1.2, says "Since MSRP
is a "binary protocol", while in the first sentence on 4 on page 6, it
says "MSRP is a text-based, ..." and 9 page 32, it says "MSRP is a text
protocol ..."

Regards,
/Ignacio

--=20
Ignacio M=E1s Ivars
Service enablers and protocols, Ericsson Research (EAB/TBG/B)
Ericsson AB                     Phone: +46 8 4045580
Torshamsgatan 23                Fax:   +46 8 4049500
SE-164 80 Stockholm, Sweden     mailto: ignacio.mas.ivars@ericsson.com

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



From simple-bounces@ietf.org Wed Oct 19 13:41:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESHw7-000288-Hx; Wed, 19 Oct 2005 13:41:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESHw2-00026Y-7D; Wed, 19 Oct 2005 13:41:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00688;
	Wed, 19 Oct 2005 13:40:56 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESI7o-0002J6-Rf; Wed, 19 Oct 2005 13:53:17 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1ESHw0-0002Td-QO; Wed, 19 Oct 2005 13:41:04 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1ESHw0-0002Td-QO@newodin.ietf.org>
Date: Wed, 19 Oct 2005 13:41:04 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: Internet Architecture Board <iab@iab.org>,
	simple mailing list <simple@ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Simple] Protocol Action: 'A Session Initiation Protocol (SIP)
 Event 
 Notification Extension for Resource Lists' 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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The IESG has approved the following document:

- 'A Session Initiation Protocol (SIP) Event Notification Extension for 
   Resource Lists '
   <draft-ietf-simple-event-list-07.txt> as a Proposed Standard

This document began as the product of the SIP for Instant Messaging and
Presence Leveraging Extensions Working Group, and was completed by the Session
Initiation Protocol Working Group.

The IESG contact persons are Allison Mankin and Ted Hardie.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-07.txt

Technical Summary
 
  This document presents an extension to the Session Initiation Protocol
   (SIP)-Specific Event Notification mechanism (RFC 3265) for subscribing
   to a homogeneous list of resources.  Instead of the subscriber
   sending a SUBSCRIBE for each resource individually, the subscriber
   can subscribe to an entire list, and then receive notifications when
   the state of any of the resources in the list changes.
 
Working Group Summary
 
 The SIMPLE working group supported this capability strongly.  The document
 was transferred to the SIP working group because it needed a SIP option tag.
 There was a delay while reviewing and revising its discussion of identity.
 The Open Mobile Alliance has expressed a critical requirement for this
  specification.

Protocol Quality
 
 This protocol has been tested in SIMPLE interoperability sessions.  It was
 reviewed for the IESG by Allison Mankin.

Note to the RFC Editor

OLD:
Language tags are defined in RFC 1766 [6].

NEW:
Language tags are defined in RFC 3066 [6].

Change reference [6] to a reference to RFC 3066.


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



From simple-bounces@ietf.org Thu Oct 20 09:51:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESapY-0005UZ-LY; Thu, 20 Oct 2005 09:51:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESapX-0005UU-H0
	for simple@megatron.ietf.org; Thu, 20 Oct 2005 09:51:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12802
	for <simple@ietf.org>; Thu, 20 Oct 2005 09:51:29 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESb1S-0000u6-E3
	for simple@ietf.org; Thu, 20 Oct 2005 10:04:00 -0400
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
	j9KDpXNA007134; Thu, 20 Oct 2005 16:51:35 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 20 Oct 2005 16:51:35 +0300
Received: from [10.162.252.47] ([10.162.252.47]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 20 Oct 2005 16:51:34 +0300
Message-ID: <4357A0E6.2030008@nokia.com>
Date: Thu, 20 Oct 2005 16:51:34 +0300
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Anat Angel <anatang@radvision.com>
Subject: Re: [Simple] draft-ietf-simple-partial-publish-03 - in what cases
	exactly the compositor send 500?
References: <E7D8D1A37669BA428A72828A4DD999AD0A3802@rvil-mail1.RADVISION.com>
In-Reply-To: <E7D8D1A37669BA428A72828A4DD999AD0A3802@rvil-mail1.RADVISION.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Oct 2005 13:51:34.0685 (UTC)
	FILETIME=[624E3CD0:01C5D57D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Sorry for the late response. Inline.

ext Anat Angel wrote:
> Hi
> 
>  
> 
> This draft states in par 4.3.1 that:
> 
> "If any errors are encountered before the entire publication is
> 
>    completely processed, the compositor MUST reject the request with a
> 
>    500 (Server Internal Error) response, and revert back to its
> 
>    original, locally stored presence information."
> 
>  
> 
> My question is:
> 
> Does this mean that if xml parsing fails (for example), 500 must be sent?
> 
> If so, why is it different from the behavior in rfc 3903 for pidf?

It really isn't different. The last part of step 5 in Chapter 6 of RFC 
3903 talks about this very issue.

However, I agree that what exactly constitutes such an "internal" server 
error is left quite open, in both PUBLISH as well as partial-publish. 
This is simply because at the time of writing RFC 3903 -- and even today 
to some extent -- it isn't well understood what a presence composer 
function does with the inputs it receives. Particularly, whether it 
checks for validity or well-formedness, and whether it rejects 
publications that are not valid or well-formed XML, or is simply liberal 
in what it receives and recovers somewoh, is still somewhat under 
discussion.

Simply put, it depends. ;)

There is work ongoing, though, and you should probably check this draft:
http://www.ietf.org/internet-drafts/draft-schulzrinne-simple-composition-00.txt

Cheers,
Aki

>  
> 
> Thanks,
> 
> Anat Angel
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

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



From simple-bounces@ietf.org Thu Oct 20 09:59:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESax5-0006pd-Vr; Thu, 20 Oct 2005 09:59:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESax3-0006pW-UF
	for simple@megatron.ietf.org; Thu, 20 Oct 2005 09:59:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13235
	for <simple@ietf.org>; Thu, 20 Oct 2005 09:59:15 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESb8z-00018V-TR
	for simple@ietf.org; Thu, 20 Oct 2005 10:11:47 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9KDvCfu015342; Thu, 20 Oct 2005 16:57:15 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 20 Oct 2005 16:59:20 +0300
Received: from [10.162.252.47] ([10.162.252.47]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 20 Oct 2005 16:59:20 +0300
Message-ID: <4357A2B7.90907@nokia.com>
Date: Thu, 20 Oct 2005 16:59:19 +0300
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Anat Angel <anatang@radvision.com>
Subject: Re: [Simple] draft-ietf-simple-partial-publish - composition rules
References: <E7D8D1A37669BA428A72828A4DD999AD0A3803@rvil-mail1.RADVISION.com>
In-Reply-To: <E7D8D1A37669BA428A72828A4DD999AD0A3803@rvil-mail1.RADVISION.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Oct 2005 13:59:20.0394 (UTC)
	FILETIME=[77E3CAA0:01C5D57E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

Again sorry for the late response. Inline.

ext Anat Angel wrote:
> Hi
> 
>  
> 
> I have a question regarding composition rules:
> 
>  
> 
> Does a composer need to treat a UA that published its state in a 
> pidf-diff method (inside MODIFY request), as if it is more updated in 
> ALL the information it previously published? That means to consider this 
> publisher more updated about information that he didn't publish in this 
> particular request as well.

As with ordinary diff and patch, the patch usually only updates part of 
the information; the rest of the document remains unchanged. The 
implication is however, that the resulting full presence document is 
still considered valid in its entirety. No part is less valid than another.

> 
> Or does the composer need to treat it as if only the patch is more updated?
> 
>  
> 
> The significance of this question is best explained in the following 
> scenario:
> 
>  
> 
> The composer gets 2 INITIAL PUBLISH requests to the same presentity.
> 
> The first one (called A1) include 3 tuples with id's: tuple1, tuple2, 
> tuple3.
> 
> The second one (called B and comes after A1) include 2 tuples with id's: 
> tuple1 and tuple2.
> 
>  
> 
> The composer sends a first NOTIFY with full-pidf of tuple1 & tuple2 from 
> B (because it's more recent) and tuple3 from A1.
> 
> This is based on approach that information inside a more recent PUBLISH 
> is more updated.
> 
>  
> 
> Now another PUBLISH is received which is MODIFY to the first PUBLISH 
> (we'll name it A2). It is pidf-diff document. This PUBLISH include only 
> a <replace> to the contents of tuple1.
> 
>  
> 
> What should now be the content of a pidf-diff NOTIFY sent by the composer?
> 
> Is it only tuple1 (identical to the received PUBLISH with pidf-diff 
> document)?
> 
> Or should it also include tuple2 from A1, because we assume that 
> publisher A is more updated about the situation of the presentity?

This seems to fall into the area of composition policy, for which the 
PUBLISH nor partial-publish doesn't intend to find solutions directly.

Instead, look at:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-05.txt

and the composition draft I pointed out in the previous email.

Cheers,
Aki

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



From simple-bounces@ietf.org Fri Oct 21 01:40:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESpdJ-0003EA-2L; Fri, 21 Oct 2005 01:40:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESpdD-0003By-J6
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 01:39:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28148
	for <simple@ietf.org>; Fri, 21 Oct 2005 01:39:45 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESpp6-0001ju-Nb
	for simple@ietf.org; Fri, 21 Oct 2005 01:52:13 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 20 Oct 2005 22:39:35 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9L5dVUw003144;
	Thu, 20 Oct 2005 22:39:31 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 21 Oct 2005 01:39:30 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 01:39:30 -0400
Message-ID: <43587F12.6050007@cisco.com>
Date: Fri, 21 Oct 2005 01:39:30 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: ac2491@cs.columbia.edu
Subject: Re: [Simple] XCAP draft questions
References: <32835.24.199.92.69.1129198380.squirrel@webmail.cs.columbia.edu>
In-Reply-To: <32835.24.199.92.69.1129198380.squirrel@webmail.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 05:39:30.0663 (UTC)
	FILETIME=[CF07BF70:01C5D601]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

answers inline.

ac2491@cs.columbia.edu wrote:

> Hi,
> 
> Some very basic doubts.
> 1. How is the user first created in the xcap server?

Administratively. It is assumed that, for all valid users in the system, 
their home directory exists.

> "PUT /services/resource-lists/users/bill HTTP/1.1"
> Will this associate a directory name-service "bill" in the xcap server

No.

> Or
> "PUT /services/resource-lists/users/bill/fr.xml HTTP/1.1"
> will this associate a directory name-service "bill" in the xcap server.

No, not if it already exists.

> It has been recommended not to create sub-directories (in specific case of
> a file system) for the document selector and create a single file.
> Maybe the use of term "directory" at places is a bit mis-leading.
> 
> 2. In example in Section 6.4
> <ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
> should be
> <ns2:baz xmlns:baz="urn:test:namespace2-uri"/>
> Looks like a typo.

No, I believe that part is correct. ns2 is the namespace prefix and is 
defined by the xmlns:ns2 attribute.

There is an error there, though, and its in the next line:

     <ns3:hi xmlns:hi="urn:test:namespace3-uri">
        <there/>
      </ns3:hi>

this should be xmlns:ns3="urn:test:namespace3-uri". I'll fix that. It 
doesnt actually impact any of the discussion that follows, but its 
misleading.

> 
> 3. As mentioned earlier the schema instance hints if removed would be nice.
> 
> 4. In case of positional inserts, if a position specified is more than the
> existing node count, should this be treated as an error case or should
> insert happen at the last location?

Its an error, since its not possible to perform an insertion such that, 
after insertion, the URI refers to the recently-inserted element.

-Jonathan R.



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

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



From simple-bounces@ietf.org Fri Oct 21 01:42:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESpgB-0004mp-KF; Fri, 21 Oct 2005 01:42:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESpgA-0004mi-3V
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 01:42:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28251
	for <simple@ietf.org>; Fri, 21 Oct 2005 01:42:48 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESps2-0001om-AC
	for simple@ietf.org; Fri, 21 Oct 2005 01:55:15 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2005 01:42:36 -0400
X-IronPort-AV: i="3.97,239,1125892800"; 
	d="scan'208"; a="74139878:sNHT25567008"
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 j9L5gXEi006284; 
	Fri, 21 Oct 2005 01:42:33 -0400 (EDT)
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);
	Fri, 21 Oct 2005 01:42:33 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 01:42:33 -0400
Message-ID: <43587FC8.9090008@cisco.com>
Date: Fri, 21 Oct 2005 01:42:32 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Simple] an incremental step forward for xcap-diff and patch-ops
References: <434758B0.7070205@cisco.com> <434BA190.2020304@nokia.com>
In-Reply-To: <434BA190.2020304@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 05:42:33.0117 (UTC)
	FILETIME=[3BC804D0:01C5D602]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

True, though the idea was that, if the server has to return xcap-diff 
documents in NOTIFY to tell users what changed, this should be the same 
format you use to tell them what changed when given in the http response.

I'm also shooting for minimal changes here, rather than revisiting major 
design decisions.

-Jonathan R.

Jari Urpalainen wrote:

> ext Jonathan Rosenberg wrote:
> 
>> Since the last IETF meeting, we havent yet resolved this issue of how 
>> to represent the changes in an XML document that are included in the 
>> xcap-diff format. The current draft uses an xcap change log type of 
>> format. The previous version used Jari's patch-ops, which has been 
>> contentious. The current mechanism doesnt work, due to some issues 
>> with CDATA encapsulation.
>>
>> Xcap itself has a dependency on xcap-diff. Not for conveying the 
>> changes in XML document, but rather, for conveying etags. That aspect 
>> of the spec has been stable and uncontentious.
>>
>> In order to at least break the dependencies and allow base xcap to 
>> move forward (though we have some work to do per my previous note), 
>> I'd propose to split the current xcap-diff draft in two. One part, 
>> which remains a working group item, defines just the format for 
>> representing the etag changes. The schema would define a point of 
>> extensibility for conveying the actual changes in the xml document, 
>> but not define a solution. I would then issue an individual -00 
>> document with an xcap change-log type of format that could be used for 
>> this.
>>
>> This would allow us to conclude on xcap-diff, and separately debate 
>> just the piece of it that describes the changes themself.
>>
>> Comments?
>>
>> Thanks,
>> Jonathan R.
> 
> 
> The other option would be to define the ETag changes content type in the 
> base xcap spec, which can be as simple as <etags xmlns="urn:foo" 
> prev="xxx" new="yyy"/> and continue xcap-diff as usual.
> br,
> Jari
> 

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

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



From simple-bounces@ietf.org Fri Oct 21 01:57:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESpu2-0004cG-8U; Fri, 21 Oct 2005 01:57:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESpu0-0004c5-GT
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 01:57:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28714
	for <simple@ietf.org>; Fri, 21 Oct 2005 01:57:06 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESq62-0002Cj-VL
	for simple@ietf.org; Fri, 21 Oct 2005 02:09:43 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 22:57:03 -0700
X-IronPort-AV: i="3.97,239,1125903600"; 
	d="scan'208"; a="354931786:sNHT25820892"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9L5v0ub027251;
	Thu, 20 Oct 2005 22:57:01 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 21 Oct 2005 01:57:00 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 01:57:00 -0400
Message-ID: <4358832B.8020203@cisco.com>
Date: Fri, 21 Oct 2005 01:56:59 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues (directory)
References: <434756D0.6070708@cisco.com> <4347D5EB.6010204@cs.columbia.edu>
In-Reply-To: <4347D5EB.6010204@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 05:57:00.0290 (UTC)
	FILETIME=[40A81E20:01C5D604]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Henning Schulzrinne wrote:

> 
>> 3. XCAPs usage of directory structures between the username and the ~~ 
>> is very underspecified, and some interop problems have been reported. 
>> The lack of an ability to create sub-directories further complicates 
>> this. I'd propose to fix this by making it a responsibility of the 
>> application usage to define a well-known convention for constructing 
>> this component of the document selector, and recommend that no 
>> sub-directories be used at all. Rather, just documents right in the 
>> user's home directory. Furthermore, for application usages with just a 
>> single document, that this document be called "index".
> 
> 
> Would it make sense to use the AUID as the file name? This avoids having 
> to maintain and avoid collisions in yet another namespace that looks 
> similar.
> 
> Example:
> 
> PUT /bill/resource-lists

Thats really not much different that requiring the application usage to 
specify a convention. The latter leaves some flexibility in case 
multiple documents are needed, so I prefer that.

> 
> In addition, the user name part is currently underspecified. There seems 
> to be an implicit assumption that one XCAP server server serves exactly 
> one domain, so that somehow the 'bill' above is related to whatever host 
> the server runs on. (In the examples, this would be 
> bill@xcap.example.com, but that's probably not what's intended.)

No, its not whats intended.

The issue is there in sip too; the username portion of the digest 
credentials could be "bill", and the realm "server.example.com", but 
this doesnt mean that the URI in the From or P-Asserted-ID would be 
sip:bill@server.example.com. Rather, the SIP URI would be based on a 
provisioned mapping of the two (private to public ID in IMS terminology).

XCAP says more or less the same thing; there is a provisioned mapping on 
the server from authenticated identity of the http client, to the XUI. 
The client has to know it as another piece of configuration.

> 
> We have enough of a configuration mess at our hands without adding more 
> unspecified linkages that must be resolved through some unknown 
> mechanism that may or may not be universally deployed. I think the most 
> sensible mechanism is to use the same NAPTR/SRV mechanism, even though 
> that's not part of the standard HTTP resolution mechanism.

I'm not sure what NAPTR has to do with it...

-Jonathan R.

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

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



From simple-bounces@ietf.org Fri Oct 21 02:10:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESq6Y-0003NH-MD; Fri, 21 Oct 2005 02:10:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESq6X-0003L7-5V
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 02:10:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29219
	for <simple@ietf.org>; Fri, 21 Oct 2005 02:10:03 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESqIc-0002YK-Na
	for simple@ietf.org; Fri, 21 Oct 2005 02:22:43 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2005 02:10:04 -0400
X-IronPort-AV: i="3.97,239,1125892800"; 
	d="scan'208"; a="74140927:sNHT26074540"
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 j9L6A1Ei010067; 
	Fri, 21 Oct 2005 02:10:02 -0400 (EDT)
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);
	Fri, 21 Oct 2005 02:10:01 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 02:10:01 -0400
Message-ID: <43588638.8040505@cisco.com>
Date: Fri, 21 Oct 2005 02:10:00 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues
References: <434756D0.6070708@cisco.com>
	<6.2.1.2.0.20051008102154.02f14100@localhost>
In-Reply-To: <6.2.1.2.0.20051008102154.02f14100@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 06:10:01.0223 (UTC)
	FILETIME=[12210970:01C5D606]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Joel M. Halpern wrote:

> I would normally be reluctant to pull anything off of the RFC-Editor queue.
> However, your comment (not reproduced below) that the current grammar 
> makes extension impossible probably means we need at least some repair 
> so that we can fix problems we find later.

Well, I wouldnt say impossible, so much as unclear. The HTTP URI grammar 
is itself extensible, so nothing stops me from constructing an http URI 
that adds something that isn't defined in xcap itself. The server would 
presumably send a 404, whcih is the right thing in any case. The issue 
is mostly that its not directly addressed, and this may lead to problems 
with folks not anticipating such extensions.

> 
> With regard to the specific solution proposed, I have a couple of minor 
> questions:
> 
> 1) If the element the client is targeting is from some namespace (I 
> believe definitionally true) doesn't the client need to fetch 
> progressive namespace bindings in order to be able to ask the final 
> binding question properly?  Or can the client make simplifying 
> assumptions that are good enough to get the binding, but not good enough 
> to write replacement elements?

There are two issues here. One is, how do you construct the namespace 
prefixes in the URI itself, and the other is, when doing a PUT, how do 
you construct the namespace prefixes in the XML content in the body.

You are talking about the latter issue in your question. That is 
addressed in section 6.4 of xcap, which allows the client to specify the 
bindings used in evaluating the URI. THus, the client doesnt need to 
know what bindings the server has; it only needs to know the namesapce 
URIs themselves, which it will.

For the former issue, constructing the prefixes in the body of the XML 
document, you HAVE to use ones valid on the server, otherwise the server 
won't validate the document (unless you start asking the server to map 
the prefixes, which requires modifying the document itself - yuck). 
Thats why the client needs to know whats in use on the server here, but 
not in the former case.

> 
> 2) With regard to the specific syntax, I think that if we use it we will 
> need some more explanation.  Looking at the XPath spec, it becomes clear 
> that namespace::* is the alternative to asking about a specific 
> namespace. 

No, thats not what it means. It means that you select all children of a 
node along the namespace axis. In other words, you select a set of 
objects which represent all of the namesapces in scope for that object.

> In our usage that specific form is not needed.  The limited 
> syntax is somewhat odd (no problem for computers, but humans will look 
> and ask "why the *?)  So I would recommend that we put in some 
> explanatory text as to what the meaning of the syntax is, without the 
> reader needing to go look at the XPath specification.
> 
> 3) If I am reading things right, we are inventing the syntax to return 
> for a namespace::* reference in an XCAP specifier. 

Yes. I looked around for something canned already, and didnt find anything.

> The example makes 
> clear what the expected syntax is.  I think this is the right syntax.  
> We will however need to clearly describe that. 

Yes, I would need to define a schema for it and include it in the 
revised xcap spec.

> (I looked through the 
> XPath specification, and the result of a namespace::* is defined only in 
> terms of the logical structure.  And that structure is actually a 
> collection of namespace nodes without the parent element. And the 
> namespace nodes are simply the logical pair of local part for the 
> namespace prefix and a string-value of the namespace URI.)

Interestingly, xpath selections are ONLY defined in terms of the logical 
document structure. XCAP is currently saying that you can select an 
element or an attribute, and then we are defining a way to represent a 
single element or attribute with the two mime types we have. What I'm 
proposing here is to add another thing you can select - namespaces - and 
then we'll define a syntax for that too.

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

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



From simple-bounces@ietf.org Fri Oct 21 03:05:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESqxd-00044d-05; Fri, 21 Oct 2005 03:05:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESqxa-00040s-2h
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 03:05:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02026
	for <simple@ietf.org>; Fri, 21 Oct 2005 03:04:51 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESr9f-0004No-R8
	for simple@ietf.org; Fri, 21 Oct 2005 03:17:32 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2005 03:04:18 -0400
X-IronPort-AV: i="3.97,239,1125892800"; 
	d="scan'208"; a="74143310:sNHT30149772"
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 j9L74EEi019956; 
	Fri, 21 Oct 2005 03:04:14 -0400 (EDT)
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);
	Fri, 21 Oct 2005 03:04:13 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 03:04:13 -0400
Message-ID: <435892EC.6050806@cisco.com>
Date: Fri, 21 Oct 2005 03:04:12 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues
References: <434756D0.6070708@cisco.com> <434B9F52.3030206@nokia.com>
In-Reply-To: <434B9F52.3030206@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 07:04:13.0368 (UTC)
	FILETIME=[A48EFB80:01C5D60D]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Jari Urpalainen wrote:

> It is unfortunate that we have to fix these bugs, but it is still imo 
> better than to start xcap-bis. Some comments inline.
> 
> ext Jonathan Rosenberg wrote:
> 
>> Folks,
>>
>> There was some debate about a month back about a problem identified in 
>> XCAP regarding namespace handling, coming out of some experiences in 
>> OMA. The specific mail that reported this problem can be found here:
>>
>> http://www1.ietf.org/mail-archive/web/simple/current/msg05675.html
>>
>> The quick summary is that, for implementations that don't normally 
>> store the entire XML document locally on the client, a GET or PUT of a 
>> fragment of the document is problematic, since the in-scope namespace 
>> bindings for that fragment won't be known. This makes it impossible to 
>> interpret the results of a GET, or to formulate the namespace prefixes 
>> in the content of the PUT so the resulting document is valid.
>>
>> Several options were proposed, including OMA-specific fixes, revising 
>> xcap, or defining some extensions. I'd like to make a concrete 
>> proposal on how to move forward here.
>>
>> Firstly, I think this problem needs to be addressed in IETF, and needs 
>> to be fixed in a way that is not specific to the OMA use cases. It has 
>> been an objective of xcap from its start that it be possible to 
>> perform manipulations on a document without the full document cached. 
>> Section 5.10 of the -07 xcap draft talks about schema design 
>> guidelines that allow for xcap to work without having the document 
>> cached, for example. The problem reported by Per Hyttfors will affect 
>> any usage for which non-caching operation is needed, and will make any 
>> such usage cumbersome if not impossible. As such, it is not OMA 
>> specific, and I consider it a bug in the specification.
>>
>> For this reason, my proposal is to ask IESG to remove xcap from the 
>> rfc-editor queue, so that I can issue an update to the draft that 
>> fixes this problem.
>>
>> My proposal to fix the problem is to follow the recommendation made by 
>> Jari:
>>
>> http://www.ietf.org/mail-archive/web/simple/current/msg05710.html
>>
>> I would update the grammar of the node selector to allow for 
>> namespace::*. Such a selector would select the namespace bindings in 
>> scope for the element in question. xcap would define a format for 
>> encoding those namespace bindings; basically, an xml fragment body 
>> with one element, the local name of the element in question, with 
>> xmlns and xmlns: attributes for each of the namespaces in scope, 
>> including the default.
>>
>> For example, consider this document:
>>
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>     <service uri="sip:marketing at example.com">
>>       <a:list name="marketing">
>>         <a:entry uri="sip:joe at example.com"/>
>>         <a:entry uri="sip:sudhir at example.com"/>
>>       </a:list>
>>       <packages>
>>         <package>presence</package>
>>       </packages>
>>     </service>
>>    </rls-services>
>>
>> The following query:
>>
>> GET 
>> http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/namespaces::* 
>>
>>
> typo namespace::*
> 
>> would return:
>>
>>    <service xmlns="urn:ietf:params:xml:ns:rls-services"
>>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>
> out-of-scope comment, but I'd rather remove all references to 
> schema-instance hints from any of the example instance documents.

OK....


> 
>>
>> This fixes the problem by allowing the client to get the in-scope 
>> bindings, and cache them, so they can be used to interpret subsequent 
>> GETs, and then used to create the namespace prefixes for elements in 
>> subsequent PUTs. Of course, the client needs to be sure that the 
>> cached namespace bindings havent changed prior to the PUT; the 
>> mechanisms in section 7.10 of XCAP apply here as normal.
>>
>> I did investigate a few other solutions to the problem. In particular, 
>> I looked to see if the XML fragment interchange:
>>
>> http://www.w3.org/TR/xml-fragment
>>
>> could be used as a solution. The idea is that you could GET an 
>> element, and if you specify the MIME type for a "fragment with context 
>> format" in the Accept header, the server could return the element 
>> along with its context instead. Turns out, the XML format defined in 
>> the TR above only defines the fragment CONTEXT; there is no 
>> w3c-defined mechanism to convey an element along with its context. As 
>> such, we'd have to define it ourselves. I'd rather not do that, since 
>> its something better suited for w3c to do. I'd also rather stick with 
>> xpath-based approaches, rather than introduce yet another new piece of 
>> XML technology for this one problem.
>>
>> Several other problems have been reported with the xcap specification 
>> since its approval, and I would propose that these also be addressed 
>> while I am revising the document. Specifically:
>>
>>
>> 1. XCAP currently doesn't allow extensibility for the node-selector 
>> itself. This means that, as currently defined, we couldn't even 
>> formally define the above fix as an extension, even if we wanted to. 
>> Other possible node-selector extensions, such as:
>>
>> http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-multiple-00.txt
>>
>> would also not be formally possible as extensions.
>>
>> This is relatively easy to fix; it requires the grammar for 
>> node-selector to add points of extensibility, and for some text to 
>> indicate that servers reject, with a 404, expressions they don't 
>> understand. Extensions to xcap that define a new node-selector would 
>> define an extension name for themselves. A client can then discover 
>> support for this new extension using the xcap-caps document as 
>> currently defined.
>>
>> 2. Jari has reported some areas of underspecification around 
>> insertions. In particular, how insertions are done relative to 
>> whitespace and comments. The proposal would be to add some text that 
>> specifies that in these cases, element insertions happen before 
>> whitespaces or comments.
>>
> There's actually two issues here: one with positional inserts and 
> secondly whitespace text node handling in general. While I proposed that 
> new element inserts should be put at the first possible position, 

actually, the current text says this:

    When the client does not explicitly indicate a position in which to
    insert a new element, the server will insert that element as the last
    child of that parent.  If this is not the desired position, the
    client should perform a positional insertion.


> there's at least one corner case that should be clearly specified, i.e.:
> <presence>
>  <tuple id="p1"/>
>  <tuple id="p2"/>
>  <!-- comment -->
>  <person/>
> </presence>
> When you e.g. add <device> with put .../presence/device the current spec 
> clearly mandates that <device> is the last child of  <presence>. 
> However, if you put ../presence/device[1] the interpretation might be 
> that <device> is the first child of <presence>. Whatever the model 
> adopted in xcap, it should just be clearly expressed what's the meaning. 

Right. The current text is inadequate. I think that a few more words 
actually make it much more crisp. Namely, that, when the insertion is 
done, it is done such that two properties exist. Firstly, after 
insertion, the HTTP URI selects that element. Secondly, if the element 
can be inserted before a sibling (whether that sibling be another 
element, whitespace, or a comment) or after it, and still meet the first 
criteria, it MUST be inserted after it. Put more simply, the inserted 
element appears as far down the list of children of the parent as 
possible while still satisfying the idempotency property.

This is a generalization of whats in there now, but covers these other 
cases you've raised. So, in the example above, if you insert 
presence/device[1] and the content of the request is <device id="aa"> 
after insertion you'd have:

<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <person/>
<device id="aa"></presence>

Notice how it comes AFTER the whitespace that was there.

> A second example is when you'll put ../presence/tuple[3], using the 
> first possible position imo seems to be the most reasonable, i.e. ending 
> up with:
> <presence>
>  <tuple id="p1"/>
>  <tuple id="p2"/><tuple id="p3"/>
>  <!-- comment -->
>  <person/>
> </presence>

With my proposal it would be:

<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <person/>
<tuple id="3"></presence>

which is wrong. You'd have to do a put of ../presence/*[3] and then 
you'd get:

<presence>
  <tuple id="p1"/>
  <tuple id="p2"/>
  <!-- comment -->
  <tuple id="3"><person/>
</presence>

which is valid.

What you are proposing, of inserting in the first possible position, 
would allow for insertions of the form ../parent/element[pos] to have 
the effect of keeping together elements of the same name. Thats all 
fine, except its not consistent with whats in the current spec. Thus, 
changing it would break backwards compatibility. Since this would be a 
feature enhancement as opposed to a bug fix, I think we need to keep it 
consistent.


> Now I am assuming that xcap cannot put several siblings at the same time 
> and there's not any magic handling of whitespace text nodes.  Then we 
> might want to delete .../presence/tuple[@id="p1"]. XPath datamodel says 
> that a text node cannot have another text node as a sibling node.

Right, only because you clump it all together into a single text node.

> So we 
> should end up having a doc like this:
> <presence>
>  
>  <tuple id="p2"/><tuple id="p3"/>
>  <!-- comment -->
>  <person/>
> </presence>
> so the two whitespace text nodes have been catenated together. 

Right - deletes JUST delete the element, not any whitespace around it, 
and the xpath data model would then concatenate the whitespace together 
into a single logical text element.


Then
> again we could delete the first text node child of <presence> with 
> delete .../presence/text()[1] ending up with:

THis is not supported.

> <presence><tuple id="p2"/><tuple id="p3"/>
>  <!-- comment -->
>  <person/>
> </presence>
> or we could have replaced the first text node with put 
> ../presence/text()[1]  (pl: linefeed with two spaces):
> <presence>
>  <tuple id="p2"/><tuple id="p3"/>
>  <!-- comment -->
>  <person/>
> </presence>
> This would mean adding text() function to the BNF. However, I cannot 
> imagine any reasonable way to add a whitespace text node between those 
> two tuples. So I am NOT proposing to add text() function to the BNF,  

With the change I am proposing around extensibility, one could define 
such a thing as an extension.

> just trying to clarify the issue. And what's the issue actually ?  The 
> canonical format of the document must be predictable, this means that 
> some whitespace text nodes are meaningful (xml:space="preserve" is the 
> default btw.). So I am just proposing that xcap spec just describes this 
> issue, too.

Agree. I think my text above on insertion covers that case. The section 
on deletion also needs to mention that it ONLY deletes the elment, and 
not surrounding whitespace.

> 
>> 3. XCAPs usage of directory structures between the username and the ~~ 
>> is very underspecified, and some interop problems have been reported. 
>> The lack of an ability to create sub-directories further complicates 
>> this. I'd propose to fix this by making it a responsibility of the 
>> application usage to define a well-known convention for constructing 
>> this component of the document selector, and recommend that no 
>> sub-directories be used at all. Rather, just documents right in the 
>> user's home directory. Furthermore, for application usages with just a 
>> single document, that this document be called "index".
>>
> Actually in my reference implementation I've have done this "automatic" 
> sub-directory creation (in users "home" dir) and I still havn't figured 
> it out whether there are any issues out there or not. Of course e.g. 
> webdav has mkcol method for this.

We don't allow for creating subdirectories within the xml doc either, so 
I dont think we should allow it outside of it. For example, if you have 
a doc:

<test>
   <doc/>
</test>

and do PUT ..test/doc/add/two/

this WOULD NOT result in:

<test>
   <doc>
     <add>
       <two/>
     </add>
   </doc>
</test>

rather it generates an error.

I'd prefer to simply discourage directories.


> 
>> 4. A couple of nits have been reported, the worst of which are some 
>> extraneous double-quotes in the xmlns() xpointer expressions. I'd fix 
>> these too.
>>
>>
> good. Also it might be worth noting that within location steps 
> apostrophes (') can be used too (like in XPath).

What is the meaning of it? I'm not familiar with that.

> 
>>
>> I would propose we limit the changes to xcap to these five items (the 
>> main problem plus the four above), and no more.
>>
>> I don't know if the scope of changes here require a re-do of both WGLC 
>> and IETF last call, and/or re-do of approval from IESG. I would hope 
>> not, but this is something we need to discuss with Ted.
>>
> I'll also hope that these fixes can be done with the easiest possible 
> effort.

So do I....

-Jonathan R.

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

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



From simple-bounces@ietf.org Fri Oct 21 03:06:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESqz2-0004KT-6n; Fri, 21 Oct 2005 03:06:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESqz0-0004KL-GQ
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 03:06:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02121
	for <simple@ietf.org>; Fri, 21 Oct 2005 03:06:20 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESrAt-0004Qv-BW
	for simple@ietf.org; Fri, 21 Oct 2005 03:18:48 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 21 Oct 2005 00:05:52 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9L75lJh000672;
	Fri, 21 Oct 2005 00:05:48 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 21 Oct 2005 03:05:47 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 03:05:47 -0400
Message-ID: <4358934A.6020900@cisco.com>
Date: Fri, 21 Oct 2005 03:05:46 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Sebastian Ley <sebastian@withouthat.org>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and	related
	issues
References: <434756D0.6070708@cisco.com> <434B9F52.3030206@nokia.com>
	<200510111425.38605.sebastian@withouthat.org>
In-Reply-To: <200510111425.38605.sebastian@withouthat.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 07:05:47.0321 (UTC)
	FILETIME=[DC8F1290:01C5D60D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I see no benefit in allowing the document-name and directory-name to be 
the same, but I see possible drawbaks with implementations which DO use 
the underlying filesystem. So, I would prefer to disallow.

-Jonathan R.

Sebastian Ley wrote:

> * Jari Urpalainen wrote:
> 
> 
>>Actually in my reference implementation I've have done this "automatic"
>>sub-directory creation (in users "home" dir) and I still havn't figured
>>it out whether there are any issues out there or not.
> 
> 
> I think in that case the specification needs to clarify if there may be a 
> document and a subdirectory with the same name in a given directory.
> 
> Since the concept of a directory is borrowed from filesystems that does not 
> seem to make sense, but non-filesystem implementations might have no problem 
> having a directory and a document with the same name. And since the document 
> selector in XCAP always selects a document and never a directory there is no 
> ambiguity there either.
> 
> In an implementation I mapped the whole document-selector to a key in an XML 
> database. In that case there may be very well a directory and a document with 
> the same name in a given directory. When doing a filesystem implementation, 
> that gets rather difficult though...
> 
> Regards,
> Sebastian
> 

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

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



From simple-bounces@ietf.org Fri Oct 21 03:10:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESr2U-0004xx-PA; Fri, 21 Oct 2005 03:10:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESr2S-0004wz-Ce
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 03:10:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02287
	for <simple@ietf.org>; Fri, 21 Oct 2005 03:09:53 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESrEY-0004YG-AN
	for simple@ietf.org; Fri, 21 Oct 2005 03:22:34 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2005 00:09:55 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.97,239,1125903600"; 
	d="scan'208"; a="13603860:sNHT25258040"
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 j9L79qEi020802; 
	Fri, 21 Oct 2005 03:09:52 -0400 (EDT)
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);
	Fri, 21 Oct 2005 03:09:52 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 03:09:52 -0400
Message-ID: <4358943F.3000100@cisco.com>
Date: Fri, 21 Oct 2005 03:09:51 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Markus.Isomaki@nokia.com
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and
	relatedissues
References: <C84E0A4ABA6DD74DA5221E0833A35DF303816C3A@esebe101.NOE.Nokia.com>
In-Reply-To: <C84E0A4ABA6DD74DA5221E0833A35DF303816C3A@esebe101.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 07:09:52.0080 (UTC)
	FILETIME=[6E725500:01C5D60E]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: ed68cc91cc637fea89623888898579ba
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Yes, I think from the responses there is consensus on this. I want to be 
clear I do NOT think we should add a text() selector. If someone wants 
that, please write up an I-D. Its a trivial extension, but its a feature 
enhancement and not a bug fix, and thus should be out of scope.

-Jonathan R.

Markus.Isomaki@nokia.com wrote:

> Hi,
> 
> I support the idea of pulling XCAP out of the RFC ed's queue and fixing the problems identified below. It would be important not expand the discussion to any more new features, though. Those should be done as separate extensions.
> 
> Markus
> 
> 
>>-----Original Message-----
>>From: simple-bounces@ietf.org 
>>[mailto:simple-bounces@ietf.org]On Behalf
>>Of ext Jonathan Rosenberg
>>Sent: 08 October, 2005 08:19
>>To: Simple WG
>>Subject: [Simple] A proposal for fixing the xcap schema problem and
>>relatedissues
>>
>>
>>Folks,
>>
>>There was some debate about a month back about a problem 
>>identified in 
>>XCAP regarding namespace handling, coming out of some experiences in 
>>OMA. The specific mail that reported this problem can be found here:
>>
>>http://www1.ietf.org/mail-archive/web/simple/current/msg05675.html
>>
>>The quick summary is that, for implementations that don't 
>>normally store 
>>the entire XML document locally on the client, a GET or PUT of a 
>>fragment of the document is problematic, since the in-scope namespace 
>>bindings for that fragment won't be known. This makes it 
>>impossible to 
>>interpret the results of a GET, or to formulate the namespace 
>>prefixes 
>>in the content of the PUT so the resulting document is valid.
>>
>>Several options were proposed, including OMA-specific fixes, revising 
>>xcap, or defining some extensions. I'd like to make a 
>>concrete proposal 
>>on how to move forward here.
>>
>>Firstly, I think this problem needs to be addressed in IETF, 
>>and needs 
>>to be fixed in a way that is not specific to the OMA use 
>>cases. It has 
>>been an objective of xcap from its start that it be possible 
>>to perform 
>>manipulations on a document without the full document cached. Section 
>>5.10 of the -07 xcap draft talks about schema design guidelines that 
>>allow for xcap to work without having the document cached, 
>>for example. 
>>The problem reported by Per Hyttfors will affect any usage for which 
>>non-caching operation is needed, and will make any such usage 
>>cumbersome 
>>if not impossible. As such, it is not OMA specific, and I 
>>consider it a 
>>bug in the specification.
>>
>>For this reason, my proposal is to ask IESG to remove xcap from the 
>>rfc-editor queue, so that I can issue an update to the draft 
>>that fixes 
>>this problem.
>>
>>My proposal to fix the problem is to follow the 
>>recommendation made by Jari:
>>
>>http://www.ietf.org/mail-archive/web/simple/current/msg05710.html
>>
>>I would update the grammar of the node selector to allow for 
>>namespace::*. Such a selector would select the namespace bindings in 
>>scope for the element in question. xcap would define a format for 
>>encoding those namespace bindings; basically, an xml fragment 
>>body with 
>>one element, the local name of the element in question, with 
>>xmlns and 
>>xmlns: attributes for each of the namespaces in scope, including the 
>>default.
>>
>>For example, consider this document:
>>
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>     <service uri="sip:marketing at example.com">
>>       <a:list name="marketing">
>>         <a:entry uri="sip:joe at example.com"/>
>>         <a:entry uri="sip:sudhir at example.com"/>
>>       </a:list>
>>       <packages>
>>         <package>presence</package>
>>       </packages>
>>     </service>
>>    </rls-services>
>>
>>The following query:
>>
>>GET 
>>http://xcap-root.com/rls-services/users/joe/~~/rls-services/se
>>rvice/namespaces::*
>>
>>would return:
>>
>>    <service xmlns="urn:ietf:params:xml:ns:rls-services"
>>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>
>>
>>This fixes the problem by allowing the client to get the in-scope 
>>bindings, and cache them, so they can be used to interpret subsequent 
>>GETs, and then used to create the namespace prefixes for elements in 
>>subsequent PUTs. Of course, the client needs to be sure that 
>>the cached 
>>namespace bindings havent changed prior to the PUT; the mechanisms in 
>>section 7.10 of XCAP apply here as normal.
>>
>>I did investigate a few other solutions to the problem. In 
>>particular, I 
>>looked to see if the XML fragment interchange:
>>
>>http://www.w3.org/TR/xml-fragment
>>
>>could be used as a solution. The idea is that you could GET 
>>an element, 
>>and if you specify the MIME type for a "fragment with context 
>>format" in 
>>the Accept header, the server could return the element along with its 
>>context instead. Turns out, the XML format defined in the TR 
>>above only 
>>defines the fragment CONTEXT; there is no w3c-defined mechanism to 
>>convey an element along with its context. As such, we'd have 
>>to define 
>>it ourselves. I'd rather not do that, since its something 
>>better suited 
>>for w3c to do. I'd also rather stick with xpath-based 
>>approaches, rather 
>>than introduce yet another new piece of XML technology for 
>>this one problem.
>>
>>Several other problems have been reported with the xcap specification 
>>since its approval, and I would propose that these also be addressed 
>>while I am revising the document. Specifically:
>>
>>
>>1. XCAP currently doesn't allow extensibility for the node-selector 
>>itself. This means that, as currently defined, we couldn't 
>>even formally 
>>define the above fix as an extension, even if we wanted to. Other 
>>possible node-selector extensions, such as:
>>
>>http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-mult
>>iple-00.txt
>>
>>would also not be formally possible as extensions.
>>
>>This is relatively easy to fix; it requires the grammar for 
>>node-selector to add points of extensibility, and for some text to 
>>indicate that servers reject, with a 404, expressions they don't 
>>understand. Extensions to xcap that define a new node-selector would 
>>define an extension name for themselves. A client can then discover 
>>support for this new extension using the xcap-caps document 
>>as currently 
>>defined.
>>
>>2. Jari has reported some areas of underspecification around 
>>insertions. 
>>In particular, how insertions are done relative to whitespace and 
>>comments. The proposal would be to add some text that 
>>specifies that in 
>>these cases, element insertions happen before whitespaces or comments.
>>
>>3. XCAPs usage of directory structures between the username 
>>and the ~~ 
>>is very underspecified, and some interop problems have been reported. 
>>The lack of an ability to create sub-directories further complicates 
>>this. I'd propose to fix this by making it a responsibility of the 
>>application usage to define a well-known convention for constructing 
>>this component of the document selector, and recommend that no 
>>sub-directories be used at all. Rather, just documents right in the 
>>user's home directory. Furthermore, for application usages 
>>with just a 
>>single document, that this document be called "index".
>>
>>4. A couple of nits have been reported, the worst of which are some 
>>extraneous double-quotes in the xmlns() xpointer expressions. I'd fix 
>>these too.
>>
>>
>>
>>I would propose we limit the changes to xcap to these five items (the 
>>main problem plus the four above), and no more.
>>
>>I don't know if the scope of changes here require a re-do of 
>>both WGLC 
>>and IETF last call, and/or re-do of approval from IESG. I would hope 
>>not, but this is something we need to discuss with Ted.
>>
>>If the working group agrees with this direction, I will commit to a 
>>revision of xcap with these changes prior to the non-00 deadline for 
>>Vancouver. As such, please reply with comments ASAP, since time is 
>>running out (October 24!).
>>
>>Thanks,
>>Jonathan R.
>>-- 
>>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>Director, Service Provider VoIP Architecture   Parsippany, NJ 
>>07054-2711
>>Cisco Systems
>>jdrosen@cisco.com                              FAX:   (973) 952-5050
>>http://www.jdrosen.net                         PHONE: (973) 952-5000
>>http://www.cisco.com
>>
>>_______________________________________________
>>Simple mailing list
>>Simple@ietf.org
>>https://www1.ietf.org/mailman/listinfo/simple
>>
> 
> 

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

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



From simple-bounces@ietf.org Fri Oct 21 03:19:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESrBy-00025m-Ep; Fri, 21 Oct 2005 03:19:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESrBw-00025W-EK
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 03:19:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02930
	for <simple@ietf.org>; Fri, 21 Oct 2005 03:19:41 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.204])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESrO1-0004wR-H7
	for simple@ietf.org; Fri, 21 Oct 2005 03:32:22 -0400
Received: by rproxy.gmail.com with SMTP id 40so23969rnz
	for <simple@ietf.org>; Fri, 21 Oct 2005 00:19:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=MRP6WITlNNs5PPey3lHhbIxQqKPcORBXZOOtjUwO9U4Nnt1ewVKdx8ELkht6u4Blo7ZM8dk/GgWcGCgent6e9poGKbzpXkTG0sY39HfKpM1/JINvdu4inme1VODcJ6y5K8/LLpMEyiae41c1nEjDhh4oaICxq13fww9b1cBgyzE=
Received: by 10.11.117.12 with SMTP id p12mr24361cwc;
	Fri, 21 Oct 2005 00:19:46 -0700 (PDT)
Received: by 10.11.117.2 with HTTP; Fri, 21 Oct 2005 00:19:46 -0700 (PDT)
Message-ID: <2b7d8b420510210019o339bffc8ybac54b574b5d22ce@mail.gmail.com>
Date: Fri, 21 Oct 2005 12:49:46 +0530
From: Binu K S <binux.lists@gmail.com>
To: Simple WG <simple@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] Schema nits - draft-ietf-simple-xcap-list-usage-05
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I found two minor problems when I used the schema defined in this
draft with a validating parser (Xerces-C).

The rls-services schema in section 4.2 should import the
resource-lists namespace:
    <xs:import namespace=3D"urn:ietf:params:xml:ns:resource-lists"/>

The resource-lists schema in section 3.2 has a redundant provision for
allowing elements from other namespaces that results in this error:
  "Complex type 'listType' violates the Unique Particle Attribution
rule in its components '##other' and '##other'"

The part of the schema that causes the error is:

         <xs:any namespace=3D"##other" processContents=3D"lax" minOccurs=3D=
"0"
          maxOccurs=3D"unbounded"/>
        </xs:choice>
       </xs:sequence>
       <xs:any namespace=3D"##other" minOccurs=3D"0" maxOccurs=3D"unbounded=
"/>

The second xs:any element in this fragment seems to be redundant. On
removing this, the parser does not have any problems and the schema
still meets the extensibility requirement for allowing elements from
other name-spaces within the list element.

Regards,
Binu K S,
Technical Architect,
Kodiak Networks.

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



From simple-bounces@ietf.org Fri Oct 21 03:21:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESrDI-0002Wj-8s; Fri, 21 Oct 2005 03:21:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESrDF-0002Ub-0w
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 03:21:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03034
	for <simple@ietf.org>; Fri, 21 Oct 2005 03:21:02 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESrPK-000503-2r
	for simple@ietf.org; Fri, 21 Oct 2005 03:33:43 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 21 Oct 2005 00:21:02 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9L7KwJj018938;
	Fri, 21 Oct 2005 00:21:00 -0700 (PDT)
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);
	Fri, 21 Oct 2005 03:20:59 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 03:20:59 -0400
Message-ID: <435896DA.1080905@cisco.com>
Date: Fri, 21 Oct 2005 03:20:58 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: "Ramalakshmi V. Gunturi" <ramagv@sonimtech.com>
Subject: Re: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
References: <E7F5A43EEB6E7C42A08C041BDEB90A5305B08F@mail2.sonimtech.com>
In-Reply-To: <E7F5A43EEB6E7C42A08C041BDEB90A5305B08F@mail2.sonimtech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 07:20:59.0361 (UTC)
	FILETIME=[FC2D5510:01C5D60F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Ramalakshmi V. Gunturi wrote:

> With reference to the earlier mail
> http://www1.ietf.org/mail-archive/web/simple/current/msg05810.html,
> 
> 
>>>>>>>>>>>>>>> Quoting from the earlier mail
>>>>>>>>>>>>>>> >>>>>>>>>>>>>.
> 
> 
> I would update the grammar of the node selector to allow for 
> namespace::*. Such a selector would select the namespace bindings in
>  scope for the element in question. xcap would define a format for 
> encoding those namespace bindings; basically, an xml fragment body
> with one element, the local name of the element in question, with
> xmlns and xmlns: attributes for each of the namespaces in scope,
> including the default.
> 
> For example, consider this document:
> 
> <?xml version="1.0" encoding="UTF-8"?> <rls-services
> xmlns="urn:ietf:params:xml:ns:rls-services" 
> xmlns:a="urn:ietf:params:xml:ns:resource-lists" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <service
> uri="sip:marketing at example.com"> <a:list name="marketing"> 
> <a:entry uri="sip:joe at example.com"/> <a:entry uri="sip:sudhir at
> example.com"/> </a:list> <packages> <package>presence</package> 
> </packages> </service> </rls-services>
> 
> The following query:
> 
> GET 
> http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/namespaces::*
> 
> 
> would return:
> 
> <service xmlns="urn:ietf:params:xml:ns:rls-services" 
> xmlns:a="urn:ietf:params:xml:ns:resource-lists" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> 
> 
> This fixes the problem by allowing the client to get the in-scope 
> bindings, and cache them, so they can be used to interpret subsequent
>  GETs, and then used to create the namespace prefixes for elements in
>  subsequent PUTs. Of course, the client needs to be sure that the
> cached namespace bindings havent changed prior to the PUT; the
> mechanisms in section 7.10 of XCAP apply here as normal.
> 
> <<<<<<<<<<<<<< end quoting from earlier mail <<<<<<<<<<<<<<<<<
> 
> As per my understanding, the above approach needs the whole request
> formation part to be done at runtime. Please correct me If I am
> wrong.

Yes, you are right. I will note that allowing xcap operations to happen 
using a statically configured query (i.e., not computed at run time) has 
not been a requirement. I understand why you want to do it, but its not 
been a requirement to date.

The only two ways I know of, which would allow you to have a static 
query that will work are:

1. require standardized definitions for namespace prefixes
2. namespace bindings can already been includedin the request-URI. These 
are used only to define the in-scope bindings for evaluating the URI. 
Also apply them to the fragment in a PUT, and then have the server 
modify the namespace prefixes in the fragment to equal those defined for 
the same namespace URI.


#2 is really ugly, and violates the http spec itself (get(put(x))) won't 
equal X. #1 interacts poorly with non-standard extensions and violates 
the spirit of xml namespace, i think.

I welcome other proposals, but the one I propsoed was the best I could 
think of.

> 
> My question is that, If we want to identify and define the parameters
> that make up each request in a xml document, and then define another
> XSLT document to transform the request from the fomer XML document to
> an XCAP format, we will need to use standard parsers and
> transformers.
> 
> In this scenario, for put requests with xml fragments having
> namespaces,  the parser throws an error because in the payload there
> is no definition of namespace. ex: fergus wants to add foo to his
> accept list.
> 
> PUT
> http://xcap.example.com/services/org.openmobilealliance.poc-rules/users/sip:fergus@example.com/pocrules/~~/cr:ruleset/cr:
> rule[@id="accept"]/cr:conditions/cp:identity/cp:entry?xmlns(cr="urn:ietf:params:xml:ns:commonpolicy")xmlns(cp="urn:oma:params:xml:ns:commonpolicy")
> HTTP/1.1
> 
> <cp:entry id="sip:foo@example.com" />
> 
> So when this payload in defined in the XSLT document and the XSL
> Transformer (javax.xml.transform.TransformerFactory) is used for
> generating the XCAP request, the transformer throws out an error
> saying "cp:entry not bound to parent", because as per the xml rules,
> the name space is not defined within the payload.

I don't quite follow this, so I can't tell if this is a problem with 
using this particular java library to generate the xcap query, or 
whether there is a protocol issue here. Can you clarify?

Thanks,
Jonathan R.

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

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



From simple-bounces@ietf.org Fri Oct 21 03:42:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESrXs-0000Cd-UE; Fri, 21 Oct 2005 03:42:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESrXr-00009N-1w
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 03:42:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03950
	for <simple@ietf.org>; Fri, 21 Oct 2005 03:42:20 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESrjv-0005iB-Ct
	for simple@ietf.org; Fri, 21 Oct 2005 03:55:01 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2005 00:42:20 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.97,239,1125903600"; 
	d="scan'208"; a="13605099:sNHT24087232"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9L7gG23013863; 
	Fri, 21 Oct 2005 03:42:17 -0400 (EDT)
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);
	Fri, 21 Oct 2005 03:42:16 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 03:42:16 -0400
Message-ID: <43589BD7.8080404@cisco.com>
Date: Fri, 21 Oct 2005 03:42:15 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] xcap diff format in SIP notify message
References: <3ACC9A25264A684F82C71840111F979847F763@carrera.eu.tieto.com>
In-Reply-To: <3ACC9A25264A684F82C71840111F979847F763@carrera.eu.tieto.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 07:42:16.0258 (UTC)
	FILETIME=[F5445A20:01C5D612]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

responses inline.

Martin.Hynar@tietoenator.com wrote:

> Hi all,
> 
> Few weeks ago I sent the question to the SIMPLE mailing list but I haven't obtained any response. However, it is very important for me so I am asking again.
> 
> I am solving now the problem with communication using xcap-diff format specified in xcap-package-03. What is the issue:
> 
> 1. The server carries XML document.
> 2. A client requests to be notified about changes in this document with xcap-diff.
> 3. The document is replaced with new content begining from the root (XCAP PUT with no ETag -> replacement of the content)
> 4. The server tries to notify the client with message of the format
> 
> HEADERS
> <?xml version="1.0" encoding="UTF-8"?>
> <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff" xcap-root="http://localhost/xcap/xcap/">
> 
>   <document doc-selector="resource-lists/users/sip:user@domain.com/doc"
>             new-etag="aaaaa"
>             previous-etag="bbbbb">
> 
>   <replace-element element="/">
>     <![CDATA[<?xml version="1.0" encoding="UTF-8"?>
> 
>       <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
> 
>                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> 
>         <list name="list_name">
> 
>           ...
> 
>         </list>   
> 
>       </resource-lists>]]>
>   </replace-element>
> 
> </document>
> 
> </xcap-diff>
> 
> The question is whether the value "/" of attribute "element" is correct?

no. This case is described in xcap-diff. You would omit the node 
selector entirely. Note this text:

    operation.  Both <put-event> and <delete-event> have a single
    optional attribute, "node-selector", which contains the node selector
    in the Request URI (after removing any escape coding) of the HTTP PUT
    or DELETE request.  The server MUST include the "node-selector" when
    the PUT or DELETE operation was against an XML element or attribute.
    The "node-selector" attribute MUST NOT be present if the PUT or
    DELETE operation was against the document itself.  The <put-event>


> 
> Another problem is that I don't know what message should be sent in case of deletion of the document. In that case I am sending reference document with equal new-etag and prevoius-etag to let client refetch the document. Is this behaviour correct?

No. This is also described in the spec:

The "new-etag" attribute provides the
    etag for the document after the application of the changes, assuming
    the document exists after those changes.  If the change being
    reported is the deletion of the document, the "new-etag" attribute
    will not be present.

So, you'd include a previous-etag, no new-etag, and the change log would 
have a delete operation, and no node selector.

-Jonathan R.


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

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



From simple-bounces@ietf.org Fri Oct 21 04:36:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESsNm-0007zL-6p; Fri, 21 Oct 2005 04:36:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESsNj-0007xn-Dl
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 04:36:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06158
	for <simple@ietf.org>; Fri, 21 Oct 2005 04:35:56 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESsZq-0007Yh-20
	for simple@ietf.org; Fri, 21 Oct 2005 04:48:38 -0400
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
	j9L8a2s1002580; Fri, 21 Oct 2005 11:36:04 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 21 Oct 2005 11:36:01 +0300
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 21 Oct 2005 11:36:01 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j9L8a1j22782; Fri, 21 Oct 2005 11:36:01 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 6E07093B6A; Fri, 21 Oct 2005 11:36:01 +0300 (EEST)
Message-ID: <4358A871.9030508@nokia.com>
Date: Fri, 21 Oct 2005 11:36:01 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues
References: <434756D0.6070708@cisco.com> <434B9F52.3030206@nokia.com>
	<435892EC.6050806@cisco.com>
In-Reply-To: <435892EC.6050806@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 08:36:01.0488 (UTC)
	FILETIME=[77A76500:01C5D61A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Jonathan Rosenberg wrote:

>
>  <tuple id="p1"/>
>  <tuple id="p2"/>
>  <!-- comment -->
>  <tuple id="3"><person/>
> </presence>
>
> which is valid.
>
> What you are proposing, of inserting in the first possible position, 
> would allow for insertions of the form ../parent/element[pos] to have 
> the effect of keeping together elements of the same name. Thats all 
> fine, except its not consistent with whats in the current spec. Thus, 
> changing it would break backwards compatibility. Since this would be a 
> feature enhancement as opposed to a bug fix, I think we need to keep 
> it consistent.
>
ok, so you are saying that the position for e.g. for a new element is 
the last possible one. That's fine with me as well, because it's 
unambiguous. The minor issue is that in the implementation you'll anyhow 
have to find first the first possible location, now with your proposal 
an implementation has to look for the next (and the last) possible node 
positions. For the implementation it should not be a major issue, however.

>
>> Now I am assuming that xcap cannot put several siblings at the same 
>> time and there's not any magic handling of whitespace text nodes.  
>> Then we might want to delete .../presence/tuple[@id="p1"]. XPath 
>> datamodel says that a text node cannot have another text node as a 
>> sibling node.
>
>
> Right, only because you clump it all together into a single text node.
>
>> So we should end up having a doc like this:
>> <presence>
>>  
>>  <tuple id="p2"/><tuple id="p3"/>
>>  <!-- comment -->
>>  <person/>
>> </presence>
>> so the two whitespace text nodes have been catenated together. 
>
>
> Right - deletes JUST delete the element, not any whitespace around it, 
> and the xpath data model would then concatenate the whitespace 
> together into a single logical text element.
>
>
> Then
>
>> again we could delete the first text node child of <presence> with 
>> delete .../presence/text()[1] ending up with:
>
>
> THis is not supported.
>
>> <presence><tuple id="p2"/><tuple id="p3"/>
>>  <!-- comment -->
>>  <person/>
>> </presence>
>> or we could have replaced the first text node with put 
>> ../presence/text()[1]  (pl: linefeed with two spaces):
>> <presence>
>>  <tuple id="p2"/><tuple id="p3"/>
>>  <!-- comment -->
>>  <person/>
>> </presence>
>> This would mean adding text() function to the BNF. However, I cannot 
>> imagine any reasonable way to add a whitespace text node between 
>> those two tuples. So I am NOT proposing to add text() function to the 
>> BNF,  
>
>
> With the change I am proposing around extensibility, one could define 
> such a thing as an extension.
>
>> just trying to clarify the issue. And what's the issue actually ?  
>> The canonical format of the document must be predictable, this means 
>> that some whitespace text nodes are meaningful (xml:space="preserve" 
>> is the default btw.). So I am just proposing that xcap spec just 
>> describes this issue, too.
>
>
> Agree. I think my text above on insertion covers that case. The 
> section on deletion also needs to mention that it ONLY deletes the 
> elment, and not surrounding whitespace.
>
good.

>>
>>> 3. XCAPs usage of directory structures between the username and the 
>>> ~~ is very underspecified, and some interop problems have been 
>>> reported. The lack of an ability to create sub-directories further 
>>> complicates this. I'd propose to fix this by making it a 
>>> responsibility of the application usage to define a well-known 
>>> convention for constructing this component of the document selector, 
>>> and recommend that no sub-directories be used at all. Rather, just 
>>> documents right in the user's home directory. Furthermore, for 
>>> application usages with just a single document, that this document 
>>> be called "index".
>>>
>> Actually in my reference implementation I've have done this 
>> "automatic" sub-directory creation (in users "home" dir) and I still 
>> havn't figured it out whether there are any issues out there or not. 
>> Of course e.g. webdav has mkcol method for this.
>
>
> We don't allow for creating subdirectories within the xml doc either, 
> so I dont think we should allow it outside of it. For example, if you 
> have a doc:
>
> <test>
>   <doc/>
> </test>
>
> and do PUT ..test/doc/add/two/
>
> this WOULD NOT result in:
>
> <test>
>   <doc>
>     <add>
>       <two/>
>     </add>
>   </doc>
> </test>
>
> rather it generates an error.
>
> I'd prefer to simply discourage directories.

ok, too.

>
>
>>
>>> 4. A couple of nits have been reported, the worst of which are some 
>>> extraneous double-quotes in the xmlns() xpointer expressions. I'd 
>>> fix these too.
>>>
>>>
>> good. Also it might be worth noting that within location steps 
>> apostrophes (') can be used too (like in XPath).
>
>
> What is the meaning of it? I'm not familiar with that.
>
from XPath spec:
"Within expressions, literal strings are delimited by single or double 
quotation marks, which are also used to delimit XML attributes. To avoid 
a quotation mark in an expression being interpreted by the XML processor 
as terminating the attribute value the quotation mark can be entered as 
a character reference (|&quot;| or |&apos;|). Alternatively, the 
expression can use single quotation marks if the XML attribute is 
delimited with double quotation marks or vice-versa."

in xcap these could appear within docs or r-uri's, so it should be imo 
described someway.
thanks,
Jari

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



From simple-bounces@ietf.org Fri Oct 21 04:48:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESsZP-0006Wg-Gr; Fri, 21 Oct 2005 04:48:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESsZO-0006W3-2Y
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 04:48:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06959
	for <simple@ietf.org>; Fri, 21 Oct 2005 04:47:59 -0400 (EDT)
Received: from [203.101.112.21] (helo=mail2.sonimtech.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESslU-00083m-DL
	for simple@ietf.org; Fri, 21 Oct 2005 05:00:41 -0400
content-class: urn:content-classes:message
Subject: RE: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
Date: Fri, 21 Oct 2005 14:21:08 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <E7F5A43EEB6E7C42A08C041BDEB90A5305B0A0@mail2.sonimtech.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
Thread-Index: AcXWEHfbIyJlq6XUTGOuYpwf9gMt8wACzJAQ
From: "Ramalakshmi V. Gunturi" <ramagv@sonimtech.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

HI,

As the Specification uses XML fragments that are not well formed (when =
used with namespaces), the standard parsers are causing problems.

I understand that using statically configured query was not a =
requirement in the specification, but looking from the development point =
of view if we have the support of static queries it gives us the =
advantage of having a cleaner code and easy adaptation to changes in =
protocols. =20

For future releases can we look at the specification from this =
perspective and provide support for well formed xml fragments ??

Thanks & Regards,
Rama


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
Sent: Friday, October 21, 2005 12:51 PM
To: Ramalakshmi V. Gunturi
Cc: simple@ietf.org
Subject: Re: [Simple] Re: A proposal for fixing the xcap schema problem
and related issues


inline.

Ramalakshmi V. Gunturi wrote:

> With reference to the earlier mail
> http://www1.ietf.org/mail-archive/web/simple/current/msg05810.html,
>=20
>=20
>>>>>>>>>>>>>>> Quoting from the earlier mail
>>>>>>>>>>>>>>> >>>>>>>>>>>>>.
>=20
>=20
> I would update the grammar of the node selector to allow for=20
> namespace::*. Such a selector would select the namespace bindings in
>  scope for the element in question. xcap would define a format for=20
> encoding those namespace bindings; basically, an xml fragment body
> with one element, the local name of the element in question, with
> xmlns and xmlns: attributes for each of the namespaces in scope,
> including the default.
>=20
> For example, consider this document:
>=20
> <?xml version=3D"1.0" encoding=3D"UTF-8"?> <rls-services
> xmlns=3D"urn:ietf:params:xml:ns:rls-services"=20
> xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"=20
> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> <service
> uri=3D"sip:marketing at example.com"> <a:list name=3D"marketing">=20
> <a:entry uri=3D"sip:joe at example.com"/> <a:entry uri=3D"sip:sudhir =
at
> example.com"/> </a:list> <packages> <package>presence</package>=20
> </packages> </service> </rls-services>
>=20
> The following query:
>=20
> GET=20
> =
http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/names=
paces::*
>=20
>=20
> would return:
>=20
> <service xmlns=3D"urn:ietf:params:xml:ns:rls-services"=20
> xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"=20
> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"/>
>=20
>=20
> This fixes the problem by allowing the client to get the in-scope=20
> bindings, and cache them, so they can be used to interpret subsequent
>  GETs, and then used to create the namespace prefixes for elements in
>  subsequent PUTs. Of course, the client needs to be sure that the
> cached namespace bindings havent changed prior to the PUT; the
> mechanisms in section 7.10 of XCAP apply here as normal.
>=20
> <<<<<<<<<<<<<< end quoting from earlier mail <<<<<<<<<<<<<<<<<
>=20
> As per my understanding, the above approach needs the whole request
> formation part to be done at runtime. Please correct me If I am
> wrong.

Yes, you are right. I will note that allowing xcap operations to happen=20
using a statically configured query (i.e., not computed at run time) has =

not been a requirement. I understand why you want to do it, but its not=20
been a requirement to date.

The only two ways I know of, which would allow you to have a static=20
query that will work are:

1. require standardized definitions for namespace prefixes
2. namespace bindings can already been includedin the request-URI. These =

are used only to define the in-scope bindings for evaluating the URI.=20
Also apply them to the fragment in a PUT, and then have the server=20
modify the namespace prefixes in the fragment to equal those defined for =

the same namespace URI.


#2 is really ugly, and violates the http spec itself (get(put(x))) won't =

equal X. #1 interacts poorly with non-standard extensions and violates=20
the spirit of xml namespace, i think.

I welcome other proposals, but the one I propsoed was the best I could=20
think of.

>=20
> My question is that, If we want to identify and define the parameters
> that make up each request in a xml document, and then define another
> XSLT document to transform the request from the fomer XML document to
> an XCAP format, we will need to use standard parsers and
> transformers.
>=20
> In this scenario, for put requests with xml fragments having
> namespaces,  the parser throws an error because in the payload there
> is no definition of namespace. ex: fergus wants to add foo to his
> accept list.
>=20
> PUT
> =
http://xcap.example.com/services/org.openmobilealliance.poc-rules/users/s=
ip:fergus@example.com/pocrules/~~/cr:ruleset/cr:
> =
rule[@id=3D"accept"]/cr:conditions/cp:identity/cp:entry?xmlns(cr=3D"urn:i=
etf:params:xml:ns:commonpolicy")xmlns(cp=3D"urn:oma:params:xml:ns:commonp=
olicy")
> HTTP/1.1
>=20
> <cp:entry id=3D"sip:foo@example.com" />
>=20
> So when this payload in defined in the XSLT document and the XSL
> Transformer (javax.xml.transform.TransformerFactory) is used for
> generating the XCAP request, the transformer throws out an error
> saying "cp:entry not bound to parent", because as per the xml rules,
> the name space is not defined within the payload.

I don't quite follow this, so I can't tell if this is a problem with=20
using this particular java library to generate the xcap query, or=20
whether there is a protocol issue here. Can you clarify?

Thanks,
Jonathan R.

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

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



From simple-bounces@ietf.org Fri Oct 21 05:11:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESsvf-0003fV-F5; Fri, 21 Oct 2005 05:11:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESsvd-0003cZ-Bc
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 05:11:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07947
	for <simple@ietf.org>; Fri, 21 Oct 2005 05:10:58 -0400 (EDT)
From: Martin.Hynar@tietoenator.com
Received: from ebb01.tietoenator.com ([193.12.180.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESt7j-0000JG-A0
	for simple@ietf.org; Fri, 21 Oct 2005 05:23:40 -0400
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-2"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] xcap diff format in SIP notify message
Date: Fri, 21 Oct 2005 11:10:20 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F77B@carrera.eu.tieto.com>
Thread-Topic: [Simple] xcap diff format in SIP notify message
Thread-Index: AcXWEwcmXSIyBsBRS+q6vtGm9RpquwACs4nd
To: <jdrosen@cisco.com>
X-OriginalArrivalTime: 21 Oct 2005 09:10:27.0310 (UTC)
	FILETIME=[46FAD0E0:01C5D61F]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I am very sorry, but this is not solution for me, because I have to use =
I-D-xcap-package-03 while your solution is according to =
I-D-simple-xcap-diff-01. So, what would be the solution with =
I-D-xcap-package-03? Is there some way how to solve it?

br, Martin Hynar

P.S. However, your recommendations I can use for the next version.




-----P=F9vodn=ED zpr=E1va-----
Od: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
Odesl=E1no: p=E1 21.10.2005 9:42
Komu: Hynar Martin
Kopie: simple@ietf.org
P=F8edm=ECt: Re: [Simple] xcap diff format in SIP notify message
=20
responses inline.

Martin.Hynar@tietoenator.com wrote:

> Hi all,
>=20
> Few weeks ago I sent the question to the SIMPLE mailing list but I =
haven't obtained any response. However, it is very important for me so I =
am asking again.
>=20
> I am solving now the problem with communication using xcap-diff format =
specified in xcap-package-03. What is the issue:
>=20
> 1. The server carries XML document.
> 2. A client requests to be notified about changes in this document =
with xcap-diff.
> 3. The document is replaced with new content begining from the root =
(XCAP PUT with no ETag -> replacement of the content)
> 4. The server tries to notify the client with message of the format
>=20
> HEADERS
> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> <xcap-diff xmlns=3D"urn:ietf:params:xml:ns:xcap-diff" =
xcap-root=3D"http://localhost/xcap/xcap/">
>=20
>   <document =
doc-selector=3D"resource-lists/users/sip:user@domain.com/doc"
>             new-etag=3D"aaaaa"
>             previous-etag=3D"bbbbb">
>=20
>   <replace-element element=3D"/">
>     <![CDATA[<?xml version=3D"1.0" encoding=3D"UTF-8"?>
>=20
>       <resource-lists xmlns=3D"urn:ietf:params:xml:ns:resource-lists"
>=20
>                       =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
>=20
>         <list name=3D"list_name">
>=20
>           ...
>=20
>         </list>  =20
>=20
>       </resource-lists>]]>
>   </replace-element>
>=20
> </document>
>=20
> </xcap-diff>
>=20
> The question is whether the value "/" of attribute "element" is =
correct?

no. This case is described in xcap-diff. You would omit the node=20
selector entirely. Note this text:

    operation.  Both <put-event> and <delete-event> have a single
    optional attribute, "node-selector", which contains the node =
selector
    in the Request URI (after removing any escape coding) of the HTTP =
PUT
    or DELETE request.  The server MUST include the "node-selector" when
    the PUT or DELETE operation was against an XML element or attribute.
    The "node-selector" attribute MUST NOT be present if the PUT or
    DELETE operation was against the document itself.  The <put-event>


>=20
> Another problem is that I don't know what message should be sent in =
case of deletion of the document. In that case I am sending reference =
document with equal new-etag and prevoius-etag to let client refetch the =
document. Is this behaviour correct?

No. This is also described in the spec:

The "new-etag" attribute provides the
    etag for the document after the application of the changes, assuming
    the document exists after those changes.  If the change being
    reported is the deletion of the document, the "new-etag" attribute
    will not be present.

So, you'd include a previous-etag, no new-etag, and the change log would =

have a delete operation, and no node selector.

-Jonathan R.


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


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



From simple-bounces@ietf.org Fri Oct 21 07:23:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESuzd-0004gx-9s; Fri, 21 Oct 2005 07:23:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuzb-0004gj-OT
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 07:23:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14827
	for <simple@ietf.org>; Fri, 21 Oct 2005 07:23:13 -0400 (EDT)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESvBh-0004vz-71
	for simple@ietf.org; Fri, 21 Oct 2005 07:35:56 -0400
Received: from [70.104.238.60] (HELO JMHLap3.stevecrocker.com)
	by execdsl.com (CommuniGate Pro SMTP 4.2.7)
	with ESMTP id 12674933 for simple@ietf.org;
	Fri, 21 Oct 2005 05:22:19 -0600
Message-Id: <6.2.1.2.0.20051021072117.030231a0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 21 Oct 2005 07:22:59 -0400
To: Simple WG <simple@ietf.org>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and
	related issues
In-Reply-To: <43588638.8040505@cisco.com>
References: <434756D0.6070708@cisco.com>
	<6.2.1.2.0.20051008102154.02f14100@localhost>
	<43588638.8040505@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Thank you for the reply.
Given that we are already defining report syntax for a number of things, 
this makes sense to me.

Is this syntax permitted on a PUT operation?  (I don't think so.)

Yours,
Joel

At 02:10 AM 10/21/2005, Jonathan Rosenberg wrote:
>Interestingly, xpath selections are ONLY defined in terms of the logical 
>document structure. XCAP is currently saying that you can select an 
>element or an attribute, and then we are defining a way to represent a 
>single element or attribute with the two mime types we have. What I'm 
>proposing here is to add another thing you can select - namespaces - and 
>then we'll define a syntax for that too.


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



From simple-bounces@ietf.org Fri Oct 21 10:26:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESxqh-0007Ia-Sf; Fri, 21 Oct 2005 10:26:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxqg-0007GL-N8
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 10:26:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24559
	for <simple@ietf.org>; Fri, 21 Oct 2005 10:26:11 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESy2n-0002yU-I3
	for simple@ietf.org; Fri, 21 Oct 2005 10:38:56 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-1.cisco.com with ESMTP; 21 Oct 2005 07:26:10 -0700
X-IronPort-AV: i="3.97,239,1125903600"; 
	d="scan'208"; a="668216085:sNHT25070066"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9LEPpJp010802;
	Fri, 21 Oct 2005 07:26:08 -0700 (PDT)
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);
	Fri, 21 Oct 2005 10:26:03 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 10:26:03 -0400
Message-ID: <4358FA79.90904@cisco.com>
Date: Fri, 21 Oct 2005 10:26:01 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and	related
	issues
References: <434756D0.6070708@cisco.com>	<6.2.1.2.0.20051008102154.02f14100@localhost>	<43588638.8040505@cisco.com>
	<6.2.1.2.0.20051021072117.030231a0@localhost>
In-Reply-To: <6.2.1.2.0.20051021072117.030231a0@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 14:26:03.0502 (UTC)
	FILETIME=[5DD468E0:01C5D64B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

No, it would be disallowed in PUT. I'll have to say that.

-Jonathan R.

Joel M. Halpern wrote:

> Thank you for the reply.
> Given that we are already defining report syntax for a number of things, 
> this makes sense to me.
> 
> Is this syntax permitted on a PUT operation?  (I don't think so.)
> 
> Yours,
> Joel
> 
> At 02:10 AM 10/21/2005, Jonathan Rosenberg wrote:
> 
>> Interestingly, xpath selections are ONLY defined in terms of the 
>> logical document structure. XCAP is currently saying that you can 
>> select an element or an attribute, and then we are defining a way to 
>> represent a single element or attribute with the two mime types we 
>> have. What I'm proposing here is to add another thing you can select - 
>> namespaces - and then we'll define a syntax for that too.
> 
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

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



From simple-bounces@ietf.org Fri Oct 21 10:29:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESxtK-0000Ch-1k; Fri, 21 Oct 2005 10:29:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxtI-0000Cc-7M
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 10:29:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24656
	for <simple@ietf.org>; Fri, 21 Oct 2005 10:28:53 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESy5R-00032P-5f
	for simple@ietf.org; Fri, 21 Oct 2005 10:41:38 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2005 10:28:55 -0400
X-IronPort-AV: i="3.97,239,1125892800"; 
	d="scan'208"; a="74165097:sNHT25939552"
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 j9LESfEs028514; 
	Fri, 21 Oct 2005 10:28:52 -0400 (EDT)
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);
	Fri, 21 Oct 2005 10:28:44 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 10:28:44 -0400
Message-ID: <4358FB1B.9060004@cisco.com>
Date: Fri, 21 Oct 2005 10:28:43 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] xcap diff format in SIP notify message
References: <3ACC9A25264A684F82C71840111F979847F77B@carrera.eu.tieto.com>
In-Reply-To: <3ACC9A25264A684F82C71840111F979847F77B@carrera.eu.tieto.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
X-OriginalArrivalTime: 21 Oct 2005 14:28:44.0314 (UTC)
	FILETIME=[BDAE5FA0:01C5D64B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA24656
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

No, it is not possible with this older version of the draft. These are=20
bugs that were fixed in later revisions.

-Jonathan R.

Martin.Hynar@tietoenator.com wrote:

> Hi,
>=20
> I am very sorry, but this is not solution for me, because I have to use=
 I-D-xcap-package-03 while your solution is according to I-D-simple-xcap-=
diff-01. So, what would be the solution with I-D-xcap-package-03? Is ther=
e some way how to solve it?
>=20
> br, Martin Hynar
>=20
> P.S. However, your recommendations I can use for the next version.
>=20
>=20
>=20
>=20
> -----P=F9vodn=ED zpr=E1va-----
> Od: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> Odesl=E1no: p=E1 21.10.2005 9:42
> Komu: Hynar Martin
> Kopie: simple@ietf.org
> P=F8edm=ECt: Re: [Simple] xcap diff format in SIP notify message
> =20
> responses inline.
>=20
> Martin.Hynar@tietoenator.com wrote:
>=20
>=20
>>Hi all,
>>
>>Few weeks ago I sent the question to the SIMPLE mailing list but I have=
n't obtained any response. However, it is very important for me so I am a=
sking again.
>>
>>I am solving now the problem with communication using xcap-diff format =
specified in xcap-package-03. What is the issue:
>>
>>1. The server carries XML document.
>>2. A client requests to be notified about changes in this document with=
 xcap-diff.
>>3. The document is replaced with new content begining from the root (XC=
AP PUT with no ETag -> replacement of the content)
>>4. The server tries to notify the client with message of the format
>>
>>HEADERS
>><?xml version=3D"1.0" encoding=3D"UTF-8"?>
>><xcap-diff xmlns=3D"urn:ietf:params:xml:ns:xcap-diff" xcap-root=3D"http=
://localhost/xcap/xcap/">
>>
>>  <document doc-selector=3D"resource-lists/users/sip:user@domain.com/do=
c"
>>            new-etag=3D"aaaaa"
>>            previous-etag=3D"bbbbb">
>>
>>  <replace-element element=3D"/">
>>    <![CDATA[<?xml version=3D"1.0" encoding=3D"UTF-8"?>
>>
>>      <resource-lists xmlns=3D"urn:ietf:params:xml:ns:resource-lists"
>>
>>                      xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-ins=
tance">
>>
>>        <list name=3D"list_name">
>>
>>          ...
>>
>>        </list>  =20
>>
>>      </resource-lists>]]>
>>  </replace-element>
>>
>></document>
>>
>></xcap-diff>
>>
>>The question is whether the value "/" of attribute "element" is correct=
?
>=20
>=20
> no. This case is described in xcap-diff. You would omit the node=20
> selector entirely. Note this text:
>=20
>     operation.  Both <put-event> and <delete-event> have a single
>     optional attribute, "node-selector", which contains the node select=
or
>     in the Request URI (after removing any escape coding) of the HTTP P=
UT
>     or DELETE request.  The server MUST include the "node-selector" whe=
n
>     the PUT or DELETE operation was against an XML element or attribute.
>     The "node-selector" attribute MUST NOT be present if the PUT or
>     DELETE operation was against the document itself.  The <put-event>
>=20
>=20
>>Another problem is that I don't know what message should be sent in cas=
e of deletion of the document. In that case I am sending reference docume=
nt with equal new-etag and prevoius-etag to let client refetch the docume=
nt. Is this behaviour correct?
>=20
>=20
> No. This is also described in the spec:
>=20
> The "new-etag" attribute provides the
>     etag for the document after the application of the changes, assumin=
g
>     the document exists after those changes.  If the change being
>     reported is the deletion of the document, the "new-etag" attribute
>     will not be present.
>=20
> So, you'd include a previous-etag, no new-etag, and the change log woul=
d=20
> have a delete operation, and no node selector.
>=20
> -Jonathan R.
>=20
>=20

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

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



From simple-bounces@ietf.org Fri Oct 21 12:02:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESzM2-0005Dr-0F; Fri, 21 Oct 2005 12:02:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzM1-0005Dm-58
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 12:02:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15221
	for <simple@ietf.org>; Fri, 21 Oct 2005 12:02:37 -0400 (EDT)
Received: from opus.cs.columbia.edu ([128.59.20.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESzYA-0003ba-Td
	for simple@ietf.org; Fri, 21 Oct 2005 12:15:24 -0400
Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j9LG2OWk026029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 21 Oct 2005 12:02:25 -0400 (EDT)
Message-ID: <435910D6.1030501@cs.columbia.edu>
Date: Fri, 21 Oct 2005 12:01:26 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues (directory)
References: <434756D0.6070708@cisco.com> <4347D5EB.6010204@cs.columbia.edu>
	<4358832B.8020203@cisco.com>
In-Reply-To: <4358832B.8020203@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

>> Example:
>>
>> PUT /bill/resource-lists
> 
> 
> Thats really not much different that requiring the application usage to 
> specify a convention. The latter leaves some flexibility in case 
> multiple documents are needed, so I prefer that.

So far, flexibility has bought us an utter configuration mess and 
significant implementation and interop complexity, so I'm less convinced 
of the trade-off.


> The issue is there in sip too; the username portion of the digest 
> credentials could be "bill", and the realm "server.example.com", but 
> this doesnt mean that the URI in the From or P-Asserted-ID would be 
> sip:bill@server.example.com. Rather, the SIP URI would be based on a 
> provisioned mapping of the two (private to public ID in IMS terminology).
> 
> XCAP says more or less the same thing; there is a provisioned mapping on 
> the server from authenticated identity of the http client, to the XUI. 
> The client has to know it as another piece of configuration.

You will not be surprised to hear that I find "yet another piece of 
configuration" wholly unsatisfactory. Why can't we make a determination 
that does not require yet more configuration, provisioning and all the 
other "flexibility" that cause existing systems to not work out of the box?

I'd rather not restrict the use of SIP to IMS and similar 
professionally-managed systems.



> 
>>
>> We have enough of a configuration mess at our hands without adding 
>> more unspecified linkages that must be resolved through some unknown 
>> mechanism that may or may not be universally deployed. I think the 
>> most sensible mechanism is to use the same NAPTR/SRV mechanism, even 
>> though that's not part of the standard HTTP resolution mechanism.
> 
> 
> I'm not sure what NAPTR has to do with it...

Getting from a user name to the XCAP URL. I want to have a simple, 
well-defined, deterministic, non-configured means of determining the 
XCAP URL once I have a user name.



> 
> -Jonathan R.
> 

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



From simple-bounces@ietf.org Fri Oct 21 13:38:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET0qw-0006XL-2J; Fri, 21 Oct 2005 13:38:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0qu-0006XD-F8
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 13:38:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20764
	for <simple@ietf.org>; Fri, 21 Oct 2005 13:38:38 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET134-0007GR-U9
	for simple@ietf.org; Fri, 21 Oct 2005 13:51:24 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2005 13:38:37 -0400
X-IronPort-AV: i="3.97,240,1125892800"; 
	d="scan'208"; a="74179334:sNHT24984322"
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 j9LHc2FE002519; 
	Fri, 21 Oct 2005 13:38:34 -0400 (EDT)
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);
	Fri, 21 Oct 2005 13:38:31 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 13:38:30 -0400
Message-ID: <43592796.1060805@cisco.com>
Date: Fri, 21 Oct 2005 13:38:30 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues (directory)
References: <434756D0.6070708@cisco.com> <4347D5EB.6010204@cs.columbia.edu>
	<4358832B.8020203@cisco.com> <435910D6.1030501@cs.columbia.edu>
In-Reply-To: <435910D6.1030501@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 17:38:30.0680 (UTC)
	FILETIME=[407BF180:01C5D666]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Henning Schulzrinne wrote:

>>> Example:
>>>
>>> PUT /bill/resource-lists
>>
>>
>>
>> Thats really not much different that requiring the application usage 
>> to specify a convention. The latter leaves some flexibility in case 
>> multiple documents are needed, so I prefer that.
> 
> 
> So far, flexibility has bought us an utter configuration mess and 
> significant implementation and interop complexity, so I'm less convinced 
> of the trade-off.

Well, my view as you know is we are well beyond the point of being able 
to usefully have a SIP UA that requires no other configuration beyond 
its username and password. So, once you think that there will need to be 
somethng to provide configuration anyway (via config framework or just 
ftp-d at startup or whatever), adding more to it has zero cost. That 
said there is no point in needless configuration, I agree.


> 
> 
>> The issue is there in sip too; the username portion of the digest 
>> credentials could be "bill", and the realm "server.example.com", but 
>> this doesnt mean that the URI in the From or P-Asserted-ID would be 
>> sip:bill@server.example.com. Rather, the SIP URI would be based on a 
>> provisioned mapping of the two (private to public ID in IMS terminology).
>>
>> XCAP says more or less the same thing; there is a provisioned mapping 
>> on the server from authenticated identity of the http client, to the 
>> XUI. The client has to know it as another piece of configuration.
> 
> 
> You will not be surprised to hear that I find "yet another piece of 
> configuration" wholly unsatisfactory.

Yup, I'm not surprised ;)

> Why can't we make a determination 
> that does not require yet more configuration, provisioning and all the 
> other "flexibility" that cause existing systems to not work out of the box?

I welcome a proposal.


>>> We have enough of a configuration mess at our hands without adding 
>>> more unspecified linkages that must be resolved through some unknown 
>>> mechanism that may or may not be universally deployed. I think the 
>>> most sensible mechanism is to use the same NAPTR/SRV mechanism, even 
>>> though that's not part of the standard HTTP resolution mechanism.
>>
>>
>>
>> I'm not sure what NAPTR has to do with it...
> 
> 
> Getting from a user name to the XCAP URL. I want to have a simple, 
> well-defined, deterministic, non-configured means of determining the 
> XCAP URL once I have a user name.

So, you are proposing something like this - that each user has their sip 
AOR (sip:user@domain). THey'd do a NAPTR lookup of the domain to 
retrieve their xcap server, and then construct the xcap request by 
taking the host learned from it, and using the user part of the aor as 
the xuid? Is that right?

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

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



From simple-bounces@ietf.org Fri Oct 21 13:52:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET13m-0006RA-K6; Fri, 21 Oct 2005 13:52:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ET13k-0006R5-WA
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 13:52:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21456
	for <simple@ietf.org>; Fri, 21 Oct 2005 13:51:54 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ET1Fv-0007it-Pi
	for simple@ietf.org; Fri, 21 Oct 2005 14:04:41 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-2.cisco.com with ESMTP; 21 Oct 2005 10:51:55 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9LHpTut003534;
	Fri, 21 Oct 2005 10:51:52 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 21 Oct 2005 13:51:49 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 21 Oct 2005 13:51:49 -0400
Message-ID: <43592AB3.9010005@cisco.com>
Date: Fri, 21 Oct 2005 13:51:47 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: "Ramalakshmi V. Gunturi" <ramagv@sonimtech.com>
Subject: Re: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
References: <E7F5A43EEB6E7C42A08C041BDEB90A5305B0A0@mail2.sonimtech.com>
In-Reply-To: <E7F5A43EEB6E7C42A08C041BDEB90A5305B0A0@mail2.sonimtech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 17:51:49.0446 (UTC)
	FILETIME=[1C95F660:01C5D668]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Ramalakshmi V. Gunturi wrote:

> HI,
> 
> As the Specification uses XML fragments that are not well formed
> (when used with namespaces), the standard parsers are causing
> problems.

I'm confused. Why is it not well-formed? Well-formed requires matching 
opening and closing brackets. This is the case for all of the xml 
fragments, including the one in your example below. What am I missing?

> 
> I understand that using statically configured query was not a
> requirement in the specification, but looking from the development
> point of view if we have the support of static queries it gives us
> the advantage of having a cleaner code and easy adaptation to changes
> in protocols.

I don't see how these relate. Maybe we are not talking about the same 
thing. To me, "static queries" means that a client can be configured 
with a particular URI to use and a particular xml body to use in a PUT 
operation, with some kind of variable (like a buddy name), which it 
fills in). Thus, the client can't do generic xcap manipulations, it can 
just do an enumerated set of operations on the server that it cares 
about. This is beneficial since it means a client implementation of xcap 
can be done almost trivially, wihtout really even knowning what xcap is.

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

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



From simple-bounces@ietf.org Fri Oct 21 15:51:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET2vR-0004VA-53; Fri, 21 Oct 2005 15:51:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET2u0-0003rI-TQ; Fri, 21 Oct 2005 15:50:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29999;
	Fri, 21 Oct 2005 15:49:56 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ET367-0004Y6-RF; Fri, 21 Oct 2005 16:02:42 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ET2tu-0001Eg-7h; Fri, 21 Oct 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1ET2tu-0001Eg-7h@newodin.ietf.org>
Date: Fri, 21 Oct 2005 15:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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) extension
                          for Partial Notification of Presence Information
	Author(s)	: M. Lonnfors, et al.
	Filename	: draft-ietf-simple-partial-notify-06.txt
	Pages		: 15
	Date		: 2005-10-21
	
By default, presence delivered using the Presence Event Package for
   the Session Initiation Protocol is represented in the Presence
   Information Data Format (PIDF).  A PIDF document contains a set of
   elements, each representing a different aspect of the presence being
   reported.  When any subset of the elements change, even just a single
   element, a new document containing the full set of elements is
   delivered.  This memo defines an extension allowing delivery of
   presence data that has actually changed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-06.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-partial-notify-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-partial-notify-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: <2005-10-21140733.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-partial-notify-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-partial-notify-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-21140733.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 Oct 21 15:54:55 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET2yd-0006RH-8m; Fri, 21 Oct 2005 15:54:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2yb-0006R8-MO
	for simple@megatron.ietf.org; Fri, 21 Oct 2005 15:54:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01376
	for <simple@ietf.org>; Fri, 21 Oct 2005 15:54:41 -0400 (EDT)
Received: from figas.ekabal.com ([204.61.215.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET3Am-00055H-FR
	for simple@ietf.org; Fri, 21 Oct 2005 16:07:29 -0400
Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88])
	(authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j9LJsiW22037;
	Fri, 21 Oct 2005 12:54:44 -0700
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <78cdbd7ab607196ec89580de86c03ac5@ekabal.com>
Content-Transfer-Encoding: 7bit
From: Rohan Mahy <rohan@ekabal.com>
Date: Fri, 21 Oct 2005 12:54:49 -0700
To: "simple@ietf.org WG" <simple@ietf.org>
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: Rohan Mahy <rohan@ekabal.com>
Subject: [Simple] new XCAP Profile draft
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I submitted a draft which specifies a limited profile of XCAP for the  
resource-list and common-policy/authorization usages.  The profile just  
further restricts the XPath expressions that an XCAP client would use.   
Clients following the profile can manipulate whole documents, whole  
resource-lists (including sublists), and individual entry, entry-ref,  
external, and rule elements, but can't dive deeper into the XPath  
hierarchy.

Please take a look at the draft and provide comments on the idea. Until  
it appears in the archive, you can find it here:

	http://scm.sipfoundry.org/rep/ietf-drafts/rohan/xcapalt/draft-mahy- 
simple-xcap-profile-00.html
	http://scm.sipfoundry.org/rep/ietf-drafts/rohan/xcapalt/draft-mahy- 
simple-xcap-profile-00.txt

thanks,
-rohan


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



From simple-bounces@ietf.org Sat Oct 22 01:54:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETCKZ-0003tX-Ks; Sat, 22 Oct 2005 01:54:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCKW-0003pR-Gu
	for simple@megatron.ietf.org; Sat, 22 Oct 2005 01:54:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19650
	for <simple@ietf.org>; Sat, 22 Oct 2005 01:53:58 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETCWn-0000cA-Kf
	for simple@ietf.org; Sat, 22 Oct 2005 02:06:50 -0400
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 21 Oct 2005 22:53:57 -0700
X-IronPort-AV: i="3.97,240,1125903600"; 
	d="scan'208"; a="222731456:sNHT24223108"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9M5ri8s022461;
	Fri, 21 Oct 2005 22:53:53 -0700 (PDT)
Received: from 10.21.120.51 ([10.21.120.51]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Sat, 22 Oct 2005 05:53:59 +0000
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Fri, 21 Oct 2005 21:52:56 -0700
Subject: Re: [Simple] MSRP v10 "msrp/tcp" <> MSRP v11 "TCP/MSRP"
From: Cullen Jennings <fluffy@cisco.com>
To: Ignacio Mas Ivars <ignacio.mas.ivars@ericsson.com>,
	"simple@ietf.org" <simple@ietf.org>
Message-ID: <BF7F13B8.569C2%fluffy@cisco.com>
Thread-Topic: [Simple] MSRP v10 "msrp/tcp" <> MSRP v11 "TCP/MSRP"
Thread-Index: AcXWxHextgOAkkK3EdqhrAARJEEJ/A==
In-Reply-To: <1124269102.7579.7.camel@localhost.localdomain>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


The short answer is a long and very education for the authors of the draft
phone call with the mmusic chair resulted in us putting exactly what they
recommended. The longer answer is this is really consistent with all the
other SDP drafts - particularly the floor control stuff.

On 8/17/05 1:58 AM, "Ignacio Mas Ivars" <ignacio.mas.ivars@ericsson.com>
wrote:

> 
> Hi!
> 
> There has been a change between version 10 and version 11 of the MSRP
> draft regarding how the protocol field of the m line in the SDP
> description is written. Version 10 says:
> 
>  An offered or accepted media-line for MSRP over TCP MUST include a
>    protocol field value of "msrp/tcp".  The media field value MUST be
>    "message".  The format list field MUST be set to "*".
> 
> 
> while version 11 changes the field to:
> 
>  An offered or accepted media-line for MSRP over TCP MUST include a
>    protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS.  The
>    media field value MUST be "message".  The format list field MUST be
>    set to "*".
> 
> Is there any particular reason for the change in order? I don't have any
> strong opinion about the change, but it requieres modifying existing
> prototype implementations and I just wonder if the reason was more
> cosmetic than anything else.
> 
> Thanks!
> /Ignacio

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



From simple-bounces@ietf.org Sat Oct 22 01:54:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETCKg-0003z8-E8; Sat, 22 Oct 2005 01:54:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCKV-0003pH-4u
	for simple@megatron.ietf.org; Sat, 22 Oct 2005 01:54:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19647
	for <simple@ietf.org>; Sat, 22 Oct 2005 01:53:53 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETCWk-0000c3-BD
	for simple@ietf.org; Sat, 22 Oct 2005 02:06:46 -0400
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 21 Oct 2005 22:53:55 -0700
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9M5ri8q022461;
	Fri, 21 Oct 2005 22:53:51 -0700 (PDT)
Received: from 10.21.120.51 ([10.21.120.51]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Sat, 22 Oct 2005 05:53:59 +0000
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Fri, 21 Oct 2005 21:48:22 -0700
Subject: Re: [Simple] Questions regarding MSRP drafts
From: Cullen Jennings <fluffy@cisco.com>
To: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
Message-ID: <BF7F12A6.569C1%fluffy@cisco.com>
Thread-Topic: [Simple] Questions regarding MSRP drafts
Thread-Index: AcXWw9RgEuI/s0K3EdqhrAARJEEJ/A==
In-Reply-To: <42FA64A0.1020109@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


You have some great comments - one I wanted to comment on.

On 8/10/05 1:33 PM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

>> Buffer overwriting
>> -------------------
>> 
>>   draft-ietf-simple-message-sessions-11 recommends that, in case of
>> chunk retransmit, the end point overwrites already received data with
>> newly received one. While it is only a SHOULD, there does not seem to be
>> any reason for this. It is illegal to receive new data that would not
>> match previously received chunks anyway. Actually, I'd rather consider
>> this as the sign of a hack attempt. So why should clients do that?
> 
> I agree with you on this one. I wanted it to be an error for any
> overlapping data to differ from the original. (Without requiring that
> this error be detected.) But I was outvoted.

This is somewhat an result of that from an overall message point of view,
this is not a store and forward system but more of a streaming systems. It
is ok to use part of the message before the whole thing is received. People
that were outputting to an output device like a speaker, or a brail printer
may not be able to backup over the data that was already output. 

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



From simple-bounces@ietf.org Sat Oct 22 01:54:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETCKi-0003zn-DG; Sat, 22 Oct 2005 01:54:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCKY-0003qu-2L
	for simple@megatron.ietf.org; Sat, 22 Oct 2005 01:54:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19658
	for <simple@ietf.org>; Sat, 22 Oct 2005 01:53:59 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETCWp-0000cA-Q7
	for simple@ietf.org; Sat, 22 Oct 2005 02:06:52 -0400
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 21 Oct 2005 22:54:00 -0700
X-IronPort-AV: i="3.97,240,1125903600"; 
	d="scan'208,217"; a="222731480:sNHT34196320"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9M5ri8w022461;
	Fri, 21 Oct 2005 22:53:56 -0700 (PDT)
Received: from 10.21.120.51 ([10.21.120.51]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Sat, 22 Oct 2005 05:54:00 +0000
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Fri, 21 Oct 2005 21:58:45 -0700
Subject: Re: [Simple] Does IMS must using IPv6?
From: Cullen Jennings <fluffy@cisco.com>
To: Cheney Stallman <zodist@gmail.com>, "simple@ietf.org" <simple@ietf.org>
Message-ID: <BF7F1515.569C3%fluffy@cisco.com>
Thread-Topic: [Simple] Does IMS must using IPv6?
Thread-Index: AcXWxUe2hk5t+UK4EdqhrAARJEEJ/A==
In-Reply-To: <29ac328c05083007565bf8baa9@mail.gmail.com>
Mime-version: 1.0
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1058038493=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1058038493==
Content-type: multipart/alternative;
	boundary="B_3212780037_8420764"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3212780037_8420764
Content-type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit


I've been puzzled by this too - I'm sure the answer is complicated and
involves understanding the many different IMSsz but as far as I can tell,
the short answer is that, in theory it does but in practice it does not.

On 8/30/05 7:56 AM, "Cheney Stallman" <zodist@gmail.com> wrote:

> This problem puzzled me, Does IMS must using IPv6, or paritial using IPv6,
> or some other restriction?
>  
> Thanks in advanced.
>  
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple



--B_3212780037_8420764
Content-type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Simple] Does IMS must using IPv6?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'><BR>
I've been puzzled by this too - I'm sure the answer is complicated and invo=
lves understanding the many different IMSsz but as far as I can tell, the sh=
ort answer is that, in theory it does but in practice it does not. <BR>
<BR>
On 8/30/05 7:56 AM, &quot;Cheney Stallman&quot; &lt;zodist@gmail.com&gt; wr=
ote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL=
E=3D'font-size:12.0px'>This problem puzzled me, Does IMS must using IPv6, or p=
aritial using IPv6,<BR>
or some other restriction?<BR>
&nbsp;<BR>
Thanks in advanced.<BR>
&nbsp;<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Monaco, Courier New"><SPAN STYLE=3D'font-size:10.0px'>____________________=
___________________________<BR>
Simple mailing list<BR>
Simple@ietf.org<BR>
https://www1.ietf.org/mailman/listinfo/simple<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courie=
r New"><SPAN STYLE=3D'font-size:10.0px'><BR>
</SPAN></FONT></FONT>
</BODY>
</HTML>


--B_3212780037_8420764--


--===============1058038493==
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

--===============1058038493==--




From simple-bounces@ietf.org Sat Oct 22 18:37:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETRzk-0001B3-8f; Sat, 22 Oct 2005 18:37:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETRzh-0001At-Iz
	for simple@megatron.ietf.org; Sat, 22 Oct 2005 18:37:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02677
	for <simple@ietf.org>; Sat, 22 Oct 2005 18:37:29 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETSC8-0007S2-J1
	for simple@ietf.org; Sat, 22 Oct 2005 18:50:32 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2005 15:37:31 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.97,241,1125903600"; 
	d="scan'208"; a="13698272:sNHT21553872"
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 j9MMbREi020113; 
	Sat, 22 Oct 2005 18:37:28 -0400 (EDT)
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);
	Sat, 22 Oct 2005 18:37:27 -0400
Received: from [10.86.242.56] ([10.86.242.56]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Sat, 22 Oct 2005 18:37:27 -0400
Message-ID: <435ABF26.4000500@cisco.com>
Date: Sat, 22 Oct 2005 18:37:26 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Simple] Questions regarding MSRP drafts
References: <BF7F12A6.569C1%fluffy@cisco.com>
In-Reply-To: <BF7F12A6.569C1%fluffy@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Oct 2005 22:37:27.0088 (UTC)
	FILETIME=[2DD45B00:01C5D759]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: Remi Denis-Courmont <remi.denis-courmont@nokia.com>,
	"simple@ietf.org" <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Cullen Jennings wrote:
> You have some great comments - one I wanted to comment on.
> 
> On 8/10/05 1:33 PM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
> 
> 
>>>Buffer overwriting
>>>-------------------
>>>
>>>  draft-ietf-simple-message-sessions-11 recommends that, in case of
>>>chunk retransmit, the end point overwrites already received data with
>>>newly received one. While it is only a SHOULD, there does not seem to be
>>>any reason for this. It is illegal to receive new data that would not
>>>match previously received chunks anyway. Actually, I'd rather consider
>>>this as the sign of a hack attempt. So why should clients do that?
>>
>>I agree with you on this one. I wanted it to be an error for any
>>overlapping data to differ from the original. (Without requiring that
>>this error be detected.) But I was outvoted.
> 
> 
> This is somewhat an result of that from an overall message point of view,
> this is not a store and forward system but more of a streaming systems. It
> is ok to use part of the message before the whole thing is received. People
> that were outputting to an output device like a speaker, or a brail printer
> may not be able to backup over the data that was already output. 

That is why I wanted to declare it an error but not require it to be 
detected. If you are streaming data, then you just don't detect the 
error. But if you are storing data (e.g. if it was a file transfer) you 
could detect the error.

But this isn't a big deal as long as it isn't considered a *feature* to 
retransmit changed data.

	Paul

	Paul

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



From simple-bounces@ietf.org Sat Oct 22 18:41:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETS3R-0002kT-KX; Sat, 22 Oct 2005 18:41:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETS3O-0002kF-Vi
	for simple@megatron.ietf.org; Sat, 22 Oct 2005 18:41:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02766
	for <simple@ietf.org>; Sat, 22 Oct 2005 18:41:18 -0400 (EDT)
Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETSFo-0007YB-Px
	for simple@ietf.org; Sat, 22 Oct 2005 18:54:22 -0400
Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net
	[141.153.174.94]) (user=hgs10 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9MMfNvb026921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 22 Oct 2005 18:41:23 -0400 (EDT)
Message-ID: <435ABFFE.8010404@cs.columbia.edu>
Date: Sat, 22 Oct 2005 18:41:02 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues (directory)
References: <434756D0.6070708@cisco.com> <4347D5EB.6010204@cs.columbia.edu>
	<4358832B.8020203@cisco.com> <435910D6.1030501@cs.columbia.edu>
	<43592796.1060805@cisco.com>
In-Reply-To: <43592796.1060805@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Jonathan Rosenberg wrote:

> Well, my view as you know is we are well beyond the point of being able 
> to usefully have a SIP UA that requires no other configuration beyond 
> its username and password. So, once you think that there will need to be 

I think this wouldn't have to be the case, at least for default 
operation (and no outbound proxy). What would one really *need* beyond that?


> somethng to provide configuration anyway (via config framework or just 
> ftp-d at startup or whatever), adding more to it has zero cost. That 
> said there is no point in needless configuration, I agree.

Each new identifier space brings with it possible confusion, 
particularly since implementors seem to be unable to use consistent 
terminology. Thus, having application IDs that are different from the 
directory will just lead to misconfiguration, with no discernible 
benefit. Those rate "applications" that need multiple documents can just 
use multiple identifiers.

>> Why can't we make a determination that does not require yet more 
>> configuration, provisioning and all the other "flexibility" that cause 
>> existing systems to not work out of the box?
> 
> 
> I welcome a proposal.
> 

I made one: directory/file name === AUID (depending on how the default 
structure.

By default, the XUI should be equal to the public ID, i.e., the AOR. 
(This is most likely the only correct behavior if we allow third parties 
to access other XUIs.)

If some configuration wants to override this, fine, but by providing a 
default, things work without configuration and for (a/the) common case.


> So, you are proposing something like this - that each user has their sip 
> AOR (sip:user@domain). THey'd do a NAPTR lookup of the domain to 
> retrieve their xcap server, and then construct the xcap request by 
> taking the host learned from it, and using the user part of the aor as 
> the xuid? Is that right?

Almost. I'd use the NAPTR approach in the way you describe but, but then 
use the AOR as-is as the XUI. This works if several hosts share the same 
XCAP server, for example.

We'd essentially create a "pseudo" URN, just like the "pres" and "IM" 
URNs, as in xcap:user@domain, and then use DDDS to get us to the right 
place. Thus, we'd have

AOR: alice@example.com
--> NAPTR provides xcap-provider.com, a shared web host serving lots of 
AOR domains

GET /alice@example.com/resource-list
Host: xcap-provider.com

By default, they'd use the same Digest credentials to access that 
resource. Thus, no new configuration.

> 
> -Jonathan R.

Henning

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



From simple-bounces@ietf.org Sun Oct 23 00:30:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETXVY-0002XK-Q7; Sun, 23 Oct 2005 00:30:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETXVV-0002VV-Jq
	for simple@megatron.ietf.org; Sun, 23 Oct 2005 00:30:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13173
	for <simple@ietf.org>; Sun, 23 Oct 2005 00:30:41 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETXhy-0007gj-Nf
	for simple@ietf.org; Sun, 23 Oct 2005 00:43:47 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 23 Oct 2005 00:30:44 -0400
X-IronPort-AV: i="3.97,241,1125892800"; 
	d="scan'208"; a="74244060:sNHT23929736"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9N4UY29012142
	for <simple@ietf.org>; Sun, 23 Oct 2005 00:30:42 -0400 (EDT)
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);
	Sun, 23 Oct 2005 00:30:40 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Sun, 23 Oct 2005 00:30:40 -0400
Message-ID: <435B11F0.7090903@cisco.com>
Date: Sun, 23 Oct 2005 00:30:40 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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 <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Oct 2005 04:30:40.0713 (UTC)
	FILETIME=[8636E390:01C5D78A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Subject: [Simple] updated xcap-diff and new xcap-log
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Folks,

I've just submitted an update to xcap-diff. Per my email to the list a 
week or so ago, I've split the draft in two. One part, xcap-diff:

http://www.jdrosen.net/papers/draft-ietf-simple-xcap-diff-02.txt

is a minimal format that just conveys etags, very short. The actual 
change indication itself is now specified here:

http://www.jdrosen.net/papers/draft-rosenberg-simple-xcap-change-log-00.txt

The idea for the split was that xcap depends only on the content of 
xcap-diff now, not on the more controversial content of xcap-change-log.

Some other changes, mostly in change-log:

* escape coding required for node-selector

* the main problem reported about change-log in the last meeting, was 
the fact that it was using cdata to encapsultate the xml fragment that 
was added or changed in the doc. However, if that fragment contains 
CDATA too, you end up with nested cdata.

So, my fix was to include the xml fragment without encapsulation. In 
order to do that, all in-scope namespaces need to get declared in the 
enclosing element.


Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Sun Oct 23 01:44:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETYeG-0003yN-22; Sun, 23 Oct 2005 01:44:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETYeE-0003yI-GP
	for simple@megatron.ietf.org; Sun, 23 Oct 2005 01:43:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15818
	for <simple@ietf.org>; Sun, 23 Oct 2005 01:43:45 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ETYqi-00019i-7Q
	for simple@ietf.org; Sun, 23 Oct 2005 01:56:53 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 22 Oct 2005 22:43:48 -0700
X-IronPort-AV: i="3.97,241,1125903600"; 
	d="scan'208"; a="355569150:sNHT23505708"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9N5hjub001243
	for <simple@ietf.org>; Sat, 22 Oct 2005 22:43:46 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Sun, 23 Oct 2005 01:43:45 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Sun, 23 Oct 2005 01:43:45 -0400
Message-ID: <435B2310.4010009@cisco.com>
Date: Sun, 23 Oct 2005 01:43:44 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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 <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Oct 2005 05:43:45.0114 (UTC)
	FILETIME=[BB8563A0:01C5D794]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Subject: [Simple] updated presence 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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I've just submitted an update to the presence data model draft based on 
comments received during WGLC. Until it appears in the archives, you can 
pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-06.txt

The only change was to fix some line wrapping, and to clarify the 
meaning of the absence of the contact parameter in a service.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Oct 24 00:59:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETuQx-0001ZK-2T; Mon, 24 Oct 2005 00:59:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETuQr-0001WA-Ki
	for simple@megatron.ietf.org; Mon, 24 Oct 2005 00:59:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14820
	for <simple@ietf.org>; Mon, 24 Oct 2005 00:59:24 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ETudY-0003hf-48
	for simple@ietf.org; Mon, 24 Oct 2005 01:12:44 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 23 Oct 2005 21:59:28 -0700
X-IronPort-AV: i="3.97,243,1125903600"; 
	d="scan'208"; a="355764803:sNHT31763896"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9O4xPJh016439
	for <simple@ietf.org>; Sun, 23 Oct 2005 21:59:26 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 24 Oct 2005 00:59:25 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 24 Oct 2005 00:59:25 -0400
Message-ID: <435C6A2C.60101@cisco.com>
Date: Mon, 24 Oct 2005 00:59:24 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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 <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Oct 2005 04:59:25.0187 (UTC)
	FILETIME=[B47E7D30:01C5D857]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c2e58d9873012c90703822e287241385
Content-Transfer-Encoding: 7bit
Subject: [Simple] Revised XCAP I-D posted
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Folks,

I've revised the xcap spec per discussion over the last few weeks and 
submitted to the I-D editor. At a high level, I made the following changes:

* fixed bugs and unclear things reported since approval
* added extensibility to the URI and described server behavior in the 
face of unknown URI
* added the ability to select namespaces and GET them, returning a 
simple document format that defines the namespaces for an element
* RECOMMEND conventions for the xcap root services URI, XUI and 
directory structures to avoid the need to configure these
* Significant new text discussing where elements get inserted exactly, 
especially as it relates to white space, comments, etc.

Until the document appears, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-xcap-08.txt


I think there is more discussion to be had here; I'll post a few notes 
momentarily.

Here are the detailed changes I made to the document:

* Added extensibility for the URI. This was done by adding two hooks
into the grammar for the URI. Added language that requires a server to
reject a request with a 404 if it doesnt understand one of the
extensions. Mentioned that a xcap-caps document lists an extension
token for extensions that extend the selector capabilities of xcap.

* Added the ability to query for namespaces, using namespace::* from
xpath. Specify this only for GET - returns a 405 if in PUT or
DELETE. It returns a document of form xcap-ns+xml, which is an xml
fragment containing a single element, which is the element whose
namespace bindings are desired. That element has xmlns and
xmlns:prefix declarations for all in-scope namespaces. Gave an example
of how this works. Added MIME type definitions for it.

* Fixed faulty XML document example in section 6.4, which should have
had a namespace binding declared with xmlns:ns3 and not xmlns:hi as
written.

* Example in section 6.3 didn't respect whitespace in the value
returned by the xcap query. Fixed this.

* Example namespace binding declarations with xmlns() in section 6.4
included quotes in them, but those are not allowed URI characters ane
need to be escaped. Fixed them to be escaped with %22

* Section 7.4 said, " The "*" indicates that all children of 
<watcher-info> are to be
    considered when computing the position for insertion.  If, instead
of ..." when it really mean, "..indicates that all element
children...". So, added the word element in there.

* There was some discussion on the list in early September around
confusion on when to send a 200 or 201. Specifically, Dean had asked
this:

Here's the question as it was asked me: "Problem Summary: In the
document: "The Extensible Markup Language (XML)Configuration Access
Protocol, (XCAP), draft-ietf-simple-xcap-07" section 8.2.6 is unclear
regarding a server response to a PUT request.  Problem Text: In the
document: "The Extensible Markup Language (XML)Configuration Access
Protocol, (XCAP), draft-ietf-simple-xcap-07" section 8.2.6 states "If
the creation or insertion was successful, and the resource
interdependencies are resolved, the server returns a 200 OK or 201
Created, as appropriate."

This text is faulty. In particular, the sentence, "If the creation or
insertion..." is problematic, since both creation and insertion result
in a 201. The text needs to say creation or replacement, to match up
with the operations defined in Section 8.2.3 and 8.2.4
respectively. There was also some confusion about whether 201 applies
to element or attribute insertions. The answer is
ABSOLUTELY. REmember, the big idea with xcap is that elements and
attributes are just resources like any other http resource, and rules
for handling them apply as defined in rfc2616.

So, the new text I put in the last paragraph of 8.2.6 now reads:

<t> If the creation or replacement was successful, and the resource
interdependencies are resolved, the server returns a 201 Created or OK
or 200, respectively. Note that a 201 Created is generated for
creation of new documents, elements, or attributes. If the client
included "application/xcap-diff+xml" in an Accept header in the PUT


* Updated URI reference from 2396 to 3986 per Ted's recommendation in
the discussoin on quoting of ~~

* Clarified the escaping of ~~ in the beginning of section 6. Text now
reads:

..identifies a document within the XCAP root. The path separator is a
path segment with a value of double tilde ("~~"), and SHOULD NOT be
percent-encoded, as advised in Section 2.3 of RFC 3986 <xref
target="RFC3986"/>.  URIs containing %7E%7E should be normalized to ~~
for comparison; they are equivalent. The path separator is piece of
syntactic sugar that separates the document selector from the node
selector. The node selector is an expression that identifies an XML
element within a document.  </t>


* removed schema-instance declarations from example documents per
Jaris comments

* On the whole insertion thing, I removed this paragraph entirely from the
bottom of section 7.4:

<t>
When the client does not explicitly indicate a position in which to
insert a new element, the server will insert that element as the last
child of that parent. If this is not the desired position, the client
should perform a positional insertion.
</t>

This is misleading, since even with an explicit position there is only
a certain amount of control on where the server inserts.

And indeed, where the server inserts was very much underspecified. The
logic I sent out on the list didnt quite work, since it led to various
inconsistent behaviors. I ended up adding the following text in
Section 8.2.3:

<t> If the PUT request is for an element, the server inserts the
content of the request body as a new child element of the parent
element selected in <xref target="sec:parent"/>. The insertion is done
such that, the request URI, when evaluated, would now point to the
element which was inserted. If the target selector is defined by a
by-name or by-attr production (in other words, there is no position
indicated) the server MUST insert the element such that it is in the
"earliest last" position. "Earliest last" means that it MUST be
inserted so that there are no elements after 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. Furthermore, if there were comment, whitespace, or
processing instructions after the last element with the same name,
they MUST occur prior to the insertion of the new element. In other
words, it appears just after the last element with that name, but
before any comments, whitespace or processing instructions. If there
were no other sibling elements with the same element name, the new
element is inserted such that it is the last element amongst all
element siblings. Furthermore, if there were comment, whitespace, or
processing instructions after the former last element,
they MUST occur prior to the insertion of the new element.
</t>

<t> 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. Furthermore, if there were comment, whitespace, or
processing instructions after the previous element with the same name,
they MUST occur prior to the insertion of the new element. If there
were no other sibling elements with the same element name, a
positional insertion is only possible if the position was 1. In such a
case, the new element is inserted such that it is the last element
amongst all element siblings. Furthermore, if there were comment,
whitespace, or processing instructions after the former last element,
they MUST occur prior to the insertion of the new element.  </t>

<t>
For example, consider the following document:
</t>

<figure><artwork>
<![CDATA[
<root>
  <el1 att="first"/>
  <el1 att="second"/>
  <!--comment -->
  <el2 att="first/>
</root>
<figure><artwork>
]]></artwork></figure>


<t>
A PUT request whose content is &lt;el1 att="third"/&gt; and whose node
selector is root/el1[@att="third"] would result in the following
document:
</t

<figure><artwork>
<![CDATA[
<root>
  <el1 att="first"/>
  <el1 att="second"/>
  <!--comment -->
  <el1 att="third"><el2 att="first/>
</root>
<figure><artwork>
]]></artwork></figure>

<t>
Notice how it has been inserted as the third el1 element in the
document, and has been inserted right below it, but just after the
comments and whitespace. It would have been inserted in exactly the
same place if the node selector had been root/el1[3][@att="third"]. If
the content of request had been &lt;el3 att="first"/&gt; and the node
selector was root/el3, it would result in the following document:
</t>

<figure><artwork>
<![CDATA[
<root>
  <el1 att="first"/>
  <el1 att="second"/>
  <!--comment -->
  <el2 att="first/>
<el3 att="first"/></root>
<figure><artwork>
]]></artwork></figure>


* I added the following text in section 8.4 on whitespace handling:

Note that
this deletion does not include any white space around the element that
was deleted; the XCAP server MUST preserve surrounding whitespace.


* RECOMMEND that XUI = SIP AOR

* Added the following text in the section on naming conventions for
application usages:

<t>
For many application usages, users need only a single document. In
such a case, it is RECOMMENDED that the application usage require that
this document be called "index" and exist within the users home
directory.
</t>

URI construction talks about this as well, recommending that, when
there is a single document, its called "index". Explicitly say that
usage of subdirectories is NOT RECOMMENDED. MUST NOT have a document
and sub-directory with same name.



Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Oct 24 01:22:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETumf-0007EG-Km; Mon, 24 Oct 2005 01:22:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ETumc-0007E5-12
	for simple@megatron.ietf.org; Mon, 24 Oct 2005 01:22:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15732
	for <simple@ietf.org>; Mon, 24 Oct 2005 01:21:52 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETuzI-0004Kz-26
	for simple@ietf.org; Mon, 24 Oct 2005 01:35:13 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2005 01:21:56 -0400
X-IronPort-AV: i="3.97,243,1125892800"; 
	d="scan'208"; a="74274572:sNHT26912632"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9O5Ls23015589
	for <simple@ietf.org>; Mon, 24 Oct 2005 01:21:54 -0400 (EDT)
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, 24 Oct 2005 01:21:53 -0400
Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 24 Oct 2005 01:21:53 -0400
Message-ID: <435C6F71.4060506@cisco.com>
Date: Mon, 24 Oct 2005 01:21:53 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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 <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Oct 2005 05:21:53.0793 (UTC)
	FILETIME=[D8536F10:01C5D85A]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Content-Transfer-Encoding: 7bit
Subject: [Simple] XCAP namespace conundrum - another approach?
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

As folks can see from the updated xcap I-D I posted, I've added the fix 
for the namespace discovery problem that was reported. This fix allows a 
client to fetch the namespaces in scope for an element, so that it can 
then construct a valid document fragment for insertion. This is needed 
only when a client doesnt cache the whole document.

Its fair to say that this is still not perfect. Its main drawbacks are:

1. to get the namespace bindings that are actually in use, the client 
has to make up a set of namespace bindings in the xmlns() components of 
the query string in the URI, just to get back the real bindings. Having 
to make up an intermediate set is ugly and inefficient

2. It requires a query to first get the namespace bindings, and then 
another query to PUT an element that uses them. The query to get the 
namespaces can happen just once and then the results cached. Conditional 
PUT would then be done for subsequent operations to make sure nothing 
has changed. However, we have the limitation that conditional PUT only 
works for modifications, not insertions. So, if you want to insert a 
buddy in your buddy list, you'll have to check the etags in the 201 
response to the buddy insertion to make sure you made the addition 
against the right version, and back out if you didnt. Complex.


I have in mind another potential solution, which can be used in addition 
to, or instead of, what is document in the xcap-08.

In my email where I originally propsoed the fix in -08, I had mentioned 
an alternative was to have well-known namespace bindings for namespaces 
used on the server. The problem with that approach is that it limits 
extensibility to new namespaces. Specs would need to be written for each 
one prior to usage by either client or server. Today, a client can use 
elements from new namespaces without the server knowing them, and this 
has been a very desirable feature.

My idea is a variation on this. Instead of using well-known namespace 
bindings, the namespace binding would be computed as a base64-encoded 
crypto-hash on the namespace URI, using sufficient number of bits to 
reduce the collision probability in any particular document to really 
low. Fortunately, you don't need a lot of bits at all. I suspect 32 is 
more than enough, so you'd have a six byte prefix. An applicatoin usage 
could then specify, as part of its non-schema validation constraints, 
that the namespace prefixes be limited in this way. The server would 
then reject documents that are PUT which don't satisfy this constraint.

I'd also then modify matching rules for the request-URI so that the 
namespace bindings in scope when evaluating the URI are the hashed ones 
for all namespace URI in the document itself. When you use these hashed 
prefixes, you wouldn't need to use the xmlns() query components.

You'd also be able to, for example, insert a new buddy into a buddy list 
without caching the document, and with a single operation. No need for 
conditional operations and thus we avoid the problem with conditional 
insertions.

The approach still allows for new elements from new namespaces. The 
server doesnt need to know about the namespace URI ahead of time.

The only drawbacks I can see are:

1. completely falls apart for documents that were created prior to their 
access through xcap. That is why I'm recommending that this be 
enabled/disabled on an app-usage by app-usage basis. You could define an 
app-usage where this wasn't used, in case you had documents that existed 
prior to usage with xcap. Thats why I think we still need whats in 
xcap-08  - for these cases.

2. its still kind of ugly. I think the spirit of XML is that namespace 
prefixes are always a localized choice, and we'd be globally 
constraining them.

3. you might get a collision in the hashes. Fortunately, you would 
usually know this ahead of time since, in most cases, the set of 
namespace URI used for a particular application usage are relatively 
small and known. Thus, when designing a new extension, you could pick a 
namespace URI that you KNOW doesnt conflict with an existing one.


What do folks think of this?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Oct 24 19:31:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUBmY-00053Q-FW; Mon, 24 Oct 2005 19:31:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUBmW-00053F-Kj
	for simple@megatron.ietf.org; Mon, 24 Oct 2005 19:31:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05463
	for <simple@ietf.org>; Mon, 24 Oct 2005 19:30:55 -0400 (EDT)
Received: from marauder.andrew.com ([198.17.217.129])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBzM-0006Lf-VU
	for simple@ietf.org; Mon, 24 Oct 2005 19:44:25 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 18:30:54 -0500
Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl
	E-mail Filter (4.7); Mon, 24 Oct 2005 18:30:53 -0500
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 18:30:58 -0500
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC0DD412E1@aopex5.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>, "Simple WG" <simple@ietf.org>
Date: Mon, 24 Oct 2005 18:29:31 -0500
Subject: RE: [Simple] XCAP namespace conundrum - another approach?
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 24 Oct 2005 23:30:58.0919 (UTC)
	FILETIME=[FD0E5F70:01C5D8F2]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: [Simple] XCAP namespace conundrum - another approach?
Thread-Index: AcXYWzd/pn7c7VnTTdyJrydq1x9yFgAAQ0mA
X-Spam-Score: 2.0 (++)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1379437839=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============1379437839==
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
Content-Transfer-Encoding: base64

SXQncyBwcm9iYWJseSBoZWxwZnVsIHRvIGhhdmUgYSBwcm9ibGVtIHJlc3RhdGVtZW50LiAgSSBz
ZWUgdHdvIHNpZGVzIHRvIHRoZSBwcm9ibGVtOg0KDQoxLiBXaGVuIGluc2VydGluZyBhbiBYTUwg
ZnJhZ21lbnQgaW50byBhIChwb3NzaWJseSkgdW5rbm93biBjb250ZXh0LCB0aGUgY2xpZW50IG5l
ZWRzIHRvIGJlIHNvbWUgd2F5IG9mIGVuc3VyaW5nIHRoYXQgdGhlIG5hbWVzcGFjZSBvZiB0aGUg
bm9kZXMgaW4gdGhlIGZyYWdtZW50IGFyZSBjb3JyZWN0bHkgaWRlbnRpZmllZC4gIFRoaXMgc2hv
dWxkIGJlIHBvc3NpYmxlIHdpdGhvdXQgaGF2aW5nIGEgY2Fub25pY2FsIGZyYWdtZW50IHRoYXQg
ZXhoYXVzdGl2ZWx5IGRlZmluZXMgYWxsIHVzZWQgbmFtZXNwYWNlIHByZWZpeGVzLg0KDQoyLiBX
aGVuIHJlY2VpdmluZyBhbiBYTUwgZnJhZ21lbnQgZnJvbSBhIChwb3NzaWJseSkgdW5rbm93biBj
b250ZXh0LCB0aGUgY2xpZW50IG5lZWRzIHNvbWUgd2F5IG9mIGlkZW50aWZ5aW5nIHRoZSBuYW1l
c3BhY2UgYmluZGluZ3MgZm9yIHRoYXQgZnJhZ21lbnQgc28gdGhleSBjYW4gbWFrZSBzZW5zZSBv
ZiBpdC4NCg0KWW91ciBwcm9wb3NhbCBpcyBzdGlsbCwgaW4gZXNzZW5jZSwgc3VnZ2VzdGluZyB0
aGF0IG5hbWVzcGFjZSBwcmVmaXhlcyBhcmUgZml4ZWQuICBUaGlzIGhhcyBhbHJlYWR5IGJlZW4g
ZGVlbWVkIHByb2JsZW1hdGljLiAgUmVhZCB0aGUgc2VjdGlvbiBmcm9tIENhbm9uaWNhbCBYTUwg
b24gdGhlIG1hdHRlcjoNCglodHRwOi8vd3d3LnczLm9yZy9UUi94bWwtYzE0biNOb05TUHJlZml4
UmV3cml0aW5nDQoNCg0KSSBoYXZlIGEgY291cGxlIG9mIHBvc3NpYmxlIGFsdGVybmF0aXZlcyB0
aGF0IGVuc3VyZSB0aGF0IG1hcHBpbmcgaW5mb3JtYXRpb24gaXMgY2FycmllZCB3aXRoIHRoZSBY
TUwgZnJhZ21lbnQuICBBbGwgb2YgdGhlc2UgaGF2ZSB0aGUgYWR2YW50YWdlIG9mIHJlcXVpcmlu
ZyBvbmx5IGEgc2luZ2xlIHJlcXVlc3QuICBNeSBhcG9sb2dpZXMgaWYgdGhlc2UgaGF2ZSBhbHJl
YWR5IGJlZW4gZGlzY3Vzc2VkLg0KDQoNCmkuIFByb3ZpZGUgb3V0LW9mLWJhbmQgaW5kaWNhdGlv
biBvZiBuYW1lc3BhY2UgcHJlZml4IG1hcHBpbmcuICBTaW1pbGFyIHRvIHRoZSAibmFtZXNwYWNl
OjoqIiBzZWxlY3RvciwgdGhpcyB3b3VsZCBiZSByZXF1aXJlZCBvbiBib3RoIEdFVCByZXNwb25z
ZXMgYW5kIFBVVCByZXF1ZXN0cy4gIFRoaXMgZG9lc24ndCBmaXQgaW50byBIVFRQLCBzbyB0aGlz
IHdvdWxkIHJlcXVpcmUgYW4gZW52ZWxvcGUuDQpBZHZhbnRhZ2U6IFRoZSBib2R5IG9mIHRoZSBt
ZXNzYWdlIGlzIGEgY29tcGxldGUgKGFuZCB2YWxpZCkgWE1MIGRvY3VtZW50Lg0KRGlzYWR2YW50
YWdlOiBQcm9jZXNzaW5nIGlzIHJlcXVpcmVkIHRvIGV4dHJhY3QgYWN0dWFsIGNvbnRlbnQgb2Yg
cmVxdWVzdGVkIG5vZGUuICBUaGUgcmVzb3VyY2UgaXMgbm8gbG9uZ2VyIGRpcmVjdGx5IGFjY2Vz
c2libGUuIA0KDQogICBQVVQgL3NlcnZpY2VzL3Jlc291cmNlLWxpc3RzL3VzZXJzL2JpbGwvZnIu
eG1sL35+L3Jlc291cmNlLWxpc3RzL2xpc3QlNWJAbmFtZT0lMjJmcmllbmRzJTIyJTVkL2VudHJ5
IEhUVFAvMS4xDQogICBIb3N0OiB4Y2FwLmV4YW1wbGUuY29tDQogICBDb250ZW50LVR5cGU6IGFw
cGxpY2F0aW9uL3hjYXAtZW52K3htbA0KDQogICA8eGNhcDplbnYgeG1sbnM9InVybjppZXRmOnBh
cmFtczp4bWw6bnM6cmxzLXNlcnZpY2VzIg0KICAgICAgICAgICAgIHhtbG5zOnhjYXA9IiJ1cm46
aWV0ZjpwYXJhbXM6eG1sOm5zOnhjYXAtZW52Ij4NCiAgICAgPGVudHJ5IHVyaT0ic2lwOmJvYkBl
eGFtcGxlLmNvbSI+DQogICAgICAgPGRpc3BsYXktbmFtZT5Cb2IgSm9uZXM8L2Rpc3BsYXktbmFt
ZT4NCiAgICAgPC9lbnRyeT4NCiAgIDwveGNhcDplbnY+DQoNCkFsc28sIGNhcmUgbmVlZHMgdG8g
YmUgdGFrZW4gdGhhdCB0aGUgbnMgcHJlZml4IG9uIHRoZSBlbnZlbG9wZSBkb2Vzbid0IGNsYXNo
IHdpdGggYW55IHRoYXQgYXJlIHVzZWQgaW4gdGhlIGFjdHVhbCBjb250ZW50Lg0KDQoNCmlpLiBJ
bnZlbnQgYSBzaW1wbGUgbm90YXRpb24gc28gdGhhdCBtYXBwaW5nIGluZm9ybWF0aW9uIGNhbiBi
ZSBlbWJlZGRlZC4gIEFkdmFudGFnZTogSXQncyBzaW1wbGUgYW5kIGVhc3kgdG8gc3BlY2lmeSwg
c2ltcGxlIHRvIHBhcnNlIGFzIHdlbGwuDQpEaXNhZHZhbnRhZ2U6IFlvdSBjYW4ndCBldmVuIHBy
ZXRlbmQgdGhhdCB0aGlzIGlzIFhNTC4NCg0KICAgUFVUIC9zZXJ2aWNlcy9yZXNvdXJjZS1saXN0
cy91c2Vycy9iaWxsL2ZyLnhtbC9+fi9yZXNvdXJjZS1saXN0cy9saXN0JTViQG5hbWU9JTIyZnJp
ZW5kcyUyMiU1ZC9lbnRyeSBIVFRQLzEuMQ0KICAgSG9zdDogeGNhcC5leGFtcGxlLmNvbQ0KICAg
Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94Y2FwLWVsK3htbA0KDQogICAgIDxlbnRyeSB7eG1s
bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6cmxzLXNlcnZpY2VzIn0gdXJpPSJzaXA6Ym9iQGV4
YW1wbGUuY29tIj4NCiAgICAgICA8ZGlzcGxheS1uYW1lPkJvYiBKb25lczwvZGlzcGxheS1uYW1l
Pg0KICAgICA8L2VudHJ5Pg0KDQoNCmlpaS4gVXNlIEhUVFAgaGVhZGVycyB0byBjYXJyeSB0aGUg
aW5mb3JtYXRpb24uICBBICJDb250ZW50LS4uLiIgaGVhZGVyIGlzIGEgcHJldHR5IGdvb2QsIGlm
IHJvdWdoLCBmaXQuDQpBZHZhbnRhZ2VzOiBsb29rcyBtb3N0IGxpa2UgdGhlIGN1cnJlbnQgaW5j
YXJuYXRpb24uDQpEaXNhZHZhbnRhZ2VzOiBtb3JlIEhUVFAgaGVhZGVyIGZsdWZmLg0KDQogICBQ
VVQgL3NlcnZpY2VzL3Jlc291cmNlLWxpc3RzL3VzZXJzL2JpbGwvZnIueG1sL35+L3Jlc291cmNl
LWxpc3RzL2xpc3QlNWJAbmFtZT0lMjJmcmllbmRzJTIyJTVkL2VudHJ5IEhUVFAvMS4xDQogICBI
b3N0OiB4Y2FwLmV4YW1wbGUuY29tDQogICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3hjYXAt
ZWwreG1sDQogICBYLUNvbnRlbnQteG1sbnMtQ29udGV4dDogeG1sbnM9InVybjppZXRmOnBhcmFt
czp4bWw6bnM6cmxzLXNlcnZpY2VzIg0KDQogICAgIDxlbnRyeSB1cmk9InNpcDpib2JAZXhhbXBs
ZS5jb20iPg0KICAgICAgIDxkaXNwbGF5LW5hbWU+Qm9iIEpvbmVzPC9kaXNwbGF5LW5hbWU+DQog
ICAgIDwvZW50cnk+DQoNCg0KQ2hlZXJzLA0KTWFydGluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQpGcm9tOiBzaW1wbGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpbXBsZS1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9uYXRoYW4gUm9zZW5iZXJnDQpTZW50OiBNb25k
YXksIDI0IE9jdG9iZXIgMjAwNSAzOjIyIFBNDQpUbzogU2ltcGxlIFdHDQpTdWJqZWN0OiBbU2lt
cGxlXSBYQ0FQIG5hbWVzcGFjZSBjb251bmRydW0gLSBhbm90aGVyIGFwcHJvYWNoPw0KDQpBcyBm
b2xrcyBjYW4gc2VlIGZyb20gdGhlIHVwZGF0ZWQgeGNhcCBJLUQgSSBwb3N0ZWQsIEkndmUgYWRk
ZWQgdGhlIGZpeCANCmZvciB0aGUgbmFtZXNwYWNlIGRpc2NvdmVyeSBwcm9ibGVtIHRoYXQgd2Fz
IHJlcG9ydGVkLiBUaGlzIGZpeCBhbGxvd3MgYSANCmNsaWVudCB0byBmZXRjaCB0aGUgbmFtZXNw
YWNlcyBpbiBzY29wZSBmb3IgYW4gZWxlbWVudCwgc28gdGhhdCBpdCBjYW4gDQp0aGVuIGNvbnN0
cnVjdCBhIHZhbGlkIGRvY3VtZW50IGZyYWdtZW50IGZvciBpbnNlcnRpb24uIFRoaXMgaXMgbmVl
ZGVkIA0Kb25seSB3aGVuIGEgY2xpZW50IGRvZXNudCBjYWNoZSB0aGUgd2hvbGUgZG9jdW1lbnQu
DQoNCkl0cyBmYWlyIHRvIHNheSB0aGF0IHRoaXMgaXMgc3RpbGwgbm90IHBlcmZlY3QuIEl0cyBt
YWluIGRyYXdiYWNrcyBhcmU6DQoNCjEuIHRvIGdldCB0aGUgbmFtZXNwYWNlIGJpbmRpbmdzIHRo
YXQgYXJlIGFjdHVhbGx5IGluIHVzZSwgdGhlIGNsaWVudCANCmhhcyB0byBtYWtlIHVwIGEgc2V0
IG9mIG5hbWVzcGFjZSBiaW5kaW5ncyBpbiB0aGUgeG1sbnMoKSBjb21wb25lbnRzIG9mIA0KdGhl
IHF1ZXJ5IHN0cmluZyBpbiB0aGUgVVJJLCBqdXN0IHRvIGdldCBiYWNrIHRoZSByZWFsIGJpbmRp
bmdzLiBIYXZpbmcgDQp0byBtYWtlIHVwIGFuIGludGVybWVkaWF0ZSBzZXQgaXMgdWdseSBhbmQg
aW5lZmZpY2llbnQNCg0KMi4gSXQgcmVxdWlyZXMgYSBxdWVyeSB0byBmaXJzdCBnZXQgdGhlIG5h
bWVzcGFjZSBiaW5kaW5ncywgYW5kIHRoZW4gDQphbm90aGVyIHF1ZXJ5IHRvIFBVVCBhbiBlbGVt
ZW50IHRoYXQgdXNlcyB0aGVtLiBUaGUgcXVlcnkgdG8gZ2V0IHRoZSANCm5hbWVzcGFjZXMgY2Fu
IGhhcHBlbiBqdXN0IG9uY2UgYW5kIHRoZW4gdGhlIHJlc3VsdHMgY2FjaGVkLiBDb25kaXRpb25h
bCANClBVVCB3b3VsZCB0aGVuIGJlIGRvbmUgZm9yIHN1YnNlcXVlbnQgb3BlcmF0aW9ucyB0byBt
YWtlIHN1cmUgbm90aGluZyANCmhhcyBjaGFuZ2VkLiBIb3dldmVyLCB3ZSBoYXZlIHRoZSBsaW1p
dGF0aW9uIHRoYXQgY29uZGl0aW9uYWwgUFVUIG9ubHkgDQp3b3JrcyBmb3IgbW9kaWZpY2F0aW9u
cywgbm90IGluc2VydGlvbnMuIFNvLCBpZiB5b3Ugd2FudCB0byBpbnNlcnQgYSANCmJ1ZGR5IGlu
IHlvdXIgYnVkZHkgbGlzdCwgeW91J2xsIGhhdmUgdG8gY2hlY2sgdGhlIGV0YWdzIGluIHRoZSAy
MDEgDQpyZXNwb25zZSB0byB0aGUgYnVkZHkgaW5zZXJ0aW9uIHRvIG1ha2Ugc3VyZSB5b3UgbWFk
ZSB0aGUgYWRkaXRpb24gDQphZ2FpbnN0IHRoZSByaWdodCB2ZXJzaW9uLCBhbmQgYmFjayBvdXQg
aWYgeW91IGRpZG50LiBDb21wbGV4Lg0KDQoNCkkgaGF2ZSBpbiBtaW5kIGFub3RoZXIgcG90ZW50
aWFsIHNvbHV0aW9uLCB3aGljaCBjYW4gYmUgdXNlZCBpbiBhZGRpdGlvbiANCnRvLCBvciBpbnN0
ZWFkIG9mLCB3aGF0IGlzIGRvY3VtZW50IGluIHRoZSB4Y2FwLTA4Lg0KDQpJbiBteSBlbWFpbCB3
aGVyZSBJIG9yaWdpbmFsbHkgcHJvcHNvZWQgdGhlIGZpeCBpbiAtMDgsIEkgaGFkIG1lbnRpb25l
ZCANCmFuIGFsdGVybmF0aXZlIHdhcyB0byBoYXZlIHdlbGwta25vd24gbmFtZXNwYWNlIGJpbmRp
bmdzIGZvciBuYW1lc3BhY2VzIA0KdXNlZCBvbiB0aGUgc2VydmVyLiBUaGUgcHJvYmxlbSB3aXRo
IHRoYXQgYXBwcm9hY2ggaXMgdGhhdCBpdCBsaW1pdHMgDQpleHRlbnNpYmlsaXR5IHRvIG5ldyBu
YW1lc3BhY2VzLiBTcGVjcyB3b3VsZCBuZWVkIHRvIGJlIHdyaXR0ZW4gZm9yIGVhY2ggDQpvbmUg
cHJpb3IgdG8gdXNhZ2UgYnkgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIuIFRvZGF5LCBhIGNsaWVu
dCBjYW4gdXNlIA0KZWxlbWVudHMgZnJvbSBuZXcgbmFtZXNwYWNlcyB3aXRob3V0IHRoZSBzZXJ2
ZXIga25vd2luZyB0aGVtLCBhbmQgdGhpcyANCmhhcyBiZWVuIGEgdmVyeSBkZXNpcmFibGUgZmVh
dHVyZS4NCg0KTXkgaWRlYSBpcyBhIHZhcmlhdGlvbiBvbiB0aGlzLiBJbnN0ZWFkIG9mIHVzaW5n
IHdlbGwta25vd24gbmFtZXNwYWNlIA0KYmluZGluZ3MsIHRoZSBuYW1lc3BhY2UgYmluZGluZyB3
b3VsZCBiZSBjb21wdXRlZCBhcyBhIGJhc2U2NC1lbmNvZGVkIA0KY3J5cHRvLWhhc2ggb24gdGhl
IG5hbWVzcGFjZSBVUkksIHVzaW5nIHN1ZmZpY2llbnQgbnVtYmVyIG9mIGJpdHMgdG8gDQpyZWR1
Y2UgdGhlIGNvbGxpc2lvbiBwcm9iYWJpbGl0eSBpbiBhbnkgcGFydGljdWxhciBkb2N1bWVudCB0
byByZWFsbHkgDQpsb3cuIEZvcnR1bmF0ZWx5LCB5b3UgZG9uJ3QgbmVlZCBhIGxvdCBvZiBiaXRz
IGF0IGFsbC4gSSBzdXNwZWN0IDMyIGlzIA0KbW9yZSB0aGFuIGVub3VnaCwgc28geW91J2QgaGF2
ZSBhIHNpeCBieXRlIHByZWZpeC4gQW4gYXBwbGljYXRvaW4gdXNhZ2UgDQpjb3VsZCB0aGVuIHNw
ZWNpZnksIGFzIHBhcnQgb2YgaXRzIG5vbi1zY2hlbWEgdmFsaWRhdGlvbiBjb25zdHJhaW50cywg
DQp0aGF0IHRoZSBuYW1lc3BhY2UgcHJlZml4ZXMgYmUgbGltaXRlZCBpbiB0aGlzIHdheS4gVGhl
IHNlcnZlciB3b3VsZCANCnRoZW4gcmVqZWN0IGRvY3VtZW50cyB0aGF0IGFyZSBQVVQgd2hpY2gg
ZG9uJ3Qgc2F0aXNmeSB0aGlzIGNvbnN0cmFpbnQuDQoNCkknZCBhbHNvIHRoZW4gbW9kaWZ5IG1h
dGNoaW5nIHJ1bGVzIGZvciB0aGUgcmVxdWVzdC1VUkkgc28gdGhhdCB0aGUgDQpuYW1lc3BhY2Ug
YmluZGluZ3MgaW4gc2NvcGUgd2hlbiBldmFsdWF0aW5nIHRoZSBVUkkgYXJlIHRoZSBoYXNoZWQg
b25lcyANCmZvciBhbGwgbmFtZXNwYWNlIFVSSSBpbiB0aGUgZG9jdW1lbnQgaXRzZWxmLiBXaGVu
IHlvdSB1c2UgdGhlc2UgaGFzaGVkIA0KcHJlZml4ZXMsIHlvdSB3b3VsZG4ndCBuZWVkIHRvIHVz
ZSB0aGUgeG1sbnMoKSBxdWVyeSBjb21wb25lbnRzLg0KDQpZb3UnZCBhbHNvIGJlIGFibGUgdG8s
IGZvciBleGFtcGxlLCBpbnNlcnQgYSBuZXcgYnVkZHkgaW50byBhIGJ1ZGR5IGxpc3QgDQp3aXRo
b3V0IGNhY2hpbmcgdGhlIGRvY3VtZW50LCBhbmQgd2l0aCBhIHNpbmdsZSBvcGVyYXRpb24uIE5v
IG5lZWQgZm9yIA0KY29uZGl0aW9uYWwgb3BlcmF0aW9ucyBhbmQgdGh1cyB3ZSBhdm9pZCB0aGUg
cHJvYmxlbSB3aXRoIGNvbmRpdGlvbmFsIA0KaW5zZXJ0aW9ucy4NCg0KVGhlIGFwcHJvYWNoIHN0
aWxsIGFsbG93cyBmb3IgbmV3IGVsZW1lbnRzIGZyb20gbmV3IG5hbWVzcGFjZXMuIFRoZSANCnNl
cnZlciBkb2VzbnQgbmVlZCB0byBrbm93IGFib3V0IHRoZSBuYW1lc3BhY2UgVVJJIGFoZWFkIG9m
IHRpbWUuDQoNClRoZSBvbmx5IGRyYXdiYWNrcyBJIGNhbiBzZWUgYXJlOg0KDQoxLiBjb21wbGV0
ZWx5IGZhbGxzIGFwYXJ0IGZvciBkb2N1bWVudHMgdGhhdCB3ZXJlIGNyZWF0ZWQgcHJpb3IgdG8g
dGhlaXIgDQphY2Nlc3MgdGhyb3VnaCB4Y2FwLiBUaGF0IGlzIHdoeSBJJ20gcmVjb21tZW5kaW5n
IHRoYXQgdGhpcyBiZSANCmVuYWJsZWQvZGlzYWJsZWQgb24gYW4gYXBwLXVzYWdlIGJ5IGFwcC11
c2FnZSBiYXNpcy4gWW91IGNvdWxkIGRlZmluZSBhbiANCmFwcC11c2FnZSB3aGVyZSB0aGlzIHdh
c24ndCB1c2VkLCBpbiBjYXNlIHlvdSBoYWQgZG9jdW1lbnRzIHRoYXQgZXhpc3RlZCANCnByaW9y
IHRvIHVzYWdlIHdpdGggeGNhcC4gVGhhdHMgd2h5IEkgdGhpbmsgd2Ugc3RpbGwgbmVlZCB3aGF0
cyBpbiANCnhjYXAtMDggIC0gZm9yIHRoZXNlIGNhc2VzLg0KDQoyLiBpdHMgc3RpbGwga2luZCBv
ZiB1Z2x5LiBJIHRoaW5rIHRoZSBzcGlyaXQgb2YgWE1MIGlzIHRoYXQgbmFtZXNwYWNlIA0KcHJl
Zml4ZXMgYXJlIGFsd2F5cyBhIGxvY2FsaXplZCBjaG9pY2UsIGFuZCB3ZSdkIGJlIGdsb2JhbGx5
IA0KY29uc3RyYWluaW5nIHRoZW0uDQoNCjMuIHlvdSBtaWdodCBnZXQgYSBjb2xsaXNpb24gaW4g
dGhlIGhhc2hlcy4gRm9ydHVuYXRlbHksIHlvdSB3b3VsZCANCnVzdWFsbHkga25vdyB0aGlzIGFo
ZWFkIG9mIHRpbWUgc2luY2UsIGluIG1vc3QgY2FzZXMsIHRoZSBzZXQgb2YgDQpuYW1lc3BhY2Ug
VVJJIHVzZWQgZm9yIGEgcGFydGljdWxhciBhcHBsaWNhdGlvbiB1c2FnZSBhcmUgcmVsYXRpdmVs
eSANCnNtYWxsIGFuZCBrbm93bi4gVGh1cywgd2hlbiBkZXNpZ25pbmcgYSBuZXcgZXh0ZW5zaW9u
LCB5b3UgY291bGQgcGljayBhIA0KbmFtZXNwYWNlIFVSSSB0aGF0IHlvdSBLTk9XIGRvZXNudCBj
b25mbGljdCB3aXRoIGFuIGV4aXN0aW5nIG9uZS4NCg0KDQpXaGF0IGRvIGZvbGtzIHRoaW5rIG9m
IHRoaXM/DQoNClRoYW5rcywNCkpvbmF0aGFuIFIuDQoNCi0tIA0KSm9uYXRoYW4gRC4gUm9zZW5i
ZXJnLCBQaC5ELiAgICAgICAgICAgICAgICAgICA2MDAgTGFuaWRleCBQbGF6YQ0KRGlyZWN0b3Is
IFNlcnZpY2UgUHJvdmlkZXIgVm9JUCBBcmNoaXRlY3R1cmUgICBQYXJzaXBwYW55LCBOSiAwNzA1
NC0yNzExDQpDaXNjbyBTeXN0ZW1zDQpqZHJvc2VuQGNpc2NvLmNvbSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIEZBWDogICAoOTczKSA5NTItNTA1MA0KaHR0cDovL3d3dy5qZHJvc2VuLm5l
dCAgICAgICAgICAgICAgICAgICAgICAgICBQSE9ORTogKDk3MykgOTUyLTUwMDANCmh0dHA6Ly93
d3cuY2lzY28uY29tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpTaW1wbGUgbWFpbGluZyBsaXN0DQpTaW1wbGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3
MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQg
cmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwg
b3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVk
IGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBk
ZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwg
aXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
W21mMl0=



--===============1379437839==
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

--===============1379437839==--



From simple-bounces@ietf.org Tue Oct 25 07:41:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUNBl-0008OI-3s; Tue, 25 Oct 2005 07:41:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUNBi-0008NE-MD
	for simple@megatron.ietf.org; Tue, 25 Oct 2005 07:41:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08611
	for <simple@ietf.org>; Tue, 25 Oct 2005 07:41:40 -0400 (EDT)
Received: from theater-sate.de ([81.169.138.67]
	helo=h93074.serverkompetenz.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUNOd-0007IE-9I
	for simple@ietf.org; Tue, 25 Oct 2005 07:55:17 -0400
Received: from coyote (coyote.mmweg.RWTH-Aachen.DE [134.130.118.117])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by h93074.serverkompetenz.net (Postfix) with ESMTP id 78DA224C61
	for <simple@ietf.org>; Tue, 25 Oct 2005 13:41:40 +0200 (CEST)
From: Sebastian Ley <sebastian@withouthat.org>
To: simple@ietf.org
Subject: Re: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
Date: Tue, 25 Oct 2005 13:41:38 +0200
User-Agent: KMail/1.8.2
References: <E7F5A43EEB6E7C42A08C041BDEB90A5305B08F@mail2.sonimtech.com>
	<435896DA.1080905@cisco.com>
In-Reply-To: <435896DA.1080905@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510251341.38860.sebastian@withouthat.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

* Jonathan Rosenberg wrote:

> 1. require standardized definitions for namespace prefixes
> 2. namespace bindings can already been includedin the request-URI. These
> are used only to define the in-scope bindings for evaluating the URI.
> Also apply them to the fragment in a PUT, and then have the server
> modify the namespace prefixes in the fragment to equal those defined for
> the same namespace URI.
>
>
> #2 is really ugly, and violates the http spec itself (get(put(x))) won't
> equal X. #1 interacts poorly with non-standard extensions and violates
> the spirit of xml namespace, i think.

Correct me if I am wrong, but I thought that the get(put(x)) == x requirement 
is from XCAP. HTTP mandates idempotency which is satisfied even with the 
prefix mangling suggestion above. Right? 

In that case we would "just" need to drop the above requirement and revert to 
the HTTP idempotency to make solution 2 possible. That means extra work for 
the server, but takes a lot complexity from the clients, allows for single 
pass updates and static URI construction.

Together with a former suggestion of Per Hyttfors who proposed to solve the 
namespace querying for GETs with XML Canonicalisation 
(http://www.ietf.org/mail-archive/web/simple/current/msg05728.html) that 
would make client implementations very simple and put all namespace resolving 
"burden" on the server. That sounds like a good idea to me.

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

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



From simple-bounces@ietf.org Tue Oct 25 10:49:55 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUQ7f-0003Vl-TB; Tue, 25 Oct 2005 10:49:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQ7e-0003Vg-S6
	for simple@megatron.ietf.org; Tue, 25 Oct 2005 10:49:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21348
	for <simple@ietf.org>; Tue, 25 Oct 2005 10:49:39 -0400 (EDT)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQKa-0004t0-B0
	for simple@ietf.org; Tue, 25 Oct 2005 11:03:19 -0400
Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j9PEngPI013764
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <simple@ietf.org>; Tue, 25 Oct 2005 09:49:44 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v734)
Content-Transfer-Encoding: 7bit
Message-Id: <9DB31DCF-2265-43BD-8E80-56DDE6F86394@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Simple WG <simple@ietf.org>
From: Robert Sparks <rjsparks@nostrum.com>
Date: Tue, 25 Oct 2005 09:49:42 -0500
X-Mailer: Apple Mail (2.734)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Subject: [Simple] agenda requests
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Folks -

Hisham and I are working out the agenda details for our meeting in  
Vancouver.

Note that we are meeting Friday morning.

Note also that geopriv is making a special effort to close out common- 
policy
during their session - please attend that session.

We will spend time on:

+ what we're doing to xcap core
+ adjusting to the geopriv common-policy discussion
    (this hopefully will be a short status report)
+ adjusting to what we learn at the XML-Patch-Ops BOF
    (this affects the -partial- drafts and xcap-diff)
+ closing on a path forward for xcap-diff
+ discussing progress on the IMDN work
+ discussing the presence policy drafts
and if time allows (and I think it will)
+ new drafts

If you see something missing or have a new draft
you want agenda time for and haven't already
contacted us, please send us a note today.

Thanks,

RjS

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



From simple-bounces@ietf.org Tue Oct 25 15:51:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUUpU-00075n-4s; Tue, 25 Oct 2005 15:51:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUUoB-0006n6-BD; Tue, 25 Oct 2005 15:50:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15695;
	Tue, 25 Oct 2005 15:49:52 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EUV17-0007s5-W0; Tue, 25 Oct 2005 16:03:32 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EUUo5-0007jy-Tz; Tue, 25 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EUUo5-0007jy-Tz@newodin.ietf.org>
Date: Tue, 25 Oct 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-02.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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) Document
                          Format for Indicating A Change in XML 
                          Configuration Access  Protocol (XCAP) Resources
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-xcap-diff-02.txt
	Pages		: 13
	Date		: 2005-10-25
	
This specification defines a document format that can be used to
   indicate that a change has occurred in a document managed by the
   Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP).  This format indicates the document that has changed and its
   former and new entity tags.  XCAP diff documents can be delivered to
   clients using a number of means, including the Session Initiation
   Protocol (SIP) event package for configuration data.  By subscribing
   to this event package, clients can learn about document changes made
   by other clients.  The XCAP diff format is extensible, so that
   additional information, such as a description of the actual change,
   can be included.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-xcap-diff-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-xcap-diff-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-10-25134139.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-xcap-diff-02.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-simple-xcap-diff-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-25134139.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From simple-bounces@ietf.org Tue Oct 25 15:52:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUUqP-0007IP-KJ; Tue, 25 Oct 2005 15:52:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUUoE-0006od-9C; Tue, 25 Oct 2005 15:50:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15724;
	Tue, 25 Oct 2005 15:49:54 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EUV18-0007sH-7B; Tue, 25 Oct 2005 16:03:32 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EUUo6-0007kV-3S; Tue, 25 Oct 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EUUo6-0007kV-3S@newodin.ietf.org>
Date: Tue, 25 Oct 2005 15:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-data-model-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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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-06.txt
	Pages		: 34
	Date		: 2005-10-25
	
This document defines the underlying presence data model used by
   Session Initiation Protocol (SIP) for Instant Messaging Leveraging
   Presence 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-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-presence-data-model-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-presence-data-model-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: <2005-10-25140513.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-data-model-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-data-model-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-25140513.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From simple-bounces@ietf.org Tue Oct 25 23:43:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUcCI-0002TQ-MS; Tue, 25 Oct 2005 23:43:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcCH-0002TD-1k
	for simple@megatron.ietf.org; Tue, 25 Oct 2005 23:43:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18842
	for <simple@ietf.org>; Tue, 25 Oct 2005 23:43:13 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUcPJ-0000aM-IW
	for simple@ietf.org; Tue, 25 Oct 2005 23:57:00 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2005 23:43:18 -0400
X-IronPort-AV: i="3.97,251,1125892800"; 
	d="scan'208"; a="74440714:sNHT25450020"
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 j9Q3hCEk028594; 
	Tue, 25 Oct 2005 23:43:15 -0400 (EDT)
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, 25 Oct 2005 23:43:13 -0400
Received: from [192.168.1.100] ([10.86.241.0]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 25 Oct 2005 23:43:13 -0400
Message-ID: <435EFB51.7010109@cisco.com>
Date: Tue, 25 Oct 2005 23:43:13 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] agenda requests
References: <9DB31DCF-2265-43BD-8E80-56DDE6F86394@nostrum.com>
In-Reply-To: <9DB31DCF-2265-43BD-8E80-56DDE6F86394@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 03:43:13.0485 (UTC)
	FILETIME=[645F9FD0:01C5D9DF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

related to this one:

Robert Sparks wrote:


> + adjusting to the geopriv common-policy discussion
>    (this hopefully will be a short status report)

Note that I have submitted an update to the presence-auth draft, such 
that it aligns with the geopriv common policy doc. Until it appears, you 
can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-04.txt

Thanks,
Jonathan R.

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

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



From simple-bounces@ietf.org Tue Oct 25 23:57:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUcPa-00025L-VP; Tue, 25 Oct 2005 23:57:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcPZ-00024d-3C
	for simple@megatron.ietf.org; Tue, 25 Oct 2005 23:57:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19431
	for <simple@ietf.org>; Tue, 25 Oct 2005 23:56:57 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUcce-00014A-IR
	for simple@ietf.org; Wed, 26 Oct 2005 00:10:44 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2005 23:57:04 -0400
X-IronPort-AV: i="3.97,251,1125892800"; 
	d="scan'208"; a="74441464:sNHT26938356"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9Q3ux23013543; 
	Tue, 25 Oct 2005 23:57:00 -0400 (EDT)
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);
	Tue, 25 Oct 2005 23:56:59 -0400
Received: from [192.168.1.100] ([10.86.241.0]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 25 Oct 2005 23:56:59 -0400
Message-ID: <435EFE8A.3020603@cisco.com>
Date: Tue, 25 Oct 2005 23:56:58 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Simple] XCAP namespace conundrum - another approach?
References: <AF9FCF3C02DB264EAF9872DFB6040FCC0DD412E1@aopex5.andrew.com>
In-Reply-To: <AF9FCF3C02DB264EAF9872DFB6040FCC0DD412E1@aopex5.andrew.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 03:56:59.0338 (UTC)
	FILETIME=[509ECAA0:01C5D9E1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Thomson, Martin wrote:

> It's probably helpful to have a problem restatement.  I see two sides
> to the problem:
> 
> 1. When inserting an XML fragment into a (possibly) unknown context,
> the client needs to be some way of ensuring that the namespace of the
> nodes in the fragment are correctly identified.  This should be
> possible without having a canonical fragment that exhaustively
> defines all used namespace prefixes.

I'm not sure I understand the last sentence here. If you mean that the 
client shouldn't have to know apriori all of the namespace bindings in 
scope at the point of insertion, then I kind of agree. I think the REAL 
requirement is to be able to do an insertion in this situation with a 
single request.

> 
> 2. When receiving an XML fragment from a (possibly) unknown context,
> the client needs some way of identifying the namespace bindings for
> that fragment so they can make sense of it.

Yes, and again without an additional request.

> 
> Your proposal is still, in essence, suggesting that namespace
> prefixes are fixed.  This has already been deemed problematic.  Read
> the section from Canonical XML on the matter: 
> http://www.w3.org/TR/xml-c14n#NoNSPrefixRewriting

Thanks for the pointer. However, that text is in regard to rewriting of 
a namespace prefix that already exists in a document. I agree this is 
bad since it creates problems of referential integrity. What I am 
proposing is NOT to rewrite, but that the only namespace prefix that is 
allowed in the document in the first place is a specific one, equal to a 
hash of the namespace URI. THus, you would never have the problems 
pointed out in the reference you cite.

> 
> 
> I have a couple of possible alternatives that ensure that mapping
> information is carried with the XML fragment.  All of these have the
> advantage of requiring only a single request.  My apologies if these
> have already been discussed.
> 
> 
> i. Provide out-of-band indication of namespace prefix mapping.
> Similar to the "namespace::*" selector, this would be required on
> both GET responses and PUT requests.  This doesn't fit into HTTP, so
> this would require an envelope. Advantage: The body of the message is
> a complete (and valid) XML document. Disadvantage: Processing is
> required to extract actual content of requested node.  The resource
> is no longer directly accessible.
> 
> PUT
> /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry
> HTTP/1.1 Host: xcap.example.com Content-Type:
> application/xcap-env+xml
> 
> <xcap:env xmlns="urn:ietf:params:xml:ns:rls-services" 
> xmlns:xcap=""urn:ietf:params:xml:ns:xcap-env"> <entry
> uri="sip:bob@example.com"> <display-name>Bob Jones</display-name> 
> </entry> </xcap:env>
> 
> Also, care needs to be taken that the ns prefix on the envelope
> doesn't clash with any that are used in the actual content.

I don't know how this would help though. THe server presumably unwraps 
the envelope, extracts the <entry> and inserts it. The prolem, though, 
is that the default namesapce within the envelope 
(urn:ietf:params:xml:ns:rls-services) may not match the default 
namespace in scope of the parent of <entry> in the actual document. 
Thus, you have the same problem we have today.

> 
> 
> ii. Invent a simple notation so that mapping information can be
> embedded.  Advantage: It's simple and easy to specify, simple to
> parse as well. Disadvantage: You can't even pretend that this is XML.
> 
> 
> PUT
> /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry
> HTTP/1.1 Host: xcap.example.com Content-Type: application/xcap-el+xml
> 
> 
> <entry {xmlns="urn:ietf:params:xml:ns:rls-services"}
> uri="sip:bob@example.com"> <display-name>Bob Jones</display-name> 
> </entry>

As above, I don't see how this helps.

> 
> 
> iii. Use HTTP headers to carry the information.  A "Content-..."
> header is a pretty good, if rough, fit. Advantages: looks most like
> the current incarnation. Disadvantages: more HTTP header fluff.
> 
> PUT
> /services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry
> HTTP/1.1 Host: xcap.example.com Content-Type: application/xcap-el+xml
>  X-Content-xmlns-Context: xmlns="urn:ietf:params:xml:ns:rls-services"
> 
> 
> <entry uri="sip:bob@example.com"> <display-name>Bob
> Jones</display-name> </entry>
> 

Same as above. Unless I'm missing something, none of these help. Its not 
a transport problem, its a knowledge problem. The problem is that, the 
client needs KNOWLEDGE of the namespace bindings in scope at a point of 
insertion in order to construct an XML fragment which produces a valid 
document after insertion. AFAICT, there are only two fundamental paths 
to solve this:

1. we provide a way for the client to learn the valid bindings, or
2. we provide a way for the server to rewrite the bindings in the 
request to equal the valid bindings

You've made some good arguments via the spec you site above, on why (2) 
is a bad idea. I also dislike it, since requestin gthe XCAP server to 
rewrite prefixes, will fundamentally break get(put(x)) = x.

So, that leaves us with (1). To solve that, we either need to fix the 
bindings so that they are well known, or provide a way for them to be 
learned. Providing a way for them to be learned in advance of a PUT 
would seem, to me, to require an additional transaction ahead of the 
PUT, thus violating our requirement for a single method. This leaves the 
only choice of making them well-known, and thus my proposal for a hash.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Wed Oct 26 00:04:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUcWH-0005Os-Vs; Wed, 26 Oct 2005 00:04:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcWF-0005OE-El
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 00:04:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19824
	for <simple@ietf.org>; Wed, 26 Oct 2005 00:03:51 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUcjI-0001Fi-PE
	for simple@ietf.org; Wed, 26 Oct 2005 00:17:39 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 25 Oct 2005 21:03:55 -0700
X-IronPort-AV: i="3.97,251,1125903600"; 
	d="scan'208"; a="223912059:sNHT26025096"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9Q43oV0005961;
	Tue, 25 Oct 2005 21:03:53 -0700 (PDT)
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, 26 Oct 2005 00:03:51 -0400
Received: from [192.168.1.100] ([10.86.241.0]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 26 Oct 2005 00:03:51 -0400
Message-ID: <435F0027.60402@cisco.com>
Date: Wed, 26 Oct 2005 00:03:51 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Sebastian Ley <sebastian@withouthat.org>
Subject: Re: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
References: <E7F5A43EEB6E7C42A08C041BDEB90A5305B08F@mail2.sonimtech.com>	<435896DA.1080905@cisco.com>
	<200510251341.38860.sebastian@withouthat.org>
In-Reply-To: <200510251341.38860.sebastian@withouthat.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 04:03:51.0463 (UTC)
	FILETIME=[46441370:01C5D9E2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Sebastian Ley wrote:

> * Jonathan Rosenberg wrote:
> 
> 
>>1. require standardized definitions for namespace prefixes
>>2. namespace bindings can already been includedin the request-URI. These
>>are used only to define the in-scope bindings for evaluating the URI.
>>Also apply them to the fragment in a PUT, and then have the server
>>modify the namespace prefixes in the fragment to equal those defined for
>>the same namespace URI.
>>
>>
>>#2 is really ugly, and violates the http spec itself (get(put(x))) won't
>>equal X. #1 interacts poorly with non-standard extensions and violates
>>the spirit of xml namespace, i think.
> 
> 
> Correct me if I am wrong, but I thought that the get(put(x)) == x requirement 
> is from XCAP. HTTP mandates idempotency which is satisfied even with the 
> prefix mangling suggestion above. Right? 

Hmm. Fair point. You are right. We long ago decided that with xcap we 
would meet the idempotency requirement by maintaining the property that 
get(put(x))=x.

However, there are other issues with the namespcae prefix munging, which 
Martin just posted on.

> 
> In that case we would "just" need to drop the above requirement and revert to 
> the HTTP idempotency to make solution 2 possible. That means extra work for 
> the server, but takes a lot complexity from the clients, allows for single 
> pass updates and static URI construction.

Well, the hashing approach also removes complexity from clients, allows 
for single pass updates and static URI construction too. Its also less 
verbose than a rewrite, since it would reqiure you to declare the 
namespace prefixes you used in the fragment. And it doesnt have the 
other issues with namespace munging that Martin referenced.

> 
> Together with a former suggestion of Per Hyttfors who proposed to solve the 
> namespace querying for GETs with XML Canonicalisation 
> (http://www.ietf.org/mail-archive/web/simple/current/msg05728.html) that 
> would make client implementations very simple and put all namespace resolving 
> "burden" on the server. That sounds like a good idea to me.

I'll be responding to that note in a moment. Unfortunately I don't 
follow the proposal; I'm not an expert in the canonicalization spec. Can 
you or Per summarize the idea?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Wed Oct 26 00:13:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUceu-0003Io-K8; Wed, 26 Oct 2005 00:13:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUces-0003Hk-RN
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 00:13:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20323
	for <simple@ietf.org>; Wed, 26 Oct 2005 00:12:47 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EUcry-0001V5-Ds
	for simple@ietf.org; Wed, 26 Oct 2005 00:26:34 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 21:12:53 -0700
X-IronPort-AV: i="3.97,251,1125903600"; 
	d="scan'208"; a="356771892:sNHT26359956"
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 j9Q4Co94025804;
	Tue, 25 Oct 2005 21:12:51 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 26 Oct 2005 00:12:50 -0400
Received: from [192.168.1.100] ([10.86.241.0]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 26 Oct 2005 00:12:49 -0400
Message-ID: <435F0241.7090406@cisco.com>
Date: Wed, 26 Oct 2005 00:12:49 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues
References: <434756D0.6070708@cisco.com> <434B9F52.3030206@nokia.com>
	<435892EC.6050806@cisco.com> <4358A871.9030508@nokia.com>
In-Reply-To: <4358A871.9030508@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 04:12:49.0974 (UTC)
	FILETIME=[873E5560:01C5D9E3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Jari Urpalainen wrote:


>> What you are proposing, of inserting in the first possible position, 
>> would allow for insertions of the form ../parent/element[pos] to have 
>> the effect of keeping together elements of the same name. Thats all 
>> fine, except its not consistent with whats in the current spec. Thus, 
>> changing it would break backwards compatibility. Since this would be a 
>> feature enhancement as opposed to a bug fix, I think we need to keep 
>> it consistent.
>>
> ok, so you are saying that the position for e.g. for a new element is 
> the last possible one. That's fine with me as well, because it's 
> unambiguous. The minor issue is that in the implementation you'll anyhow 
> have to find first the first possible location, now with your proposal 
> an implementation has to look for the next (and the last) possible node 
> positions. For the implementation it should not be a major issue, however.

What ended up in the text is a bit different than what I propose, and 
closer to what you hav ein mind, I think. Please take a look.


>>>>
>>> good. Also it might be worth noting that within location steps 
>>> apostrophes (') can be used too (like in XPath).
>>
>>
>>
>> What is the meaning of it? I'm not familiar with that.
>>
> from XPath spec:
> "Within expressions, literal strings are delimited by single or double 
> quotation marks, which are also used to delimit XML attributes. To avoid 
> a quotation mark in an expression being interpreted by the XML processor 
> as terminating the attribute value the quotation mark can be entered as 
> a character reference (|&quot;| or |&apos;|). Alternatively, the 
> expression can use single quotation marks if the XML attribute is 
> delimited with double quotation marks or vice-versa."
> 
> in xcap these could appear within docs or r-uri's, so it should be imo 
> described someway.
> thanks,

We have this already in section 6:

Note that the left bracket, right bracket, and double quote
    characters, which are meaningful to XCAP, cannot be directly
    represented in the HTTP URI.  As a result, they are escape coded when
    placed within the HTTP URI.  Furthermore, since XML allows for non-
    ASCII characters, the names of elements and attributes may not be
    directly representable in a URI.  Any such characters MUST be
    represented by converting them to an octet sequence corresponding to
    their representation in UTF-8, and then escape-coding that sequence
    of octets.

is that not sufficient?

Thanks,
Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Wed Oct 26 00:28:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUcuC-0002ff-Tb; Wed, 26 Oct 2005 00:28:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcuA-0002e1-V2
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 00:28:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20844
	for <simple@ietf.org>; Wed, 26 Oct 2005 00:28:35 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUd7G-0001oT-Pz
	for simple@ietf.org; Wed, 26 Oct 2005 00:42:23 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2005 00:28:42 -0400
X-IronPort-AV: i="3.97,251,1125892800"; 
	d="scan'208"; a="74442897:sNHT25828292"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9Q4Sd23018039; 
	Wed, 26 Oct 2005 00:28:39 -0400 (EDT)
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);
	Wed, 26 Oct 2005 00:28:39 -0400
Received: from [192.168.1.100] ([10.86.241.0]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 26 Oct 2005 00:28:38 -0400
Message-ID: <435F05F6.2010505@cisco.com>
Date: Wed, 26 Oct 2005 00:28:38 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using
	only the XML fragment body.
References: <1AF90E65795A3D45AA116B9264B4DAAF029D872D@SELDMSX01.corpusers.net>
In-Reply-To: <1AF90E65795A3D45AA116B9264B4DAAF029D872D@SELDMSX01.corpusers.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 04:28:39.0005 (UTC)
	FILETIME=[BCE8F8D0:01C5D9E5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Cc: "Gulin, Jens" <Jens.Gulin@sonyericsson.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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

since this was recently referenced, I wanted to follow up on a couple of 
specific points:

Hyttfors, Per wrote:

> Comments inline.
> 
> 

>>Some other thoughts are:
>>
>>1. an xcap extension that allowed to specifically query for 
>>the namespace bindings in scope for a particular element
>>
> 
> 
> If this can be done within the original request (is that alternative 2?)
> I think it has value. In case it would require a client to make two
> requests it seems to make more trouble than it solves. I suppose that
> the second request also would need to be conditional to safely assure
> that the data and prefixes weren't changed since the initial element
> fetch.

This is what is now written in xcap-08. It requires two requests; at 
least, one to get the namespace bindings, and one to do the update. You 
can cache the bindings, but then you run into problems if they have 
changed when you do an update.



> 
>>2. change xcap so that what is returned is an xml fragment 
>>that includes additional information on the namespace bindings in scope
>>
> 
> 
> W3C dealt with this problem years ago and came up with their XML
> fragment entity. It is already a working standard and there has to be
> several implementations already using this.

I looked at it recently, though not really during the design of xcap 
itself. The main problem I had is that they never got around to 
specifying a consolidated format that included both the fragment context 
and the body. Thus, to use this with GET, we'd have to either go to 
multipart or define our own consolidated format. Same with PUT, except 
the added ugliness that when you do a PUT, youre not really putting the 
fragment and its context; you really ARE putting just the body.


> 
> Another W3C standard that seems to deal with exactly the problems you
> get when maintaining XML documents on a server is Exclusive XML
> Canonicalization. To me this seems to be an ideal solution for us. The
> fragment will simply inherit all the required namespace bindings and
> include them as if it was part of the fragment.


OK, I took a look at this spec. If I understand what it means, the 
topmost element would contain namespace declarations for only those 
namespace prefixes used in its children. That helps the GET case,  but 
not the PUT case. If you PUT such a canonicalization, it would require 
munging of the namepsace prefixes before insertion into the document, 
with the problems that come with that.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Wed Oct 26 05:37:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUhiu-0003M9-Vh; Wed, 26 Oct 2005 05:37:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhis-0003JE-RB
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 05:37:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07038
	for <simple@ietf.org>; Wed, 26 Oct 2005 05:37:15 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUhvz-0002sj-8f
	for simple@ietf.org; Wed, 26 Oct 2005 05:51:05 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9Q9XfE3006968; Wed, 26 Oct 2005 12:33:46 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 12:37:26 +0300
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 12:37:25 +0300
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Oct 2005 12:37:25 +0300
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816C9B@esebe101.NOE.Nokia.com>
Thread-Topic: [Simple] agenda requests
Thread-Index: AcXZdgmwRARtxd3DSCCWqcLGDzc95AAlZmbg
To: <rjsparks@nostrum.com>, <simple@ietf.org>
X-OriginalArrivalTime: 26 Oct 2005 09:37:25.0833 (UTC)
	FILETIME=[DFC29390:01C5DA10]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Simple] RE: SIMPLE document status (was: agenda requests)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Robert, Hisham,

During IETF#63 SIMPLE meeting you presented the following roadmap of how =
the various SIMPLE documents would be delivered to the IESG:

* Presence data package (9/2005)
  - Rpid,cipid,future done
  - data-model,prescaps-ext close
* MSRP (10/2005)
* Presence rules (10/2005)
  - Common-policy dependency
* Partial-* (12/2005)

Could you shortly summarize the status of each of these items, and =
update the roadmap accordingly. I think I know where XCAP, Presence =
rules & Common policy and Partial-* are at the moment, but I don't fully =
understand what is happening with rpid, cipid, future, data-model, =
prescaps-ext and MSRP. There have been several WGLC's, some comments =
have been provided, documents have been updated, etc., but according to =
I-D tracker no progress has been made with any of these.

Markus


> -----Original Message-----
> From: simple-bounces@ietf.org=20
> [mailto:simple-bounces@ietf.org]On Behalf
> Of ext Robert Sparks
> Sent: 25 October, 2005 17:50
> To: Simple WG
> Subject: [Simple] agenda requests
>=20
>=20
> Folks -
>=20
> Hisham and I are working out the agenda details for our meeting in =20
> Vancouver.
>=20
> Note that we are meeting Friday morning.
>=20
> Note also that geopriv is making a special effort to close=20
> out common-=20
> policy
> during their session - please attend that session.
>=20
> We will spend time on:
>=20
> + what we're doing to xcap core
> + adjusting to the geopriv common-policy discussion
>     (this hopefully will be a short status report)
> + adjusting to what we learn at the XML-Patch-Ops BOF
>     (this affects the -partial- drafts and xcap-diff)
> + closing on a path forward for xcap-diff
> + discussing progress on the IMDN work
> + discussing the presence policy drafts
> and if time allows (and I think it will)
> + new drafts
>=20
> If you see something missing or have a new draft
> you want agenda time for and haven't already
> contacted us, please send us a note today.
>=20
> Thanks,
>=20
> RjS
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>=20

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



From simple-bounces@ietf.org Wed Oct 26 06:51:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUisc-0006Tk-Tx; Wed, 26 Oct 2005 06:51:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUisa-0006S4-VG
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 06:51:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11226
	for <simple@ietf.org>; Wed, 26 Oct 2005 06:51:21 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUj5i-0005EQ-1U
	for simple@ietf.org; Wed, 26 Oct 2005 07:05:12 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9QAlliu023476; Wed, 26 Oct 2005 13:47:47 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 13:51:25 +0300
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 13:51:25 +0300
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] Does IMS must using IPv6?
Date: Wed, 26 Oct 2005 13:51:25 +0300
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816C9F@esebe101.NOE.Nokia.com>
Thread-Topic: [Simple] Does IMS must using IPv6?
Thread-Index: AcXWxUe2hk5t+UK4EdqhrAARJEEJ/ADVKTRw
To: <fluffy@cisco.com>, <zodist@gmail.com>, <simple@ietf.org>
X-OriginalArrivalTime: 26 Oct 2005 10:51:25.0738 (UTC)
	FILETIME=[362650A0:01C5DA1B]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,
=20
Originally IMS (the 3GPP version of it, I think that is the original one =
;-) was specified exclusively on top of IPv6. The thinking was that =
mobile operators have no choise but to deploy v6 since in a few years =
there will be hundreds of millions of IP-equipped devices using their =
networks. Also, it was understood that the e-2-e media sessions would =
not work without a global address space.
=20
However, in practice most GRPS/CDMA/WCDMA access networks still only =
provide IPv4+NAT. In practice all IMS products thus need to support v4 =
(some of them ALSO support v6), and most deployments have been done with =
v4. This, and the need for NAT traversal, has been noticed then also in =
the standards world, and consequently v4 support has been added to IMS =
on paper too, and currently 3GPP and ETSI TISPAN (who has adopted 3GPP =
IMS) are defining B2BUA/SBC-based solutions for NAT traversal. (SBCs =
seem to be much more popular among the operators than the IETF solutions =
such as STUN, TURN, ICE. Too bad...)
=20
Markus
=20

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf =
Of ext Cullen Jennings
Sent: 22 October, 2005 07:59
To: Cheney Stallman; simple@ietf.org
Subject: Re: [Simple] Does IMS must using IPv6?



I've been puzzled by this too - I'm sure the answer is complicated and =
involves understanding the many different IMSsz but as far as I can =
tell, the short answer is that, in theory it does but in practice it =
does not.=20

On 8/30/05 7:56 AM, "Cheney Stallman" <zodist@gmail.com> wrote:



This problem puzzled me, Does IMS must using IPv6, or paritial using =
IPv6,
or some other restriction?
=20
Thanks in advanced.
=20


  _____ =20

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






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



From simple-bounces@ietf.org Wed Oct 26 07:35:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUjZ3-0003Io-G3; Wed, 26 Oct 2005 07:35:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjZ1-0003IW-4Y
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 07:35:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12840
	for <simple@ietf.org>; Wed, 26 Oct 2005 07:35:10 -0400 (EDT)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUjm9-0006MY-Vp
	for simple@ietf.org; Wed, 26 Oct 2005 07:49:02 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9QBVgVf006997; Wed, 26 Oct 2005 14:31:42 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 14:35:22 +0300
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 26 Oct 2005 14:35:22 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j9QBZMj22134; Wed, 26 Oct 2005 14:35:22 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 881E693B6A; Wed, 26 Oct 2005 14:35:22 +0300 (EEST)
Message-ID: <435F69FA.5070106@nokia.com>
Date: Wed, 26 Oct 2005 14:35:22 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] A proposal for fixing the xcap schema problem and related
	issues
References: <434756D0.6070708@cisco.com> <434B9F52.3030206@nokia.com>
	<435892EC.6050806@cisco.com> <4358A871.9030508@nokia.com>
	<435F0241.7090406@cisco.com>
In-Reply-To: <435F0241.7090406@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 11:35:22.0790 (UTC)
	FILETIME=[59F48460:01C5DA21]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Jonathan Rosenberg wrote:

> inline.
>
> Jari Urpalainen wrote:
>
>
>>> What you are proposing, of inserting in the first possible position, 
>>> would allow for insertions of the form ../parent/element[pos] to 
>>> have the effect of keeping together elements of the same name. Thats 
>>> all fine, except its not consistent with whats in the current spec. 
>>> Thus, changing it would break backwards compatibility. Since this 
>>> would be a feature enhancement as opposed to a bug fix, I think we 
>>> need to keep it consistent.
>>>
>> ok, so you are saying that the position for e.g. for a new element is 
>> the last possible one. That's fine with me as well, because it's 
>> unambiguous. The minor issue is that in the implementation you'll 
>> anyhow have to find first the first possible location, now with your 
>> proposal an implementation has to look for the next (and the last) 
>> possible node positions. For the implementation it should not be a 
>> major issue, however.
>
>
> What ended up in the text is a bit different than what I propose, and 
> closer to what you hav ein mind, I think. Please take a look.
>
I havn't yet read the whole new doc, just commenting this one issue. 
Anyway, I had to read 8.2.3 a couple of times before I probably 
understood what you have in mind ;).  That said, the skipping of 
whitespace, PI and comment nodes is problematic or actually whitespace 
nodes. That's because during the insert phase it is impossible to 
distinguish a whitespace node from the usual text node (mixed content), 
unless the schema is known. So imo the only reasonable solution is to 
use either the first or the last possible position for the newly 
inserted node (or actually element). As I said before, from the 
implementation pov the first possible position is better (i.e. when 
you'll have positional constraints).

When you don't have positional constraints (or you'll have elem[1] but 
not any other <elem>) I am inclined to prefer the former backwards 
compatibility mode, so just simply adding elements as last children. If 
you intend to keep this new proposal (without skipping) you should then 
add some text what will happen when you send 'root/*[3][@add="third"]' 
just in order to remove any ambiquity.

>
>>>>>
>>>> good. Also it might be worth noting that within location steps 
>>>> apostrophes (') can be used too (like in XPath).
>>>
>>>
>>>
>>>
>>> What is the meaning of it? I'm not familiar with that.
>>>
>> from XPath spec:
>> "Within expressions, literal strings are delimited by single or 
>> double quotation marks, which are also used to delimit XML 
>> attributes. To avoid a quotation mark in an expression being 
>> interpreted by the XML processor as terminating the attribute value 
>> the quotation mark can be entered as a character reference (|&quot;| 
>> or |&apos;|). Alternatively, the expression can use single quotation 
>> marks if the XML attribute is delimited with double quotation marks 
>> or vice-versa."
>>
>> in xcap these could appear within docs or r-uri's, so it should be 
>> imo described someway.
>> thanks,
>
>
> We have this already in section 6:
>
> Note that the left bracket, right bracket, and double quote
>    characters, which are meaningful to XCAP, cannot be directly
>    represented in the HTTP URI.  As a result, they are escape coded when
>    placed within the HTTP URI.  Furthermore, since XML allows for non-
>    ASCII characters, the names of elements and attributes may not be
>    directly representable in a URI.  Any such characters MUST be
>    represented by converting them to an octet sequence corresponding to
>    their representation in UTF-8, and then escape-coding that sequence
>    of octets.
>
> is that not sufficient?
>
> Thanks,
> Jonathan R.
>
Well not quite, e.g. BNF doesn't allow aposthrobe ('). Also if some 
example would contain one it would be neat.
thanks,
Jari


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



From simple-bounces@ietf.org Wed Oct 26 07:54:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUjrW-0005bI-J9; Wed, 26 Oct 2005 07:54:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjrV-0005b6-5v
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 07:54:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13640
	for <simple@ietf.org>; Wed, 26 Oct 2005 07:54:18 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUk4d-0006xU-8Q
	for simple@ietf.org; Wed, 26 Oct 2005 08:08:09 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9QBprAs021444; Wed, 26 Oct 2005 14:51:55 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 14:53:47 +0300
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 14:53:47 +0300
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Oct 2005 14:53:46 +0300
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816CA1@esebe101.NOE.Nokia.com>
Thread-Topic: [Simple] Questions regarding MSRP drafts
Thread-Index: AcXWw9RgEuI/s0K3EdqhrAARJEEJ/ADWMA+g
To: <fluffy@cisco.com>, <eburger@brooktrout.com>, <ben@estacado.net>,
	<rohan@ekabal.com>
X-OriginalArrivalTime: 26 Oct 2005 11:53:47.0091 (UTC)
	FILETIME=[EC2B7A30:01C5DA23]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: quoted-printable
Cc: simple@ietf.org
Subject: [Simple] MSRP with content indirection
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I would like to understand how well MSRP and SIP content indirection =
work together by default. I.e., if one of the parties indicates in SDP =
for MSRP...

   a=3Daccept-types:message/external-body

...is it possible for the other party to send something like this...

   MSRP a786hjs2 SEND
   To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
   From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
   Message-ID: 87652
   Byte-Range: ...
   Content-Type: message/external-body;
      ACCESS-TYPE=3DURL;
      URL=3D"http://www.example.net/party/06/2002/announcement";
      EXPIRATION=3D"Sat, 20 Jun 2002 12:00:00 GMT";
      size=3D231
   Content-Length: ...

   Content-Type: image/jpg
   Content-Disposition: ...
   Content-ID: <4e5562cd1214427d@example.net>

...so that the semantics would be clear and unambiguous?

In other words, is this possible by just combining the two specs, or is =
there need to write an additional short draft to cover this?

Markus=20

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



From simple-bounces@ietf.org Wed Oct 26 08:17:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUkDT-0000EO-Mg; Wed, 26 Oct 2005 08:17:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkDR-0000Dz-JI
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 08:17:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15081
	for <simple@ietf.org>; Wed, 26 Oct 2005 08:16:58 -0400 (EDT)
Received: from theater-sate.de ([81.169.138.67]
	helo=h93074.serverkompetenz.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkQa-0007hX-Q6
	for simple@ietf.org; Wed, 26 Oct 2005 08:30:49 -0400
Received: from coyote (coyote.mmweg.RWTH-Aachen.DE [134.130.118.117])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by h93074.serverkompetenz.net (Postfix) with ESMTP id 0605D24C64;
	Wed, 26 Oct 2005 14:17:01 +0200 (CEST)
From: Sebastian Ley <sebastian@withouthat.org>
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] Re: A proposal for fixing the xcap schema problem and
	related issues
Date: Wed, 26 Oct 2005 14:16:55 +0200
User-Agent: KMail/1.8.2
References: <E7F5A43EEB6E7C42A08C041BDEB90A5305B08F@mail2.sonimtech.com>
	<200510251341.38860.sebastian@withouthat.org>
	<435F0027.60402@cisco.com>
In-Reply-To: <435F0027.60402@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510261416.59109.sebastian@withouthat.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

* Jonathan Rosenberg wrote:

> > Correct me if I am wrong, but I thought that the get(put(x)) == x
> > requirement is from XCAP. HTTP mandates idempotency which is satisfied
> > even with the prefix mangling suggestion above. Right?
>
> Hmm. Fair point. You are right. We long ago decided that with xcap we
> would meet the idempotency requirement by maintaining the property that
> get(put(x))=x.
>
> However, there are other issues with the namespcae prefix munging, which
> Martin just posted on.

Hm, I can't find that one... Which post do you mean?

> > In that case we would "just" need to drop the above requirement and
> > revert to the HTTP idempotency to make solution 2 possible. That means
> > extra work for the server, but takes a lot complexity from the clients,
> > allows for single pass updates and static URI construction.
>
> Well, the hashing approach also removes complexity from clients, allows
> for single pass updates and static URI construction too. Its also less
> verbose than a rewrite, since it would reqiure you to declare the
> namespace prefixes you used in the fragment. And it doesnt have the
> other issues with namespace munging that Martin referenced.

While it is true, that the hashing approach solves the namespace mess
for both, PUTs and GETs, it has a major impact on human readability,
which was (IMO) always a great asset of XML. An example from the spec:

   <foo xmlns="urn:test:default-namespace">
     <ns1:bar xmlns:ns1="urn:test:namespace1-uri"
              xmlns="urn:test:namespace1-uri">
       <baz/>
       <ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
     </ns1:bar>
   </foo>

becomes (after md5sum | base64-encode):

   <foo xmlns="urn:test:default-namespace">
     <MWE2NDI0MDRlNTc1YTM1Y2FmNGE0NzdkNWI0OTEzYWUgIC0K:bar
              xmlns:MWE2NDI0MDRlNTc1YTM1Y2FmNGE0NzdkNWI0OTEzYWUgIC0K="urn:test:namespace1-uri"
              xmlns="urn:test:namespace1-uri">
       <baz/>
       <Y2MyYjQ3NTQ0NjBkZDEyMjE3YmEwYmFkYzdlZjBjMzUgIC0K:baz
              xmlns:Y2MyYjQ3NTQ0NjBkZDEyMjE3YmEwYmFkYzdlZjBjMzUgIC0K="urn:test:namespace2-uri"/>
     </MWE2NDI0MDRlNTc1YTM1Y2FmNGE0NzdkNWI0OTEzYWUgIC0K:bar>
   </foo>

While my computer has no problem in eating this, I certainly have my
problems ;-)

> > Together with a former suggestion of Per Hyttfors who proposed to solve
> > the namespace querying for GETs with XML Canonicalisation
> > (http://www.ietf.org/mail-archive/web/simple/current/msg05728.html) that
> > would make client implementations very simple and put all namespace
> > resolving "burden" on the server. That sounds like a good idea to me.
>
> I'll be responding to that note in a moment. Unfortunately I don't
> follow the proposal; I'm not an expert in the canonicalization spec. Can
> you or Per summarize the idea?

I reckon you found Per's summary of the idea from his previous post.
You are right, it only fixes the GET case. It is obsolete if you want to
apply the hashing solution,  but for the above reasons, I would advise
to reconsider that...

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

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



From simple-bounces@ietf.org Wed Oct 26 08:25:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUkLb-0005Jv-8z; Wed, 26 Oct 2005 08:25:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkLZ-0005Ib-9J
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 08:25:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15455
	for <simple@ietf.org>; Wed, 26 Oct 2005 08:25:22 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkYi-0007vr-To
	for simple@ietf.org; Wed, 26 Oct 2005 08:39:13 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9QCPU7G019273; Wed, 26 Oct 2005 15:25:33 +0300
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Oct 2005 15:25:33 +0300
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 26 Oct 2005 15:25:33 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j9QCPXj02292; Wed, 26 Oct 2005 15:25:33 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id C2AB593B77; Wed, 26 Oct 2005 15:25:32 +0300 (EEST)
Message-ID: <435F75BC.7010800@nokia.com>
Date: Wed, 26 Oct 2005 15:25:32 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using
	only the XML fragment body.
References: <1AF90E65795A3D45AA116B9264B4DAAF029D872D@SELDMSX01.corpusers.net>
	<435F05F6.2010505@cisco.com>
In-Reply-To: <435F05F6.2010505@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 12:25:33.0303 (UTC)
	FILETIME=[5C5C5870:01C5DA28]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Content-Transfer-Encoding: 7bit
Cc: "Gulin, Jens" <Jens.Gulin@sonyericsson.com>, "Hyttfors,
	Per" <Per.Hyttfors@sonyericsson.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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Jonathan Rosenberg wrote:

> since this was recently referenced, I wanted to follow up on a couple 
> of specific points:
>
> Hyttfors, Per wrote:
>
>> Comments inline.
>>
>>
>
>>> Some other thoughts are:
>>>
>>> 1. an xcap extension that allowed to specifically query for the 
>>> namespace bindings in scope for a particular element
>>>
>>
>>
>> If this can be done within the original request (is that alternative 2?)
>> I think it has value. In case it would require a client to make two
>> requests it seems to make more trouble than it solves. I suppose that
>> the second request also would need to be conditional to safely assure
>> that the data and prefixes weren't changed since the initial element
>> fetch.
>
>
> This is what is now written in xcap-08. It requires two requests; at 
> least, one to get the namespace bindings, and one to do the update. 
> You can cache the bindings, but then you run into problems if they 
> have changed when you do an update.
>
>
>
>>
>>> 2. change xcap so that what is returned is an xml fragment that 
>>> includes additional information on the namespace bindings in scope
>>>
>>
>>
>> W3C dealt with this problem years ago and came up with their XML
>> fragment entity. It is already a working standard and there has to be
>> several implementations already using this.
>
>
> I looked at it recently, though not really during the design of xcap 
> itself. The main problem I had is that they never got around to 
> specifying a consolidated format that included both the fragment 
> context and the body. Thus, to use this with GET, we'd have to either 
> go to multipart or define our own consolidated format. Same with PUT, 
> except the added ugliness that when you do a PUT, youre not really 
> putting the fragment and its context; you really ARE putting just the 
> body.
>
>
>>
>> Another W3C standard that seems to deal with exactly the problems you
>> get when maintaining XML documents on a server is Exclusive XML
>> Canonicalization. To me this seems to be an ideal solution for us. The
>> fragment will simply inherit all the required namespace bindings and
>> include them as if it was part of the fragment.
>
>
>
> OK, I took a look at this spec. If I understand what it means, the 
> topmost element would contain namespace declarations for only those 
> namespace prefixes used in its children. That helps the GET case,  but 
> not the PUT case. If you PUT such a canonicalization, it would require 
> munging of the namepsace prefixes before insertion into the document, 
> with the problems that come with that.
>
> -Jonathan R.

The whole issue (if there's any) has no influence on my reference 
implementation as I don't have any cases where I needed these "blind" 
updates. I have found it extremely difficult to write an application 
that doesn't break easily when you'll try to do "blind" xcap patching. 
There are imo quite rare cases where it can/could be used. So the whole 
discussion is imo quite obscure.

However, if an application wants to try this "blind" patching  (==put 
with some qualified elements) why just simply add those declarations on 
the payload. Sure it leads to additional ns declarations on the server, 
but who cares. There's no ambiquity with the canonical format, because 
those addiotional ns declarations are then removed anyway. (and I 
certainly don't want that the server is required to remove those ns 
declarations during xcap put patching, no).

Perhaps I'm a lousy programmer but to me this is a no-issue or at least 
largely exaggerated one. Also having some mandated prefixes is a bad 
idea, imo. In addition, it looks like that there must be another 
application that first has created the doc, and now your app has to edit 
it (as if as your app doesn't know what it is doing, right ?). So is 
this really this big issue ? E.g. I am personally much more worried 
about the case where you'll have many apps editing the same doc, as 
you'll have no locks in xcap (== not a proposal to add one, no)
 
And btw. regarding to the original example from Per, xcap-list should 
have reused imo the same namespace declaration for lists and services...

br,
Jari

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



From simple-bounces@ietf.org Wed Oct 26 09:06:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUkza-0004ox-Ih; Wed, 26 Oct 2005 09:06:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkzY-0004ok-SR
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 09:06:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18193
	for <simple@ietf.org>; Wed, 26 Oct 2005 09:06:42 -0400 (EDT)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUlCj-0000uQ-0Q
	for simple@ietf.org; Wed, 26 Oct 2005 09:20:33 -0400
Received: from [192.168.0.103] (c-24-1-67-0.hsd1.tx.comcast.net [24.1.67.0])
	(authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j9QD6nGn012380
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 26 Oct 2005 08:06:50 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <C84E0A4ABA6DD74DA5221E0833A35DF303816C9B@esebe101.NOE.Nokia.com>
References: <C84E0A4ABA6DD74DA5221E0833A35DF303816C9B@esebe101.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <EE22B27C-15BA-4128-9CC5-818A022C788D@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Date: Wed, 26 Oct 2005 08:06:50 -0500
To: <Markus.Isomaki@nokia.com>
X-Mailer: Apple Mail (2.734)
Received-SPF: pass (nostrum.com: 24.1.67.0 is authenticated by a trusted
	mechanism)
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org
Subject: [Simple] Re: SIMPLE document status (was: agenda requests)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


We recently got the final versions of rpid and the datamodel.
We will request publication of rpid,cipid,future, and the datamodel  
within the next couple of days.
prescaps-ext will be WGLCed as soon as the most recent submission  
makes it into the repository.
Jon is holding a token on MSRP - I hope to have that cleared before  
we get to Vancouver.
Presence-rules depends on the in-progress common-policy.
the -partial- drafts depend on feedback from XML-Patch-Ops

RjS

On Oct 26, 2005, at 4:37 AM, <Markus.Isomaki@nokia.com> wrote:

> Robert, Hisham,
>
> During IETF#63 SIMPLE meeting you presented the following roadmap  
> of how the various SIMPLE documents would be delivered to the IESG:
>
> * Presence data package (9/2005)
>   - Rpid,cipid,future done
>   - data-model,prescaps-ext close
> * MSRP (10/2005)
> * Presence rules (10/2005)
>   - Common-policy dependency
> * Partial-* (12/2005)
>
> Could you shortly summarize the status of each of these items, and  
> update the roadmap accordingly. I think I know where XCAP, Presence  
> rules & Common policy and Partial-* are at the moment, but I don't  
> fully understand what is happening with rpid, cipid, future, data- 
> model, prescaps-ext and MSRP. There have been several WGLC's, some  
> comments have been provided, documents have been updated, etc., but  
> according to I-D tracker no progress has been made with any of these.
>
> Markus
>
>
>
>> -----Original Message-----
>> From: simple-bounces@ietf.org
>> [mailto:simple-bounces@ietf.org]On Behalf
>> Of ext Robert Sparks
>> Sent: 25 October, 2005 17:50
>> To: Simple WG
>> Subject: [Simple] agenda requests
>>
>>
>> Folks -
>>
>> Hisham and I are working out the agenda details for our meeting in
>> Vancouver.
>>
>> Note that we are meeting Friday morning.
>>
>> Note also that geopriv is making a special effort to close
>> out common-
>> policy
>> during their session - please attend that session.
>>
>> We will spend time on:
>>
>> + what we're doing to xcap core
>> + adjusting to the geopriv common-policy discussion
>>     (this hopefully will be a short status report)
>> + adjusting to what we learn at the XML-Patch-Ops BOF
>>     (this affects the -partial- drafts and xcap-diff)
>> + closing on a path forward for xcap-diff
>> + discussing progress on the IMDN work
>> + discussing the presence policy drafts
>> and if time allows (and I think it will)
>> + new drafts
>>
>> If you see something missing or have a new draft
>> you want agenda time for and haven't already
>> contacted us, please send us a note today.
>>
>> Thanks,
>>
>> RjS
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>>
>


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



From simple-bounces@ietf.org Wed Oct 26 11:17:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUn1g-0004gQ-84; Wed, 26 Oct 2005 11:17:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUn1d-0004bw-DJ
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 11:17:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00356
	for <simple@ietf.org>; Wed, 26 Oct 2005 11:16:57 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnEo-0006dx-Rl
	for simple@ietf.org; Wed, 26 Oct 2005 11:30:51 -0400
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 26 Oct 2005 08:17:04 -0700
X-IronPort-AV: i="3.97,254,1125903600"; 
	d="scan'208"; a="224100820:sNHT25256912"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9QFGQ98012304;
	Wed, 26 Oct 2005 08:16:57 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 26 Oct 2005 11:16:59 -0400
Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 26 Oct 2005 11:16:58 -0400
Message-ID: <435F9DEA.2090105@cisco.com>
Date: Wed, 26 Oct 2005 11:16:58 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
Subject: Re: [Simple] MSRP with content indirection
References: <C84E0A4ABA6DD74DA5221E0833A35DF303816CA1@esebe101.NOE.Nokia.com>
In-Reply-To: <C84E0A4ABA6DD74DA5221E0833A35DF303816CA1@esebe101.NOE.Nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 15:16:58.0770 (UTC)
	FILETIME=[4EFA0F20:01C5DA40]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: fluffy@cisco.com, eburger@brooktrout.com, simple@ietf.org, rohan@ekabal.com
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Markus,

In general I think it is already covered. But there may be points of 
interpretation that would be well served by writing something down 
someplace.

In your example, I would interpret message/external-body as a wrapper 
type. So in your example, it would be wrong to use it to wrap a jpeg. To 
make it right, I think one of the following should be used in the 
offer/answer:

     a=accept-types:message/external-body,image/jpg

or

     a=accept-types:message/external-body
     a=accept-wrapped-types:image/jpg

	Paul

Markus.Isomaki@nokia.com wrote:
> Hi,
> 
> I would like to understand how well MSRP and SIP content indirection work together by default. I.e., if one of the parties indicates in SDP for MSRP...
> 
>    a=accept-types:message/external-body
> 
> ...is it possible for the other party to send something like this...
> 
>    MSRP a786hjs2 SEND
>    To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
>    From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
>    Message-ID: 87652
>    Byte-Range: ...
>    Content-Type: message/external-body;
>       ACCESS-TYPE=URL;
>       URL="http://www.example.net/party/06/2002/announcement";
>       EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT";
>       size=231
>    Content-Length: ...
> 
>    Content-Type: image/jpg
>    Content-Disposition: ...
>    Content-ID: <4e5562cd1214427d@example.net>
> 
> ...so that the semantics would be clear and unambiguous?
> 
> In other words, is this possible by just combining the two specs, or is there need to write an additional short draft to cover this?
> 
> Markus 
> 
> _______________________________________________
> 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 Oct 26 12:24:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUo4h-0007gn-FZ; Wed, 26 Oct 2005 12:24:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUo4f-0007ed-9p
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 12:24:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05565
	for <simple@ietf.org>; Wed, 26 Oct 2005 12:24:09 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUoHq-0000kz-Da
	for simple@ietf.org; Wed, 26 Oct 2005 12:38:03 -0400
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 26 Oct 2005 09:24:15 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9QGNr8u003689;
	Wed, 26 Oct 2005 09:24:06 -0700 (PDT)
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);
	Wed, 26 Oct 2005 12:24:10 -0400
Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 26 Oct 2005 12:24:10 -0400
Message-ID: <435FADA9.7080100@cisco.com>
Date: Wed, 26 Oct 2005 12:24:09 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Xiao Wang <wangsmile@huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2005 16:24:10.0093 (UTC)
	FILETIME=[B1D521D0:01C5DA49]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>
Subject: [Simple] Re: draft-wang-simple-presence-ril-00
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

After reading this draft, I am left wondering "why?".

I just don't see the problem that this draft is trying to solve. I would
expect that a subscriber will either request everything he can get, or
at least everything that he knows how to process. If bandwidth
constrained he may request only those things that are valuable enough to
him that he wants to expend the bandwidth to get them. But I don't see
why a subscriber would be limiting what he wants based on what he thinks
the publisher is willing or able to offer.

I think there is also a potential privacy issue in what is proposed. If
I want to exclude someone from obtaining certain pieces of presence
information, I probably don't want to tell them they are being excluded.
I would prefer them to think that information isn't available to anyone.

	Paul

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



From simple-bounces@ietf.org Wed Oct 26 15:53:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUrLB-0006XV-6B; Wed, 26 Oct 2005 15:53:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUrHt-0005Ni-W5; Wed, 26 Oct 2005 15:50:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17901;
	Wed, 26 Oct 2005 15:50:02 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EUrUw-0007W9-Fy; Wed, 26 Oct 2005 16:03:47 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EUrHf-00074h-QJ; Wed, 26 Oct 2005 15:50:03 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EUrHf-00074h-QJ@newodin.ietf.org>
Date: Wed, 26 Oct 2005 15:50:03 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-08.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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		: The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-xcap-08.txt
	Pages		: 66
	Date		: 2005-10-26
	
This specification defines the Extensible Markup Language (XML)
   Configuration Access Protocol (XCAP).  XCAP allows a client to read,
   write and modify application configuration data, stored in XML format
   on a server.  XCAP maps XML document sub-trees and element attributes
   to HTTP URIs, so that these components can be directly accessed by
   HTTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-xcap-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-xcap-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-10-26151712.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-xcap-08.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-simple-xcap-08.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-26151712.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From simple-bounces@ietf.org Wed Oct 26 17:48:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUt8I-0001AO-7Q; Wed, 26 Oct 2005 17:48:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUt8G-0001AG-Vp
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 17:48:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28702
	for <simple@ietf.org>; Wed, 26 Oct 2005 17:48:13 -0400 (EDT)
Received: from marauder.andrew.com ([198.17.217.129])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUtLU-0006TY-T1
	for simple@ietf.org; Wed, 26 Oct 2005 18:02:10 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 16:48:05 -0500
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
	E-mail Filter (4.7); Wed, 26 Oct 2005 16:48:05 -0500
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 16:48:04 -0500
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC0DF79072@aopex5.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Jari Urpalainen" <jari.urpalainen@nokia.com>,
	"ext Jonathan Rosenberg" <jdrosen@cisco.com>
Date: Wed, 26 Oct 2005 16:47:03 -0500
Subject: RE: [Simple] XCAP and its problem with Namespaces caused by usingonly
	the XML fragment body.
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 26 Oct 2005 21:48:04.0602 (UTC)
	FILETIME=[F1B3DDA0:01C5DA76]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: [Simple] XCAP and its problem with Namespaces caused by
	usingonly the XML fragment body.
Thread-Index: AcXaKKHK9kARe5RaTN+gHz6pXjoA/QATaVsw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: "Gulin, Jens" <Jens.Gulin@sonyericsson.com>, "Hyttfors,
	Per" <Per.Hyttfors@sonyericsson.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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1015094935=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============1015094935==
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
Content-Transfer-Encoding: base64

SmFyaSBtYWtlcyBhIHZlcnkgZ29vZCBwb2ludC4gIEhpcyBpcyBhIHByYWN0aWNhbCBzb2x1dGlv
biB0aGF0IHdpbGwgd29yayB3aXRoIG5vIGNoYW5nZXMgcmVxdWlyZWQuICBJJ2QgYWdyZWUgdGhh
dCB0aGUgcHJvYmxlbSBpc24ndCBvbmUgd29ydGggc29sdmluZy4NCg0KPiBUaGUgd2hvbGUgaXNz
dWUgKGlmIHRoZXJlJ3MgYW55KSBoYXMgbm8gaW5mbHVlbmNlIG9uIG15IHJlZmVyZW5jZQ0KPiBp
bXBsZW1lbnRhdGlvbiBhcyBJIGRvbid0IGhhdmUgYW55IGNhc2VzIHdoZXJlIEkgbmVlZGVkIHRo
ZXNlICJibGluZCINCj4gdXBkYXRlcy4gSSBoYXZlIGZvdW5kIGl0IGV4dHJlbWVseSBkaWZmaWN1
bHQgdG8gd3JpdGUgYW4gYXBwbGljYXRpb24NCj4gdGhhdCBkb2Vzbid0IGJyZWFrIGVhc2lseSB3
aGVuIHlvdSdsbCB0cnkgdG8gZG8gImJsaW5kIiB4Y2FwIHBhdGNoaW5nLg0KPiBUaGVyZSBhcmUg
aW1vIHF1aXRlIHJhcmUgY2FzZXMgd2hlcmUgaXQgY2FuL2NvdWxkIGJlIHVzZWQuIFNvIHRoZSB3
aG9sZQ0KPiBkaXNjdXNzaW9uIGlzIGltbyBxdWl0ZSBvYnNjdXJlLg0KPiANCj4gSG93ZXZlciwg
aWYgYW4gYXBwbGljYXRpb24gd2FudHMgdG8gdHJ5IHRoaXMgImJsaW5kIiBwYXRjaGluZyAgKD09
cHV0DQo+IHdpdGggc29tZSBxdWFsaWZpZWQgZWxlbWVudHMpIHdoeSBqdXN0IHNpbXBseSBhZGQg
dGhvc2UgZGVjbGFyYXRpb25zIG9uDQo+IHRoZSBwYXlsb2FkLiBTdXJlIGl0IGxlYWRzIHRvIGFk
ZGl0aW9uYWwgbnMgZGVjbGFyYXRpb25zIG9uIHRoZSBzZXJ2ZXIsDQo+IGJ1dCB3aG8gY2FyZXMu
IFRoZXJlJ3Mgbm8gYW1iaXF1aXR5IHdpdGggdGhlIGNhbm9uaWNhbCBmb3JtYXQsIGJlY2F1c2UN
Cj4gdGhvc2UgYWRkaW90aW9uYWwgbnMgZGVjbGFyYXRpb25zIGFyZSB0aGVuIHJlbW92ZWQgYW55
d2F5LiAoYW5kIEkNCj4gY2VydGFpbmx5IGRvbid0IHdhbnQgdGhhdCB0aGUgc2VydmVyIGlzIHJl
cXVpcmVkIHRvIHJlbW92ZSB0aG9zZSBucw0KPiBkZWNsYXJhdGlvbnMgZHVyaW5nIHhjYXAgcHV0
IHBhdGNoaW5nLCBubykuDQo+IA0KPiBQZXJoYXBzIEknbSBhIGxvdXN5IHByb2dyYW1tZXIgYnV0
IHRvIG1lIHRoaXMgaXMgYSBuby1pc3N1ZSBvciBhdCBsZWFzdA0KPiBsYXJnZWx5IGV4YWdnZXJh
dGVkIG9uZS4gQWxzbyBoYXZpbmcgc29tZSBtYW5kYXRlZCBwcmVmaXhlcyBpcyBhIGJhZA0KPiBp
ZGVhLCBpbW8uIEluIGFkZGl0aW9uLCBpdCBsb29rcyBsaWtlIHRoYXQgdGhlcmUgbXVzdCBiZSBh
bm90aGVyDQo+IGFwcGxpY2F0aW9uIHRoYXQgZmlyc3QgaGFzIGNyZWF0ZWQgdGhlIGRvYywgYW5k
IG5vdyB5b3VyIGFwcCBoYXMgdG8gZWRpdA0KPiBpdCAoYXMgaWYgYXMgeW91ciBhcHAgZG9lc24n
dCBrbm93IHdoYXQgaXQgaXMgZG9pbmcsIHJpZ2h0ID8pLiBTbyBpcw0KPiB0aGlzIHJlYWxseSB0
aGlzIGJpZyBpc3N1ZSA/IEUuZy4gSSBhbSBwZXJzb25hbGx5IG11Y2ggbW9yZSB3b3JyaWVkDQo+
IGFib3V0IHRoZSBjYXNlIHdoZXJlIHlvdSdsbCBoYXZlIG1hbnkgYXBwcyBlZGl0aW5nIHRoZSBz
YW1lIGRvYywgYXMNCj4geW91J2xsIGhhdmUgbm8gbG9ja3MgaW4geGNhcCAoPT0gbm90IGEgcHJv
cG9zYWwgdG8gYWRkIG9uZSwgbm8pDQo+IA0KPiBBbmQgYnR3LiByZWdhcmRpbmcgdG8gdGhlIG9y
aWdpbmFsIGV4YW1wbGUgZnJvbSBQZXIsIHhjYXAtbGlzdCBzaG91bGQNCj4gaGF2ZSByZXVzZWQg
aW1vIHRoZSBzYW1lIG5hbWVzcGFjZSBkZWNsYXJhdGlvbiBmb3IgbGlzdHMgYW5kIHNlcnZpY2Vz
Li4uDQo+IA0KPiBiciwNCj4gSmFyaQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9u
bHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl
IHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9y
aWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRl
ZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0=



--===============1015094935==
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

--===============1015094935==--



From simple-bounces@ietf.org Wed Oct 26 18:52:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUu88-0001JY-4E; Wed, 26 Oct 2005 18:52:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUu60-0000X5-DS; Wed, 26 Oct 2005 18:50:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02383;
	Wed, 26 Oct 2005 18:49:55 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EUuJ7-0008Ht-M2; Wed, 26 Oct 2005 19:03:49 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EUu5r-0005eU-CG; Wed, 26 Oct 2005 18:50:03 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EUu5r-0005eU-CG@newodin.ietf.org>
Date: Wed, 26 Oct 2005 18:50:03 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-05.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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		: Presence Information Data format (PIDF) 
                          Extension for Partial Presence
	Author(s)	: M. Lonnfors, et al.
	Filename	: draft-ietf-simple-partial-pidf-format-05.txt
	Pages		: 16
	Date		: 2005-10-26
	
The Presence Information Document Format (PIDF) specifies the
   baseline XML based format for describing presence information.  One
   of the characteristic of the PIDF is that document always needs to
   carry all presence information available for the presentity.  In some
   environments where low bandwidth and high latency links can exist it
   is often beneficial to limit the amount of transported information
   over the network.  This document introduces a new MIME type which
   enables transporting of either only the changed parts or the full
   PIDF based presence information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-partial-pidf-format-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-10-26184106.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-partial-pidf-format-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-26184106.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From simple-bounces@ietf.org Wed Oct 26 23:46:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUyig-0004EX-BN; Wed, 26 Oct 2005 23:46:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyie-0004Cg-8E
	for simple@megatron.ietf.org; Wed, 26 Oct 2005 23:46:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20026
	for <simple@ietf.org>; Wed, 26 Oct 2005 23:46:08 -0400 (EDT)
Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUyvt-0005fE-TL
	for simple@ietf.org; Thu, 27 Oct 2005 00:00:08 -0400
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 <0IP000HTU2QK84@szxga01-in.huawei.com> for
	simple@ietf.org; Thu, 27 Oct 2005 11:51:57 +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 <0IP000FZU2QDVO@szxga01-in.huawei.com> for
	simple@ietf.org; Thu, 27 Oct 2005 11:51:56 +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 <0IP0008T62YTGD@szxml01-in.huawei.com>; Thu,
	27 Oct 2005 11:56:53 +0800 (CST)
Date: Thu, 27 Oct 2005 11:45:46 +0800
From: Xiao Wang <wangsmile@huawei.com>
In-reply-to: <435FADA9.7080100@cisco.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Message-id: <048401c5daa8$ea1542f0$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
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7BIT
Cc: simple@ietf.org
Subject: [Simple] RE: draft-wang-simple-presence-ril-00
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Thank for Paul's comments.

I know your meaning. But the PIDF ,RPID and others are so many to a user who

can not understand all. So tell the subscriber the user doesn't understand
element, I think that is a good idea. And People may have a reason that he
don't support some of the element in PIDF,RPID etc. In fact, a proxy can
subscribe another proxy,
being excluded is significance among the proxies to subscribe.  


Xiao

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, October 27, 2005 12:24 AM
> To: Xiao Wang
> Cc: Simple WG
> Subject: Re: draft-wang-simple-presence-ril-00
> 
> After reading this draft, I am left wondering "why?".
> 
> I just don't see the problem that this draft is trying to solve. I would
> expect that a subscriber will either request everything he can get, or
> at least everything that he knows how to process. If bandwidth
> constrained he may request only those things that are valuable enough to
> him that he wants to expend the bandwidth to get them. But I don't see
> why a subscriber would be limiting what he wants based on what he thinks
> the publisher is willing or able to offer.
> 
> I think there is also a potential privacy issue in what is proposed. If
> I want to exclude someone from obtaining certain pieces of presence
> information, I probably don't want to tell them they are being excluded.
> I would prefer them to think that information isn't available to anyone.
> 
> 	Paul


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



From simple-bounces@ietf.org Thu Oct 27 02:51:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EV1bh-00086A-UA; Thu, 27 Oct 2005 02:51:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EV1aQ-0007m9-IW; Thu, 27 Oct 2005 02:50:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28151;
	Thu, 27 Oct 2005 02:49:51 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EV1ng-0003GQ-QL; Thu, 27 Oct 2005 03:03:50 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EV1aM-00071x-7r; Thu, 27 Oct 2005 02:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EV1aM-00071x-7r@newodin.ietf.org>
Date: Thu, 27 Oct 2005 02:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-04.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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		: Presence Authorization Rules
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-presence-rules-04.txt
	Pages		: 27
	Date		: 2005-10-26
	
Authorization is a key function in presence systems.  Authorization
   policies, also known as authorization rules, specify what presence
   information can be given to which watchers, and when.  This
   specification defines an Extensible Markup Language (XML) document
   format for expressing presence authorization rules.  Such a document
   can be manipulated by clients using the XML Configuration Access
   Protocol (XCAP), although other techniques are permitted.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-04.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-rules-04.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-rules-04.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: <2005-10-26192607.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-rules-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-rules-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-26192607.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 Thu Oct 27 08:05:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EV6VS-00077S-1H; Thu, 27 Oct 2005 08:05:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6VO-00076P-34
	for simple@megatron.ietf.org; Thu, 27 Oct 2005 08:05:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24592
	for <simple@ietf.org>; Thu, 27 Oct 2005 08:04:57 -0400 (EDT)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV6ik-0008BM-8c
	for simple@ietf.org; Thu, 27 Oct 2005 08:19:02 -0400
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
	j9RC1IPf026278; Thu, 27 Oct 2005 15:01:26 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Oct 2005 15:05:06 +0300
Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 27 Oct 2005 15:05:06 +0300
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
	j9RC55L08921; Thu, 27 Oct 2005 15:05:05 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 4DBF293B6A; Thu, 27 Oct 2005 15:05:05 +0300 (EEST)
Message-ID: <4360C271.30702@nokia.com>
Date: Thu, 27 Oct 2005 15:05:05 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-08.txt
References: <E1EUrHf-00074h-QJ@newodin.ietf.org>
In-Reply-To: <E1EUrHf-00074h-QJ@newodin.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Oct 2005 12:05:06.0295 (UTC)
	FILETIME=[AB6B8870:01C5DAEE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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		: The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
>	Author(s)	: J. Rosenberg
>	Filename	: draft-ietf-simple-xcap-08.txt
>	Pages		: 66
>	Date		: 2005-10-26
>	
>This specification defines the Extensible Markup Language (XML)
>   Configuration Access Protocol (XCAP).  XCAP allows a client to read,
>   write and modify application configuration data, stored in XML format
>   on a server.  XCAP maps XML document sub-trees and element attributes
>   to HTTP URIs, so that these components can be directly accessed by
>   HTTP.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-08.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-simple-xcap-08.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-simple-xcap-08.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Simple mailing list
>Simple@ietf.org
>https://www1.ietf.org/mailman/listinfo/simple
>  
>
Some nits/questions?

In 6.3 extension selector is missing repitition ? = 1*(%x00-2e / %x30-ff)
Do you thus mean that an XCAP extension (like multi-insert) extending 
this BNF does not have to do any corresponding IANA registrations ?

Later in 6.3 : "elements with namespace attributes", XPath specs don't 
describe anything about namespace attributes, but instead systematically 
about namespace nodes.

Also later in 6.3: instead of sentencies: "Note that the default 
namespace..." and "If the attribute name in the attribute sel..."
 From XPath 2.0:
"An unprefixed attribute QName is in no namespace."

In 6.4 Namespace Bindings for the Selector:
namespace uris are still within quotation marks: remove %22 chars

In 8.2.3 remove additional <figure><artwork>'s

In 10 Namespace Binding Format: xmlns scheme does not use quotation marks

In 11.2 there's no extension point in error schema, might be worth adding.

In 12.2 <xcap-caps> is extensible with xs:any but processContents="lax" 
is missing which might have been the intention

In 13 Examples:

HTTP/1.1 200 OK
Etag: "wwhha"
Content-Type: application/resource-lists+xml

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
  <list name="friends">
  <entry uri="sip:bob@example.com">
  <display-name>Bob Jones</display-name>
</entry></list>
</resource-lists>

thanks,
Jari


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



From simple-bounces@ietf.org Thu Oct 27 08:07:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EV6X8-00083j-4c; Thu, 27 Oct 2005 08:07:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6X6-00080s-0r
	for simple@megatron.ietf.org; Thu, 27 Oct 2005 08:07:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24674
	for <simple@ietf.org>; Thu, 27 Oct 2005 08:06:43 -0400 (EDT)
Received: from [203.101.112.21] (helo=mail2.sonimtech.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV6kQ-0008E6-3p
	for simple@ietf.org; Thu, 27 Oct 2005 08:20:48 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] XCAP namespace conundrum - another approach?
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 27 Oct 2005 17:39:55 +0530
Message-ID: <E7F5A43EEB6E7C42A08C041BDEB90A5305B0A7@mail2.sonimtech.com>
Thread-Topic: [Simple] XCAP namespace conundrum - another approach?
Thread-Index: AcXa71e7l2OsBFPbS5CxMXqYuySYmA==
From: "Ramalakshmi V. Gunturi" <ramagv@sonimtech.com>
To: <simple@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Hi,

Is this possible to have this scenario.=20

We make it mandatory to use the namespaces and the prefixes as defined =
in the XCAP standard.
Now, when we have to PUT an XML fragment that has namespace prefixes, =
then we can mention the namespace as an attribute in the top element of =
the payload.

When the server receives this request, it should ignore the namespace =
definition attribute and process the remaining part of the payload.=20

Ex:
	PUT /resource-lists/users/foo/index.xml
=09
	<rl:entry xmlns:rl=3D"urn:ietf:params:xml:ns:rls-services" =
uri=3D"sip:foo@example.com">
		<rl:display-name>Foo</rl:display-name>
	</rl:entry>

Note: This will only work if the namespaces and prefixes are followed as =
mentioned in the XCAP standard.


Thanks & Regards,
Rama


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



From simple-bounces@ietf.org Thu Oct 27 10:00:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EV8Ie-0004MW-C8; Thu, 27 Oct 2005 10:00:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Ic-0004MR-J7
	for simple@megatron.ietf.org; Thu, 27 Oct 2005 10:00:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01149
	for <simple@ietf.org>; Thu, 27 Oct 2005 09:59:54 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8Vw-0002yp-Gi
	for simple@ietf.org; Thu, 27 Oct 2005 10:14:00 -0400
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
	j9RDxtgw007093; Thu, 27 Oct 2005 16:59:58 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Oct 2005 16:59:57 +0300
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 27 Oct 2005 16:59:57 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j9RDxuj28621; Thu, 27 Oct 2005 16:59:56 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 4BDA493B6A; Thu, 27 Oct 2005 16:59:56 +0300 (EEST)
Message-ID: <4360DD5C.9080402@nokia.com>
Date: Thu, 27 Oct 2005 16:59:56 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-02.txt
References: <E1EUUo5-0007jy-Tz@newodin.ietf.org>
In-Reply-To: <E1EUUo5-0007jy-Tz@newodin.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Oct 2005 13:59:57.0359 (UTC)
	FILETIME=[B6D073F0:01C5DAFE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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) Document
>                          Format for Indicating A Change in XML 
>                          Configuration Access  Protocol (XCAP) Resources
>	Author(s)	: J. Rosenberg
>	Filename	: draft-ietf-simple-xcap-diff-02.txt
>	Pages		: 13
>	Date		: 2005-10-25
>	
>This specification defines a document format that can be used to
>   indicate that a change has occurred in a document managed by the
>   Extensible Markup Language (XML) Configuration Access Protocol
>   (XCAP).  This format indicates the document that has changed and its
>   former and new entity tags.  XCAP diff documents can be delivered to
>   clients using a number of means, including the Session Initiation
>   Protocol (SIP) event package for configuration data.  By subscribing
>   to this event package, clients can learn about document changes made
>   by other clients.  The XCAP diff format is extensible, so that
>   additional information, such as a description of the actual change,
>   can be included.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-02.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-simple-xcap-diff-02.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-simple-xcap-diff-02.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Simple mailing list
>Simple@ietf.org
>https://www1.ietf.org/mailman/listinfo/simple
>  
>
As already discussed in Paris, using multipart/related would be imo the 
only reasonable way to retrieve (==get ) xcap resources (==documents) 
with only sip (as embedding xml docs within other xml doc isn't possible 
in practice).  That is,  you'd have separate metadata (including ETags) 
and actual xml documents within multipart content type. So imo, this 
spec should describe that in addition to actual xml-patching (which is 
another interesting issue ;)).  Given this, I cannot see any fast 
progress. So, it is still my preference that the base xcap should just 
define the <xcap-etags> content type in order to remove the dependancy 
on this spec.
br,
Jari

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



From simple-bounces@ietf.org Thu Oct 27 10:15:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EV8Xq-0002EV-TS; Thu, 27 Oct 2005 10:15:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Xo-0002ED-QN
	for simple@megatron.ietf.org; Thu, 27 Oct 2005 10:15:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02240
	for <simple@ietf.org>; Thu, 27 Oct 2005 10:15:37 -0400 (EDT)
Received: from theater-sate.de ([81.169.138.67]
	helo=h93074.serverkompetenz.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8lA-0003XN-7y
	for simple@ietf.org; Thu, 27 Oct 2005 10:29:42 -0400
Received: from coyote (coyote.mmweg.RWTH-Aachen.DE [134.130.118.117])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by h93074.serverkompetenz.net (Postfix) with ESMTP id E534924C6A;
	Thu, 27 Oct 2005 16:15:38 +0200 (CEST)
From: Sebastian Ley <sebastian@withouthat.org>
To: simple@ietf.org
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using
	only the XML fragment body.
Date: Thu, 27 Oct 2005 16:15:34 +0200
User-Agent: KMail/1.8.2
References: <1AF90E65795A3D45AA116B9264B4DAAF029D872D@SELDMSX01.corpusers.net>
	<435F05F6.2010505@cisco.com> <435F75BC.7010800@nokia.com>
In-Reply-To: <435F75BC.7010800@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510271615.35513.sebastian@withouthat.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

* Jari Urpalainen wrote:

> E.g. I am personally much more worried
> about the case where you'll have many apps editing the same doc, as
> you'll have no locks in xcap (== not a proposal to add one, no)

Well, at least singleton commits can be protected with an HTTP If-Match. This 
is no replacement for transactions, but I had not the impression that this 
was in scope for XCAP...

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

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



From simple-bounces@ietf.org Thu Oct 27 13:03:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVBAF-0004YS-0Z; Thu, 27 Oct 2005 13:03:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBAC-0004Xr-RF
	for simple@megatron.ietf.org; Thu, 27 Oct 2005 13:03:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15689
	for <simple@ietf.org>; Thu, 27 Oct 2005 13:03:23 -0400 (EDT)
Received: from seldrel01.sonyericsson.com ([212.209.106.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBNY-0003u9-Gr
	for simple@ietf.org; Thu, 27 Oct 2005 13:17:31 -0400
Received: from seldrel01.sonyericsson.com(212.209.106.2) by
	seldrel01.sonyericsson.com via smtp
	id 1a82_9c6713c4_470b_11da_80b1_0002b3a9a21a;
	Thu, 27 Oct 2005 19:03:36 +0200
Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by
	seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Oct 2005 19:03:17 +0200
Received: from seldcon01.corpusers.net ([10.129.0.26]) by
	seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Oct 2005 19:03:17 +0200
Received: from seldefe01.corpusers.net ([10.129.0.199]) by
	seldcon01.corpusers.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Oct 2005 19:03:17 +0200
Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by
	seldefe01.corpusers.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 27 Oct 2005 19:03:16 +0200
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] Re: A proposal for fixing the xcap schema problem
	andrelated issues
Date: Thu, 27 Oct 2005 19:03:16 +0200
Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF041BEB6C@SELDMSX01.corpusers.net>
Thread-Topic: [Simple] Re: A proposal for fixing the xcap schema problem
	andrelated issues
Thread-Index: AcXZ4odLRrBk8nU6RzC+USGxqXfxjwBNQ0FQ
From: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>,
	"Sebastian Ley" <sebastian@withouthat.org>
X-OriginalArrivalTime: 27 Oct 2005 17:03:16.0589 (UTC)
	FILETIME=[52DDC1D0:01C5DB18]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Content-Transfer-Encoding: quoted-printable
Cc: "Gulin, Jens" <Jens.Gulin@sonyericsson.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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

>>=20
>> Together with a former suggestion of Per Hyttfors who proposed to=20
>> solve the namespace querying for GETs with XML Canonicalisation
>> (http://www.ietf.org/mail-archive/web/simple/current/msg05728.html)=20
>> that would make client implementations very simple and put all=20
>> namespace resolving "burden" on the server. That sounds like=20
>a good idea to me.
>
>I'll be responding to that note in a moment. Unfortunately I=20
>don't follow the proposal; I'm not an expert in the=20
>canonicalization spec. Can you or Per summarize the idea?
>
>Thanks,
>Jonathan R.
>

Another attempt to explain my idea, using exclusive Canonicalization to
maintain each xml-fragment in a valid namespace scope:


When the server extracts an XML fragment from the document and separate
the selected node from its parent the server should include the omitted
namespace bindings so that the selected node's namespace context remain
valid. This is exactly what is achieved with exclusive XML
Canonicalization, but could also be accomplished with "normal" XML
Canonicalization, the only difference is that the exclusive version
excludes bindings that is not in use by the selected node and its
children.

The proposal is to demand that the server can respond with an XML
fragment body on the exclusive XML Canonicalization form that will
contain the elements and always a valid namespace context.=20


This could be accomplished by changing the current form of the mime-type
"application/xcap-el+xml", or if compatibility with current
specification is of interest, as Jari has suggested before, by
introducing a new mime-type that a client can request instead.

One important thing to be aware of when receiving fragments that is in
exclusive XML Canonicalization form is that not only will all the
required namespace bindings be included, but the whole fragment will
follow the rules of Canonicalization. =20
Hence the data in the fragment will be logically equivalent with the
corresponding part of the server document, however it will vary in
physical representation as the fetched fragment's representation will be
on the canonical form.

However I don't see that this could cause a problem, my understanding of
the XCAP specification is that there is nothing that requires that the
cached copy is bitwise identical to the server document.


Example:

The default ns for the AUID is "ns1". And the server document looks like
this:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<foo:root xmlns:foo=3D"ns1" xmlns:bar=3D"ns2">
  <foo:element>
    <bar:element>
      <bar:child attr=3D"value" b:attr=3D"value" xmlns:b=3D"ns3"/>
    </bar:element>
  </foo:element>
</foo:root>


This request:

GET ../~~/root/element/

will with this change return this:

<foo:element xmlns:bar=3D"ns2" xmlns:foo=3D"ns1">
  <bar:element >
    <bar:child xmlns:b=3D"ns3" attr=3D"value" =
b:attr=3D"value"></bar:child>
  </bar:element>
</foo:element>

instead of this, as the current specification returns:

<foo:element>
  <bar:element>
    <bar:child attr=3D"value" b:attr=3D"value" xmlns:b=3D"ns3"/>
  </bar:element>
</foo:element>

Clearly the Canonicalization allows the reader to understand what both
"foo" and "bar" is, in a way that the current specification doesn't.


As I see it, the only real problem is the GET case, the PUT case is not
a problem since you can always add the additional required namespace
bindings in your request to the server to make the fragment maintain a
valid namespace context. Some could argue that it will fragment the
server document with tons of superfluous namespace declarations taking
up unnecessary data space and that is of course correct.

Something that could minimize the superfluous namespace declarations
created by such PUT requests as well as making the cached document copy
bitwise the same as the server document is to always keep the server
document (as well as any client copy) in canonical form. The server only
needs to do XML Canonicalization after the addition of new data. The
strength of minimizing superfluous namespace declarations depends
heavily on where the bindings are in the document as well as if new
prefixes are introduced.



Conclusion:

The strength of this proposal:

1. No need for multiple requests to do one thing.
2. Requires very little change of the current specification.
3. The response could be a new mime-type leaving the current
"application/xcap-el+xml" as it is today.


The weakness of this proposal:

1. The server document can still be filled with superfluous namespace
declarations by clients that do not cache the server document.


Regards,

Per



Per Hyttfors=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
_________________________________________________________


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



From simple-bounces@ietf.org Thu Oct 27 15:50:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVDlN-0007gB-GS; Thu, 27 Oct 2005 15:50:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVDlD-0007al-Qb; Thu, 27 Oct 2005 15:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25287;
	Thu, 27 Oct 2005 15:49:48 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EVDyd-0000dO-Od; Thu, 27 Oct 2005 16:03:56 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EVDlC-0006PA-F3; Thu, 27 Oct 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EVDlC-0006PA-F3@newodin.ietf.org>
Date: Thu, 27 Oct 2005 15:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-05.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=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		: User Agent Capability Extension to  Presence Information Data Format (PIDF)
	Author(s)	: M. Lonnfors, K. Kiss
	Filename	: draft-ietf-simple-prescaps-ext-05.txt
	Pages		: 29
	Date		: 2005-10-27
	
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 RFC3840 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-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-prescaps-ext-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-prescaps-ext-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-10-27105745.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-prescaps-ext-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-prescaps-ext-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-10-27105745.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 Thu Oct 27 17:21:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVFBI-0007k2-VU; Thu, 27 Oct 2005 17:21:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFBH-0007iH-4O
	for simple@megatron.ietf.org; Thu, 27 Oct 2005 17:21:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18009
	for <simple@ietf.org>; Thu, 27 Oct 2005 17:20:46 -0400 (EDT)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVFOg-00017z-01
	for simple@ietf.org; Thu, 27 Oct 2005 17:34:56 -0400
Received: from [192.168.0.103] (c-24-1-67-0.hsd1.tx.comcast.net [24.1.67.0])
	(authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j9RLKmKD075422
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <simple@ietf.org>; Thu, 27 Oct 2005 16:20:49 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v734)
Content-Transfer-Encoding: 7bit
Message-Id: <E9F5D821-73EF-4C79-B707-F2C107499BA2@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Simple WG <simple@ietf.org>
From: Robert Sparks <rjsparks@nostrum.com>
Date: Thu, 27 Oct 2005 16:20:50 -0500
X-Mailer: Apple Mail (2.734)
Received-SPF: pass (nostrum.com: 24.1.67.0 is authenticated by a trusted
	mechanism)
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Subject: [Simple] Agenda SIMPLE IETF64
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Here is the current working agenda.
It will show up on the official agenda pages shortly.

This is, as always, subject to change.

If you are a token holder below, please let me know if I missed
any pointers to reference material.

Thanks,

RjS

--------------------------
SIMPLE - IETF64
Friday November 11
0900-1130

Please note that geopriv is making a special effort to close out
common-policy during their session - please attend that session.

0900-0915 Administrivia

0915-0945 Where we're going with XCAP core (Jonathan)
   See the thread "A proposal for fixing the xcap schema problem
   and related issues"

0945-1000 Adjusting to the geopriv common-policy discussion (Jonathan)
   draft-ietf-simple-presence-rules-04

1000-1030 Adjusting to what we learn at the XML-Patch-Ops BOF (Aki)
   draft-ietf-simple-partial-pidf-format-05
   draft-ietf-simple-partial-notify-06
   draft-ietf-simple-partial-publish-03

1030-1045 Closing on a path forward for xcap dif (Jonathan)
   draft-ietf-simple-xcap-diff-02
   draft-rosenberg-simple-xcap-change-log-00

1045-1100 IMDN (Eric)
   draft-burger-simple-imdn-02

1100-1110 draft-mahy-simple-xcap-profile-00 (Rohan)
1110-1120 draft-wang-simple-presence-ril-00 (Xiao)

1120-1130 AOB


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



From simple-bounces@ietf.org Fri Oct 28 06:00:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVR2a-0002fS-RB; Fri, 28 Oct 2005 06:00:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVR2Z-0002eP-EQ; Fri, 28 Oct 2005 06:00:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04857;
	Fri, 28 Oct 2005 06:00:34 -0400 (EDT)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EVRG4-0008VX-CQ; Fri, 28 Oct 2005 06:14:51 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j9S9uxu6029186; Fri, 28 Oct 2005 12:57:00 +0300
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 28 Oct 2005 13:00:46 +0300
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 28 Oct 2005 13:00:44 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j9SA0jj08222; Fri, 28 Oct 2005 13:00:45 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 10ADB93B6A; Fri, 28 Oct 2005 13:00:45 +0300 (EEST)
Message-ID: <4361F6CC.5010602@nokia.com>
Date: Fri, 28 Oct 2005 13:00:44 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simple WG <simple@ietf.org>, sipping@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Oct 2005 10:00:44.0435 (UTC)
	FILETIME=[7637CE30:01C5DBA6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [Simple] xml-patch BoF agenda requests
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi all!

If you have any agenda requests for xml-patch BoF meeting in Vancouver, 
please send them to Lisa, who's chairing the session.

--Jari

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



From simple-bounces@ietf.org Fri Oct 28 08:52:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVTiN-0004o1-NB; Fri, 28 Oct 2005 08:52:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTiL-0004no-LZ
	for simple@megatron.ietf.org; Fri, 28 Oct 2005 08:52:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12300
	for <simple@ietf.org>; Fri, 28 Oct 2005 08:51:52 -0400 (EDT)
Received: from smtp8.clb.oleane.net ([213.56.31.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVTvs-0004Qt-2Q
	for simple@ietf.org; Fri, 28 Oct 2005 09:06:11 -0400
Received: from Pavillonquatre ([194.3.133.88]) (authenticated)
	by smtp8.clb.oleane.net with ESMTP id j9SCLOxL022054
	for <simple@ietf.org>; Fri, 28 Oct 2005 14:21:24 +0200
Message-Id: <200510281221.j9SCLOxL022054@smtp8.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <simple@ietf.org>
Date: Fri, 28 Oct 2005 14:51:33 +0200
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcXbvlM9fLBv9AEGQIeg6OJXdGWjmw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Subject: [Simple] 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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1963447348=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1963447348==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0175_01C5DBCF.190490D0"

This is a multi-part message in MIME format.

------=_NextPart_000_0175_01C5DBCF.190490D0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

The third edition of the WiMAX Summit 2006, the most important European
event, will be held on February 21 to 24 at the Sofitel Bercy Hotel in
Paris. 

The conference will largely be devoted to case studies presented by both
incumbent and new entrant operators who have set up WiMAX infrastructures.

 

All details at:

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

 


------=_NextPart_000_0175_01C5DBCF.190490D0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The third edition of the&nbsp;<strong><b><font
face=3DArial><span style=3D'font-family:Arial'>WiMAX Summit =
2006</span></font></b></strong>,
the most important European event,&nbsp;will be held on <strong><b><font
face=3DArial><span style=3D'font-family:Arial'>February 21 to =
24</span></font></b></strong>
at the Sofitel Bercy Hotel in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Paris</st1:City></st1:place>.
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The conference will largely be devoted to case
studies presented by both incumbent and new entrant operators who have =
set up
WiMAX infrastructures.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>All details at:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.upperside.fr/wimax2006/wimax2006intro.htm"
title=3D"http://www.upperside.fr/wimax2006/wimax2006intro.htm"><span =
lang=3DEN-GB>http://www.upperside.fr/wimax2006/wimax2006intro.htm</span><=
/a></span></font><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0175_01C5DBCF.190490D0--



--===============1963447348==
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

--===============1963447348==--





From simple-bounces@ietf.org Fri Oct 28 10:39:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVVNk-0006K9-2H; Fri, 28 Oct 2005 10:39:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVNi-0006Jz-P9
	for simple@megatron.ietf.org; Fri, 28 Oct 2005 10:38:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20678
	for <simple@ietf.org>; Fri, 28 Oct 2005 10:38:42 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVbI-0007k1-7z
	for simple@ietf.org; Fri, 28 Oct 2005 10:53:01 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2005 10:38:49 -0400
X-IronPort-AV: i="3.97,263,1125892800"; 
	d="scan'208"; a="74623909:sNHT24953628"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9SEc82b026277; 
	Fri, 28 Oct 2005 10:38:46 -0400 (EDT)
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);
	Fri, 28 Oct 2005 10:38:26 -0400
Received: from [192.168.1.100] ([10.86.242.243]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 28 Oct 2005 10:38:25 -0400
Message-ID: <436237E1.6070100@cisco.com>
Date: Fri, 28 Oct 2005 10:38:25 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
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: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] Agenda SIMPLE IETF64
References: <E9F5D821-73EF-4C79-B707-F2C107499BA2@nostrum.com>
In-Reply-To: <E9F5D821-73EF-4C79-B707-F2C107499BA2@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Oct 2005 14:38:25.0608 (UTC)
	FILETIME=[410D0C80:01C5DBCD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

One fix:

Robert Sparks wrote:

> Here is the current working agenda.
> It will show up on the official agenda pages shortly.
> 
> This is, as always, subject to change.
> 
> If you are a token holder below, please let me know if I missed
> any pointers to reference material.
> 
> Thanks,
> 
> RjS
> 
> --------------------------
> SIMPLE - IETF64
> Friday November 11
> 0900-1130
> 
> Please note that geopriv is making a special effort to close out
> common-policy during their session - please attend that session.
> 
> 0900-0915 Administrivia
> 
> 0915-0945 Where we're going with XCAP core (Jonathan)
>   See the thread "A proposal for fixing the xcap schema problem
>   and related issues"

There is also the xcap draft update itself:
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-08.txt

Thanks,
Jonathan R.

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

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



From simple-bounces@ietf.org Fri Oct 28 16:24:36 2005
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 1EVamC-0001kh-JT; Fri, 28 Oct 2005 16:24:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EVam9-0001bo-2J
	for simple@megatron.ietf.org; Fri, 28 Oct 2005 16:24:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15988
	for <simple@ietf.org>; Fri, 28 Oct 2005 16:24:14 -0400 (EDT)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVazm-0003X0-Dv
	for simple@ietf.org; Fri, 28 Oct 2005 16:38:38 -0400
X-IronPort-AV: i="3.97,263,1125892800"; 
	d="scan'208"; a="21975765:sNHT40007996"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] MSRP with content indirection
Date: Fri, 28 Oct 2005 16:24:30 -0400
Message-ID: <330A23D8336C0346B5C1A5BB19666647017303FE@ATLANTIS.Brooktrout.com>
Thread-Topic: [Simple] MSRP with content indirection
Thread-Index: AcXaQE+MiZtOcrTzQ2S0GEI1AY6cKABqlcgA
From: "Eric Burger" <eburger@brooktrout.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>, <Markus.Isomaki@nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is one of those weird situations where we probably need a new draft
that is 99% "what he said."

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Wednesday, October 26, 2005 11:17 AM
To: Markus.Isomaki@nokia.com
Cc: fluffy@cisco.com; Eric Burger; ben@estacado.net; rohan@ekabal.com;
simple@ietf.org
Subject: Re: [Simple] MSRP with content indirection

Markus,

In general I think it is already covered. But there may be points of=20
interpretation that would be well served by writing something down=20
someplace.

In your example, I would interpret message/external-body as a wrapper=20
type. So in your example, it would be wrong to use it to wrap a jpeg. To

make it right, I think one of the following should be used in the=20
offer/answer:

     a=3Daccept-types:message/external-body,image/jpg

or

     a=3Daccept-types:message/external-body
     a=3Daccept-wrapped-types:image/jpg

	Paul

Markus.Isomaki@nokia.com wrote:
> Hi,
>=20
> I would like to understand how well MSRP and SIP content indirection
work together by default. I.e., if one of the parties indicates in SDP
for MSRP...
>=20
>    a=3Daccept-types:message/external-body
>=20
> ...is it possible for the other party to send something like this...
>=20
>    MSRP a786hjs2 SEND
>    To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
>    From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
>    Message-ID: 87652
>    Byte-Range: ...
>    Content-Type: message/external-body;
>       ACCESS-TYPE=3DURL;
>       URL=3D"http://www.example.net/party/06/2002/announcement";
>       EXPIRATION=3D"Sat, 20 Jun 2002 12:00:00 GMT";
>       size=3D231
>    Content-Length: ...
>=20
>    Content-Type: image/jpg
>    Content-Disposition: ...
>    Content-ID: <4e5562cd1214427d@example.net>
>=20
> ...so that the semantics would be clear and unambiguous?
>=20
> In other words, is this possible by just combining the two specs, or
is there need to write an additional short draft to cover this?
>=20
> Markus=20
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>=20

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



From simple-bounces@ietf.org Mon Oct 31 16:33:14 2005
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 1EWhHG-0000Kd-GC; Mon, 31 Oct 2005 16:33:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhHB-0000Jy-Vr
	for simple@megatron.ietf.org; Mon, 31 Oct 2005 16:33: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 QAA12021;
	Mon, 31 Oct 2005 16:32:50 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EWhVS-0007XW-6R; Mon, 31 Oct 2005 16:47:54 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1EWhH8-0000OT-1D; Mon, 31 Oct 2005 16:33:06 -0500
Content-Type: text/plain
Mime-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>,
	Hisham Khartabil <hisham.khartabil@telio.no>
From: Dean Willis(OMA) <dean.willis@softarmor.com>
Message-Id: <E1EWhH8-0000OT-1D@newodin.ietf.org>
Date: Mon, 31 Oct 2005 16:33:06 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA12021
Cc: Ted Hardie <hardie@qualcomm.com>, statements@ietf.org,
	Scott Hollenbeck <shollenbeck@verisign.com>,
	Krisztian Kiss <krisztian.kiss@nokia.com>, simple@ietf.org
Subject: [Simple] Submission of New Liaison Statement,
 "OMA PAG LS on Partial features in Presence" 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Title: OMA PAG LS on Partial features in Presence
Submission Date: 2005-10-31
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det=
ail.cgi?detail_id=3D145=20
Please reply by 2005-11-12

From: Dean Willis(OMA) <dean.willis@softarmor.com>
To: IETF SIMPLE Working Group(Robert Sparks <rjsparks@nostrum.com>, Hisha=
m Khartabil <hisham.khartabil@telio.no>)
Cc: Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>
simple@ietf.org
Reponse Contact: Krisztian Kiss <krisztian.kiss@nokia.com>
Technical Contact: Krisztian Kiss <krisztian.kiss@nokia.com>
Purpose: For action=20
Body: 1	Overview

The OMA SIMPLE Presence 1.0 enabler has dependencies on IETF drafts draft=
-ietf-simple-partial-publish and draft-ietf-simple-partial-notify. Since =
both of these drafts normatively reference draft-urpalainen-simple-xml-pa=
tch-ops-01, the OMA SIMPLE Presence 1.0 enabler is also implicitly depend=
ent on this draft.

The OMA PAG Working Group is scheduled to approve the OMA SIMPLE Presence=
 1.0 enabler by end of this year. Because of this tight schedule, the OMA=
 PAG WG is seeking your guidance about the expected progress on this draf=
t.=20

The OMA PAG WG kindly requests the IETF SIMPLE WG to provide feedback abo=
ut the status of open issues on XML Patch Operations and the expectation =
on their resolutions. The response from IETF SIMPLE WG could be a key dec=
ision factor on PAG WG=E2=80=99s future decision on how to proceed with P=
artial Publication and Partial Notification procedures in OMA SIMPLE Pres=
ence 1.0 enabler.=20

2	Requested Action(s)

=E2=80=A2	The OMA PAG WG kindly requests the IETF SIMPLE WG to provide fe=
edback about the status of open issues on XML Patch Operations and the ex=
pectation on their resolutions. =20

The OMA PAG WG would like to thank the IETF SIMPLE WG for their considera=
tion and response to this request and we look forward to future opportuni=
ties to work together.

Kind regards,
The OMA PAG WG
Contact: Krisztian Kiss, krisztian.kiss@nokia.com
Attachment(s):
No document has been attached



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



From simple-bounces@ietf.org Mon Oct 31 16:58:15 2005
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 1EWhfT-0005Q6-94; Mon, 31 Oct 2005 16:58:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhfQ-0005Oi-O9
	for simple@megatron.ietf.org; Mon, 31 Oct 2005 16:58:12 -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 QAA13398
	for <simple@ietf.org>; Mon, 31 Oct 2005 16:57:52 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWhtf-0002Cm-T9
	for simple@ietf.org; Mon, 31 Oct 2005 17:12:57 -0500
Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9VM3NBw029253
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <simple@ietf.org>; Mon, 31 Oct 2005 16:03:23 -0600
Mime-Version: 1.0 (Apple Message framework v734)
Content-Transfer-Encoding: 7bit
Message-Id: <35E4A9E7-8F4F-4E60-AC47-AD9728C424E3@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Simple WG <simple@ietf.org>
From: Dean Willis <dean.willis@softarmor.com>
Date: Mon, 31 Oct 2005 15:58:09 -0600
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: [Simple] PMA PAG Liaison 0051 on XCAP Namespace Issues 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


The ITEF "upload tool" is supposed to have sent out an announcement  
(it worked for the 052 statement) but  I haven't seen it yet. It may  
appear later.

In the meantime, please see:

https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=144


--
Dean Willis
IETF liaison manager to OMA

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



From simple-bounces@ietf.org Mon Oct 31 17:10:05 2005
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 1EWhqv-00005p-Kv; Mon, 31 Oct 2005 17:10:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhqt-00005B-Of
	for simple@megatron.ietf.org; Mon, 31 Oct 2005 17:10: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 RAA15182
	for <simple@ietf.org>; Mon, 31 Oct 2005 17:09:43 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWi59-0003eK-4c
	for simple@ietf.org; Mon, 31 Oct 2005 17:24:48 -0500
Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9VMFCLM029321
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 31 Oct 2005 16:15:13 -0600
In-Reply-To: <35E4A9E7-8F4F-4E60-AC47-AD9728C424E3@softarmor.com>
References: <35E4A9E7-8F4F-4E60-AC47-AD9728C424E3@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <34DF3264-B678-4C29-A226-CF8CBB9195C8@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Simple] PMA PAG Liaison 0051 on XCAP Namespace Issues 
Date: Mon, 31 Oct 2005 16:09:57 -0600
To: Dean Willis <dean.willis@softarmor.com>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Whoops, that subject line should be "OMA", not PMA.

On Oct 31, 2005, at 3:58 PM, Dean Willis wrote:

>
> The ITEF "upload tool" is supposed to have sent out an announcement  
> (it worked for the 052 statement) but  I haven't seen it yet. It  
> may appear later.
>
> In the meantime, please see:
>
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=144
>
>
> --
> Dean Willis
> IETF liaison manager to OMA
>
> _______________________________________________
> 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 Oct 31 23:27:18 2005
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 1EWnjy-0003yA-Fp; Mon, 31 Oct 2005 23:27:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWnjw-0003xA-7n; Mon, 31 Oct 2005 23:27:16 -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 XAA09476;
	Mon, 31 Oct 2005 23:26:55 -0500 (EST)
Received: from marauder.andrew.com ([198.17.217.129])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EWnyD-0008MM-32; Mon, 31 Oct 2005 23:42:03 -0500
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 22:27:03 -0600
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
	E-mail Filter (4.7); Mon, 31 Oct 2005 22:27:03 -0600
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 22:27:01 -0600
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC0E3185C7@aopex5.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "ext Jonathan Rosenberg" <jdrosen@cisco.com>, <simple@ietf.org>
Date: Mon, 31 Oct 2005 22:26:17 -0600
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 01 Nov 2005 04:27:01.0052 (UTC)
	FILETIME=[810107C0:01C5DE9C]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: Comments: draft-rosenberg-simple-common-policy-caps-02
Thread-Index: AcXenGbcZFboL6yfRyy4idd22p8Hdw==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
Cc: geopriv@ietf.org
Subject: [Simple] Comments: draft-rosenberg-simple-common-policy-caps-02
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0673641630=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============0673641630==
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
Content-Transfer-Encoding: base64

SSd2ZSBjcm9zcy1wb3N0ZWQgdGhpcyBiZWNhdXNlIHRoZXJlIGFyZSBmb2xrcyBpbiBHRU9QUklW
IHdobyBhcmUgaW50ZXJlc3RlZC4NCg0KQ29tbWVudHMgZm9yOiBBbiBFeHRlbnNpYmxlIE1hcmt1
cCBMYW5ndWFnZSAoWE1MKSBSZXByZXNlbnRhdGlvbiBmb3INCkV4cHJlc3NpbmcgUHJlc2VuY2Ug
UG9saWN5IENhcGFiaWxpdGllcw0KKGRyYWZ0LXJvc2VuYmVyZy1zaW1wbGUtY29tbW9uLXBvbGlj
eS1jYXBzLTAyLnR4dCkNCg0KLS0gR2VuZXJhbA0KDQooU3VtbWFyeTogVGhlIGRyYWZ0IGRlc2Ny
aWJlcyBhIG1lYW5zIG9mIGNvbnZleWluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGV2ZWwNCm9m
IHN1cHBvcnQgZm9yIGNvbW1vbi1wb2xpY3kgZmVhdHVyZXMuICBUaGlzIGluZm9ybWF0aW9uIGlz
IGNhcnJpZWQgd2l0aGluDQp0aGUgYm9keSBvZiBhIHBvbGljeSBkb2N1bWVudCBhbmQgaXMgcmVw
cmVzZW50ZWQgYnkgWE1MIGVsZW1lbnRzLiAgRWFjaA0KZmVhdHVyZSBpcyByZXByZXNlbnRlZCBi
eSBhbiBlbGVtZW50LCBhbmQgdGhlIHByZXNlbmNlIG9mIHRoaXMgZWxlbWVudA0KaW5kaWNhdGVz
IHN1cHBvcnQgZm9yIHRoYXQgZmVhdHVyZS4pDQoNClRoaXMgZHJhZnQgaXMgZXNzZW50aWFsIGlm
IGNvbW1vbi1wb2xpY3kgaXMgdG8gaGF2ZSBhbnkgbG9uZ2V2aXR5LiAgQXMNCnN0YXRlZCwgdGhl
IGJhc2ljIHNldCBvZiBmZWF0dXJlcyBwcm92aWRlZCBieSBjb21tb24tcG9saWN5IGFyZSBsaW1p
dGVkIC0gdGhlDQppZGVhIGJlaW5nIHRoYXQgaXQgaXMgZXh0ZW5kZWQgYnkgb3RoZXIgc3BlY2lm
aWNhdGlvbnMgb3IgdmVuZG9yIGV4dGVuc2lvbnMuDQpJZiB0aGlzIHNvcnQgb2YgbWl4ZWQgY29u
dGVudCBpcyBhbGxvd2VkLCBpdCBpcyB2ZXJ5IHVzZWZ1bCB0byBoYXZlIHNvbWUNCm1lYW5zIG9m
IGNvbW11bmljYXRpbmcgY2FwYWJpbGl0aWVzLg0KDQotLSBNb2RlIG9mIG9wZXJhdGlvbg0KDQoo
U3VtbWFyeTogQSBjbGllbnQgbWF5IHF1ZXJ5IHRoZSBjYXBhYmlsaXRpZXMgb2YgYSBzZXJ2ZXIg
YnkgcmVxdWVzdGluZyBhDQpkb2N1bWVudCBiZWZvcmUgcHVibGlzaGluZyBhbnkgY29udGVudC4p
DQoNCkFzIGZhciBhcyB0aGlzIHVzYWdlIGlzIGNvbmNlcm5lZCwgSSBkb24ndCBhbnRpY2lwYXRl
IGFueSBwcm9ibGVtcy4gIEVhY2gNCnByb3RvY29sIG5lZWRzIHRvIGhhdmUgYSBtZWFucyBvZiBy
ZXF1ZXN0aW5nIHRoaXMgZG9jdW1lbnQuDQoNCkkgd291bGQgYmUgYSBsaXR0bGUgc3RyaWN0ZXIg
d2l0aCByZWdhcmRzIHRvIHNwZWNpZnlpbmcgaG93IGEgY2xpZW50IHJldHJpZXZlDQp0aGUgZG9j
dW1lbnQgdGhvdWdoLiAgU3VnZ2VzdCB0aGF0IHlvdSBSRUNPTU1FTkQgdGhhdCBzZXJ2ZXJzIGRv
bid0IHJlbW92ZQ0KY2FwYWJpbGl0aWVzIC0gYSBwdWJsaXNoZWQgY2FwYWJpbGl0aWVzIGRvY3Vt
ZW50IGlzIGxpa2UgYSBwcm9taXNlLiAgQWxzbywNCmZvciBYQ0FQLCBJIGFzc3VtZSB0aGF0IHRo
ZSBzdGFuZGFyZCBIVFRQIG1ldGhvZHMgY2FuIGJlIHVzZWQgdG8gc2V0IGV4cGlyeQ0KdGltZXMg
YW5kIGNoZWNrIGZvciBjaGFuZ2VzIChFVGFnLCBJZi1Nb2RpZmllZC1TaW5jZSwgZXRjLi4uKS4g
IFRoYXQgc2hvdWxkDQpzdWZmaWNlIGZvciBtb3N0IGNsaWVudHMuDQoNCi0tIFhNTCBkb2N1bWVu
dCBzdHJ1Y3R1cmUNCg0KKFN1bW1hcnk6IFRoZSBkb2N1bWVudCBzdHJ1Y3R1cmUgY2xvc2VseSBt
aXJyb3JzIHRoZSBjb21tb24tcG9saWN5IHN0cnVjdHVyZQ0KLSB0aGUgcHJlc2VuY2Ugb2YgYW4g
ZWxlbWVudCBpbmRpY2F0ZXMgc3VwcG9ydCBmb3IgdGhhdCBlbGVtZW50LikNCg0KSSBoYXZlIGEg
cHJvYmxlbSB3aXRoIHRoZSB3YXkgdGhhdCB0aGUgY2FwYWJpbGl0aWVzIGRvY3VtZW50IGlzIHN0
cnVjdHVyZWQuDQpJJ2xsIHByZXNlbnQgbXkgY3JpdGlxdWUsIHRoZW4gSSB3aWxsIHByb3Bvc2Ug
YSBmZXcgYWx0ZXJuYXRpdmVzLg0KDQpFbmNvZGluZyBkYXRhIHVzaW5nIGVsZW1lbnQgbmFtZXMg
aXMgLi4uIHVnbHkuICBFbGVtZW50IG5hbWVzIGluIGFuIFhNTA0KZG9jdW1lbnQgYXJlIGRlc2Ny
aXB0aXZlIG9mIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGRvY3VtZW50LCBub3QgdGhlIGRhdGEgdGhh
dA0KdGhlIGRvY3VtZW50IGNvbnZleXMuICBGb3IgZXhhbXBsZSwgaWYgSSB3YW50IHRvIGluZGlj
YXRlIHRoYXQgSSBzdXBwb3J0IHRoZQ0KY3A6aWRlbnRpdHkgZWxlbWVudCwgImNwOmlkZW50aXR5
IiBpcyBkYXRhLCBub3Qgc3RydWN0dXJlLg0KDQpUaGUgYmVzdCBhbmFsb2d5IHRoYXQgSSBjYW4g
dGhpbmsgb2Ygd291bGQgYmUgdG8gcHJvdG9jb2wgaGVhZGVycywgYW5kIEkNCmRvbid0IHRoaW5r
IHRoYXQgaXQncyB0b28gbXVjaCBvZiBhIHN0cmV0Y2guICBJbWFnaW5lIGlmIHRoZSBBbGxvdyBo
ZWFkZXIgaW4NClNJUCBhbmQgSFRUUCB3aGVyZSBpbnN0ZWFkIGltcGxlbWVudGVkIGFzIGEgc2Vy
aWVzIG9mIGhlYWRlcnM6IEFsbG93LUlOVklURSwNCkFsbG93LUFDSywgQWxsb3ctT1BUSU9OUywg
QWxsb3ctUFVCTElTSCwgLi4uDQoNCkkgdW5kZXJzdGFuZCB0aGF0IGluIHNvbWUgY2FzZXMsIHRo
ZSBsaW5lIGJldHdlZW4gc3RydWN0dXJlIGFuZCBkYXRhIGNhbg0KYmVjb21lIGJsdXJyZWQsIGJ1
dCB0aGlzIGRyYWZ0IHRha2VzIGl0IHRvbyBmYXIuICBJIGFsc28gYXBwcmVjaWF0ZSB0aGF0DQp0
aGVyZSBtYXkgYWxyZWFkeSBiZSBhIHByZWNlZGVudCBmb3IgdGhpcyBwcmFjdGljZTsgSSBoYXZl
IGV4YWN0bHkgdGhlIHNhbWUNCnByb2JsZW0gd2l0aCB0aG9zZSBkcmFmdHMsIEkgaG9wZSB0aGF0
IHRoZWlyIGF1dGhvcnMgcmVhZCB0aGlzLCB1bmRlcnN0YW5kDQphbmQgbWFrZSBzb21lIGNoYW5n
ZXMuDQoNClRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0sIHlvdSBoYXZlIHRvIHVuZGVyc3RhbmQg
aG93IGl0IGFycml2ZXMuICBNeSB0aGVvcnkNCmlzIHRoYXQgYW4gYXV0aG9yIG5lZWRzIHRvIGlu
ZGljYXRlIGEgc2V0IG9mIHBvc3NpYmxlIHZhbHVlcyBmb3IgYSBwYXJhbWV0ZXIuDQpJIGNhbiBk
ZWZpbmUgYSBzaW1wbGUgdHlwZSBpbiBzY2hlbWEgYXMgYW4gZXhhbXBsZToNCg0KICA8eHM6c2lt
cGxlVHlwZSBuYW1lPSJjb29raW5nVHlwZSI+DQogICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9Inhz
OnRva2VuIj4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iZnJpZWQiLz4NCiAgICAgIDx4
czplbnVtZXJhdGlvbiB2YWx1ZT0iYm9pbGVkIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFs
dWU9InBvYWNoZWQiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0ic2NyYW1ibGVkIi8+
DQogICAgPC94czpyZXN0cmljdGlvbj4NCiAgPC94czpzaW1wbGVUeXBlPg0KDQpIb3dldmVyLCB0
aGUgYWJvdmUgbGlzdCBwcm9iYWJseSBpc24ndCBleGhhdXN0aXZlOyBzb21lb25lIHdpbGwgaW5l
dml0YWJseQ0KZmluZCBhbm90aGVyIHdheSB0byBjb29rIGFuIGVnZyBhbmQgd2lsbCB0aGVuIHdh
bnQgdG8gdXNlIHRoYXQgdmFsdWUgaW5zdGVhZC4NClNvIEkgX2NvdWxkXyBqdXN0IGxvb3NlbiB0
aGUgc3RydWN0dXJlIGEgbGl0dGxlIGJpdCwgYnV0IHRoZSBlbnVtZXJhdGlvbg0KZWxlbWVudHMg
YXJlbid0IHVzZWZ1bCBhbnkgbW9yZToNCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJjb29raW5n
VHlwZSI+DQogICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnRva2VuIj4NCiAgICAgIDx4czpw
YXR0ZXJuIHZhbHVlPSJcdysiLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBs
ZVR5cGU+DQoNCkJ1dCB0aGVuLCBpdCBpc24ndCBleHBsaWNpdCB0aGF0ICJmcmllZCIgaXNuJ3Qg
YSB2YWxpZCB2YWx1ZS4gIEkgbGVhdmUgdGhvc2UNCndvcmRzIGluIHRoZSBzcGVjaWZpY2F0aW9u
IHRleHQsIGJ1dCBpdCBkb2Vzbid0IGxlYXZlIG1lIHdpdGggdGhlIHNhbWUNCnNhdGlzZnlpbmcg
ZmVlbGluZyB0aGF0IEkgaGF2ZSBwdXQgdGhlIGNvbnN0cmFpbnQgaW50byBzY2hlbWEuICBIZW5j
ZSB0aGUNCmZvbGxvd2luZyBzdHJ1Y3R1cmUgZXZvbHZlcywgd2hpY2ggc2VlbXMgdG8gc2F0aXNm
eToNCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iY29va2luZ1R5cGUiPg0KICAgIDx4czpjaG9p
Y2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJmcmllZCIgdHlwZT0ibXk6ZW1wdHlUeXBlIi8+
DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJib2lsZWQiIHR5cGU9Im15OmVtcHR5VHlwZSIvPg0K
ICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icG9hY2hlZCIgdHlwZT0ibXk6ZW1wdHlUeXBlIi8+DQog
ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzY3JhbWJsZWQiIHR5cGU9Im15OmVtcHR5VHlwZSIvPg0K
ICAgICAgPHhzOmFueSBuYW1lc3BhY2U9IiMjb3RoZXIiLz4NCiAgICA8L3hzOmNob2ljZT4NCiAg
PC94czpjb21wbGV4VHlwZT4NCg0KVGhpcyBsb29rcyBsaWtlIGl0IHNvbHZlcyB0aGUgcHJvYmxl
bSwgYW5kIGl0IG1vcmUtb3ItbGVzcyBkb2VzLCBidXQgdGhpcw0KbWVhbnMgdGhhdCB0aGUgZG9j
dW1lbnQgbm93IGhhcyBzdHJ1Y3R1cmFsIGluZm9ybWF0aW9uIHRoYXQgaGFzIHRvIGJlDQppbnRl
cnByZXRlZCBhcyBkYXRhLiAgSXQgaXMgbG9uZ2VyIGNsZWFyIHdoYXQgYSBkb2N1bWVudCBtZWFu
cyAtIGVtcHR5DQplbGVtZW50cyBpbmRpY2F0ZSBhbiBlbXB0eSBjb250YWluZXIgLSB3aGF0IGlu
IHRoaXMgaW5zdGFuY2UgaXMgaW5kaWNhdGVkIGJ5DQphbiBlbXB0eSA8ZnJpZWQvPiBlbGVtZW50
PyAgQXNpZGUgdGhhdCwgYSBjbGllbnQgdGhhdCBpbnRlcnByZXRzIHRoaXMNCmRvY3VtZW50IGJl
Y29tZXMgbW9yZSBjb21wbGV4LCBkb2N1bWVudHMgYmVjb21lIGEgbGl0dGxlIGxhcmdlci4NCg0K
SSBiZWxpZXZlIHRoYXQgaW4gdGhlc2UgY2FzZXMgaXQgaXMgYmV0dGVyIHRvIGxlYXZlIHRoZSBl
eHBsaWNpdCBjb250ZW50IG91dA0Kb2YgdGhlIHNjaGVtYSBhbmQgbWFrZSByZWNvbW1lbmRhdGlv
bnMgdXNpbmcgdGhlIHRleHQuDQoNCkFub3RoZXIgZXhhbXBsZSB0aGF0IGlzIGxlc3MgY2xlYXI6
DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9InNvbWVUeXBlIj4NCiAgICA8eHM6c2VxdWVuY2U+
DQogICAgICA8eHM6ZWxlbWVudCByZWY9InVuaW1wb3J0YW50Ii8+DQogICAgICA8eHM6ZWxlbWVu
dCBuYW1lPSJib29sZWFuRGF0YSIgdHlwZT0ibXk6ZW1wdHlUeXBlIiBtaW5PY2N1cnM9IjAiLz4N
CiAgICAgIDx4czplbGVtZW50IHJlZj0iaXJyZWxldmFudCIvPg0KICAgIDwveHM6c2VxdWVuY2U+
DQogIDwveHM6Y29tcGxleFR5cGU+DQoNClByZXNlbmNlIGluZGljYXRlcyBhIHZhbHVlIG9mICJ0
cnVlIi4gIEJ1dCBvbmNlIGFnYWluLCB3ZSBoYXZlIHN0cnVjdHVyZSBhbmQNCmNvbnRlbnQgbWl4
aW5nLiAgVGhlIHByb3BlciB0aGluZyB0byBkbyB3b3VsZCBiZSB0byBjaGFuZ2UgdGhlIHR5cGU6
DQoNCiAgPHhzOmVsZW1lbnQgbmFtZT0iYm9vbGVhbkRhdGEiIHR5cGU9InhzOmJvb2xlYW4iLz4N
Cg0KLi5vciBpZiB0aGUgYWJpbGl0eSB0byBvbWl0IHRoZSBkYXR1bSBpcyBpbXBvcnRhbnQsIGl0
IGNhbiBiZSBhbiBhdHRyaWJ1dGUNCndpdGggYSBkZWZhdWx0IHZhbHVlOg0KDQogIDx4czphdHRy
aWJ1dGUgbmFtZT0iYm9vbGVhbkRhdGEiIHR5cGU9InhzOmJvb2xlYW4iIGRlZmF1bHQ9ImZhbHNl
Ii8+DQoNCkkgdXN1YWxseSByZXNlcnZlIGF0dHJpYnV0ZXMgZm9yIG1ldGFkYXRhLCBtb2RpZmll
cnMgYW5kIHF1YWxpZmllcnMsIGFueQ0KY2hvaWNlIHdpbGwgZGVwZW5kIG9uIHRoZSBzcGVjaWZp
YyBnb2FscyB5b3UgaGF2ZSBpbiBtaW5kLg0KDQoNClNvIGJhY2sgdG8gdGhlIGlzc3VlIGF0IGhh
bmQsIEkgd291bGQgYmUgcmVtaXNzIG9mIG1lIHRvIHBvaW50IG91dCBwcm9ibGVtcw0Kd2l0aG91
dCBvZmZlcmluZyBzdWdnZXN0aW9ucywgc28gSSBhbSBnb2luZyB0byBwcm9wb3NlIGFuIGFsdGVy
bmF0aXZlLiAgWW91DQp3aWxsIGFjdHVhbGx5IHNlZSB0aGF0IHRoaXMgYXBwcm9hY2ggYWN0dWFs
bHkgZ29lcyBhbm90aGVyIHN0ZXAgYW5kIG1ha2VzIHRoZQ0KcHJvbGlmZXJhdGlvbiBvZiBjb21w
YW5pb24gZG9jdW1lbnRzIChsaWtlDQpkcmFmdC1ndWVudGhlci1nZW9wcml2LXBvbGljeS1jYXBz
LTAzKSB1bm5lY2Vzc2FyeSAtIHlvdSBvbmx5IG5lZWQgdG8NCnVuZGVyc3RhbmQgYSBkb2N1bWVu
dCBzcGVjaWZpZWQgaW4gdGhpcyBuYW1lc3BhY2UgdG8gdW5kZXJzdGFuZCB0aGUNCmNhcGFiaWxp
dGllcyBvZiB0aGUgc2VydmVyLiAgVGhpcyBoYXMgdGhlIGJlbmVmaXQgb2YgbWFraW5nIHRoZSBj
YXBhYmlsaXRpZXMNCmRvY3VtZW50IHNpZ25pZmljYW50bHkgbGVzcyBjb21wbGV4IHRoYW4gdGhl
IGFjdHVhbCBpbnN0YW5jZSBkb2N1bWVudCwNCnBhcnRpY3VsYXJseSBmcm9tIHRoZSBwZXJzcGVj
dGl2ZSBvZiBzcGVjaWZpY2F0aW9uLg0KDQpJIGhhdmUgc3BsaXQgdGhpcyBpbnRvIHR3byBsZXZl
bHMgb2Ygc3VwcG9ydC4gIFRoaXMgaXMgc29tZXdoYXQgcmVtaW5pc2NlbnQNCm9mIGNvbW1vbi1w
b2xpY3kgaW4gdGhhdCB0aGVyZSBhcmUgYW5hbG9ndWVzIG9mIDxvbmUvPiBhbmQgPG1hbnkvPi4g
IElmIHRoZQ0KZGlzdGluY3Rpb24gYmV0d2VlbiBjb25kaXRpb24sIGFjdGlvbiBhbmQgdHJhbnNm
b3JtYXRpb24gbmVlZHMgdG8gYmUNCnJldGFpbmVkLCBJIGhhdmUgYWRkZWQgYW4gZWxlbWVudCB0
aGF0IGNhbiBiZSB1c2VkIHRvIGVzdGFibGlzaCBhIGNvbnRleHQuDQoNClRoZXNlIHRoaW5ncyB0
ZW5kIHRvIGJlIGVhc2llc3QgdG8gZXhwbGFpbiBieSBleGFtcGxlIHNvIGhlcmUgaXMgbXkgZXhh
bXBsZQ0KZG9jdW1lbnQ6DQoNCiAgPHBvbGljeS1jYXBhYmlsaXRpZXMgeG1sbnM9InVybjppZXRm
OnBhcmFtczp4bWw6bnM6cG9saWN5LWNhcGFiaWxpdGllcyINCiAgICAgICAgICAgICAgICAgICAg
ICAgeG1sbnM6Y3A9InVybjppZXRmOnBhcmFtczp4bWw6bnM6Y29tbW9uLXBvbGljeSINCiAgICAg
ICAgICAgICAgICAgICAgICAgeG1sbnM6dnBwPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL3BvbGlj
eS1jYXBzLWV4Ij4NCiAgICA8c3VwcG9ydC1uYW1lc3BhY2UgbnM9InVybjppZXRmOnBhcmFtczp4
bWw6bnM6Y29tbW9uLXBvbGljeSIvPg0KDQogICAgPGNvbnRleHQgc2VsZWN0PSJjcDpjb25kaXRp
b25zIj4NCiAgICAgIDxzdXBwb3J0LW5hbWVzcGFjZSBucz0idXJuOmlldGY6cGFyYW1zOnhtbDpu
czpnZW9wcml2LXBvbGljeSINCiAgICAgICAgICAgICAgICAgICAgICAgICBzY2hlbWFMb2NhdGlv
bj0iZ2VvcHJpdi1wb2xpY3kueHNkIj4NCiAgICAgICAgPGV4Y2VwdD5jaXZpYy1sb2MtY29uZGl0
aW9uPC9leGNlcHQ+DQogICAgICAgIDxleGNlcHQ+Ly9AY3JzTmFtZVtzdHJpbmcoLikhPSJ1cm46
b2djOmRlZjpjcnM6RVBTRzo2LjY6NDMyNiJdPC9leGNlcHQ+DQogICAgICA8L3N1cHBvcnQtbmFt
ZXNwYWNlPg0KICAgICAgPHN1cHBvcnQ+dnBwOmhhcHB5PC9zdXBwb3J0Pg0KICAgIDwvY29udGV4
dD4NCg0KICAgIDxjb250ZXh0IHNlbGVjdD0iY3A6YWN0aW9ucyI+DQogICAgICA8c3VwcG9ydD52
cHA6bG9nPC9zdXBwb3J0Pg0KICAgIDwvY29udGV4dD4NCg0KICAgIDxjb250ZXh0IHNlbGVjdD0i
Y3A6dHJhbnNmb3JtYXRpb25zIj4NCiAgICAgIDxzdXBwb3J0LW5hbWVzcGFjZSBucz0idXJuOmll
dGY6cGFyYW1zOnhtbDpuczpnZW9wcml2LXBvbGljeSINCiAgICAgICAgICAgICAgICAgICAgICAg
ICBzY2hlbWFMb2NhdGlvbj0iZ2VvcHJpdi1wb2xpY3kueHNkIj4NCiAgICAgICAgPGV4Y2VwdD5j
aXZpYy1sb2MtdHJhbnNmb3JtYXRpb248L2V4Y2VwdD4NCiAgICAgIDwvc3VwcG9ydC1uYW1lc3Bh
Y2U+DQogICAgICA8c3VwcG9ydCBjaGlsZHJlbj0iZmFsc2UiPnZwcDptaW4tc2VjdXJpdHk8L3N1
cHBvcnQ+DQogICAgPC9jb250ZXh0Pg0KDQogIDwvcG9saWN5LWNhcGFiaWxpdGllcz4NCg0KVGhl
IGFib3ZlIGlzIGxhcmdlbHkgdGhlIHNhbWUgYXMgdGhhdCBnaXZlbiBpbiB0aGUgZG9jdW1lbnQs
IGJ1dCBpdCBhbHNvDQppbmNsdWRlcyBpbmRpY2F0ZXMgdGhhdCBnZW9wcml2LXBvbGljeSBpcyBz
dXBwb3J0ZWQgZm9yIGNvbmRpdGlvbnMgYW5kDQp0cmFuc2Zvcm1hdGlvbnMsIGV4Y2VwdCB0aGUg
Y2l2aWMgY29tcG9uZW50cy4NCg0KSWYgeW91IHVuZGVyc3RhbmQgU2NoZW1hdHJvbiAoaHR0cDov
L3d3dy5zY2hlbWF0cm9uLmNvbS9vdmVydmlldy5odG1sKSwgdGhpcw0KZG9jdW1lbnQgdXNlcyBz
dGF0ZW1lbnRzIG5vdCBkaXNzaW1pbGFyIHRvIFNjaGVtYXRyb24gY29uc3RyYWludHMuICBBIGNv
bnRleHQNCmlzIGVzdGFibGlzaGVkIGFuZCB3aXRoaW4gdGhhdCBjb250ZXh0IHRoZSBzdXBwb3J0
ZWQgZWxlbWVudHMgYXJlIGlkZW50aWZpZWQuDQpCeSBkZWZhdWx0IHRoZSBjb250ZXh0IGlzIGVh
Y2ggPHJ1bGU+IGVsZW1lbnQgaW4gdGhlIHJ1bGVzZXQuDQoNCk9uY2UgYSBjb250ZXh0IGhhcyBi
ZWVuIGVzdGFibGlzaGVkLCB0aGVyZSBhcmUgdHdvIHNvcnRzIG9mIHN0YXRlbWVudHMgdGhhdA0K
Y2FuIGJlIHVzZWQ6DQoNCiAgQSA8c3VwcG9ydD4gc3RhdGVtZW50IGluZGljYXRlcyBzdXBwb3J0
IGZvciBhIHBhcnRpY3VsYXIgWFBhdGggbm9kZS4gIEZvcg0KICBpbnN0YW5jZSB0aGUgYWJvdmUg
ZG9jdW1lbnQgc3RhdGVzIHRoYXQgaXQgc3VwcG9ydHMgdGhlIHZwcDpoYXBweSBlbGVtZW50Lg0K
ICBCeSBkZWZhdWx0LCBhbGwgY2hpbGRyZW4gb2YgdGhlIG5vZGUgYXJlIGluY2x1ZGVkDQogIChp
LmUuICIvLypbYW5jZXN0b3Itb3Itc2VsZjo6Ki8uLi5dIiBpcyBpbXBsaWVkKSwgdW5sZXNzIGV4
cGxpY2l0bHkNCiAgZXhjbHVkZWQgYnkgdXNpbmcgdGhlIGF0dHJpYnV0ZSBjaGlsZHJlbj0iZmFs
c2UiIC4gIE5vdGUgPHN1cHBvcnQ+IGFjdHVhbGx5DQogIHNlbGVjdHMgYSBub2RlLXNldCwgd2hp
Y2ggbWF5IGluY2x1ZGUgbXVsdGlwbGUgZWxlbWVudHMuDQoNCiAgQSA8c3VwcG9ydC1uYW1lc3Bh
Y2U+IHN0YXRlbWVudHMgaW5kaWNhdGVzIHN1cHBvcnQgZm9yIGFsbCBlbGVtZW50cyBmcm9tIGEN
CiAgZ2l2ZW4gbmFtZXNwYWNlLiAgQW4gb3B0aW9uYWwgc2NoZW1hTG9jYXRpb24gYXR0cmlidXRl
IGVzdGFibGlzaGVzIGEgY29tbW9uDQogIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB0aGF0IG5hbWVz
cGFjZSBpbXBsaWVzIChhIGxpdHRsZSBkaXNhbWJpZ3VhdGlvbiBoZWxwcw0KICBzb21ldGltZXMp
LiAgTm9kZXMgdGhhdCBhcmUgbm90IHN1cHBvcnRlZCBmcm9tIHRoYXQgZG9jdW1lbnQgYXJlIGlu
ZGljYXRlZA0KICB1c2luZyB0aGUgPGV4Y2VwdD4gZWxlbWVudC4NCg0KT25lIGFzcGVjdCBvZiB0
aGlzIGRvY3VtZW50IGlzIHRoYXQgaXQgY291bGQgYmUgdXNlZCB0byBjb25zdHJ1Y3QgYW4gaW5w
dXQNCmZpbHRlciBmb3IgdGhlIHNlcnZlci4gIEkgY2FuIHR1cm4gdGhlIGFib3ZlIGRvY3VtZW50
IGludG8gY29kZSB0aGF0IHdvdWxkDQp0ZXN0IGZvciBjb21wbGlhbmNlIHRvIHRoZSBjYXBhYmls
aXRpZXMgcmVsYXRpdmVseSBlYXNpbHkuDQoNCkknbSBzdXJlIHRoYXQgYSBjb21wbGV0ZSBYUGF0
aCBpbXBsZW1lbnRhdGlvbiBtaWdodCBzZWVtIHRvIGJlIGEgbGl0dGxlIHRvbw0KbXVjaCBmb3Ig
dGhpcyBwYXJ0aWN1bGFyIHRhc2ssIHNvIEknZCByZWNvbW1lbmQgYSBzaW1pbGFyIHN1YnNldCB0
byB0aGF0DQp1c2VkIGZvciBYQ0FQLCB3aGljaCBzaG91bGQgYmUgcXVpdGUgYWRlcXVhdGUuICBU
aGUgZ2l2ZW4gZXhhbXBsZSBmb3IgY3JzTmFtZQ0KaXMgcHJvYmFibHkgc29tZXRoaW5nIHRoYXQg
Y291bGQgYmUgY3V0IHdpdGhvdXQgdG9vIG1hbnkgcHJvYmxlbXMuDQoNCg0KT25lIGZpbmFsIGNv
bW1lbnQgLSBJIGRvbid0IHNlZSB0aGUgbmVlZCBmb3IgdGhlIC5wY3AgZXh0ZW5zaW9uIGZvciB0
aGlzDQpkb2N1bWVudCwgcGFydGljdWxhcmx5IHNpbmNlIHlvdSBhcmVuJ3QgYWN0dWFsbHkgdXNp
bmcgaXQgZm9yIFhDQVAuDQoNCg0KQ2hlZXJzLA0KTWFydGluIA0KDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0
ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFy
eSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2Vp
dmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFu
ZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1h
aWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KW21mMl0=



--===============0673641630==
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

--===============0673641630==--