[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sip] Some comment to draft-ietf-sip-xcapevent-02

Hi Jari and Keith,
I had a look at the latest xcap event draft  http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-02.txt  what was updated after the WG last call for this i-d.. OMA-PAG WG is as both you know using this i-d as part of the OMA XDM 2.0 enabler release. I have from a OMA XDM 2.0 point of view reviewed the i-d to give you some more feedback as beeing a member of this WG  
My personal view is that this version of the i-d fulfills the needs that I  see exists for the  function to be able to monitor changes in XML document managed by the OMA XDM enabler..
When reviewing the document I have only found some minor things in the examples that I think needs to be addressed..

#1
Section A.2
"If the   Expires header has a value "0" this is effectively a similar request  than the PROPFIND method of WebDAV, the syntax's and responses differ, however."
This sentence is a bit unclear to me 
shall it be better to write 
"If the   Expires header has a value "0" this is effectively a similar request  to the PROPFIND method of WebDAV, the syntax's and responses  differ, however."
instead if you mean that both metods do the same stuff but with different syntax/responses. 
 
#2
Section A.4
"If it were an another device it would probably do a re-fetch of this new document."
 
shall it be just "fetch" as it is a new documen? Re-fetch of a new document sounds a bit strange. Shall it be 
"If it were an another device it would probably do a fetch of this new document."
instead.
#3
Section A.5
The example is a bit confusing and I think it needs some clarification. A suggestion is added in bold text. I have assumed that the starting point is that the document exist.
 
The user Joe does an initial subscription for the "id" affribute of the <doc> element:
The "index" document exists ,but the <doc> root element does not contain the "id" attribute at the time of the subscription.

   SUBSCRIBE sip:tests at xcap.example.com SIP/2.0
   ...
   Accept: application/xcap-diff+xml
   Event: xcap-diff
   Content-Type: application/resource-lists+xml
   Content-Length: [XXX]

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
    <list>
     <entry uri="tests/users/sip:joe at example.com/index/~~/doc/@id"/>
    </list>
   </resource-lists>
In addition to the 200 OK response, the first NOTIFY looks like since
   there's nothing to indicate as:   
NOTIFY sip:joe at userhost.example.com SIP/2.0
   ...
   Event: xcap-diff
   Content-Type: application/xcap-diff+xml
   Content-Length: [XXX]

   <?xml version="1.0" encoding="UTF-8"?>
   <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
              xcap-root="http://xcap.example.com/"/>


   Afterwards Joe's XCAP client updates the whole document root element including the attribute "id"
   (not a typical XCAP operation nor a preferred one, just an
   illustration here):


   PUT /tests/users/sip:joe at example.com/index/~~/doc HTTP/1.1
   Host: xcap.example.com
   ....
   Content-Type: application/xcap-el+xml
   Content-Length: [XXX]

   <doc id="bar">This is a new root element</doc>


   The reported*** new HTTP ETag of "index" document is now "dwawrrtyy".   ( ***remove reported as it is not reported to the subscriber in the NOTIFY it is only send back in the response to the PUT else remove the whole sentence as ETAG is not used in this type of Noitify and ETAG value is therefore not relevant)

   Then the subscriber gets a notification:


   NOTIFY sip:joe at userhost.example.com SIP/2.0
   ...
   Event: xcap-diff
   Content-Type: application/xcap-diff+xml
   Content-Length: [XXX]

   <?xml version="1.0" encoding="UTF-8"?>
   <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
              xcap-root="http://xcap.example.com/";>

    <attribute sel="tests/users/sip:joe at example.com/index/~~/doc/@id"
     >bar</attribute>

   </xcap-diff>

Kind Regards
Anders
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip