Subject: [MEDIACTRL] [RAI] RAI Review of draft-ietf-mediactrl-sip-control-framework-02 - Critical Issue 2

From: "Chris Boulton" <[email-masked]>
Date: Fri, 23 May 2008 23:43:29 +0100

2) Why do we need an entirely new protocol for this? Could this not have
been done with one of many existing protocols that allow us to send
requests with MIME bodies and get responses? (e.g. HTTP)? I assume the
work group thought about this, and has good reasons. It would help to
have the reasoning documented in the draft.

[CJB] Based on the other mail thread (Critical Issue 1) I would most
certainly say that the group has thought and discussed this topic over a
long period time.  Once the decision to use SIP had been made, using SIP
INFO which is currently used by protocols such as MSML and MSCML was not
an option.  We therefore needed a generic, asynchronous framework that
could be used for all our extension package needs.

We could certainly document more but I personally am not convinced it is
needed.  At the end of the day we need to make this appropriately
friendly to folks trying to develop the specification and I am not
convinced that adding this type of text helps - I can't remember MSRP
having this type of text (but I may have missed it?).  If it is felt to
be essential by the group we could add a brief summary in the spec about
the characteristics of the protocol.

Its worth taking a look at the draft in the 'other' thread
(http://tools.ietf.org/html/draft-burger-mscl-thoughts-01).  The group
certainly debated for a long time on alternatives and came to consensus.

Chris.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Ben Campbell <[email-masked]>
Date: Fri, 23 May 2008 22:33:10 -0500

On May 23, 2008, at 5:43 PM, Chris Boulton wrote:

> 2) Why do we need an entirely new protocol for this? Could this not  
> have been done with one of many existing protocols that allow us to  
> send requests with MIME bodies and get responses? (e.g. HTTP)? I  
> assume the work group thought about this, and has good reasons. It  
> would help to have the reasoning documented in the draft.
>
> certainly say that the group has thought and discussed this topic  
> over a long period time.  Once the decision to use SIP had been  
> made, using SIP INFO which is currently used by protocols such as  
> MSML and MSCML was not an option.  We therefore needed a generic,  
> asynchronous framework that could be used for all our extension  
> package needs.
>
> We could certainly document more but I personally am not convinced  
> it is needed.  At the end of the day we need to make this  
> appropriately friendly to folks trying to develop the specification  
> and I am not convinced that adding this type of text helps – I can’t  
> remember MSRP having this type of text (but I may have missed it?).

Ouch :-) But I will not for a moment hold MSRP up as a shining example  
of good process. That was a very long, strange trip, and I hope we  
learned some lessons (see below.)

>   If it is felt to be essential by the group we could add a brief  
> summary in the spec about the characteristics of the protocol.

On reflection, it is not really critical, and I should have probably  
put this in the general comments rather than list it as a "critical"  
comment.  It's really more a matter that this question is likely to  
come up more than once between now and RFC time, and if there was even  
just a couple of sentences mentioning the motivation it might save  
some grief. One of the frustrations in completing MSRP (since you  
brought it up ;-)  )is we routinely had people questioning choices  
that had been made years in the past, and it was hard to dig up the  
motivations from memory and list archives.

>
> Its worth taking a look at the draft in the ‘other’ thread (http://tools.ietf.org/html/draft-burger-mscl-thoughts-01 
> ).  The group certainly debated for a long time on alternatives and  
> came to consensus.
>

Is that document something that could be referenced for this purpose?

---

From: "Adnan Saleem" <[email-masked]>
Date: Mon, 26 May 2008 13:25:53 -0700

As Chris had pointed out in this email thread, there are several
architectural advantages of using SIP to drive the media
control interface. This is also quite evident by the large number of
implementations/deployments which have beed used in
real commercial systems for over 5 years with many many use cases, all
using the SIP+XML model.
 
The issues around SIP/INFO had also been discussed to great length and
the preferred approach for the MediaCtrl
interface within the working group seemed to be to use SIP for media
control channel negotiation (rather than SIP/INFO).
 
If the above is not abundantly evident in the current
mediactrl-sip-control-framework draft then additional supporting
explanation can be added, but I see no need to change the architecture.
 
Adnan

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chris Boulton
Sent: May 23, 2008 3:43 PM
To: [email-masked]
Cc: Eric Burger; [email-masked]
Subject: [MEDIACTRL] [RAI] RAI Review
ofdraft-ietf-mediactrl-sip-control-framework-02 - Critical Issue 2

Chris.