[Geopriv] BUG in PIDF-LO Profile Found
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Geopriv] BUG in PIDF-LO Profile Found



Hi all, 

Thanks to Erwan, who recently read the PIDF-LO profile document very
carefully and compared it to the OMA specification, a bug was found.
Krisztian Kiss provided us with the corresponding text paragraphs from
the Presence Data Model supporting the observation. 

Here is the issue: 

In the document we allow the <geopriv> element to appear in <device>,
<person> and <tuple>. That's OK. 

However, we put <geopriv> as a child element of <status> rather than as
an immediate child element of <device>, <person> or <tuple>. Although
RFC 4119 indicates this placement RFC 4479
(http://www.ietf.org/rfc/rfc4479.txt) changes it by saying: 

"
   Unfortunately, the original PIDF specification did have a separate
   part of a tuple for describing status, and the basic status was
   defined to exist within that part of the tuple.  This specification
   does not change PIDF; however, all future presence attributes MUST be
   defined as children of the <tuple> and not the <status> element.
   Furthermore, the schemas defined here do not contain a <status>
   element for either the <person> or <device> elements.
"

"
   The existing <tuple> element in the PIDF document is used to
   represent the service.  This is consistent with the original intent
   of RFC 2778 and RFC 3863, and achieves backward compatibility with
   implementations developed before the model described here was
   complete.  The <contact> element in the <tuple> element is used to
   encode the service URI.  New presence attributes, whether they
   represent dynamic status or static characteristics, appear directly
   as children of <tuple>.  However, attributes defined prior to
   publication of this specification that were defined as children of
   <status> (such as <basic>) remain as children of <status>, for
   purposes of backward compatibility.  Consequently, a presence
   attribute describing a service could appear as either a child of
   <status> or directly as a child of <tuple>, but never both.
"

Hence, I suggest to follow RFC 4474 and to put the <geopriv> element
directly under <device>, <person> and <tuple>. 

Ciao
Hannes


_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.