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

[For those who don't want to read the details, I later suggest compromising 
on mustUnderstand being used only within optional extensions.]

Jon,

I fear this discussion is ratholing.  I don't have the motivation or 
commitment to my suggestion to argue this indefinitely, but I'll make one 
more attempt and then consent to whatever the WG decide.

You make a number of reasonable points with respect to the current 
specification:  according to the immediate requirements, it fairly clearly 
does not need mustUnderstand, so there is a clear argument for dropping it.

But, and this is my real concern here, if one assumes that the 
specification will be extended in the future, defining mustUnderstand now 
provides a safeguard for future extensions that must be understood, or 
incur undetected mis-interpretation.

Here's a hypothetical scenario (applied to instant messaging):

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.)

I agree with your other point that this presumes a failure reporting 
mechanism.  But note my earlier comment about independent development of 
format and protocol.  You may argue that this isn't an important issue for 
presence notification -- maybe, but it's difficult to predict the future.

So my case ultimately rests on the assertion that a mustUnderstand type of 
mechanism, in conjunction with allowing new extension elements in the 
protocol, is a cheap and increasingly adopted mechanism for laying a path 
to future extensibility without trying to second-guess what extensions may 
be required.

I think including this is a minimal route to satisfying the spirit, if not 
the letter, of the extensibility requirement in RFC 2779:
[[
    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.
]]
which makes it clear that future extension beyond the current functionality 
is clearly envisaged by the requirements.  If we presume, now, that such 
extensions can always be ignored by unextended clients we may be creating 
difficulties for future designers of these extensions.

Some further comments inline...

At 06:24 AM 8/29/02 -0400, Peterson, Jon wrote:
> > 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.

What is out of band?  A system may be built from several distinct protocols 
to perform complementary purposes -- indeed, that's what I understand to be 
underlying presumption of the IMPP model (separate protocols for IM and 
presence, used together to create an IMPP system).  I think it's a hallmark 
of successful IETF protocols that they have been assembled from small 
largely independent pieces rather than built as single monolithic structures.

> > 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.

I guess that might be workable in the case of presence, particularly in 
light of RFC 2779 requirement 3.1.1, even if I'm wary about trying to 
second-guess the future:
[[
    3.1.1. All ENTITIES MUST produce and consume at least a common base
    format for PRESENCE INFORMATION.
]]
(particularly the "MUST ... consume" bit).  Maybe this is a suitable basis 
for compromise?

[...]

[The rest is not really relevant to my argument ... bored readers may skip]

> > 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.

Actually, I think Internet fax faced a quite similar position:  forging 
consensus among quite distinct world-views of how to achieve some 
goal.  Not based in different protocols, but in deep differences of view 
about how an existing suite of protocols could be used and extended.  The 
logjam was eventually broken by focusing an initial effort an a *very* 
basic core functionality which had a mandatory-to-implement baseline that 
was guaranteed to be understood by all compliant parties, but leaving open 
possibilities for deploying additional functionality which absolutely 
*could* result in non-operability of the kinds you describe.  Enhancements 
that build on that initial basic specification have since proposed 
mechanisms to allow desired extended behaviours to be deployed without 
causing undetected non-interoperability.  But, to date, it's only the very 
basic specification that is advancing to Draft Standard.

(If there is a difference from Internet Fax here, I think it is that most 
of this WG currently believe that the requirements set out in RFC2779 are 
sufficient for the foreseeable goals of IMPP.  That sense of sufficiency 
was clearly not widely held for the initial target of Internet Fax.)

>.... 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.

I agree that would be a very undesirable outcome.  If you really believe it 
would be used that way then I agree you are bound to oppose my 
suggestion.  I suppose I don't expect developers to use it capriciously (as 
with the scope for incompatible extension in Internet fax) because to do so 
would clearly be defeating the purpose of using a standard in the first place.

#g


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




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