Subject: [Simple] MSRP Open Issues

From: Ben Campbell <[email-masked]>
Date: Mon, 17 Nov 2003 16:04:53 -0600

Here is the list of significant issues and to-do's from the IETF58 
meeting. At least, it is the list that I am aware of. Please send me 
anything I may have missed. (Numbers are for naming purposes, and do not 
indicate priority--with the exception of 1, of course. 3 Also seems high 
priority due to the number of items that depend on it)

I plan to have a new rev of the base spec out before the end of 
December. That rev will include the removal of relays, and the other 
issues that we have closure on. Items that require more discussion will 
depend on the status of the discussion.

-------------------------------------------------
1. Remove relays from the base spec. (Saving relay text for relay 
specific work, of course...) Does this mean that we have to rename the 
protocol?

2. Remove text suggesting re-sending failed messages on the same 
connection. Instead, we should close the connection and re-connect. (See 
item 3...)

3. Close on handling of broken TCP connection. We discussed in the 
meeting that we should be able to reconnect without having to re-signal. 
(I remember now that we had discussed this before, and had a good reason 
at that time _not_ to do this--I will attempt to further remember the 
details so we can decide what currently makes sense.)

3.5 Determine if we need explicity un-visit (interacts with 3.)

4. Do we need a cross-connection duplicate suggestion mechanism? I think 
we said yes, if the new connection is part of the same session as the 
old. (Needs further list discussion as it interacts with 3...)

5. Generalize MIME handling to include mime version and allow arbitrary 
MIME headers.

6. Add text specifying use of sdp send-only attributes to identify 
sessions intended for one-way delivery of large content.

7. Close on keep-alive handling--needs more list discussion. In 
particular, do keep-alives need to be bi-directional?

8. Add more verbiage in security considerations, particularly 
considering TLS certificate usage, self-signed certificates, and 
interactions between TLS and digest authentication. (Cullen volunteered 
to send text on TLS cert usage.) (This also interacts with 3.)

9. A number of nits and editorial fixes.

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

---

From: [email-masked]
Date: Tue, 18 Nov 2003 16:56:08 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Ben Campbell
> Sent: Tuesday, November 18, 2003 12:05 AM
> To: Simple WG
> Subject: [Simple] MSRP Open Issues
> 
> 

MSP is ok.

> connection. Instead, we should close the connection and 

I'm still confused about this one. Long messages might cause a time-out at the sender's side. Perhaps we need to define 3 different behaviours:

a) a timeout
b) an error response
c) broken TCP connection

a) is what I have real concern for when long messages are involved. Is the problem gone when relays are removed?

> details so we can decide what currently makes sense.)

One endpoint might crash and reboot. Ports might change so you need to re-signal.

> 3.5 Determine if we need explicity un-visit (interacts with 3.)

I think its needed. If the visitor just tears down the TCP connection, the host does not know if the visitor deliberately ended the session, or if something has gone wrong at the visitor side.

> old. (Needs further list discussion as it interacts with 3...)

Now you are calling sessions connections? I still think retransmission is not needed.

> particular, do keep-alives need to be bi-directional?

Probably not. a keep-alive from one side results in a 200 from the other. Therefore both sides are alive.

> 9. A number of nits and editorial fixes.

10. We need normative text about how to construct a second SDP offer/answer exchange.

Regards,
Hisham