Subject: [Simple] Other MIME type than xcap-el/attr

From: Jaekwon Oh <[email-masked]>
Date: Tue, 07 Feb 2006 21:58:24 +0900

Hello Jonathan and all,

One quick question on XCAP-08.
Does XCAP allows to extend xcap-el/attr MIME Type for the fragement containing element/attrs? 
In other words, does XCAP allows to use other MIME Type than xcap-el/attr for the element/attr fragment?
According to XCAP-08 texts, it seems not allowed; the text says that it 'MUST' use such MIME Type.
Thank you in advance.

BR,
Jaekwon Oh

Global Stanadards & Research
Samsung Electronics, Co. Ltd.
TEL  +82 31 279 5086
CP   +82 16 9530 5086
FAX  +82 31 279 5130
[email-masked]

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Feb 2006 16:57:54 -0500

The intent was that its not meant to be extended, and that nothing else
would be used. Do you have a use case or need for something else?

Thanks,
Jonathan R.

Jaekwon Oh wrote:

> In other words, does XCAP allows to use other MIME Type than 
> xcap-el/attr for the element/attr fragment?
> [email-masked] <mailto:[email-masked]>
>  
>  

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

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 09 Feb 2006 10:53:36 +0200

Inline --

> would be used. Do you have a use case or need for something else?
well I had another impression. E.g. with multi-insert one would use
multiple elements in the body, would it be the same content-type than
xcap-el+xml, for example ? Anyhow, I don't much care if some new
content-types are defined by some new extensions, because they don't
break the base spec in anyway, imo. That is, you'll negotiate response
type with Accept-header and even in some cases you might use request
body as well and XCAP capabilities doc may list this extension tag.
Although XCAP isn't an XML database or something like that, a really
cool extension would be, for example, XQuery like requests over docs. So
I don't see a problem for a future extension to define some new
semantics with new mime-types (although I don't have an intention to
propose something now, no ;-)). Also one could argue that some BNF
extensions (which are now explicitly allowed) are useless without the
ability to have new mime-types as well.  

br Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 10 Feb 2006 07:36:29 -0500

inline.

Jari Urpalainen wrote:

> xcap-el+xml, for example ?

Yes; it would just have multiple elements.

> Anyhow, I don't much care if some new
> break the base spec in anyway, imo.

They don't; my point though was that unless you were doing something 
substanially different, xcap-el+xml really ought to suffice. I'd still 
like to understand what the use case was around the question.

  That is, you'll negotiate response
> cool extension would be, for example, XQuery like requests over docs. 

Right - like I said, unless you're doing something pretty radically 
different, xcap-el+xml will suffice.

> So

There I disagree. The new extensions to the URI are meant to allow 
different ways of selecting elements and attributes, but the net result 
is that what comes back is still elements and attributes.

-Jonathan R.

---

From: Jaekwon Oh <[email-masked]>
Date: Sun, 12 Feb 2006 22:55:39 +0900

Hello,

Thank you for response and find my response inline.

BR,
Jaekwon Oh

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Jari Urpalainen" <[email-masked]>
Cc: "Jaekwon Oh" <[email-masked]>; "Simple WG" <[email-masked]>
Sent: Friday, February 10, 2006 9:36 PM
Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr

>>>would be used. Do you have a use case or need for something else?

For namespace binding information, it is understood that namespace node retrival as defined in xcap-08 is quite clean solution. However, as the operation of grabbing a wireless channel for a tranascation is delay-prone in wireless media, the intended use case is to optimize the number of transaction in getting the namespace binding infomration by allowing the fragment to contain local namespace binding within itself. The following is an example of such fragment body:

Content-Type: application/xxxxxx+xml

<namespace-bindings>
  <default>urn:ietf:params:xml:ns:rls-services</<default>
  <a>urn:ietf:params:xml:ns:resource-lists</a>
  <foo>http://example.com/foo</foo>
</namespace-bindings>

<fragment>
<service uri="sip:[email-masked]"  
              xmlns:xxxx="......(local namespace declaration or local redeclaration, if any)" >
      <a:list name="marketing">
        <a:entry uri="sip:[email-masked]"/>
        <a:entry uri="sip:[email-masked]"/>
      </a:list>
      <packages>
        <package>presence</package>
      </packages>
    </service>
</fragment>

In the above example, the <namespace-bindings> will contain the local namespace binding informatin as identified by all namespace node operation of '.../namespace::* under the element targeted. This approach allow the local namespace binding information to be within the fragment itself. Also, this approach would separate the local namespace binding information from the fragment body targeted. Thus, it could avoid the document cluttering by superfuluous local namespace binding information in the fragment body and also keep intact, any local namespace declaration or reclaration on an element.

However, as this optimization is purposed to cope with the particular environment of wireless media rather than generic one, it seems appropriate to extend basic xcap-el/attr MIME type by defining a new MIME type, *if allowed*, than trying to directly extend xcap-el/attr MIME type.

> different, xcap-el+xml will suffice.

In fact, there's another use case of 'search', where the response fragment would contain the result of 'search' operation on the targeted. Considering there could be multiple results per the search operation, there are another challenge in xcap-08. The xcap node selector allows just one or no match. In other words, one or no context node, not allowing multiple context nodes as the result of node selector. So, it is also questionable whether it is possible to bend such xcap node selector constraints with the extension selector that is newly introduced in xcap-08. But, this is another issue...

> is that what comes back is still elements and attributes.

Please understand that the question here is *not* to propose something new, rather is to confirm whether a new MIME type for element/attr is allowed in xcap.
Thank you.

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 13 Feb 2006 10:35:46 +0200

> Yes; it would just have multiple elements.
hmm. while I agree that this is certainly possible with this weird
xml ;-) it is imo worth a note somewhere because in general this is not
possible.

> different, xcap-el+xml will suffice.
XQuery might be radical, I'd say it is complex and computer intensive,
but I would not like to forbid anticipated possible future extensions,
if there's no real technical reason behind prohibiting them.
> is that what comes back is still elements and attributes.
In addition to elements and attributes (where element patching covers
undoubtedly over 90 % of the use cases, in general), text, comment,
processing instructions and namespace declarations could be allowed with
an extension specification as well.

As an example, namespace declarations could be added with a namespace
axis selector:
PUT ...~~/root/namespace::prefix   "uri:test"
A very similar (and trivial) solution than attribute selections. The
biggest difference being there's no abbreviated selector.

Text nodes could be allowed as well:
PUT ...~~/root/text()   "new replaced text" 

What is difficult with them (as well as with elements, comments and PIs)
is the exact positioning of new nodes (if there are several siblings).
One really unambiguous solution is to use XPath "node()" function within
predicates. "node()" selects all child nodes of the context element,
i.e. child text, elements, comments and PIs. So a request like:

PUT ...~~/root/node()[3][self::text()] "added or replaced text at node
position 3"

will require that the third child node of <root> must be a text node. If
the current 3. node is not a text node, it will be added there. This
could be used also to maintain pretty printing style. Comments could be
added similarly, PIs have a name. Certainly there are drawbacks, e.g.
blind updates not possible because of positional predicates, some
complexity etc. But I really don't see a point for disallowing these
kind of possible future extensions. Sure they are not amongst the most
needed features, but adding these will not break the base spec anyway. 
br,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 13 Feb 2006 12:45:25 +0200

> However, as this optimization is purposed to cope with the particular environment of wireless media rather than generic one, it seems appropriate to extend basic xcap-el/attr MIME type by defining…
I think wireless industry should be worried about increased verbosity as
well. So imo it is much better to have s simpler response format (only
for GET method) including all in-scope namespaces in <service> only,
according to the canonical xml rules (not exclusive). The use case here
is still blind updates after the retrieval of in-scope namespaces if I
have understood correctly. When the client issues this kind of request,
it knows that response will contain superfluous namespace declarations.
Given that canonical xml is the baseline determining the equivalence of
xcap resources (or documents), the client may remove superfluous
namespace declarations if it tries to store a local copy as well (which
may not be the case regarding an upcoming "blind" update). So I'm
definitely not against of having this sort of an additional optional
feature as long as the base XCAP semantics is kept where the body looks
similar to what appears in the document. I'm only questioning the
proposed format.

In principle, this could be used with put as well, but one can already
use local namespace declarations in the body (with elements, but not
with qualified attributes). What I'm not thrilled about that XCAP
servers should remove superfluous namespace declarations. Sure, one can
say that if this extension is supported, the server must also remove the
superfluous namespace declarations. IMO, if this is specified as an
extension to the base XCAP spec, that's fine (doesn't break the base
spec, i.e. harmless though not super useful in a generic case)
br,
Jari

---

From: <[email-masked]>
Date: Tue, 21 Feb 2006 15:49:34 +0200

Hello,

So from OMA PAG WG point of view we like to know what is statement of
SIMPLE WG to 
following question: Is OMA PAG are already allowed (with XCAP-08) to
make and use 
OMA extension MIME type for retrieving namespace binding information
without breaking 
XCAP or does it requires relaxation of usage of xcap-el/attr MIME Type
in XCAP. 
And if the latter one is the case, then I'd like to know whether this
could be 
possible in the next version of XCAP or near future.

Thanks in advance!

Br, Antti

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Jari Urpalainen
>Sent: 13 February, 2006 12:45
>To: ext Jaekwon Oh
>Cc: Simple WG
>> >>>The intent was that its not meant to be extended, and 
>that nothing 
>> >>>else would be used. Do you have a use case or need for 
>something else?
>> >>>
>> >>>Thanks,
>> >>>Jonathan R.
>> >>>
>> 
>> For namespace binding information, it is understood that 
>namespace node retrival as defined in xcap-08 is quite clean 
>solution. However, as the operation of grabbing a wireless 
>channel for a tranascation is delay-prone in wireless media, 
>the intended use case is to optimize the number of transaction 
>in getting the namespace binding infomration by allowing the 
>fragment to contain local namespace binding within itself. The 
>following is an example of such fragment body:
>> 
>> In the above example, the <namespace-bindings> will contain 
>the local namespace binding informatin as identified by all 
>namespace node operation of '.../namespace::* under the 
>element targeted. This approach allow the local namespace 
>binding information to be within the fragment itself. Also, 
>this approach would separate the local namespace binding 
>information from the fragment body targeted. Thus, it could 
>avoid the document cluttering by superfuluous local namespace 
>binding information in the fragment body and also keep intact, 
>any local namespace declaration or reclaration on an element.
>> 
>> However, as this optimization is purposed to cope with the 
>particular environment of wireless media rather than generic 
>one, it seems appropriate to extend basic xcap-el/attr MIME 
>type by defining a new MIME type, *if allowed*, than trying to 
>directly extend xcap-el/attr MIME type.
>> 
>I think wireless industry should be worried about increased 
>verbosity as well. So imo it is much better to have s simpler 
>response format (only for GET method) including all in-scope 
>namespaces in <service> only, according to the canonical xml 
>rules (not exclusive). The use case here is still blind 
>updates after the retrieval of in-scope namespaces if I have 
>understood correctly. When the client issues this kind of 
>request, it knows that response will contain superfluous 
>namespace declarations.
>Given that canonical xml is the baseline determining the 
>equivalence of xcap resources (or documents), the client may 
>remove superfluous namespace declarations if it tries to store 
>a local copy as well (which may not be the case regarding an 
>upcoming "blind" update). So I'm definitely not against of 
>having this sort of an additional optional feature as long as 
>the base XCAP semantics is kept where the body looks similar 
>to what appears in the document. I'm only questioning the 
>proposed format.
>
>In principle, this could be used with put as well, but one can 
>already use local namespace declarations in the body (with 
>elements, but not with qualified attributes). What I'm not 
>thrilled about that XCAP servers should remove superfluous 
>namespace declarations. Sure, one can say that if this 
>extension is supported, the server must also remove the 
>superfluous namespace declarations. IMO, if this is specified 
>as an extension to the base XCAP spec, that's fine (doesn't 
>break the base spec, i.e. harmless though not super useful in 
>a generic case) br, Jari
>
>