Subject: Registering SDP names with IANA

From: Mark Handley <[email-masked]>
Date: Wed, 21 Jan 1998 16:54:56 -0500

As part of the final process (I hope) before SDP can become a proposed
standard, we need to agree a registration mechanism for SDP names.
The following is my proposed text for these guidelines that IANA has
provisionally approved.  I'm forwarding this to the list in case
anyone has any comments or suggestions (in the next 24 hrs please!).

Cheers,
	Mark

--------

Appendix C: Guidelines for registering SDP names with IANA

There are five field names that	may be registered with IANA.  Using  the
terminology  in	 the  SDP  specification BNF, they are "media",	"proto",
"fmt", "att-field" and "bwtype".

"media"	(eg, audio, video, application,	data).

    The	set of media is	intended to be small  and  not	to  be	extended
    except  under  rare	 circumstances.	 The same rules	should apply for
    media names	as for top-level MIME content types, and where	possible
    the	 same  name should be registered for SDP as for	MIME.  For media
    other than existing	MIME top-level content types, a	 standards-track
    RFC	 MUST  be  produced  for  a  new  top-level  content  type to be
    registered,	and the	registration MUST provide good justification why
    no existing	media name is appropriate.

"proto"

    In general this should be an IETF standards-track transport	protocol
    identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile).

    However, people will want to invent	their own proprietary  transport
    protocols.	 Some  of  these  should  be registered	as a "fmt" using
    "udp" as the protocol and some of which probably can't be.

    Where the protocol and the application are intimately  linked,  such
    as	with  the LBL whiteboard wb which used a proprietary and special
    purpose protocol over UDP, the protocol name should	be "udp" and the
    format  name  that should be registered is "wb".  The rules	for for-
    mats (see below) apply to such registrations.

    Where the proprietary transport protocol really  carries  many  dif-
    ferent  data formats, it is	possible to register a new protocol name
    with IANA.	In such	a case,	an RFC MUST be produced	 describing  the
    protocol  and  referenced  in  the registration.  Such an RFC MAY be
    informational, although it is preferable if	it is standards-track.

"fmt"

    The	format namespace is dependent on  the  context	of  the	 "proto"
    field,  so	a  format cannot be registered without specifying one or
    more transport protocols that it applies to.

    Formats cover all the possible encodings that might	want to	be tran-
    sported in a multimedia session.

    For	RTP formats that have been assigned static  payload  types,  the
    payload  type  number is used.  For	RTP formats using a dynamic pay-
    load type number, the dynamic payload type number is  given	 as  the
    format and an additional "rtpmap" attribute	specifies the format and
    parameters.

    For	non-RTP	formats, any unregistered format name may be registered.
    If	there  is  a suitable mapping from a MIME subtype to the format,
    then the MIME subtype name should be registered.   If  there  is  no
    suitable  mapping  from  a	MIME  subtype,	a  new	name  should  be
    registered.	 In either case, unless	there are strong reasons not  to
    do	so, a standards-track RFC SHOULD be produced describing	the for-
    mat	and this RFC SHOULD be referenced in the registration.

"att-field" (Attribute names)

    Attribute field names MAY be registered with IANA, although	this  is
    not	compulsory, and	unknown	attributes are simply ignored.

    When an attribute is registered, it	must be	accompanied by	a  brief
    specification stating the following:

    o	  contact name,	email address and telephone number

    o	  attribute-name (as it	will appear in SDP)

    o	  long-form attribute name in English

    o	  type of attribute (session level, media level, or both)

    o	  a one	paragraph explanation of the purpose of	the attribute.

    o	  a specification  of  appropriate  attribute  values  for  this
	 attribute.

    IANA will not sanity check such attribute  registrations  except  to
    ensure that	they do	not clash with existing	registrations.

    Although the above is the minimum that  IANA  will	accept,	 if  the
    attribute  is expected to see widespread use and interoperability is
    an issue, authors are encouraged to	produce	 a  standards-track  RFC
    that specifies the attribute more precisely.

    Submitters of registrations	should ensure that the specification  is
    in	the spirit of SDP attributes, most notably that	the attribute is
    platform independent in the	sense that it makes no implicit	 assump-
    tions  about  operating systems and	does not name specific pieces of
    software in	a manner that might inhibit interoperability.

"bwtype" (bandwidth specifiers)

    A proliferation of bandwidth specifiers is strongly	discouraged.

    New	bandwidth specifiers may be registered with IANA.   The	 submis-
    sion  MUST	reference a standards-track RFC	specifying the semantics
    of the bandwidth specifier precisely, and indicating when it  should
    be used, and why the existing registered bandwidth specifiers do not
    suffice.

Registration Procedure

To register a name the above guidelines	should be followed regarding the
required  level	 of  documentation  that  is required.	The registration
itself should be sent to IANA.	Attribute registrations	 should	 include
the  information  given	 above.	  Other	registrations should include the
following additional information:

o     contact name, email address and telephone	number

o     name being registered (as	it will	appear in SDP)

o     long-form	name in	English

o     type of name ("media", "proto", "fmt" or "bwtype")

o     a	one paragraph explanation of the purpose of the	registered name.

o     a	reference to the specification (eg RFC number) of the registered
     name.

IANA may refer any registration	to the IESG or to any  appropriate  IETF
working	 group for review, and may request revisions to	be made	before a
registration will be made.

---

From: Stephen Casner <[email-masked]>
Date: Thu, 22 Jan 1998 11:18:14 -0800 (Pacific Standard Time)

>     identifier such as RTP/AVP (rfc 1889 under the rfc 1890 profile).

We need to allow for the definition of additional RTP profiles.
Initially, the SDP spec itself was the only place that "AVP" string
was defined, but the new draft to revise RFC1890 gives itself the name
"RTP/AVP".  The name really is used by SDP (or other session
description methods) and not by the profile; is it reasonable to
require that all RTP profiles give themselves names for use in SDP
(that is, should the section of the RTP spec that gives guidelines for
profiles require that profiles name themselves)?  I assume that the
registration of these names is still in the SDP "proto" namespace.

>     format and an additional "rtpmap" attribute	specifies the format and

I think the SDP spec need another sentence, perhaps in the body rather
than this appendings, stating explicitly where the values for the
<encoding name> field of the rtpmap attribute are registered.  This is
a current topic of significance for the AVT working group, and I
believe we are heading in the direction of using (a transformation of)
MIME type registrations.  I guess it would make sense for the SDP spec
to refer responsibility for these <encoding name> registrations to the
RTP profile; and I think the SDP spec needs another sentence to say
that more explicitly that the present text describing rtpmap does.
The RTP profile may subsequently refer these registrations to MIME in
a way that we need to still work out.

>     not	compulsory, and	unknown	attributes are simply ignored.

Wouldn't it be a good idea to say that unregistered attributes should
begin with "x-" as the text does for experimental encoding names?
This is to avoid a clash with future IANA registrations of attributes
(with the obvious implication that IANA won't register any attribute
beginning with "x-").
							-- Steve

---

From: Mark Handley <[email-masked]>
Date: Thu, 22 Jan 1998 14:32:18 -0500

>> "proto"
>> 
>>     In general this should be an IETF standards-track transport	protoco

Yes, I believe it's reasonable to expect new RTP profiles to do this.
If a new profile is ever written, we'd expect them to register the
profile name with IANA in the SDP proto namespace.

>> "fmt"
>> 
>>     For	RTP formats that have been assigned static  payload  types,  th
>>     payload  type  number is used.  For	RTP formats using a dynamic pay
>>     load type number, the dynamic payload type number is  given	 as  th
>>     format and an additional "rtpmap" attribute	specifies the format an
>>     parameters.
>

Yes, I agree with you that this is an RTP issue.  What I don't have
is anything I can refer people to regarding the RTP payload type
namespace, which is why this is simply left unsaid right now.  Unless
you have a good suggestion for such a wording that I can add to the
SDP draft, I was proposing not to say anything.  It's certainly not
under the SDP namespace, and SDP can't afford to wait for a new RTP
RFC.

>>     Attribute field names MAY be registered with IANA, although	this  i

Yes, Steve Hanna also sugggested this, and I've added it to the draft.

Cheers,
	Mark