[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
--> Flemming Andreasen writes:
>Jonathan Rosenberg wrote:
>> > -----Original Message-----
>> > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
>> > Sent: Thursday, June 14, 2001 11:17 AM
>> > To: Anders Kristensen
>> > Cc: Flemming Andreasen; sip@ietf.org; Jonathan Rosenberg
>> > Subject: RE: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of
>> > bis3]]
>> >
>> >
>> > Yes. In fact, we could make a session explaining that SDP was
>> > originally
>> > defined for an entirely different purpose, that it is currently being
>> > revised, and that a bunch of fields defined in SDP shall be considered
>> > optional when used with SIP. I bet that this includes essentially all
>> > the fields that are not directly related to specifying
>> > addresses, ports
>> > and coding parameters, plus the version field that we use in
>> > "re-invite."
>>
>> Well, I'm trying to avoid the case where we have two separate SDP specs -
>> one for SAP, and one for SIP. Thus, I want the usage of SDP within SIP to be
>> completely compliant to the specification we have available, which is
>> rfc2327. I think we can agree that although the BNF doesn't require it, the
>> text is clear that rfc2327 mandates either e or p lines.
>
>That's not what Colin's reply indicated.
That's what the current SDP spec mandates. Since it is widely ignored, and
we have an update of SDP in progress, we could make it optional in the new
revision.
>> I AM willing, however, to mandate that people be willing to accept SDP
>> without these. Thus, the text would basically say that either e or p should
>> be present, as mandated by rfc2327, but because it serves little value in
>> sip, and is often ignored in practice, you MUST be prepared to process SDP
>> without it.
>>
>> Maybe the difference is really academic, but I don't want to mandate that
>> people construct SDP in violation of the spec. I'd rather mandate that they
>> accept SDP that violates the spec.
>
>If the concern is simply to be SDP compliant, then why say anything about it (on
>the sending side) ? Text duplication is the sure way to inconsistency so there
>should rather just be a reference to RFC 2327. On the receiving side, I agree
>it's a good idea to mandate lenient behavior.
I think it would be better for SIP to be silent on the issue, and the
revision of SDP (for draft standard) to clarify one way or the other.
Colin
_______________________________________________
Sip mailing list http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip