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

I am inclined to agre with Graham that there is value in mustUnderstand, 
even if no matching protocol mechanisms exist in CPIM to deal with it. 
Such mechanisms could (and do) exist already in the actual protocols 
that are CPIM-compliant.

I can give a concrete analogy in the SIP world. SIP is a protocol, and 
it carries around a document format that describes sessions. This 
document is typically SDP, RFC 2327. SDP is extensible, but there is 
nothing you can do to in SDP to indicate that an extension is mandatory. 
However, SIP has mechanisms built in to support reporting of errors in 
the SDP (for example, malformed, or missing information). The lack of a 
"mustUnderstand" capability in SDP has bit us a few times, at least. 
Several SDP extensions needed this. However, because it wasnt there, we 
had to rely on SIP capabilities in this regard (the Require header) to 
indicate mandatory extensions to the body. This was definitely a kludge, 
in my opinion.

There are many things a real CPIM-compliant protocol will need to tell 
you about problems in the presence documents received in a notification. 
Just because its not in CPIM today, doesn't mean a real protocol doesn't 
need it - its just not needed for baseline interop. One of the things 
which can definitely be wrong with the presence document are that it 
requests mandatory support for an extension that is not understood.

Here is an example. Lets say we define a PIDF extension for partial 
notifications. A partial notification contains only that information 
which has changed. A partial notification would include a sequence 
number, and a flag to indicate whether the information in the document 
is actually partial, or full. If you do not understand this extension, 
the presence document is just WRONG.

Supporting partial presence doesn't require changes to the presence 
protocol itself; its all about properly interpreting the series of 
documents returned by the presence protocol. Indeed, I could receive 
these presence documents through different transports, and still 
reproduce the current presence state, since the documents themselves 
tell me everything I need to know to do that. Thus, I would argue that 
partial notifications is an example extension that is ideally done 
within the presence document, and would not be workable without a 
mustUnderstand kind of attribute.

The presence protocol will need to support a failure message and an 
indication of the reason for failure, of course. We do that in SIP 
through warn codes. Other protocols would do different things.

-Jonathan R.


Peterson, Jon wrote:
> I think we're getting closer, but we still have a ways to go. Overall, I
> maintain that the notion of mandatory extensions requires better motivation
> - it isn't clear to me that the underlying assumptions of CPIM require PIDF
> to have mandatory extensions, just extensions. In fact, I think the language
> of RFC2779 regarding presence extensibility favors compatibility ("without
> undermining or rendering invalid the fields of the common format"). Saying
> that it might be nice in ways we don't now understand to have mandatory
> extensions isn't enough, I think, considering that we do have a good deal of
> flexibility without mustUnderstand, and there are some challenges we'd need
> to resolve before we could go forward with it.
> 
> Details inline.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
>>-----Original Message-----
>>From: Graham Klyne [mailto:[email protected]]
>>Sent: Wednesday, August 28, 2002 4:59 AM
>>To: Peterson, Jon
>>Cc: '[email protected]'; '[email protected]'
>>Subject: RE: comments on draft-ietf-impp-cpim-pidf-05
>>
> 
> [snip]
> 
>>Maybe, my comment should have been:
>>[[
>>A possible fourth approach, which I prefer, is to say that an essential 
>>presence notification MUST NOT contain top-level mandatory-to-understand 
>>extensions in the absence of explicit knowledge that the intended
> 
> recipient 
> 
>>can understand them, or some other mechanism to recover from a recipient's
> 
> 
>>failure to udnerstand the message.  This effectively combines your first 
>>and third options, but with a defined hook for future extension without 
>>adding any new mechanism at this  time.
>>]]
>>
> 
> 
> In your notes below, I haven't seen any further defense of the 'explicit
> knowledge' condition described above. I think this 'explicit knowledge'
> concept is potentially a significant threat to interoperability for reasons
> I have previously outlined. That alone removed from the paragraph above
> would go a long way for me. We should not be encouraging out-of-band
> presence capability negotiation that is specific to using
> protocols/providers rather than a component of the CPIM system. 
> 
> 
>>There are three get-outs here:
>>(a) top-level (mandatory elements may still be nested in optional
> 
> extensions)
> 
> It makes more sense to me that a nested element could be mandatory. In fact,
> I would be fine with mustUnderstand if it were ONLY allowed in nested
> elements defined by extensions. Any extension could just define its own
> version of mustUnderstand if we didn't do so.
> 
> 
>>(b) reference to essential presence information -- future applications may
> 
> 
>>use separate notifications to convey information whose interpretation 
>>requires mandatory extension
> 
> 
> With regard to essential information - I have a hard time envisioning how
> any extension could entail that it is inappropriate for a watcher to use
> <basic> presence when it is available. What requirement says that a
> presentity should dictate how a watcher evaluates presence information,
> anyway? If a watcher cannot understand some extension, but <basic> is also
> present in the message, why should the presentity be entitled to boss the
> watcher around, and to say that the watcher can't make use of <basic>? No
> new extension gets to change the meaning of <basic>, right? If it did, that
> would certainly go against RFC2779 (3.1.4). If <basic> doesn't make sense
> for the type of presence being expressed, then since it's optional, the
> presentity shouldn't send it - but if it is sent, no 'mustUnderstand' sort
> of concept should preclude its use by the watcher. We are trying to foster
> interoperability here, right? Maybe if we're going to have 'mustUnderstand',
> it shouldn't apply to <basic>.
> 
> The issue of separate notifications begs deeper, darker questions about
> mustUnderstand as well. If we allow partial notifications (in which not all
> of the presence information known by a presentity is sent in a single
> notification), what implications does that have for mustUnderstand? If I
> send one complete notification that contains all of my presence information
> (<basic> and several extensions, say) including one mandatory extension that
> a given watcher doesn't understand, that watcher must discard all of my
> presence information; but, if I send two partial notifications, one of which
> contains the mandatory extension and a second that does not, that same
> watcher can accept and process any presence information in the second
> notification, correct? If so, that makes the operation of mustUnderstand
> seem kind of arbitrary - especially because partial notifications might
> occur for any number of reasons. Splitting presence information into two
> notifications probably shouldn't change how mustUnderstand operates over
> your presence information. But I think it would be worse if we assumed
> otherwise - that if you ever receive a notification from a particular
> presentity that contains a mandatory extension that you don't understand,
> that you subsequently shouldn't process any presence information from that
> presentity. 
> 
> I think we'd need to work these sorts of things out before mustUnderstand
> would be adequately specified.
> 
> 
>>(c) reference to other recovery mechanism;  an extension might provide a 
>>means to say "I don't understand that -- here are the extensions you used 
>>(if any) that I understand".
> 
> 
> That would entail some new CPIM message in response to a notification, not
> just an extension to PIDF. Since a CPIM-layer response to notification is
> not provided in the standard, this sounds like a recipe for layer violation
> - the extensibility of PIDF shouldn't change the CPIM model. Capability
> negotiation, if it is supplied, should be in one layer or another, not half
> in PIDF and half in the using protocol. That certainly would not encourage
> interoperability.
> 
> With the tools defined in the base CPIM specification I'm not sure that we
> have the means to create a recovery mechanism. I had suggested as a
> possibility that a subscription operation could enumerate the presence
> extensions known or desired by the watcher - this would have much the same
> effect as defining some error operation in CPIM while re-using an existing
> operation, but it would still require substantial protocol work.
> 
> 
>>>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.
>>
>>That sounds to me like mustUnderstand nested in an optional extension.
>>
> 
> 
> And I do think those are more reasonable.
> 
> [snip]
> 
>>But, FWIW, the Internet fax specifications took this approach in the
> 
> first, 
> 
>>simplest version of the specification and then went on to define 
>>mechanisms.  It was a very effective process device for getting consensus 
>>around the first, very simple, version of the specification.
>>
> 
> 
> Though I admittedly haven't really followed Internet fax, I'm not sure that
> fax has quite the same interoperability concerns - unless I'm mistaken they
> weren't defining an abstract protocol that would be run over multiple
> underlying protocols and operated by multiple camps with a history of
> exclusionary behavior. mustUnderstand is a tool that seems like it will
> likely be used to hamper interoperability, if only as a matter of expedience
> rather than a conscious effort to be closed. If we can avoid it, I'd rather
> not have to build this tool into the protocol. 
> 
> 
>>Hmmm.... I have vague recollection of another specification with a similar
> 
> 
>>mandatory extension idea, that added some cautionary words about 
>>interoperability failures caused by capricious use of mandatory 
>>extension.  I can't remember what spec right now.  The words were aimed 
>>partly at commercial products that might choose to implement extensions as
> 
> 
>>a way to create client lock-in.
>>
>>Aha... I recalled it -- it's the CPIM message format 
>>specification, section 
>>3.5, which says:
>>[[
>>          NOTE:  indiscriminate use of 'Require:' headers could
>>          harm interoperability.  It is suggested that any
>>          implementer who defines required headers also publish the
>>          header specifications so other implementations can
>>          succesfully interoperate.
>>]]
>>which isn't quite the same thing.  Oh well.
>>
> 
> 
> Heh - I haven't written my comments on MSGFMT yet. Maybe next week.
> 
> 
>>#g
>>--
>>
>>
>>
>>>>-----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]>
>>>>
>>-------------------
>>Graham Klyne
>><[email protected]>
>>
>>
>>
>>
>>  [reminder: [email protected] for non-technical 
>>discussions, please]
>>
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical discussions, please]
> 


-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




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