Subject: RE: [Speechsc] IANA considerations for group feedback

From: "Reifenrath, Klaus" <[email-masked]>
Date: Thu, 10 Feb 2005 04:28:25 -0500

Hi Magnus,

yes, here is the "m=" line from the example(s) of
draft-ietf-speechsc-mrcpv2-05.txt:
m=control 9 TCP application/mrcpv2

Thanks,
Klaus

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Donnerstag, 10. Februar 2005 09:54
To: Sarvi Shanmugham
Cc: Dan Burnett; [email-masked]; [email-masked]; Reifenrath,
Klaus
Subject: Re: [Speechsc] IANA considerations for group feedback

Hi,

Lets first check if we are talking about what I think we are. This 
discussion is about the media type that should go in the "m=" line 
within SDP when declaring the MRCPv2 protocol session?

Sarvi Shanmugham wrote:
> I would wait for Magnus's response. May be he has an alternate proposal to
"control".

I would suggest that you use application. It is a matching top level 
media type, however it is fairly wide. For the alternative see below.

> Sarvi
> Dan Burnett wrote: 
> 
> Does that mean we need to register it?  I would still
> 
> assume *not*.
> 

If you want to use a top level media type called "control" you will need 
to define that top level type. Thus it would require a registration of 
it, which must address the MIME registration rules, see RFC 2048.

My interpretation is that "SHOULD NOT" is directed at proprietary use. 
For an IETF standards track specification, we really should not break 
this recommendation and instead define what it means if you intend to 
use it.

So in my view you have two alternatives:

1. Use "application"

2. Define "control" in a separate document and then use it.

When it comes to message I it doesn't seem appropriate, please take a 
look at what exist currently in it (see IANA registry), and its 
description (Section 5.2 RFC 2046).

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Feb 2005 13:48:11 +0100

Thanks Klaus,

> m=control 9 TCP application/mrcpv2

which could be instead expressed as:

m=application 9 TCP/MRCPV2

Which would indicate that this is an application, and that the protocol 
is MRCPV2 over TCP. If one likes to have SCTP, one can simple define 
SCTP/MRCPV2 in the future. The reason I am suggesting to define a real 
protocol identifier instead of simply indicating TCP with a MIME type, 
is that this is standardized protocol and can't really be mixed with 
something else on that TCP connection.

 From draft-ietf-mmusic-sdp-new-23.txt:

8.2.2  Transport protocols ("proto")

    The "proto" field describes the transport protocol used.  This SHOULD
    reference a standards-track protocol RFC.  This memo registers three
    values: "RTP/AVP" is a reference to RTP [18] used under the RTP
    Profile for Audio and Video Conferences with Minimal Control [19]
    running over UDP/IP, "RTP/SAVP" is a reference to the Secure
    Real-time Transport Protocol [22], and "udp" indicates an unspecified
    protocol over UDP.

    If other RTP profiles are defined in the future, their "proto" name
    SHOULD be specified in the same manner.  For example, an RTP profile
    whose short name is "XYZ" would be denoted by a "proto" field of
    "RTP/XYZ".

    New transport protocols SHOULD be registered with IANA.
    Registrations MUST reference an RFC describing the protocol.  Such an
    RFC MAY be Experimental or Informational, although it is preferable
    if it is Standards-Track.  Registrations MUST also define the rules
    by which their "fmt" namespace is managed (see below).

The registration is not that difficult, and you also have the 
possibility to use the FMT space for something protocol related, like 
supported mode, or whatever.

One last point is that we should also gather further input on this topic 
from the MMUSIC WG.

Cheers

Magnus Westerlund

---

From: David R Oran <[email-masked]>
Date: Thu, 10 Feb 2005 08:37:21 -0500

Magnus' suggestion works for me.

On Feb 10, 2005, at 7:48 AM, Magnus Westerlund wrote:

> Which would indicate that this is an application, and that the 
> protocol is MRCPV2 over TCP. If one likes to have SCTP, one can simple 
> define SCTP/MRCPV2 in the future. The reason I am suggesting to define 
> a real protocol identifier instead of simply indicating TCP with a 
> MIME type, is that this is standardized protocol and can't really be 
> mixed with something else on that TCP connection.
>
> One last point is that we should also gather further input on this 
> topic from the MMUSIC WG.
>
>
> Cheers
>
> Magnus Westerlund
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Dan Burnett <[email-masked]>
Date: Thu, 10 Feb 2005 06:07:11 -0800 (PST)

Should we just seal the "fmt" space empty, or can
anyone think of something we might wish to use it for
(and therefore need to either reserve some formats or
develop a management policy as Magnus suggested)?

-- dan

--- David R Oran <[email-masked]> wrote:

> >    The "proto" field describes the transport
> protocol used.  This 
> > SHOULD
> >    Real-time Transport Protocol [22], and "udp"
> indicates an 
> > unspecified
> >    protocol over UDP.
> >
> >    Registrations MUST reference an RFC describing
> the protocol.  Such 
> > an
> > https://www1.ietf.org/mailman/listinfo/speechsc

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250

---

From: Dan Burnett <[email-masked]>
Date: Thu, 10 Feb 2005 14:50:30 -0800 (PST)

So at this time I will register TCP/MRCPV2 both as a
transport protocol and as an SDP "proto" value but
*not* do this for SCTP/MRCPV2 or TLS/MRCPV2.

Any objections?

-- dan

		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com

---

From: Dan Burnett <[email-masked]>
Date: Thu, 10 Feb 2005 15:13:51 -0800 (PST)

Oops.  I think I misunderstood the email trail.

I will *not* do what I described below.  Instead, I'll
just register application/mrcpv2 as a MIME type and we
can change "control" to "application" in the m= line.

-- dan

--- Dan Burnett <[email-masked]> wrote:

> > > Which would indicate that this is an
> application,
> > and that the 
> > > protocol is MRCPV2 over TCP. If one likes to
> have
> > SCTP, one can simple 
> > > define SCTP/MRCPV2 in the future. The reason I
> am
> > suggesting to define 
> > >    reference a standards-track protocol RFC. 
> This
> > memo registers three
> > >    running over UDP/IP, "RTP/SAVP" is a
> reference
> > to the Secure
> > >    whose short name is "XYZ" would be denoted by
> a
> > "proto" field of
> > >    "RTP/XYZ".
> > >
> > >    by which their "fmt" namespace is managed
> (see
> > below).
> > >

__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com

---

From: David R Oran <[email-masked]>
Date: Fri, 11 Feb 2005 10:08:23 -0500

> *not* do this for SCTP/MRCPV2 or TLS/MRCPV2.
Yes, please register TLS/MRCPv2. I believe TLS is going to wind up 
"mandatory to implement".

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: David R Oran <[email-masked]>
Date: Fri, 11 Feb 2005 10:10:26 -0500

> Oops.  I think I misunderstood the email trail.
Oops, me too.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Feb 2005 16:40:20 +0100

> can change "control" to "application" in the m= line.

Now, I got confused.

My preference when it comes do indicating the MRCPv2 control session 
within SDP when performing the SIP negotiation would be to have 
identified as a protocol. To do that would require your specification to 
register, something like "TCP/MRCPV2" for the SDP "proto" field. That 
registration needs to define what is done with the FMT part of the "m=" 
line. You can define that it isn't used. If it is desired to have also 
TLS or SCTP, corresponding proto identifiers can be registered. Such a 
registration should also define that you will use the COMEDIA way of 
setting up the TCP connections in the case of TCP and TLS. When it comes 
to SCTP it becomes more advanced and you will be on more fresh ground.

Or have you received feedback indicate that using the "TCP" proto and 
then a application/mrcpv2 would be better alternative?

There has been some ongoing debate on this topic, for example regarding 
MSRP, which however has a more complex addressing scheme. So I think we 
should take this discussion to MMUSIC.

Cheers

Magnus Westerlund

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 11 Feb 2005 09:10:33 -0800

Hi Magnus/Dave,
      Here is my plan.
   m=<media-type> <port> <proto> <fmt>

<media-type> = "application"

<proto>   =  "TCP/MRCPv2" / "TLS/MRCPv2" / "SCTP/MRCPv2"

I believe the <fmt> field together with some attributes would have been 
a nice way to address multiple
resource type identifiers and their resource channel allocation, all 
managed by a single m-line. Similar to have we do RTP payload type 
mapping/denotiation. Instead, we  have taken the route of addressing 
that using separate m-lines for each resource.  So as of the next draft, 
I will be leaving the <fmt> field as unused. If people feel strongly 
about using my above suggestion about attempting to combine them into a 
single m-line. I could write it up separately for your review.

I think "TCP/MRCPv2" and "TLS/MRCPv2" and their usage are covered in 
this specification, and the description is based on the COMEDIA draft. 
Please check to see if I have left something out in my use of the 
COMEDIA approach.  So they will be registered in this specification. I 
am not sure if "SCTP/MRCPv2" needs to be very different from the COMEDIA 
draft in terms of the SDP used. Based on that, I will decide whether to 
leave SCTP out of this draft and write up a separate one on how MRCPv2 
will use SCTP and have it register "SCTP/MRCPv2" separatetly.

What do yall think.

Sarvi

Magnus Westerlund wrote:

> identified as a protocol. To do that would require your specification 
> to register, something like "TCP/MRCPV2" for the SDP "proto" field. 
> That registration needs to define what is done with the FMT part of 
> the "m=" line. You can define that it isn't used. If it is desired to 
> have also TLS or SCTP, corresponding proto identifiers can be 
> registered. Such a registration should also define that you will use 
> the COMEDIA way of setting up the TCP connections in the case of TCP 
> and TLS. When it comes to SCTP it becomes more advanced and you will 
> be on more fresh ground.
>
> There has been some ongoing debate on this topic, for example 
> regarding MSRP, which however has a more complex addressing scheme. So 
> I think we should take this discussion to MMUSIC.
>
> Cheers
>
> Magnus Westerlund
>