RE: Augmenting PIDF draft (Re: comments on draft-ietf-impp-cpim-p idf-05)

I agree - we are quite near the end of the discussions relevant to the PIDF
specification (and those covering the core CPIM spec, I believe).

I will put together a summary mail on the issues relating to PIDF that I've
been tracking, and provide some textual proposals. A similar mail for CPIM
material is also forthcoming.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Hiroyasu Sugano [mailto:[email protected]]
> Sent: Thursday, September 12, 2002 4:26 AM
> To: Peterson, Jon; [email protected]
> Subject: Augmenting PIDF draft (Re: comments on
> draft-ietf-impp-cpim-pidf-05)
> 
> 
> Jon and all,
> 
> Sorry for joining the discussions late.  I have been awfully busy for 
> a bunch of tasks I'm currently involved in.  But, now, I've caught up 
> all of the discussions. 
> 
> I really appreciate Jon's careful reading on the PIDF draft.  I believe
> his comments and fruitful discussions following to them will make 
> the specification much stronger. 
> 
> It seems to me that most of discussions are closing or near to close. 
> So I think it is a time to go forward for actual revision of the draft, 
> even though all the issues are not completely solved.  If there is no 
> serious objection, I'd like to ask cooperations from contributors 
> inlcuding Jon, Adrian, and Graham if they can.
> 
> Regards,
> 
> 
> -- Hiroyasu Sugano
> 
> 
> > 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]
> > 
> > 
> 



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