Re: [MMUSIC] 4566bis-36: Ignoring/rejecting session description that contains unknown letter

[Paul Kyzivat <[e-mail]>]

On 7/26/19 1:09 PM, Christer Holmberg wrote:
> Hi,
> 
>>> Due to my involvement in a large number of other drafts, I haven’t
>>> been able to follow the 4566bis work lately.
>>>
>>> I do have a question.
>>>
>>> The text says:
>>>
>>>      “The set of type letters is deliberately small and not intended to be
>>>      extensible -- an SDP parser MUST completely ignore or reject any
>>>      session description that contains a type letter that it does not
>>>      understand.”
>>>
>>> Since the syntax does not allow new letters to begin with, why can’t
>>> an SDP parser simply discard an unknown letter if received? Why does
>>> the parser have to ignore/reject the whole session description?
>>
>> This has always been part of the description of SDP. It would be odd to change it now. AFAIK there has never been another letter added to the syntax.
> 
> True.
> 
> So, what does "ignore the session description" actually mean? Discard it, and move on as it if hadn't been received? Perhaps it would then be better to always reject the session description, as there is a syntax error (as the syntax does not allow new letters).

Think of it in the concept of SAP, where the SDP was probably received 
by email and used at the discretion of the receiver. There was no 
mechanism to "reject". In that case "ignore" makes sense, while with O/A 
"reject" makes sense.

>> (Related to the point that the version has never been changed, and there is no mechanism for changing it in a backward compatible way.)
> 
> I don't think it would cause any backward compatible issues, as the receiver would only discard the letter and then process the session description.

True. My point was that while SDP includes a version number, there is no 
mechanism for changing the version in a backward compatible way. That 
would presumably be needed if anybody wanted to make a change such as 
adding another "letter". And perhaps that is why it has never been done.

	Thanks,
	Paul