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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]/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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]/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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]/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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
