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

[Jari Urpalainen <jari.urpalainen at nokia.com>]

On Sun, 2006-02-12 at 22:55 +0900, ext Jaekwon Oh wrote:
> Hello,
> 
> Thank you for response and find my response inline.
> 
> 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
> jaekwon.oh at samsung.com
> 
> 
> ----- Original Message ----- 
> From: "Jonathan Rosenberg" <jdrosen at cisco.com>
> To: "Jari Urpalainen" <jari.urpalainen at nokia.com>
> Cc: "Jaekwon Oh" <jaekwon.oh at samsung.com>; "Simple WG" <simple at ietf.org>
> Sent: Friday, February 10, 2006 9:36 PM
> Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr
> 
> 
> > inline.
> > 
> > Jari Urpalainen wrote:
> > 
> >> Inline --
> >> 
> >> On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote:
> >> 
> >>>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:
> 
> 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:marketing at example.com"  
>               xmlns:xxxx="......(local namespace declaration or local redeclaration, if any)" >
>       <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>
> </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.
> 
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


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