Re: draft-ietf-impp-im-01 (was: Re: WG Last Call on multiple docu ments (deadline Jan 12))

Jon,

Monday, January 6, 2003, 7:24:22 PM, you wrote:
Jon> The one issue here that took me by surprise was your sudden recommendation
Jon> to upgrade the normative SHOULD for support of MSGFMT to MUST, on the
Jon> grounds that CPIM is no longer a system intended to interwork between
Jon> heterogenous systems. This suggested change has a few other ramifications
Jon> throughout your notes on this document set.

Forgive me if I indulge in a quick <sigh>.

Ok.  better now.  thanks.

Now I'll try to explain where I think the working group consensus is:

I remember the original CPIM mandate to be the definition of gateway
semantics, where gateways means among truly independent systems. The memory
is not fuzzy nor mine alone, and it dictated all of my own contributions to
that original effort.

Other folks have disputed this memory, claiming that, instead, we are
supposed to be working on a common data environment, with heterogeneous
transport protocols. This latter interpretation was the clear working group
consensus by the time of the last IETF meeting.

          So, the first requirement is that there be clear, documented
          consensus about the PRECISE goal of the working group.

          Folks need to appreciate just how remarkable it is that two
          document authors could be holding such different perceptions of
          that goal, at this point.

          Mark -- I believe this is yours to resolve. I was merely trying to
          work with what was -- I thought -- a painfully clear, current
          working group consensus, independent of my own sense of its
          efficacy or historical accuracy.

Assuming that, in fact, an end-to-end common data environment really IS the
current goal, then it makes no sense for its use to be in any way optional.
Remember that "should" means that people can do something else "if they have
a good reason". Think of it as being like doing Internet mail with RFC
822/2822 as being only a SHOULD.


Jon> We spent some time discussing this previously, and I thought we had agreed
Jon> to bring this issue before the IESG as a SHOULD, not a MUST.

We discussed security requirements and your memory of that matches mine.
We did not discuss whether the content format would be mandatory or
optional.

Now, one might claim that the only reason to have common format is to have
end-to-end security, but I'll claim that the real issue is deciding what the
heck we are trying to accomplish -- heterogeneous transport for a common
data environment vs. real, standalone gatewaying among truly independent
services, including those minor, strange secondary ones, like AOL and MSN.
This needs to be stated simply and clearly and to have equally clear working
group consensus. After that, engineering decisions get easy.

My own sense is that the group is still trying to satisfy very different
goals and to pursue them inconsistently. And, of course, I'd be delighted to
see the rough consensus that proves me wrong.



>>    TransID is a unique
>>    identifier used to correlate message operations to response
>>    operations.

Jon> We opted not to specify this, actually - it is listed just as an arbitrary
Jon> string. Different protocols will undoubtedly have different ways of
Jon> determining uniqueness that might be protocol-specific. I am kind of
Jon> surprised that you want to mandate some format, actually, since in the past
Jon> you have vociferous opposed mandating any sort of common formats for IM
Jon> protocol fields.

Oh.  Ok.

So, a megabyte string of random 8-bit values is a valid TransID and we
require IM nodes to properly support such a TransID?


>>    This specification defines an abstract interoperability mechanism for
>>    instant messaging protocols; the message content definition given
>>    here pertains to semantics rather than syntax.  However, some
>>
>>    [[ sorry, but this is no longer true.  this spec now defines mandatory
>>    content syntax, in order to enable end-to-end security.

Jon> It isn't mandatory - the test below says "SHOULD".

let's focus on the second word after mandatory:  syntax.   That's what I
meant to focus on, in the first place.

As I recall, msgfmt specifies a syntax and it is carried end-to-end and we
specified the syntax so it would be conformed to, in the current model of
end-to-end service that the working group rough consensus declared
recently.


>>    important properties for interoperability can only be provided if a
>>    common end-to-end format for instant messaging is employed by the
>>    interoperating instant messaging protocols.  Implementations
>>    therefore SHOULD support the format defined in MSGFMT [4].
>> <<
>>    [[ "should" made sense when this was a spec for translating among
>>    heterogeneous systems.  The spec now is for relaying among systems that
>>    use the same end-to-end content (and addressing) syntax and semantics.
>>    Therefore, the requirement now must be a MUST.  /d]]

Jon> Um... this is a somewhat major reversal philosophically... do you really
Jon> want to do this? I wasn't aware that we had changed the direction of the
Jon> spec, as you state above. When did we introduce this change?

I suspect this disparity is discussed to death enough, at the beginning of
this note.


>>    1.  If the source or destination does not refer to a valid INSTANT
>>        INBOX, a response operation having status "failure" is invoked.
>> <<
>>    [[ every node along a path must determine the complete validity of both
>>    source and destination fields?  This is not viable.  What is the real
>>    requirement?  /d ]]

Jon> I think it means that an endpoint/gateway may receive a messages for a
Jon> destination that plainly not semantically or syntactically valid (say, a
Jon> domain name in the URI that is unresolvable, or the username is not valid
Jon> for the endpoint).

But you are not sure.  Nor am I.  And I suspect we are not unique, and since
this is a specification, we need to get a precise definition.

Lest we seek to ignore 30 years of email experience, I'll note that
requiring any validation other than syntactic is problematic.


Jon> Again, I think this really depends on how we read the term 'service'. Does
Jon> it mean endpoints? Does it mean gateways? Does it mean intermediaries other
Jon> than gateways (proxies)?

well, the obvious response to your questions is that this is not a minor or
small issue and it needs to be clearly resolved.


Jon> I think this last paragraph suggests that it can mean gateways. I agree with
Jon> your analysis; this does create a dependency chain, effectively. I think
Jon> this is appropriate, however, in so far as the group in the past has wanted
Jon> end-to-end delivery confirmation for instant messages, not hop-by-hop
Jon> confirmation.

When a real-time dependency-chain like this was suggested for SMTP, it got
shot down.

Folks need to think in terms of the scaling and delay implications of such a
real-time dependency chain.


Jon> I agree that this is effectively like a DSN. Again, I thought this was what
Jon> we wanted.

as the sole acknowledgement mechanism, it has huge reliability implications,
all of them bad.

d/
-- 
 Dave <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850




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