[MMUSIC] Comments on draft-ietf-mmusic-sdp-new-15

["Drage, Keith (Keith)" <[e-mail]>]

At IETF58 requests were made for a final review of this document before resubmitting to the IESG.

These comments are made as a result of that request.

If mmusic participants wish to enter into discussion on any of these, you snip out the remainder of the comments so that mail threads do not become burdened with text that is not under discussion.

regards

Keith

Keith Drage
Lucent Technologies
[e-mail]
tel: [phone]

Comments on draft-ietf-mmusic-sdp-new-15
----------------------------------------

1)	Introduction: section 1. 2nd paragraph. In:

   When initiating multimedia teleconferences, voice-over-IP calls,
   streaming video, or other real-time sessions, there is a requirement
   to convey media details, transport addresses, and other session
   description metadata to the participants.

the words "or other real-time sessions" imply that SDP is limited to describing real-time  sessions. SDP is proposed to be used to describe message sessions, which are immediate  delivery, but which are not traditionally known as real-time. It is proposed to delete the  words "real-time", leaving "or other sessions" with the word "session" being the defined  term.

2)	Terminology: section 2. The term "session advertisment" is never used in the  document. The word "advertisment" is used in the document, but in descriptive terms that  does not really justify the use of a defined term. It is suggested we delete the definition  "session advertisment" from section 2.

3)	Terminology. I section 2, the term "session announcement" is defined, but this term  is not consistently used through the document. There are a number of places where the text  within the document should be enhanced to use this term as below. However in other cases,  rather than using the term "session announcement", it would appear that the other term  "session description" would be more appropriate to use, see also below.

a)	section 3.1, title: "Multicast announcement" --> "Multicast session announcement".

b)	section 3.1, 2nd paragraph: 

   One protocol commonly used to implement such a distributed directory
   is the Session Announcement Protocol, SAP [8]. SDP provides the
   recommended session description format for such announcements.

should become:

   One protocol commonly used to implement such a distributed directory
   is the Session Announcement Protocol, SAP [8]. SDP provides the
   recommended session description format for such _session_ announcements.

c)	section 3.4, 2nd paragraph:

   SAP announcements do not suffer from this mismatch.

should become:

   Session announcements made using SAP do not suffer from this mismatch.

d)	section 4.5, 1st paragraph:

   When many session descriptions are being distributed by SAP, or any
   other advertisement mechanism, it may be desirable to filter
   announcements that are of interest from those that are not.  SDP
   supports a categorisation mechanism for sessions that is capable of
   being automated.

should become:

   When many session descriptions are being distributed by SAP, or any
   other advertisement mechanism, it may be desirable to filter
   _session_ announcements that are of interest from those that are not.  SDP
   supports a categorisation mechanism for sessions that is capable of
   being automated.

e)	Section 5. 1st paragraph. Text:

   ...Also, since announcements may be transported via very
   unreliable means or damaged by an intermediate caching server, the
   encoding was designed with strict order and formatting rules so that
   most errors would result in malformed announcements which could be
   detected easily and discarded.  This also allows rapid discarding of
   encrypted announcements for which a receiver does not have the
   correct key.

should become:

   ...Also, since announcements may be transported via very
   unreliable means or damaged by an intermediate caching server, the
   encoding was designed with strict order and formatting rules so that
   most errors would result in malformed _session_ announcements which could be
   detected easily and discarded.  This also allows rapid discarding of
   encrypted _session_ announcements for which a receiver does not have the
   correct key.

f)	Section 5. 6th paragraph. Text:

   The set of type letters is deliberately small and not intended to be
   extensible -- an SDP parser MUST completely ignore any announcement
   that contains a type letter that it does not understand...

should become:

   The set of type letters is deliberately small and not intended to be
   extensible -- an SDP parser MUST completely ignore any _session description_
   that contains a type letter that it does not understand...


g)	Section 5.2. <version> text:

   <version> is a version number for this announcement. It is needed for
      proxy announcements to detect which of several announcements for
      the same session is the most recent...

should become:

   <version> is a version number for this _session description_. It is needed for
      proxy announcements to detect which of several announcements for
      the same session is the most recent...

Incidentally I am not sure what "proxy announcements" are, so have not proposed a revision  here. This sentence could do with revision to more clearly explain what is meant.

h)	Section 5.4, text:

   The "i=" field is information about the session.  There may be at
   most one session-level "i=" field per session description, and at
   most one "i=" field per media. Although it may be omitted, this is
   NOT RECOMMENDED for session announcements, and user interfaces for
   composing sessions should require text to be entered.  If it is
   present it must contain ISO 10646 characters (but see also the
   "a=charset" attribute below).

Assume that what is meant here is SAP rather than announcements. The text should therefore  be modified to: 

   The "i=" field is information about the session.  There may be at
   most one session-level "i=" field per session description, and at
   most one "i=" field per media. Although it may be omitted, this is
   NOT RECOMMENDED for SAP, and user interfaces for
   composing sessions should require text to be entered.  If it is
   present it must contain ISO 10646 characters (but see also the
   "a=charset" attribute below).

However, surely if this is a SAP requirement, it should be in RFC 2974 and therefore this  sentence should be deleted from this document as outside the scope.

i)	Section 5.7. text:

   A session announcement MUST contain either at least one "c=" field in
   each media description (see below) or a single "c=" field at the
   session-level.  It MAY contain a single session-level "c=" field and
   additional "c=" field(s) per media description, in which case the
   per-media values override the session-level settings for the
   respective media.

should become:

   A session description MUST contain either at least one "c=" field in
   each media description (see below) or a single "c=" field at the
   session-level.  It MAY contain a single session-level "c=" field and
   additional "c=" field(s) per media description, in which case the
   per-media values override the session-level settings for the
   respective media.

j)	Section 5.10. text:

   Thus, the above announcement could also have been written:

should become:

   Thus, the above _session_ announcement could also have been written:

k)	Section 5.11. text:

   If a session is likely to last several years, it is expected that the
   session announcement will be modified periodically rather than
   transmit several years worth of adjustments in one announcement.

should become:

   If a session is likely to last several years, it is expected that the
   session announcement will be modified periodically rather than
   transmit several years worth of adjustments in one _session_ announcement.

l)	Section 5.13. text:

   Attribute interpretation depends on the media tool being invoked.
   Thus receivers of session descriptions should be configurable in
   their interpretation of announcements in general and of attributes in
   particular.

should become:

   Attribute interpretation depends on the media tool being invoked.
   Thus receivers of session descriptions should be configurable in
   their interpretation of session descriptions in general and of attributes in
   particular.


4)	Section 4, 2nd paragraph. Current text reads:

   The purpose of SDP is to convey information about media streams in
   multimedia sessions to allow the recipients of a session description
   to participate in the session.  SDP is primarily intended for use in
   an internetwork, although it is sufficiently general that it can
   describe conferences in other network environments.

   A multimedia session, for these purposes, is defined as a set of
   media streams that exist for some duration of time.  Media streams
   can be many-to-many.  The times during which the session is active
   need not be continuous.

We already have a definition of "multimedia" session in section 2, and this purported  definition here uses different words. It is proposed to delete the duplicated definition as  follows:

   The purpose of SDP is to convey information about media streams in
   multimedia sessions to allow the recipients of a session description
   to participate in the session.  SDP is primarily intended for use in
   an internetwork, although it is sufficiently general that it can
   describe conferences in other network environments. Media streams
   can be many-to-many.  The times during which the session is active
   need not be continuous.


5)	Section 4.6. The text:

   The SDP specification recommends the use of the ISO 10646 character
   sets in the UTF-8 encoding [3] to allow many different languages to
   be represented.  However, to assist in compact representations, SDP
   also allows other character sets such as ISO 8859-1 to be used when
   desired.  Internationalization only applies to free-text fields
   (session name and background information), and not to SDP as a whole.

allows users of SIP to not use UTF-8. SIP (see RFC 3261) is defined to use UTF-8, but  apparently does not specify how included SDP in message bodies should be encoded. It would  appear to me that all SDP uses in SIP message bodies should also be encoded in UTF-8. 

Is this lack of specification a fault of the SIP specification, or is it appropriate to add  words to sdp-new stating that:

   Where an application using SDP makes no further specification of the 
   character set to be used, the ISO 10646 character sets in the UTF-8 
   encoding [3] MUST be used.

6)	Section 5. 1st paragraph. In the text:

   ... However, since SDP may be used in environments where the maximum
   permissable size of a session description is limited (e.g. SAP
   announcements; SIP transported in UDP), the encoding is deliberately
   compact...

As SIP transport using SDP is currently considered to be less than ideal, it is probably not  a good idea to identify it as an example. Therefore delete the words "SIP transported in  UDP".

7)	Section 5.6. Phone numbers. Firstly the correct terminology is not:

   Phone numbers SHOULD be given in the conventional international
   format: preceded by a "+" and the international country code. 

but rather:

   Phone numbers SHOULD be given in the form of an international public
   telecommunication number (see ITU-T Recommendation E.164) preceded 
   by a "+".

Secondly, I do not see why this use of international number is a SHOULD. Is this to allow  the provision of numbers in an entirely different numbering plan, or the use of rfc2806bis,  or what. If there is some reason for only a recommendation, rather than mandatory use, then  I would have expected a sentence explaining it.

Thirdly, for the requirement:

   There must be a space or a hyphen ("-") between the country code and the
   rest of the phone number. 

I do not see a need for this requirement. It is not needed to parse the number, and it means  that numbers in the specified international format for text representation, ITU-T  Recommendation E.123 cannot be used without modification. I suggest that E.123 representation of international public telecommunication numbers should be valid for the phone number string.

This also requires the deletion of the associated comment in the BNF in appendix A, i.e.

                            ;there must be a space or hyphen between
                            ;the international code and the rest of
                            ;the number.

8)	Section 5.6. E-mail addresses. Text:

   The alternative RFC822 name quoting convention is also allowed for
   both email addresses and phone numbers.  For example:

RFC 822 has been made obsolete by RFC 2822. Is there some reason for quoting RFC 822 rather  than RFC 2822.

9)	Section 5.6, text:

   Both email addresses and phone numbers can have an optional free text
   string associated with them, normally giving the name of the person
   who may be contacted.  This should be enclosed in parenthesis if it
   is present.  For example:

      e=[e-mail] (Jane Doe)

From the BNF, the parenthesis are mandatory for the enclosure of the free text field.  Therefore this should be revised to:

   Both email addresses and phone numbers can have an optional free text
   string associated with them, normally giving the name of the person
   who may be contacted.  This MUST be enclosed in parenthesis if it
   is present.  For example:

      e=[e-mail] (Jane Doe)


10)	Section 5.7, 6th paragraph:

   For IP4 and IP6 addresses, the connection address is defined as
   follows:

these are values within the field, rather than the names of IP numbering schemes, thus I  proposes:

   Where the <address type> is IP4 or IP6, the connection address is defined as
   follows:

11)	Section 5.8. I am not convinced that the wording relating to X- naming is adequate.  I understood this was somewhat deprecated and this could be more emphasised. Currently use  of X- for anything would be conformant to this specification and I am not sure that was  intended. I think we should certainly get rid of the MAY quoted below.

   Tool writers MAY define experimental bandwidth modifiers by prefixing
   their modifier with "X-".  For example:

Maybe this would be better rephrased as

   A prefix "X-" is defined for bandwidth modifier names. This is intended 
   for experimental purposes only. For example:

12)	Section 5.14 defines a number of media types. Are these already top-level MIME  content types, as defined in 9.2.1, or are these to be registered by IANA as new media  types? Either section 5.14 or section 9.2.1 needs enhancement to reflect what IANA are  requested to do with these.

13)	Section 6. This section lists a large number of attribute definitions, most of which  do not appear to be defined elsewhere. Section 9.2.4 says new attributes should be  registered with IANA. Are IANA expected to pick attribute registrations from clause 6, and  all these are therefore intended to be registered, or not. Text needs to be added to either  section 6, or section 9.2.4 giving more detail of this process. 

Note that if any of these attributes are defined in other documents rather than here, I  would suggest an informative reference against the attribute giving the details of where it  is defined.

14)	Section 5.14 and section 9.2.2. In section 9.2.2, the references to "proto" field  seem to be references to the "protocol" field and or a <transport> element, and or  "transport protocol" defined in section 5.14. Certainly "proto" is not used as a field name  anywhere else in the document ecept in the BNF. Field names should be aligned one way or the  other.

15)	Section 9.2.5. Does this document register the bandwidth modifiers CT and AS defined  in section 5.8. If so this should be clearly stated in this section.

16)	Section 9.2.6. Does this document register the network type IN as defined in section  5.2 and 5.7. If so, this should be clearly stated in this section.

17)	Appendix A. Would the top level construct not be better defined as  "session-description" rather than "announcement". Not all SDP data constructs are  announcements.

18)	Appendix A. There is considerable misalignment between the BNF field names and those  in the main document. For example "v=" is "proto-version" in the BNF, and "protocol version"  in the main document (section 5.1). I would suggest changing this to "protocol-version" in  the BNF. "o=" is "origin-field" in the BNF and "origin" in the main document (section 5.2).  I would suggest we use "Origin Field" in the title of 5.2. Section 5.2 gives the expansion  of "origin" as 

   o=<username> <session id> <version> <network type> <address type>
        <address>

The BNF gives:

      origin-field =        "o=" username SP sess-id SP sess-version SP
                            nettype SP addrtype SP unicast-address CRLF

Further unnecessary misalignment of names. In this case I would change the BNF to 

      origin-field =        "o=" username SP session-id SP session-version SP
                            network-type SP address-type SP unicast-address CRLF

with appropriate modification of dependent expansions, and the 5.2 text to 

   o=<username> <session id> <version> <network type> <address type>
        <unicast address>

and so on for alignment through the rest of the BNF.

19)	Appendix A. In the expansion for "proto" the following comment is added

                   ;typically "RTP/AVP" or "udp" for IP4

This document is meant to cover IPv4 and IPv6. Why is this comment IPv4 specific, and why is  TCP not mentioned as one of the typical values.

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic