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

Jon,

Tuesday, January 7, 2003, 1:50:48 AM, you wrote:
Jon>  You know that my opinion is that we need e2e
Jon> security through gateways, and so on, and that therefore MSGFMT is more or
Jon> less necessary to mandate,

One more time:  that was about must/should for security, not message format.


Jon>   I am of
Jon> course happy to see you supporting what I agree to be the apparent consensus
Jon> of the WG, and what happens to be my own preference as well.

I don't support it, but I'm trying to work with it.

But this has nothing to do with the spec's mandating security. It has to do
with the spec's mandating the use of -msgfmt- content syntax. So the -im-
security related normative text is not what I have been commenting on.


>> So, a megabyte string of random 8-bit values is a valid TransID and we
>> require IM nodes to properly support such a TransID?
Jon> I'd be happy to assign a bound to the string if that would satisfy your
Jon> concern. How does 40 bytes sound?

If folks think that 320 bits -- assuming binary -- are enough for uniqueness,
sure.

Any other syntactic limitations, such as text versus binary?


>> Lest we seek to ignore 30 years of email experience, I'll note that
>> requiring any validation other than syntactic is problematic.
Jon> I think it goes beyond syntax to semantics at least in so far as gateways
Jon> may have to resolve the domain before forwarding the message.

Before forwarding, yes.  But why must the validation be done in real-time?

The answer probably touches on the larger issue of having a model that has a
real-time, end-to-end dependency chain for what is really a store and
forward model.




Jon> [snip]
>> 
>> Jon> I agree that this is effectively like a DSN. Again, I thought this
Jon> was what
>> Jon> we wanted.
>> 
>> as the sole acknowledgement mechanism, it has huge reliability
Jon> implications,
>> all of them bad.
>>

Jon> To be clear, we're not saying here that this is the sole reliability
Jon> mechanism that would be employed by an IM protocol.

We aren't. Where else are reliability mechanisms discussed?

Jon> Looking at the text of impp-im-01, I do note that this assumption of
Jon> underlying reliability is tacit, and that this should be made explicit.
 
Yup.  For both  -im- and -pres-.

For example my impression is that the IM service model has a fundamental
difference from the email service model in this regard. Email seeks very,
very high degrees of next-hop reliability, including survival through a
power outage, whereas I believe IM does not.

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]