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

I'm following this conversation but am too busy right now to get involved 
in detail.  For the purposes of making progress, can we agree to restrict 
use of mustUnderstand to nested optional elements, leaving the <basic> to 
be always interpretable, as Jon indicates?  I'd be happy to take a shot at 
drafting something, but I suspect someone else will be able to do so sooner 
than I.

#g
--

At 05:30 PM 9/5/02 -0400, Peterson, Jon wrote:

>I think ultimately, there are two issues here. The first speaks to the same
>matter as my first mail today - what do we require of the using protocol
>versus require in some IMPP-layer object or function, and in either case
>what exact mechanism is entailed.
>
>Below, it sounds like you agree that mustUnderstand can't work without some
>kind of error response mechanism (playing the part of the SOAP fault). The
>question then is what layer that response should be in, and what influences
>it would have for interoperability (and CPIM gateway design) if it were in
>one layer as opposed to another. Mapping SIP warning codes in a CPIM gateway
>to some complimentary function in APEX does not sound like fun. The fact
>that we will need to make up new SIP warning codes to correspond to PIDF
>errors is also not fun. Doing the same in APEX, PRIM, etc makes the
>alternative, designing a CPIM-layer response to notifications, seems more
>palatable, I think. If we're going to have mustUnderstand, a good argument
>can be made that we should define a CPIM-layer response to notifications.
>Incidentally, this is orthogonal, I think, to whether or not the
>mustUnderstand attribute would be a part of the PIDF document or some other
>CPIM function - I'm only speaking to how the error response would be
>managed.
>
>The second issue is that that the whole concept that there need to be
>mandatory extensions to PIDF is still unproven, I think. SDP is a very
>different sort of document than PIDF. PIDF is informational in nature, SDP
>is a protocol (an offer/answer protocol in any reasonable implementation)
>that negotiates common communication capabilities. I believe that the
>extensibility for presence information required in RFC2778/RFC2779 speaks
>only to providing additional information, not to changing how the protocol
>or format operates.
>
>    3.1.4. There MUST be a means of extending the common presence format
>    to represent additional information not included in the common
>    format, without undermining or rendering invalid the fields of the
>    common format.
>
>What I find unacceptable about mustUnderstand from an interoperability
>perspective is the notion that because I do not understand one extension in
>a PIDF object, I therefore cannot understand <basic> in that same object -
>that implies that the extension changes the meaning of <basic> (definitely
>ruled out by 3.1.4).  I think a reasonable case can be made that 'additional
>information' should never be mandatory; nothing in RFC2779 leads me to
>believe that presence extensions should have a concept of being 'mandatory'
>or exclusionary in this sense. I think my interpretation of the extensibiliy
>requirement in RFC2778/RFC2779 is also vastly simpler to design and
>implement. I tend to favor simpler interpretations of these requirements
>whenever possible, because we are trying to define the minimum possible set
>of functions required for an interoperable multi-protocol fulfillment of
>those two RFCs.
>
>As a side note, we should have another thread about partial v. full
>notifications in PIDF - there are a lot of interesting issues with that.
>
>Jon Peterson
>NeuStar, Inc.
>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email protected]]
> > Sent: Thursday, September 05, 2002 2:33 AM
> > To: Peterson, Jon
> > Cc: 'Graham Klyne'; '[email protected]'; '[email protected]'
> > Subject: 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
> >

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




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