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

At 02:07 AM 8/27/02 -0400, Peterson, Jon wrote:
>- 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.

A possible fourth approach, which I prefer, is to say that a presence 
notification MUST NOT contain mandatory-to-understand extensions in the 
absence of explicit knowledge that the intended recipient can understand 
them.  This effectively combines your first and third options, but with a 
defined hook for future extension without adding any new mechanism at this 
time.

#g



-------------------
Graham Klyne
<[email protected]>




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