Subject: RE: MSRP-10 - Empty Body (was RE: [Simple] Comments to MSRP-10)

From: Eric Burger <[email-masked]>
Date: Mon, 7 Mar 2005 17:59:51 -0500

Sounds reasonable to me.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, March 07, 2005 2:36 PM
> To: Eric Burger
> Cc: Simple WG
> Subject: Re: MSRP-10 - Empty Body (was RE: [Simple] Comments 
> to MSRP-10)
> 
> 
> I think it needs to be (2). There is already a mandated use for this: 
> when an MSRP connection is first established there is a 
> requirement to 
> send a message over this, with content if you have it, but otherwise 
> without content.
> 
> Since content can by of any content type, you can't assume that there 
> will always be an entry in a text conversation log for every received 
> message. Its a no brainer to put in an entry when you receive 
> text. You 
> may also put an entry in that log as a placeholder for other 
> content if 
> it makes sense. But I think it is quite reasonable that 
> certain content 
> types will be used for housekeeping and not be shown at all.
> 
> 	Paul
> 
> Eric Burger wrote:
> > What does it mean to *receive* a message with an empty body?  Is it:
> > (1) A null message, like sending a CRLF?
> > (2) A null message, like a ping?
> > (3) An error?
> > 
> > I was trying to figure out what the UAS (recipient) 
> behavior should be, but
> > I found no guidance.  Should the UI present something like:
> > 	Alice: Hi Bob
> > 	Bob:                  <Bob sends an empty body>
> > 
> > Or:
> > 	Alice: Hi Bob
> > 	                      <UI is silent on reception of empty body>
> > 
> > Unless there is a compelling reason not to, I would lean 
> towards the former
> > behavior.  I could see a theoretical use for a null body in 
> that if I wanted
> > to do an MSRP 'ping', I could send a null body with 
> Success-Report: Yes.
> > However, we would need to be clear on the behavior of the 
> recipient.  The
> > recipient would not display the message, yet generate a 
> success REPORT.
> > 
> > Does anyone NEED such behavior?  If not, let's just define 
> an empty body to
> > be the same as an empty message and be done with it.
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[mailto:[email-masked]]On Behalf
> >>Of Miguel Garcia
> >>Sent: Tuesday, March 01, 2005 9:14 AM
> >>To: Ben Campbell; Rohan Mahy; Cullen Jennings
> >>Cc: Simple WG
> >>Subject: [Simple] Comments to MSRP-10
> >>
> >>
> >>I am sending a few comments to version -10 of MSRP. They are mostly 
> >>editorials.
> >>
> > 
> > [snip]
> > 
> >>2) Section 5.4, 3rd paragraph:
> >>
> >>    "Likewise, the active endpoint MUST immediately issue a 
> >>SEND request.
> >>    This initial SEND request MAY have a empty body, or MAY carry
> >>    content."
> >>
> >>I would like to see some motivational text for such requirement.
> > 
> > [snip]
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Mar 2005 21:01:19 -0600

I had been assuming option 2 as well. We probably need to clarify this.

---

From: Adam Roach <[email-masked]>
Date: Tue, 08 Mar 2005 10:33:25 -0600

It seems to me that a lot of the behavior should depend on the indicated 
content type.

What I would propose is:

    * Empty messages with no content-type indicated act as the "null
      messages" mentioned below. This is what a client would send if it
      sets up a connection but has nothing to send immediately.
    * Messages with a content type but a zero-length body would be
      rendered to the user as appropriate for the indicated content
      type. So, for example, for a text body, the experience would be
      the "Bob sends an empty body" example given below. There may, in
      fact, be some content types for which sending a zero-length body
      is a perfectly acceptable, reasonable, and common thing to do.

/a

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Mar 2005 13:08:38 -0600

I agree. I was working under the assumption we were talking about 
messages with no bodies, as opposed to messages with bodies of zero 
length. That is, no content-type vs having a content-type and body 
length of zero.

On Mar 8, 2005, at 10:33 AM, Adam Roach wrote:

> It seems to me that a lot of the behavior should depend on the 
> indicated content type.
>
> What I would propose is:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Mar 2005 14:12:16 -0500

This seems reasonable to me if it is legal. I can't remember from mime 
perspective if it is ok to have a content-type with no body. (As I 
recall this isn't allowed in SIP.)

If so, it then becomes important to specify what the default content 
type is if there is none specified and there is no body. Or else we need 
to specify that a content-type is required even if there is no body.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 08 Mar 2005 13:26:38 -0600

Paul Kyzivat wrote:

> type is if there is none specified and there is no body. Or else we 
> need to specify that a content-type is required even if there is no body.

I think it is more sensible to say that *if* there is no content-type, 
*then* you MUST not include a body.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Mar 2005 14:43:54 -0500

Yes, this is emminently reasonable. Do you know if it is consistent with 
mime?

	Paul

---

From: Hans Persson <[email-masked]>
Date: Tue, 15 Mar 2005 17:04:30 +0100

>       sets up a connection but has nothing to send immediately.

It would also be useful for clients that have detected that they are
located behind a NAT to be able to send MSRP continously (every 15
seconds or whatever) to keep NAT bindings alive, I guess.

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210857   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/