Subject: [Simple] comments on partial-pidf-format

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Mar 2005 00:23:06 -0500

> The Presence Information Document Format (PIDF) specifies the
>    baseline XML based format for describing presence information.  One

you should cite rfc3863.

> In addition to patch operation elements the data format consists of
>    some additional parameters.  The 'version' attribute within the
>    document root node contains a sequence number that is progressively
>    incremented by one between subsequent document updates i.e.  a more
>    recent document update has a higher 'version' value than the previous
>    one.  This is used to ensure consistent updates as the recipient of
>    the document can use the 'version' attribute value to properly order
>    received documents.

this helps order the diff documents, but doesnt help figure out against 
which version of the presence document the diff is applied. How does 
that work? Without that, when you get the first diff, how do you know if 
its a diff against the version you currently have?

> 3.2  'entity' attribute
> 
>    Every presence document compliant with this specification MAY contain
>    an 'entity' attribute in the <pidf-diff> root document node.  It's
>    content MUST then be the same than that of the full presence
>    document.

what is this used for?

> 5.3  XML Schema Registration
> 
>    This section registers a new XML Schema.
> 
>       URI:
>       urn:ietf:params:xml:schema:pidf-diff

you have to tell IANA where the schema is.

Section 6:

out of curiousity, have you compared the number of bytes in the xcap 
diff with the size of the presence document after applying gzip or some 
kind of other compression?

> Interoperability Considerations
> 
>    Systems compliant with CPP [9] will not be by default able to use
>    this specification.  However, this will not cause any
>    interoperability problems because all endpoints and gateways must
>    support the default MIME type (application/pidf+xml) regardless if
>    they support this specification.  Thus if a gateway or another end
>    point does not understand this specification it will not be used.

you might want to explain that this format is negotiated using simple, 
and reference the partial notification spec.

> Presence information may contain highly sensitive information about
>    the presentities.  The protocol used to distribute it SHOULD ensure
>    privacy, message integrity and authentication.  Furthermore, the
>    protocol should provide access controls which restrict who can see
>    who else's presence information.  All security considerations
>    identified for PIDF [3] apply unchanged for this document.

I think you should start with the last sentence, and explain why - 
namely that there is no difference in information content when this 
specification is used, it is effectively another way to encode the same 
data.

An additional consideration - if an attacker can disrupt a single diff 
document, it can ruin the presence document seen by the watcher from 
that point forward. This is not the case with normal pidf, where that is 
self-correcting after the same notify.

You should mention this and discuss it.

Also, another issue. The xcap-diff format has a hash value that allows a 
recipient to validate that, after the patch, the document they have 
arrived at is the same as on the server. This is not really specific to 
xcap diff, and applies to any usage of the patch operations. Perhaps 
this should be moved into the common core document?

-Jonathan R.

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

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

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 09 Mar 2005 18:37:29 +0200

inline

>>    baseline XML based format for describing presence information.  One
ok.

> this helps order the diff documents, but doesnt help figure out 
> against which version of the presence document the diff is applied. 
> How does that work? Without that, when you get the first diff, how do 
> you know if its a diff against the version you currently have?
>
this is described in partial publish/notify.  Instead of version 
attribute I would prefer using sip ETag instead. However, it is only 
specified with PUBLISH.   

>>    content MUST then be the same than that of the full presence

if i understood correctly (Mikko) it is used outside sip.

> you have to tell IANA where the schema is.

ok, good catch.

> diff with the size of the presence document after applying gzip or 
> some kind of other compression?
>
no in this particular case. 

> and reference the partial notification spec.
ok.

> specification is used, it is effectively another way to encode the 
> same data.
>
> that point forward. This is not the case with normal pidf, where that 
> is self-correcting after the same notify.
>
ok.

>
> Also, another issue. The xcap-diff format has a hash value that allows 
> a recipient to validate that, after the patch, the document they have 
> arrived at is the same as on the server. This is not really specific 
> to xcap diff, and applies to any usage of the patch operations. 
> Perhaps this should be moved into the common core document?
>
> -Jonathan R.
>
This sounds a good idea, although we may not have that common core 
document ;)

Thanks for the comments,
Jari