PIDF issues summary (long)

Here is my own summary of issues/edits for PIDF. In most cases, I am
speaking to different passages in the text than Graham did in his recent
suggested edits. One point of overlap - Graham has proposed some text for
modifying the last paragraph of 4.2.3 (where mustUnderstand is discussed). I
feel that some additional changes are necessary to the second paragraph of
4.2.3, and I also have an alternative suggestion for replacing the final
paragraph of 4.2.3 (my version normatively restricts the use of
mustUnderstand to nested elements within extensions, which are always
understood to be optional - Graham's text doesn't quite put the normative
emphasis in the same place).

At a high level my proposals are:

mustUnderstand - After some debate about this subject, we seem to have
reached consensus that the mustUnderstand attribute can only be used within
nested extensions, not within top-level elements in PIDF.

tuples - While this may be an ongoing subject for discussion, I think that
making some simple changes will be adequate for the PIDF draft (future
presence protocols and applications will have greater responsibilities).
Basically, those changes entail providing the most elementary motivation for
tuples (the concept that, for whatever reason, there may be multiple sources
of presence information), and a simple method of understanding segmented
presence information in the absence of any further context. I also propose a
few very general guidelines for using tuples. See my proposed changes to
4.1.2 below.

extensibility - There should be an example XML Schema, and some explicit
instructions, for creating extensions to the PIDF format. Since XML Schema
isn't really my forte, someone with more knowledge than myself should
provide real XML Schema text for the sections I discuss below (see my
proposed sections 4.2.5 and 4.4).

security - The need for end-to-end confidentiality and integrity properties
of notifications, as well as AuthNZ functions, must be specifically
enumerated as requirements. Some mention of MIME-level security should be
made in the Sec Cons, even if specifics of the mechanism are deferred to the
core CPIM specification.

A couple nits are also listed below, after the more interesting proposed
changes.

Jon Peterson
NeuStar, Inc.

----

Proposed changes:

-- 2.1 Minimal Model --

Append to (a) the following sentence: "Note that the CONTACT ADDRESS in a
COMMUNICATIONS ADDRESS is understood more narrowly in this document to refer
only to a URI."

As a security fix, I suggest replacing (f) with the following: 

"(f) The common presence format must allow the PRESENTITY to secure presence
information sent to a WATCHER. The format must allow integrity,
confidentiality and authentication properties to be applied to presence
information. (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, 5.3.3)"

-- 2.2 Added Features --

To the end of (b), I suggest adding: "Note that this mechanism does not
assume any global time synchronization system for watchers and presentities
(see Appendix A of RFC2779, 8.1.4 A7), but rather assumes that watcher and
presentities will be loosely synchronized."

-- 4.1.2 The <tuple> Element --

I would insert the following paragraph between the first and second
paragraphs in this section:

"Tuples provide a way of segmenting presence information. Protocols or
applications may choose to segment the presence information associated with
a presentity for any number of reasons - for example, because components of
the full presence information for a presentity have come from distinct
devices or different applications on the same device, or have been generated
at different times. Tuples should be preferred over other manners of
segmenting presence information such as creating multiple PIDF instances."

I would also suggest appending the following to the last paragraph of this
section: "Tuples that contain a <basic> status element SHOULD contain a
<contact> address. Tuples MAY contain conflicting presence information - one
<tuple> might provide a <basic> <status> of OPEN, and another <tuple> in the
same PIDF could contain a <basic> <status> of CLOSED, even if they both
contain the same <contact> address."

I would also suggest adding the following paragraph to the end of this
section:

"The manner in which segmented presence information is understood by the
watcher is highly dependent on the capabilities of the watcher and the
presence application in question. In the absence of any application-specific
or protocol-specific understanding of the meaning of tuples, watchers MAY
obey the following guidelines. Watchers should note which tuples in the PIDF
have changed their state since the last notification by correlating the 'id'
of each <tuple> with those received in previous notifications and comparing
both <status> values and <timestamp> elements in the tuples, if any are
present. If at least one tuple in the PIDF contains a <basic> <status>
element with a value of OPEN, then the presentity should be considered to be
currently available. <contact> elements in tuples that do not declare a
<basic> <status> of OPEN should not, however, be presented by the watcher as
ways to communicate with the presentity at this time."

-- 4.1.7 The <timestamp> Element --

Append to the first paragraph: "As a security measure, the <timestamp>
element SHOULD be included in all tuples unless the exact time of the status
change cannot be determined."

Also, I recommending adding the following paragraph to the end of this
section: "For security guidelines for watchers receiving presence
information with timestamps, see the Security Considerations."

-- 4.2 Presence Information Extensibility --

Some information on the applicability of the extensibility mechanism would
be useful here. I recommend appending a new paragraph to this section:
"RFC2779 requires that PIDF have a means of extending <status> values beyond
<basic>. The extensibility mechanism provided here These extensions MUST NOT
modify how <basic> is to be understood, nor change the the structure or
semantics of PIDF bodies themselves. These extensions merely allow protocols
and applications to define richer presence data."

-- 4.2.3 Handling of Unrecognized Element Names --

I think you should keep the first paragraph as it is, but for the second
paragraph, substitute something like the following:

"Extensions to PIDF are informational in nature - they provide additional
information beyond <basic> status. However, in order to understand a complex
extension, nested elements within an extension element might need to be
marked as mandatory. In such cases, the element name is qualified with a
mustUnderstand='true' or mustUnderstand='1' attribute, which attribute name
is associated with the CPIM presence namespace.See section 4.3.3 for an
example."

Retain the editor's note (that serves as the third paragraph), and the
fourth paragraph. I recommending substituting the following for the fifth
paragraph: "If an agent receives PRESENCE INFORMATION with a <status> block
containing an unrecognized element that has a mustUnderstand='true' (or '1')
attribute, it should treat the entire element as unrecognized and not
attempt to process it."

-- 4.2.5 Registering Extensions --

This would be a new section providing detailed instructions for authoring
extensions. I would suggest the following:

"It may be desirable to standardize elements that can appear in the <status>
element of PIDF. Note that the existing XML Schema definition of PIDF
already allows arbitrary elements to appear in the <status> element, so
standardization is of the syntax of these elements is not mandatory.
However, the semantics of an extension (the meanings of particular statuses,
how their should be interpreted) may also be reasonable a subject of
standardization. Therefore, a new URN namespace has been created for
elements that can appear in the <status> element.

The following example XML Schema defines an extension for <location>
presence information, which can have the values of 'home', 'office', or
'car'. If the <location> element were standardized, this document would be
made available in an RFC along with information about the use of the
extension. These extensions should use the namespace
'urn:ietf:params:xml:ns:cpim-pidf:status', and each RFC defining an
extension should register an extension name within that namespace with IANA.

[NOTE - Someone should create a real XML Schema - this is just Jon's
approximation]

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:cpim-pidf:status"
        xmlns:tns="urn:ietf:params:xml:ns:cpim-pidf:status"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">

     <xs:simpleType name="location">
       <xs:restriction base="xs:string">
         <xs:enumeration value="home"/>
         <xs:enumeration value="office"/>
         <xs:enumeration value="car"/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>

In addition to the XML Schema to validate the extension, registration of the
extension name with IANA, RFCs defining extensions MUST discuss:

- The domain of applicability of the extension. Is this extension
exclusively valuable to IM clients, telephones, geolocators, etc? What sorts
of presence applications would use this extension and under what
circumstances?
- Semantics for the presence states defined in the extension. What
disposition provokes an automated presentity to declare that it is in state
X, or does a human select X from a drag-down menu? Is there any general
guidance for watchers of presence information with state Y (for example, how
they should best attempt to communicate with the presentity, if at all, when
the principal is in state Y).

Extensions SHOULD also discuss:

- How, if at all, any presence states defined in the extension related to
<basic>, or to any relevant extension previously published in an RFC. For
example, "state Z implies OPEN, so it MUST NOT be used if a basic state of
CLOSED is expressed", or  "you should use the extension in this document,
not the extension in RFC QQQQ, if your circumstances are as follows...."
"

-- 4.3.3 Example Mandatory To Understand Extensions --

Change name to "Example Mandatory to Understand Elements".

In addition, this example currently contains a top-level mustUnderstand;
change the middle of this example to:

"
       <myex:complexExtension>
         <myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
         <myex:ex2>val2</myex:ex2>
       </myex:complexExtension>
"

-- 4.4 XML Schema Definitions --

At the very end of 4.4, the global attribute for mustUnderstand should be
removed. I'm not sure if it is possible to define how the mustUnderstand
attributes could be used by elements of extensions within an XML Schema.
Should we define a separate XML Schema defining mustUnderstand? Need some
more XML Schema expertise here.

"
     <xs:complexType name="status">
       <xs:sequence>
         <xs:element name="basic" type="tns:basic" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax" minOccurs="0"
            maxOccurs="unbounded">
            <xs:attribute name="mustUnderstand" type="xs:boolean"
default="0"/>
         </xs:any>
       </xs:sequence>
     </xs:complexType>
"

-- IANA Considerations --

This section needs an overview of extensibility, and a reference back to
4.2.5. I recommend using the following for Section 5:

"
This memo calls for IANA to:
 - register a new MIME content-type application/cpim-pidf+xml,
   per [RFC 2048],
 - register a new XML namespace URN for PIDF per [XML-Registry].
 - register a new XML namespace URN for status extensions per
[XML-Registry].

The registration templates for these are below. For more information on
status extensions, see section 4.2.5.
"

I recommend the following text for a new section 5.3:

"
5.3 URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim-
   pidf:status'

      URI
         urn:ietf:params:xml:ns:cpim-pidf:status

      Description:
         This is the XML namespace URI for XML elements defined by [RFCXXXX]
         to describe extensions to the status of CPIM presence information
in        
         application/cpim-pidf+xml content type.

      Registrant Contact
         IETF, IMPP working group, <[email protected]>
         Hiroyasu Sugano, <[email protected]>

      XML
         BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml">
           <head>
             <meta http-equiv="content-type"
                content="text/html;charset=iso-8859-1"/>
             <title>Namespace for CPIM status extensions</title>
           </head>
           <body>
             <h1>Namespace for CPIM presence information extensions</h1>
             <h2>application/cpim-pidf+xml</h2>
             <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
           </body>
           </html>
         END
"

-- Security Considerations --

I suggest replacing the existing text with the following:

"Because presence is very privacy-sensitive information, the protocol for
the presence information MUST have capabilities to protect PIDF from
possible threats, such as eavesdropping, corruption, tamper and replay
attacks. These security mechanisms must be able to be used end-to-end
between presentities and watchers, even if the watcher and the presentity
employ different presence protocols and communicate through a CPIM gateway.
Since the 'application/cpim-pidf+xml' MIME type is defined for this PIDF
document, staging security for PIDF at the MIME level (with S/MIME [x])
seems appropriate. Therefore, PIDF should follow the normaivge
recommendations for the use of S/MIME (including minimum ciphersuites) given
in the core CPIM specification.

Note that the use of timestamps in PIDF (see section 4.1.7) can provide some
rudimentary protection against replay attacks. If a watcher receives
presence information that is outdated, it SHOULD be ignored. A watcher can
determine that presence information is outdated in a number of fashions.
Most significantly, if the timestamp on presence information is older than
the last received presence information, it should be considered outdated.
Applications and protocols also are advised to adopt their own rules for
determining how frequently presence information should be refreshed. For
example, if presence information appears to be more than one hour old, it
could be considered outdated (a notification generated for this presence
information will not take such a long time to reach a watcher, and if a
presentity has not refreshed its presence state in the last hour, it is
probably offline)."

-----

Nits:

- The last paragraph of 4.1.5 (on the <contact> element) talks about
priority among tuples - surely this should be priority among contacts?

- The <tuple> 'id' attributes in the examples in 4.2.2, 4.2.4, 4.3.1, 4.3.2,
and 4.3.3 should be changed from their current form (which specifies some
sort of device or application name) to an opaque token, like a unique
identifier. 

- Is there a distinction intended between (d) and (g) in 2.1? If so, perhaps
it should be clearer. If not, I'd suggest that (g) be removed (since (d)
seems to be inclusive of (g)).



  [reminder: [email protected] for non-technical discussions, please]