Subject: [Simple] Details on MSRP Details (DSN)

From: Eric Burger <[email-masked]>
Date: Sun, 16 May 2004 11:58:56 -0400

I am back after a hiatus.

I have not read the latest message-sessions draft.  However, I have read
some discussions on the list about it.

One substantive issue: The status code is NOT a parsing of the three digits
of HTTP/SIP.  The first digit does map directly.  However, the other
segments are 3-digit sequences conveying much more detailed status
information.

A bigger issue comes out when you read the discussions on DSN, fragments,
SAR, message size, etc.  From a big picture, a high-level description of
MSRP is... "We have invented TCP, and it runs over TCP."

What triggered this thought?  The idea of tossing DSN's after a session
completes.  This brings us right back to where we started: DSN's DO NOT MAKE
SENSE FOR SESSION MODE TRANSACTIONS.  They make sense for store-and-forward,
but they do not for interactive sessions.  We have Layer 8 (user) protocols
to deal with it, e.g., "did you get my message?".

If the counter-argument is, "what if they didn't read it", then I would
suggest sending a registered letter.  But seriously, I didn't know that
replacing SMTP was in the charter.

--
- Eric

P.S. Unfortunately, I will not be attending the f2f, so don't hold back
responses - either privately or on the list.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Eric Burger <[email-masked]>
Date: Sun, 23 May 2004 21:49:24 -0400

Relays are the ONE place that DSN's make sense.  Note that a real DSN won't
tell you if the recipient read the message, only that their UA received it.

-----Original Message-----
From: Ben Campbell
To: Ben Campbell
Cc: Eric Burger; [email-masked]'
Sent: 5/21/04 5:31 PM
Subject: Re: [Simple] Details on MSRP Details (DSN)

Oops, itchy trigger finger. I meant to say that, with relays, you either

need to make an upstream transaction pend on a downstream transaction, 
which has nasty chaining properties; or you need some way for a relay to

tell you that it could not deliver the message.

Ben Campbell wrote:

> Eric Burger wrote:
> I agree they don't make sense for peer to peer sessions. That is why
we 
> want them to be optional. Further, it may make sense to make the
default 
> be no DSN at all, at least for peer to peer sessions.
> 
> But when you introduce relays, the fact that you successfully
delivered 
> a message to the relay does not mean the relay can successfully
deliver 
> it downstream. This means you either have to make the upstre
> 
> 
>>

---

From: Eric Burger <[email-masked]>
Date: Sun, 23 May 2004 21:49:24 -0400

-----Original Message-----
From: Ben Campbell
To: Ben Campbell
Cc: Eric Burger; [email-masked]'
Sent: 5/21/04 5:31 PM
Subject: Re: [Simple] Details on MSRP Details (DSN)

we 
default 
delivered 
deliver