Subject: [Simple] MSRP Open Issues Revisited

From: Ben Campbell <[email-masked]>
Date: Thu, 08 Jan 2004 13:23:41 -0600

I sent this out back in November. We have had good discussion on some, 
but not all. I have added status comments for each item. It is entirely 
possible (and even likely) that I have miremembered some point, so 
please feel free to correct.

Ben Campbell wrote:

> 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?

Will be handled in an update I will send out in a day or two.

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

I think we have closed on this. Will be reflected in aformentioned revision.

> 
> 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.)
> 

I think we have closed on this. Connections cannot be re-established 
without a new sdp exchange. Will be reflected in aformentioned revision.

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

I think this is still open. However, with the conclusions on 3, I am 
leaning towards saying we do not need it.

> 
> 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...)
> 

I think we have agreement we need it, but not necessarily on how it 
works. This will be an open issue in the aformentioned revision.

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

We have agreement to do this. It will probably not be complete in 
forthcoming version, but will come soon after.

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

Done in aformentioned revision.

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

More discussion needed. It is not clear to me that we need this at all 
without relays. Can we push this entirely into the relay solution?

> 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.)
> 

Waiting for promised text.

> 9. A number of nits and editorial fixes.
>

Most will be traded in for new and novel nits in the forthcoming revision.

Also, Hisham added the following item:

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

We have had lots of discussion on this, and have converged on most of 
it. We realized we had a problem where there is no good way for the 
active party to indicate whether an MSRP stream should be reconnected 
when sending a new SDP offer. Paul proposed adding a version attribute 
a-line, which seems like it would solve the problem. However, it is 
different than the current COMEDIA proposal for the same problem (a 
"reconnect" a-line attribute.)

The upcoming revision will capture this discussion, but there will have 
an open issue on the version vs. reconnect attribute. I personally lean 
towards Paul's proposal, but I want to make sure everyone thinks through 
the fact that MSRP and COMEDIA may take different approaches to solve 
the same problem.

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 08 Jan 2004 13:23:41 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jan 2004 14:52:12 -0500

Sounds good. One comment below.

	Paul

> without relays. Can we push this entirely into the relay solution?

I agree that without relays keep alives probably aren't needed.
(If you get a hankering to know if the other end is still paying 
attention you can send an empty message, but no protocol machinery is 
needed for that.)

But clearly the way we were going keep alives were needed when relays 
were present. When we add relays later, we will either be faced with 
having to change the endpoints to send keepalives or else we will have 
to find a different solution that doesn't require them.

So, it seems likely that the addition of relays will impact all prior 
implementations. That is a downside to partitioning the work this way. 
But maybe it is still worth it.

>> interactions between TLS and digest authentication. (Cullen 
>> volunteered to send text on TLS cert usage.) (This also interacts with 
>> 3.)
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jan 2004 14:52:12 -0500

Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 08 Jan 2004 14:04:03 -0600

> But maybe it is still worth it.

We had a fairly long discussion about a different topic where we 
discussed that relays will be an extension, and endpoints will have to 
know about the extension to use it. Do you see this case as different?

>>> volunteered to send text on TLS cert usage.) (This also interacts 
>>> with 3.)
>>>
>>
>> The upcoming revision will capture this discussion, but there will 
>> have an open issue on the version vs. reconnect attribute. I 
>> personally lean towards Paul's proposal, but I want to make sure 
>> everyone thinks through the fact that MSRP and COMEDIA may take 
>> different approaches to solve the same problem.
>>
>>
>>
>>
>>
>>
>>
>>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 08 Jan 2004 14:04:03 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jan 2004 15:13:38 -0500

Ben Campbell wrote:
>>> More discussion needed. It is not clear to me that we need this at 
>>> all without relays. Can we push this entirely into the relay solution?
>>
>>
>>

I suppose not. But I imagine there might be an expectation that only one 
party in a conversation need know about relays for them to be used.

But this is a tolerable issue in order to make progress.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jan 2004 15:13:38 -0500

Paul