Subject: [Simple] Comments on message-sessions-02

From: [email-masked]
Date: Wed, 5 Nov 2003 17:47:36 +0200

Some comments below are more serious that others. Please respond to the ones that you think will cause some discussion is separate emails:

- General:
  - Should we use URI in the text instead of URL? The RFC that is referenced talks about URI (note if the references section, it wrongly says URL)

- Section 4: 
   - It should mention that a SEND request is also used as a keepalive mechanism (it is stays that way)-
   - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip  
   - This section also talks about inactivity timer, and says that that hosting device invalidates the session state when timer expires. Why is it just the hosting device?

- Section 5.1:
   - Is this section normative? It have normative text like SHOULD and SHOULD not.

- Section 5.2:
   - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mime-type. In this way, the other endpoint does not use that session to send normal messages.
   - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session alive. Eg: if you have a session for text/plain and you create a second one to send a 5gb video file, the text/plain session can be used to keepalive both sessions since they are both to the same remote end.

- Section 6:
   - Reference to RFC 3264 is probably needed here.
   - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we need to include the session attribute carrying the session URI again? What do we set the direction attribute to, if set at all in the second offer? Some text and examples for this issue is needed.

- Section 6.1:
   - The example is missing the accept-types attribute.

- Section 6.3:
  - the BNF provided allows accept-types to have multiple *. eg: a=accept-types: * * *
    It should be fixed to something like: 

               accept-types       = accept-types-label ":" format-list
               accept-types-label = "accept-types"
               format-list        = "*" / format-entries
               format-entries     = format-entry *( SP format-entry)
               format-entry       = (type "/" subtype)
               type               = token
               subtype            = token

   - Need to reference the ABNF RFC
   - This section should mention that the offerer should use the accept-types in the answer to send.

- Section 6.4:
   - "format entries from the m-line SHOULD NOT be repeated in this attribute". Should say accept-types instead of m-lines.

- Section 7.1:
   - msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
                                                      ^^^
   - @ is missing after userinfo
   - Should include server in the BNF since the text mentions server many times, but its not to be seen in the BNF. So BNF would look like:
     msrp_url = "msrp" ":" "//" server ["/" resource]
     server   = [userinfo "@"] hostport
     resource = 1*unreserved
   - Should mandate the resource when the msrp URI is present in an SDP offer

- Section 7.1.2:
   - Why is there text describing the use of SRV if no port is present? The port is mandatory and therefore resolving should fail if no port is present. INVITE requests would then be rejected. If we want SRV, then we need to relax the MUST for port.

- Section 7.4.1:
   - The last step before section 7.4.2 talks about Exp header. That should not be there. There is no Exp header in a 200 response to a visit.

- Section 7.4.3:
   - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the very large message being sent again (long messages have the potential to falsely timing out and the sender gets a 500 response).
   - Open issue: NO.

- Section 7.4.4:
   - an INVITE request can also terminate a message session (port 0). That should be noted along side the SIP BYE example. Otherwise implementers will think that only a BYE can terminate a message session.
   - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200 responses to SENDs until it has received a 200 for the SIP BYE. The recipient of the SIP BYE should cease responding to SENDs as soon as it sent a 200 for the SIP BYE. This allows more outstanding SENDs to complete.

- Section 7.4.5:
   - Open issue: I don't understand the open issue.
   - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it.

- Section 7.5.1:
   - Steps for a Relay receiving a BIND request. Step 3 refers to section 7.4.5, but that section talks about inactivity timer.
   - How dies the host communicate the pre-visit timer to the visitor?
   - Steps for a Relay receiving a VISIT request. The last step should mention that the pre-visit timer is no longer valid.

- Section 7.7.2:
   - Need to mention that SEND is also used for keepalive. Or preferably, we can define an new method like KEEPALIVE as been discussed. If not, then the SHOULD contain MIME should be relaxed.

- Section 8:
  - Many examples don't have the CFLF between header and body in MSRP messages.

Regards,
Hisham

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

---

From: [email-masked]
Date: Mon, 10 Nov 2003 22:53:57 +0200

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 7:16 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Comments on message-sessions-02
> 
> 
> Hi--I addressed some points in separate emails. Others inline:
> 
> [email-masked] wrote:
> 
> [...]
> 
> > - Section 4: 
[snip]
> 
> >    - This section also talks about inactivity timer, and 
> says that that hosting device invalidates the session state 
> when timer expires. Why is it just the hosting device?
> 
> Let me turn that question around. Why would any other device need to? 
> When the hosting device closes the session, the endpoints 
> will learn of 
> it in short order as they get their connections closed. So will a 
> visiting relay, for that matter (although I do think we have an open 
> item on whether visiting relays should have to worry about the timer.)

Why does the visiting peer have an inactivity timer then? It also needs to clear up state on its end when the timer fires.

> Yes, section 5.1 is intended to be normative, although it contains no 
> statements stronger than SHOULD. But we mean those SHOULDs 
> just as much 
> as any other SHOULDs in the document. :-)

maybe those SHOULDs and SHOULD NOTs should be changed to lower case :)

> 
> > 
> > - Section 5.2:
> >    - Open issue: the attribute accept-type can be used to 
> restrict the use of a message session. So if a session was 
> created to send mpeg video. The accept-types attribute should 
> only carry that mime-type. In this way, the other endpoint 
> does not use that session to send normal messages.
> 
> That is an interesting approach. But I think we may have overlap in 
> types that are allowed on an IM session, and types that are 
> allowed on a 
> file transfer session. What if I want to transfer a large 
> file of type 
> text/plain?

Excuse my ignorance, but don't files have their own mime-type text/something?

[snip]
> The example in 6.1 is explicitly just an m-line, not an 
> entire SDP document.

But the text above the example indicates that the example shows the accept types.

> That does not seem to allow for something like "a=accept-types: 
> message/cpim text/plain *", which is semantically meaningful. I can 
> change the syntax to only allow one "*", but do we really 
> care? "* * *" 
> may be silly, but it can still be interpreted reasonably.

what does it mean to say "a=accept-types: message/cpim text/plain *" ? * is enough in this case and encapsulates  message/cpim and text/plain.

> 
> [...]
> 
> > - Section 7.1.2:
> >    - Why is there text describing the use of SRV if no port 
> is present? The port is mandatory and therefore resolving 
> should fail if no port is present. INVITE requests would then 
> be rejected. If we want SRV, then we need to relax the MUST for port.
> > 
> 
> It is not mandatory for a URL that designates a relay that is 
> handed to 
> an endpoint out-of-band. (For example, when a user configures 
> a client 
> to use a relay.)

Section 7.1 says: 

"An MSRP URL server part identifies the hosting device of an MSRP
   session. If the server part contains a numeric IP address, it MUST
   also contain a port"

So maybe you need to add text differentiating between a relay URL and a session URL.

/Hisham

---

From: [email-masked]
Date: Tue, 11 Nov 2003 05:05:41 +0200

> Sent: Monday, November 10, 2003 11:03 PM
> > Why does the visiting peer have an inactivity timer then? 
> It also needs to clear up state on its end when the timer fires.
> > 
> 
> It needs it so that it knows when and if it needs to send traffic to 
> avoid having the host device kill the session.

well, that was my point. The text in that specific section omits this information about the visitor.

> 
> > 
> >>>- Section 5.1:
> >>>   - Is this section normative? It have normative text like 
> >>
> >>SHOULD and SHOULD not.
> >>
> I am not sure of the point. You are suggesting they should not be 
> normative? Why?

I think this whole section 5.1 is just informative. EG: "Therefore relays SHOULD NOT be used indiscriminately", how is that a protocol normative text?

> It may be my own ignorance speaking, but I would expect a 
> text file to 
> have a mime type of text/plain. Which is also a reasonable 
> type for an IM.

text/plain does not tell you there is a file attached. I believe it has its own mime type.

> > what does it mean to say "a=accept-types: message/cpim 
> text/plain *" ? * is enough in this case and encapsulates  
> message/cpim and text/plain.

Does your silence on this issue means you agree?

> relay URL and a session URL.

Also here??

/Hisham

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2003 21:32:56 -0600

> believe it has its own mime type.

Errmm... no. The mime type doesn't indicate anything about whether
the content is supposed to be rendered to the user or saved to a
file. What you're thinking of is Content-Disposition.

  http://www.ietf.org/rfc/rfc2183.txt

So, if you wanted to hint that a text/plain payload should be saved
instead of rendered, I would submit that adding a Content-Disposition
header to MSRP would achieve the effect you want.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Nov 2003 11:27:16 -0600

Aki Niemi [mailto:[email-masked]] writes:

> These are somewhat orthogonal aspects of a message session. It is 
> probably useful to label a specific session as e.g., file-transfer

Yes. You do this by using port 21. If you know a priori that all
you are going to do is transfer files, the IETF has already
defined a file transfer protocol.

> It is another thing to state the disposition of a message. 
> Although in a file transfer session, all messages would likely
> have the same disposition (like "attachment"), it would still
> be useful to list other things like filename per each message.

I think you want the "filename" parameter defined in RFC 2183.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Nov 2003 16:12:01 -0600

At the risk of beating a dead horse even more: I wasn't trying
to make the point that MSRP should never be used for file
transfer (although the purist in me still believes this to be
"correct").

My point was that if you were going to initiate "a specific
session" for file transfer and file transfer only (that is,
no instant messages, just file transfer) as your mail seemed
to be advocating, then you *are* using the wrong protocol.

More succinctly: there is no valid use case for labeling a
session "file transfer only."

/a

> From: Aki Niemi [mailto:[email-masked]]
> Sent: Tuesday, November 11, 2003 13:22
> To: ext Ben Campbell
> Cc: ext Adam Roach; [email-masked]'; [email-masked]
> Hi,
> Perhaps I should also clarify my position. Clearly, if you 
> are going to 
> just do file transfer, there is no sense at all to start to develop 
> something else but to use FTP.
> 
> But this is not the case here. We are developing MSRP to 
> enable sending 
> messages in a session, negotiating this in SIP/SDP, and have tools to 
> invoke relays for these sessions.
> 
> Now, it is also possible *and* useful to send files, or things other 
> than text/plain, in this session - at which point it becomes "file 
> transfer". Please explain why this is bad practice just because IETF 
> already has another protocol to do "file transfer"?
> 
> It's not like we are re-developing TCP here. If we were, I'd 
> share your 
> concerns. As I understand it, in the hour-glass model of Internet, 
> multiple application layer protocols that may even overlap in 
> functionality is not a bad thing.
> 
> Cheers,
> Aki
> 
> ext Ben Campbell wrote:
> >  From section 5.1:
> > 
> > "An analysis of whether it makes sense to do this [file transfer or 
> > sending very large content], rather than sending such 
> content over FTP, 
> > HTTP, or some other such protocol, is beyond the scope of 
> this document."
> > 
> > I originally took (and still agree with) Adam's position, 
> but that is 
> > clearly not the consensus of this group. (If I am incorrect in that 
> > belief, I would love to hear it as I could remove quite a 
> bit of text.)
> > 
> > 
> > Aki Niemi wrote:
> > 
> >>
> >>
> >> ext Adam Roach wrote:
> >>
> >> Right. And if you know a priori that all you are going to 
> do is chat 
> >> with the other party, then just use IRC. Great, we're done.
> >>
> >> Thanks,
> >> Aki
> >>
> >>
> >>> /a
> > 
> > 
> > 
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Nov 2003 16:12:01 -0600

/a

---

From: [email-masked]
Date: Wed, 12 Nov 2003 07:22:50 +0200

> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2003 12:12 AM
> To: Niemi Aki (NMP/Helsinki); Ben Campbell
> Cc: Adam Roach; Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]
> Subject: RE: [Simple] Comments on message-sessions-02
> 
> 

First, we agreed that in order not to block a conversation, a long message should be sent on a separate session. Then there was the concern that the other endpoint will start using that second session to send normal short messages. Hence I suggested that an endpoint can restrict what a session was used for using mime-types (accept-types).

Ben pointed to the problem that a message with mime type text/plain could still carry a very long text file. This is how the content-disposition discussion started. So, should content disposition be used in SDP to restrict the type of "things" that can be sent in an MSRP session? I think it's useful.

Regards,
Hisham