Re: [Simple] XCAP and its problem with Namespaces caused by using only the XML fragment body.

Jari Urpalainen <jari.urpalainen@nokia.com> Wed, 17 August 2005 08:05 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5IvC-0004S5-In; Wed, 17 Aug 2005 04:05:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Iv9-0004Rs-Lr for simple@megatron.ietf.org; Wed, 17 Aug 2005 04:05: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 EAA13930 for <simple@ietf.org>; Wed, 17 Aug 2005 04:05:09 -0400 (EDT)
Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5JUd-000726-LF for simple@ietf.org; Wed, 17 Aug 2005 04:41:53 -0400
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j7H83xG15547; Wed, 17 Aug 2005 11:03:59 +0300 (EET DST)
X-Scanned: Wed, 17 Aug 2005 11:03:41 +0300 Nokia Message Protector V1.3.35 2005042208 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j7H83fdF022469; Wed, 17 Aug 2005 11:03:41 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Yuot5b; Wed, 17 Aug 2005 11:03:40 EEST
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 j7H83eK23667; Wed, 17 Aug 2005 11:03:40 +0300 (EET DST)
Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id F310193B6A; Wed, 17 Aug 2005 11:03:39 +0300 (EEST)
Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id C660771D; Wed, 17 Aug 2005 11:03:39 +0300 (EEST)
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using only the XML fragment body.
From: Jari Urpalainen <jari.urpalainen@nokia.com>
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
In-Reply-To: <43028B85.5060100@cisco.com>
References: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net> <43028B85.5060100@cisco.com>
Content-Type: text/plain
Date: Wed, 17 Aug 2005 11:03:39 +0300
Message-Id: <1124265819.11970.26.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4)
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: "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

On Tue, 2005-08-16 at 20:57 -0400, ext Jonathan Rosenberg wrote:
> inline.
> 
> Hyttfors, Per wrote:
> 
> > Hello,
> >  
> > As I see it there is a major problem with retrieving elements in an XML 
> > document using XCAP. The problem has to do with that the XDM clients has 
> > to know all the namespace prefix bindings in the server document prio 
> > the fetch of an element.
> >  
> > The problem is that the current XCAP specification only mandates that a 
> > XCAP fragment body is sent between server and client when performing 
> > XCAP operations. Not being an fcs document with the fragment context 
> > specification leads to problems now when the XCAP URL has been made 
> > independent of the namespaces prefixes used in the document on the server.
> >  
> > The XML data returned in the 200 OK answer on a fetch of an element will 
> > contain the exact content of that element in the XML document on the 
> > server. If this element or any child elements use namespace prefixes 
> > declared earlier in the document they will not be included in the 
> > response to the client. Hence the only way to know all the prefixes is 
> > to have done a fetch of the whole document.
> 
> The client doesn't need the whole document; it just needs the portion of 
> the document above the element that has been fetched, in order to know 
> the namespace bindings that are in scope for the element that is being 
> fetched.
> 
> I'm assuming that you have in mind an application where the client 
> doesn't normally store the whole document, for example a cell phone 
> where I want to retrieve portions of my buddy list one buddy at a time.
> 
> As such, one solution is to fetch the whole document at startup, get the 
> namespace bindings and etag, and dump the document. Then, subsequent 
> GETs are conditional against the etag, and so the client can get the 
> information it needs and use the cached namespace bindings.
> 
> This is clearly not optimal since it requires a full document get just 
> to obtain the namespace bindings. However, it works with the current spec.
> 
> Some other thoughts are:
> 
> 1. an xcap extension that allowed to specifically query for the 
> namespace bindings in scope for a particular element
> 
> 2. change xcap so that what is returned is an xml fragment that includes 
> additional information on the namespace bindings in scope
> 
> 3. have the xcap server return xml data using the namespace bindings in 
> scope for the request URI. This requires the server to modify the xml 
> data before sending it to the client
> 
I suppose this question has come from OMA people. An XPath way of doing
this could be GET ....~~/root/namespace::*, i.e. namespace axis could be
used to request all the in-scope namespaces of some element. An XCAP
extension should then describe this BNF extension as well as the payload
format.

br,
Jari


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