Subject: SDP draft and Proposed Standard submission

From: Mark Handley <[email-masked]>
Date: Wed, 03 Sep 1997 16:52:44 -0400

I just submitted a slightly revised SDP draft to the internet drafts
archive, and also to the IESG for consideration as a Proposed Standard.

Most of the changes are simply typographic, and the others have been
discussed here and reflect changes suggested during last call.  They
include:

  - a security considerations section has been added.
  - IS0 10646 UTF 8 as the default character set instead of ISO 8859-1
    in line with IESG policy
  - "application" top level media type replaces "whiteboard" and "text"
  - multiple "c=" fields are now allowed for a media encoding to define
    hierarchical encodings that use admin scoping.

Until it appears in the ID archives, you can obtain the new draft from:
  ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-04.txt
  ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sdp-04.ps
or also from
  http://north.east.isi.edu/~mjh/draft-ietf-mmusic-sdp-04.txt
  http://north.east.isi.edu/~mjh/draft-ietf-mmusic-sdp-04.ps

Cheers,
	Mark

---

From: Steve Hanna <[email-masked]>
Date: Thu, 4 Sep 1997 16:44:30 -0400 (EDT)

I have a few comments on the latest SDP draft. I apologize for sending them 
late, but some of them pertain to the changes just made. I have provided 
specific alternatives when possible with the hope that this won't slow things 
down too much.

1) The description of the charset attribute should probably describe in greater 
detail what the valid values for this attribute are and what their meanings are.

Maybe: "The character set identifier MUST be one of those registered with the 
IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and 
MUST be compared against the IANA identifiers using a case-insensitive 
comparison. If the identifier is not recognized or not supported, all strings 
that are affected by it SHOULD be regarded as byte strings. The default value is 
UTF-8 (ISO 10646 with UTF-8, as described in RFC 2044)."

If we decide to use IANA character set names, the example given 
("a=charset:iso8859-1") should use a valid IANA character set name (like 
"a=charset:iso-8859-1").

2) The charset attribute only applies to the session name (field type s) and 
information (field type i), right? Everything else must be US-ASCII? If that's
correct, it should be stated early on (perhaps in section 5.6, 
Internationalization).

3) It would be nice to be able to apply the charset attribute to attribute 
values (like the keywords attribute or some application-specific attributes).

We could specify an alternative form of the attribute rule that indicates that 
the attribute uses the character set specified in the charset parameter. Or we 
could simply specify that any attribute may do so by specifying this in the 
definition of the attribute.

4) At the top of page 9 (text version), it says "Text records such as the 
session name and information may contain any printable 8 bit ISO 10646 character 
with the exceptions of 0x0a (ASCII newline) and 0x0d (ASCII carriage return)." I 
believe that the phrase "8 bit ISO 10646 character" is a contradiction in terms. 
Also, in the next sentence CRLF is 0x0d0a not 0x0a0d.

I'm also not sure exactly what a "printable" ISO 10646 character is. Do you want 
to exclude combining characters (also known as diacritical characters), layout 
and format control characters, etc.? I see no reason to do so. Only LF and CR 
must be protected against.

Actually, it might be better to make this sentence refer to the text records as 
byte strings, since their character set depends on the value of the charset 
attribute. It might be ISO 10646, but it might not.

So this sentence could be replaced with "Text records such as the session name 
and information are byte strings that must be interpreted according to the value 
of the charset attribute. They may contain any byte with the exceptions of 0x0a 
(ASCII newline) and 0x0d (ASCII carriage return)." Of course, this would also 
require changing the text rule in the BNF. It should probably be revised anyway, 
as it seems to be restricted to ISO 10646 with UTF-8 and ISO 8859-1.

5) What if the charset parameter specifies a character set that uses 0A or 0D 
(the UTF-8 versions of 000A and 000D) for important characters? For instance, 
say ISO-10646-UCS-2 is chosen (or any other multibyte character set). 
Disallowing the use of 0A or 0D would eliminate lots of characters (all Gujarati 
characters in ISO-10646-UCS-2, for instance).

One way to solve this problem would be to provide a way to specify a content 
encoding (like quoted-printable or BASE64) that may be used in conjunction with 
the charset.

6) What should we do about language tags? Harald Alvestrand's I-D "IETF Policy 
on Character Sets and Languages" (draft-alvestrand-charset-policy-00.txt) says 
that "Protocols that transfer human-readable text MUST provide for multiple 
languages." We could add another attribute to identify the language used in this 
announcement (like a=language:language-tag). It would be nice to be able to send 
an announcement of a session in several languages at once, but that's a bit 
harder.

7) Just a nit, but the document should use MAY, MUST, SHOULD, and other key 
words to define requirements throughout, as described in RFC 2119. Right now, 
it's fairly loose.

8) At the bottom of page 19, it refers to an IANA registration procedure for 
protocol names. Is this defined somewhere?

9) Is it a goal to allow SDP descriptions to be transported in email without 
requiring encoding? If so, we might want to add a way to do line folding by 
specifying that the sequence CRLF SPACE is equivalent to a SPACE and may appear 
anywhere a SPACE may appear.

10) The BNF for attribute values is awfully restrictive. I would suggest that we 
add at least "+", "/", and "=" so that people can put BASE64 encoded objects in 
there. In fact, the frame rate attribute needs "." and the keywords attribute 
needs SPACE or some other separator. Is there any reason not to use the text 
rule? Of course, that raises the question of whether the charset attribute 
should apply to them.

Overall, this is a great draft and a very nice protocol. I enjoy using it. I 
just want to make sure it is specified clearly and properly.

Thanks,

Steve Hanna
Sun Microsystems, Inc.

---

From: Steve Hanna <[email-masked]>
Date: Thu, 4 Sep 1997 16:44:30 -0400 (EDT)

Thanks,

Steve Hanna
Sun Microsystems, Inc.