Subject: RE: [SIP] SDP issues

From: "William Lee" <[email-masked]>
Date: Thu, 20 Apr 2000 01:35:25 -0500

Henning:

In reply to the first SDP issue (s=nothing):

*	According to RFC 2327 s= is a required SDP parameter. Is it the
intention of the spec writers
      to allow nothing to be sent?
*	If so, then should s= even be a required SDP parameter?
*	If s=nothing is permitted, then the fact that s= was present in the
SDP message must be recorded
      in order to adhere to the requirement that s= was indeed in the SDP
message.
*	If an SDP parser is strictly compliant, it will complain about the
s=nothing scenario.
*	SDP parameters are required to appear in a specific order. This
possibly presents
      issues, if a SDP parser strictly validates, depending on how it deals
with the above issue.
*	Section B7, RFC 2543, says that for two-party sessions, the SDP s=
parameter may be left empty. 
      Isn't this in conflict with RFC 2327? However, in the case of
multicast sessions it has to be s=something. 
*	Having the s= parameter follow a varying rule set seems to add an
unnecessary complication for
      SDP message validation.

Comments appreciated. Thanks.

Bill Lee

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:[email-masked]]
> Sent:	Wednesday, April 19, 2000 1:56 PM
> To:	[email-masked]; [email-masked]
> Subject:	[SIP] SDP issues
> 
> During the SIP bake-off, two SDP-related issues were raised:
> 
> Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> at least one character. It doesn't seem necessary to enforce that s=
> have anything in them (like a space). Other textual Internet protocols
> seem to be fine with having empty unformatted fields (like Subject: in
> email).
> 
> Secondly, the rtpmap description does not specify whether the 'encoding
> name' is case-sensitive or not. Since it's also used as a media type and
> media types are case-insensitive (RFC 2616, 3.7), it probably makes
> sense to make them CI in SDP as well.
> 
> Comments are appreciated.
> 
> Henning
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Apr 2000 12:55:50 -0400

> William Lee wrote:

Probably best discussed on the confctrl mailing list. However, all other
protocols and standard C/C++ coding convention is that the empty string
("") is always legal as input. Clearly, for positional parameters, this
does not work, but for things like s=, it makes no difference. It is
annoying to have to remember everywhere to code

if (strlen(s) == 0) {
  free(s);
  s = strdup(" ");
}
sprintf(sdp, "s=%s", s);

or similar.

>    * If so, then should s= even be a required SDP parameter?

I would say that it shouldn't (and I suspect that many implementations
don't send it).

>    * If s=nothing is permitted, then the fact that s= was present in
>      the SDP message must be recorded
> 
>       in order to adhere to the requirement that s= was indeed in the
> SDP message.
> 
>    * If an SDP parser is strictly compliant, it will complain about
>      the s=nothing scenario.

I doubt that any existing implementations break on that. If they do,
they are not going to work well in practice...

>       issues, if a SDP parser strictly validates, depending on how it
> deals with the above issue.
> 
>    * Section B7, RFC 2543, says that for two-party sessions, the SDP
>      s= parameter may be left empty.
> 

Ruling out in a protocol what robust implementations need to do anyway
seems like a futile exercise. The only difference is that difficulties
are detected later, in the field...

I would think that making s= optional and (certainly) allowing the null
string as an argument to s= seems in the spirit of all other Internet
text protocols, beyond the reasons mentioned above.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs