Augmenting PIDF draft (Re: comments on draft-ietf-impp-cpim-pidf-05)

Okay.  Got it.
The list server checks the sender's address, right? 

I try again. 

-- Hiroyasu

==========================================
All,

Resending the message I sent 12 hours ago because I've
not received it from the list.

Sorry if you receive it twice. 

-- Hiroyasu 

==========================================
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]