Subject: RE: [Simple] MSRP Open Issues Revisited

From: "Chris Boulton" <[email-masked]>
Date: Fri, 9 Jan 2004 09:11:23 -0000

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

[Chris Boulton]I agree - If a hosting endpoint identifies a reconnect -
it would just locally 'un-visit' the client. 

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

[Chris Boulton]I'm more than happy for it to be pushed into a relay
solution.  The only reason I can think that this would be required in a
non-relay solution would be for more efficient connection failure
detection.  

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

This message has been scanned for viruses by MailControl - www.mailcontrol.com

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