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

As I said before, restricting the use of 'mustUnderstand' to nested elements
within (optional) extensions is acceptable to me. I definitely support your
reading of RFC2779 3.1.1. Once again, it is good to be able to come to
consensus.

While I too fear rat-holes, I do want to make sure we give this, and the
other important issues in PIDF, due diligence. A few more notes below on
your motivational example for mustUnderstand, just trying to make our
consensus as firm as possible.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Graham Klyne [mailto:[email protected]]
> Sent: Friday, August 30, 2002 3:42 AM
> To: Peterson, Jon
> Cc: '[email protected]'
> Subject: RE: comments on draft-ietf-impp-cpim-pidf-05
> 
> 
[snip]
> 
> Let us suppose that a future extension of instant messaging is required to

> provide confirmation of receipt of a notification -- for example, in 
> support of a real-time auction application.  In the absence of a 
> mustUnderstand mechanism, an enhanced client requesting confirmation from
a 
> legacy client has no way to determine whether or not the message was 
> received, thus defeating the purpose of the extension.  (We encountered 
> just such problems when trying to define email enhancements in the
Internet 
> Fax working group:  the availability of a UA-to-UA mustUnderstand type 
> mechanism would have made life very much easier.)
> 

First of all, I must contend that this is a little bit circular - your
motivation for a mechanism that is broken without a error response
capability is to use the extension to define a response capability and then
claim it's fixing the response problem - but in fact this problem is only
introduced by adding the mechanism, so that can hardly motivate the
mechanism. We have already acknowledged that mustUnderstand would not be
broken if there were a notification response capability, and that's
presumably true whether the response were defined in CPIM or in a
PIDF/MSGFMT extension - but if the response is absolutely necessary for the
use of mustUnderstand, surely we wouldn't just want to define it in an
extension. But that aside...

In your example above, doesn't it strike you as odd that we use a PIDF
extension to express whether or not a notification should get a response?
Isn't there a layer distinction between a notification and a presence
document? If we need a system of extensibility to know things like that a
notification gets a response, I think that should be part of the
notification operation in CPIM, not part of the PIDF document. Think about
that one for a minute. Is it really an aspect of your presence information
that a notification gets a response? The way the extensibility requirements
are worded in 2778/2779 makes me think that these extensions are intended to
be for expressing more detailed presence states than OPEN and CLOSED, not
for changing the way the underlying protocol operates by giving commands to
watchers (e.g., send me an instant message saying "I got it!"). This view
that extensions to PIDF are supplemental information also supports the idea
that extensions probably don't need to be mandatory. 

As I said when I first supplied my comments on cpim-pidf-05, my notes were
motivated by my goal to close issues in the core CPIM specification.
'mustUnderstand' is only half of a capability negotiation system because the
other half cannot be instantiated in the existing CPIM model.  My main
concern when I studied mustUnderstand was that it had implications for core
CPIM messaging - either it required error reporting (a new notification
response message) or additional specification the subscription operation.
The possibility of mandatory extensions seemed to imply a need for
extensibility in CPIM, rather than PIDF, if it were going to be anywhere.

Any notes on further material below would be drawing us into the rat-hole I
think...



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