Subject: Comments on sd draft

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Mar 1995 13:38:27 +0200

Just a few quick, random comments, mostly nits, on the 00 sd draft.

1) 8859 is not sufficient; you probably mean 8859-1 (8859-3, for 
example, is
   Hebrew or something like that).

2) There should be a remark earlier that this protocol differs from 
'standard'
Internet protocol convention (NVT ASCII, CRLF line separator).

3) If you allow \n, you also must implicitly allow \\ or outlaw the 
backslash. Is this escape valid for all character sets? Suggestion: get 
rid of \n or make the content HTML :-).

4) The specification should note that it is not sufficient to build a 
session announcement tool (delivered through whatever means); in 
particular, the multicast address assignment algorithm is missing.

5) Some mechanism for 'registering' attribute values should be 
mentioned.
Is the usual x- escape recommended?

6) ASN/1 -> ASN.1, I believe.

7) A bit of guidance about things like whitespace might help. Maybe 
even a more formal notation like HTTP uses. What about control 
characters (tab, ^A, ^H, etc.)? I'd want to avoid somebody sending 
xterm control codes...

8) =u: I presume you mean URI (so that whatever URN comes along in a 
few months is ok too). In any event, the relevant RFC should be cited.

9) it's kb (1000) not Kb (1024); the particular data rate seems to 
include some lower layers. This value will likely be different with 
RTP; it should be spelled out where you get the number from.

10) The encodings might want to reference the ones in the RTP profile. 
The two sets should be roughly the same.

11) p.11: sdp means what?

12) Maybe phone number and email should reference the same format as in 
RTCP? (This allows pasting into my automatic dialer and discourages the 
US-centric phone numbers like (617) 555-1212 instead of +1 617 555 
1212.)

13) Interpreting bandwidth as 'application defined' is a bit vague 
unless you implicitly define a 'default' application that sets the 
standard for each media/encoding. If I want to build an application 
that understands jpeg, do I have to reverse engineer whichever JPEG 
application(s) already exist?

14) Having a protocol that implies 4-byte IP addresses (p. 2) seems a 
bit short-sighted just as IPng is going to Proposed. Other references 
implying IPv4 should also probably be made more general, but they are 
harmless since they are text strings.

There are also some typos to chase after.

The issue of whether a single encoding or a list of candidates is 
better also remains to be resolved. I tend to favor a list, as a list 
conveys more information (e.g., I might choose a different viewer that 
supports all likely encodings rather than the one listed in the sd 
announcement, which may have nothing to do with the one currently in 
use). This becomes more important as receiver-feedback scaling might 
lead to switching between algorithms. Also, it might provide some 
possibility for better error indication, avoiding the 'my video tool 
says it doesn't understand the current encoding; sd says, only H261 is 
to be used; ivs understands H.261'.  This also allows some early 
warning as in 'I saw you might be using FOOBAR in your session. I'm 
doing a demo at the White House and my new video widget doesn't 
understand FOOBAR. Would you mind not using it?'.

Henning
Schulzrinne

---

From: Mark Handley <[email-masked]>
Date: Tue, 28 Mar 95 20:17:54 +0100

>   Hebrew or something like that).

Agreed. This was an oversight on my part.

>rid of \n or make the content HTML :-).

Oh dear...

\n was in my first draft, then after implementing sdr I removed it.
Van put it back in the latest draft with the proviso that it should be
avoided.  I added the unicode stuff afterwards.  If we're going to
leave the unicode suggestion in, then I prefer to remove \n.  I prefer
not to use HTML (though I toyed with it briefly in sdr).  It tends to
lead to long descriptions, which is not really the intention - the URL
(URI?) field is for that.

>particular, the multicast address assignment algorithm is missing.

Agreed.

>Is the usual x- escape recommended?

So far, we haven't done that with sd.  It's probably not a bad idea though.

>characters (tab, ^A, ^H, etc.)? I'd want to avoid somebody sending 

well, we have:

"In general <value> is either a number of fields delimited by a single
space character or free format string."

and

"Text records such as the session name and information may contain any  8
bit  ISO  8859  character with the exceptions of 0x0a (newline) and 0x0d
(carriage return).  Carriage Return is prohibited, and Newline  is  used
to end a record."

I think the word "printable" got dropped somewhere here (it's in the
i= definition).  Between them they're fairly explicit.

If I get time, I'll have a go at a grammar.

>few months is ok too). In any event, the relevant RFC should be cited.

Agreed

>The two sets should be roughly the same.

Agreed.  I was listing the ones in use today, but a reference would be
good.  However not all sessions are RTP based (imm, wb, ...).

In particular, I don't like the "jpg" (still image jpeg) and "jpeg"
(motion jpeg) fields.

I was wondering whether we needed to distinguish RTP formats from none
RTP formats in some way, but in the end left it out of this draft.

>11) p.11: sdp means what?

I think the word "attribute" has been omitted.

>US-centric phone numbers like (617) 555-1212 instead of +1 617 555 

Agreed.  But how does this deal with where you should or shouldn't add
a leading zero if you're in the same country.  For instance +44 171
387 7050 is 0171 387 7050 from within the UK.  Dialing 0044 171 387
7050 simply doesn'k work.  There should be a way to indicate what to
add if you're in the relevant country.  +44 (0) 171 387 7050 is
sometimes used as a convention for this.  What's the situation elsewhere?

>application(s) already exist?

Hmm.  The current wording is very deliberate.  We don't believe we
have enough experience to specify the meaning of bandwidth precisely.
There is an optional modifier for this purpose which is also currently
undefined.  

>harmless since they are text strings.

The 4 bytes is for SDPv1 compatibility.  However, given the
incompatibility with start and stop times anyway, this may be less
relevant.  We should discuss this in Danvers.

>understand FOOBAR. Would you mind not using it?'.

I can understand why you might want a list, but it leads to other
problems.  For instance, if you have two encodings listed, and you
only have two distinct tools - one for each encoding, which one do you
start?  Now I'd love to see all tools support all encodings, but I
don't want to attempt to dictate it or we'll stifle interesting
research.

For receiver-feedback controlled encodings, perhaps we could have
recommended "encoding groups" where a group is effectively your format
list, but under a single name with a recommended bandwidth/coding
scheme progression.  That way maybe you'd be less likely to attempt to
join a conference if your tool only supported a subset of the listed
encodings.

Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Mar 1995 12:45:02 +0200

> I prefer

HTML was strictly in jest. For obious reasons, anything that encourages 
long-windedness is evil. One alternative if you absolutely need it, 
would be the use of the actual control character \r. Simpler to parse, 
as well.

> space character or free format string."

Maybe amplify, space (0x20), as some think of space = white space, 
including tabs and such.

> good.  However not all sessions are RTP based (imm, wb, ...).

Should have said that the RTP values should be a strict subset of the 
sd list.

> RTP formats in some way, but in the end left it out of this draft.

I hope not.

> I think the word "attribute" has been omitted.

And what does sdp stand for?

> sometimes used as a convention for this.  What's the situation elsewhere?

Pretty common situation. The US is, I believe, one of the few countries 
where the international prefix (1) is the same as the long distance 
prefix (1). You dial the first when you call from the UK, the second 
when you call within the US. Fortunately, the phone dial can't tell the 
difference. But there is indeed a difference: if you want an 
operator-assisted LD call, you'd dial 0 617 555 1212.
The algorithm is pretty simple: If you see a +, check if the next 
number is the same as your own country. If yes, dial the long distance 
prefix (after checking that it's not a local number), if no, dial your 
international access code (00, in your case and many other countries, 
but 011 from the U.S. and Canada) and the remainder. I don't know 
whether the (0) is a recognized convention.

> There is an optional modifier for this purpose which is also currently

But the problem remains, unless you have monopolistic applications.

> relevant.  We should discuss this in Danvers.

I was wondering how the a= notation is motivated. From a Tcl 
perspective, simply having a <space> makes it easy to split the thing 
into a list. Standard (SMTP/HTTP/NNTP/etc.) convention seems to use a 
colon.

> start? 

At least in that case, you are forewarned and you can have a default of 
using the first one listed. If you don't do this and the sender 
switches, you are hosed in the middle of the session.

> Now I'd love to see all tools support all encodings, but I

I doubt that will ever be feasible, particularly now that companies are 
pushing low-bandwidth audio encodings. (True Speech, etc.).

> join a conference if your tool only supported a subset of the listed

The RTP profile contains an attempt at specifying a minimum set of 
interopable encodings. Your set name idea may be workable.

Henning