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

Yet more follows, though I don't think there's really much below on which we
disagree at this point.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Monday, January 06, 2003 11:10 PM
> To: Peterson, Jon
> Cc: 'Dave Crocker'; [email protected]
> Subject: Re: draft-ietf-impp-im-01 (was: Re: WG Last Call on multiple
> docu ments (deadline Jan 12))
> 
> 
[snip]
> 
>           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.
> 

I think the only reason that we hold such different perspectives is that we
arrived at  a hard-won compromise for the existing language which I haven't
heard you challenge until now. You know that my opinion is that we need e2e
security through gateways, and so on, and that therefore MSGFMT is more or
less necessary to mandate, but in the past I've been happy to defer to your
greater experience and insight and to adopt less stringent text. I am of
course happy to see you supporting what I agree to be the apparent consensus
of the WG, and what happens to be my own preference as well. I would be
relieved to change the text - I think it will get this through the IESG much
more smoothly. 

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

I do believe that e2e security is the rationale to have a common format, the
requirement that shows us why an e2e common format is necessary - in fact,
the MSGFMT draft explains its own existence in these terms and has done so
for some time. I agree that if we accept this rationale, and accept the
necessity of a common format, engineering decisions get easier.

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

Call me overly optimistic, but I think we're all on more or less the same
track.

> 
[snip]
> 
> 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?
> 

I'd be happy to assign a bound to the string if that would satisfy your
concern. How does 40 bytes sound?

[snip]
> 
> 
> >>    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.
> 

I think it goes beyond syntax to semantics at least in so far as gateways
may have to resolve the domain before forwarding the message. I think we can
clarify 1. to this effect, anyway.

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

Agreed, we can do something about the term 'service' in the draft.
Historically, the term 'service' probably had a connotation of a monolithic
service provider like AOL, which would operate its own gateways to interact
with CPIM protocols, say. I think a service should probably be clarified as
a protocol endpoint - which could be a gateway or could be an IM client.

[snip]
> 
> 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.
>

To be clear, we're not saying here that this is the sole reliability
mechanism that would be employed by an IM protocol. We do assume that IM
protocols which are gatewayable by CPIM can reliably deliver messages
hop-by-hop somehow (though it isn't our place to specify how - right?). When
crossing a CPIM gateway, however, some other form of e2e reliability is
required.

Looking at the text of impp-im-01, I do note that this assumption of
underlying reliability is tacit, and that this should be made explicit.
 
> 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]