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

If the sender knows that the recipient can use the extension, why do they
need to mark it mustUnderstand at all? The only point of marking an
extension mustUnderstand is to require that the recipient fail processing
the presence information if they don't understand the extension (that's the
only resulting behavior described in cpim-pidf-05, anyway). Well, therefore,
if the sender knows somehow that the recipient can understand it, there
doesn't seem to be any point in marking it as mandatory. 

Maybe what you really want is a 'mustUse' indicator - if you understand
this, then you must use it (whatever that would entail)? That would be very
different from how mustUnderstand is specified today.

I am also a little concerned about the way that the sender 'somehow' knows
that the recipient supports the extension. The big problem with
mustUnderstand is that it cannot fully negotiate capabilities - but I
hesitate to suggest that some out-of-band mechanism (either at a protocol or
administrative level) should fill in the blanks. I fear the result will be
balkanization - I share my full presence information only with the community
that I know has the capability to understand it, i.e. others using my
protocol/provider.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Graham Klyne [mailto:[email protected]]
> Sent: Tuesday, August 27, 2002 5:15 AM
> To: Peterson, Jon
> Cc: '[email protected]'; '[email protected]'
> Subject: 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]