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

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]