comments on draft-ietf-impp-cpim-pidf-05

Sugano-san, all,

As I've been working through the CPIM framework document, I've been
comparing its contents to the PIDF draft in order to determine whether or
not we have a complete solution (and if not, trying to figure out where
things should be filled in). The PIDF document looks very strong - I think
it is quite close to completion. I do have a few issues below, some of which
I think are impactful.

If necessary, I'd be happy to provide text corresponding to any of the
issues below, provided the group believes they merit remedy.

Jon Peterson
NeuStar, Inc.

----

- I think the Security Considerations need to be expanded to account for a
number of security properties of notifications. First of all, RFC2779
dictates a MUST-level requirement for authentication and confidentiality
(while it doesn't mention integrity explicitly, it follows from these other
two) for notification. Therefore, the Sec Cons should at least note that the
requirement to support a security mechanism with these properties is at a
MUST level, not a SHOULD. Also, note that deferring this function to the
'transport protocol' (we might want to use another term here, to
differentiate this from layer 4 protocols - maybe 'using protocol'?) has a
number of dangerous implications, the most serious of which is that the
contents of a confidential notification would be revealed to a CPIM gateway
when an encrypted message was passed from one CPIM-compliant protocol to
another. I believe this security must be staged around the MIME body, not
the transport layer, if we're to have any hope of interoperability and
actual end-to-end security. One base security mechanism has to be required
for PIDF, including a minimum ciphersuite - although I suspect both of these
should probably be stated in the base CPIM spec, in order that the same
security mechanism is required for presence and instant messaging. Section
2.1 item (f) could probably be a little more specific about the security
requirements that are inherited from RFC2779 - (f) is more of a summary.

- A few things about timestamps. First, I think that 2.2 (b) should mention
RFC2779 Appendix A item A7. I think it needs to say that RFC2779 noted that
timestamps had some complications, but that their use in PIDF does not
require any global synchronization - that timing should be loosely
synchronized well within the uncertainty of disparate time sources. Section
4.1.7 should also offer a little guidance on semantics for watchers of
presence information with timestamps. The text here should at least suggest
that presence information is created at a particular time, and that presence
information ages; some CPIM-compliant watchers may choose to expire
information that is old (without specifying any recommended interval). I
also think this section could offer some normative recommendation for
presentities to include timestamps in presence information they generate -
maybe SHOULD. The Security Considerations should also mention the security
properties of timestamps in PIDF - that is, protection from out-of-order
delivery of presence information, and aging of presence information. The
threats that go unaddressed if presence information is sent without
timestamps should be described.

- PIDF rightly defines only a bare-bones presence format and a means to
extend that format. While I don't believe we need to add any more presence
functionality to the baseline PIDF, I do think that some further information
about how to extend PIDF could be extremely useful. We need to make it
easier for new presence states to be proposed as standard extensions to
PIDF. First, I believe that the document could greatly benefit from an
example of an XML Schema for an extension to PIDF that could be used as a
reference by those that intend to extend PIDF (perhaps an XML Schema
definition for the 'local' extension shown in 4.2.4). There is already an
example of how a PIDF body would look with such an extension, which benefits
implementers, but protocol designers could use some help with authoring
these extensions as well. Secondly, I think the document should offer some
guidance about how extensions are managed at a process level in the IETF or
elsewhere. Should extensions (with their XML Schema and motivational text)
be published as RFCs, or it enough to just register the URN in the
designated namespace? Is any particular review process required for these
extensions? Personally, I think that the semantics of these extensions merit
inclusion in an RFC, and that this should be strongly encouraged if not
required. If standardization is not encouraged, I fear this will lead to the
balkanization of presence extensions, the proliferation of many slightly
differing but unfortunately non-interoperable presence extensions that will
be used by competing protocols or providers.

- The mustUnderstand attribute in 4.2.3 provides some primitive but useful
capability-negotiation features for extensions to PIDF. However, I think
there is a unsolved problem with the use of this attribute. When a watcher
subscribes to a presentity, if the presentity generates presence information
that always uses a mandatory extension that the watcher doesn't understand,
then the watcher will always discard the presence information - there
doesn't seem to be any way for the watcher to communicate that it cannot
understand presence information containing a given mandatory extension
(there's no SOAP fault), or any way for them both to negotiate downwards to
<basic>. One could argue that this isn't that big a problem, but it could
pose a significant obstacle to interoperability, especially if the extension
mechanism encourages the development of proprietary or single-purpose
extensions. I think that ideally, there should always be a way to negotiate
down to something that all devices support, namely <basic>  - I suspect that
this is what RFC2779 3.1.1 and especially the second half of 3.1.4 really
meant (though I would be interested to know if anyone feels otherwise).
Without this, SIMPLE could develop SIMPLE-specific presence, APEX could
develop APEX-specific presence, and never the twain would meet. Three
solutions to this problem come to mind. First, I don't think RFC2779
requires us to have a mustUnderstand-like concept - we could abandon it,
saying that <basic> is mandatory and all extensions are optional (which
leads us to what the current text in the last paragraph of 4.2.4 describes).
Second, we could develop a concept that a subscription operation can specify
the presence extensions that the watcher supports, and use this to begin
some sort of negotiation process. Obviously, there are serious obstacles to
undertaking the second option; it would require a lot of new mechanism. The
third solution would be to note that this is an open issue in 4.2.3 and say
that we'll try to come back and fix it later (probably by developing some
version of the second solution). There are probably some other attacks on
this problem, but based on my current understanding, I'd recommend the
first.

- Nits:

1.0 - Second to last paragraph, last sentence: About extensibility and
scope. I think extensibility is within the scope of this memo - I'd suggest
striking this sentence.

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

2.2 - This section should note in a new item (c) the 'mustUnderstand'
attribute from 4.2.3, if it is still included in the PIDF draft. As far as I
can tell, 'mustUnderstand' does not derive from the requirements of RFC2779.

3.2 - The list here consists of (implicitly) mandatory and OPTIONAL elements
in a PIDF MIME body - would we benefit at all from having three levels of
granularity: MUST, SHOULD and MAY strength? It strikes me that 'human
readable comments' sound like a MAY, whereas timestamps (as I suggest above)
sound like a SHOULD.  

4.2.3 - The final paragraph contains a single sentence hinged on a should -
should that be a SHOULD? or a MUST? If it is a SHOULD, then maybe the
attribute would best be named 'shouldUnderstand'? Whatever the strength, the
sentence should be normative.
 



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