Re: [MMUSIC] Finding a max length of "a=mid" attribute

On 3/3/21 4:06 PM, Nils Ohlmeier wrote:
>> Am 3/3/21 um 06:31 schrieb Paul Kyzivat <pkyzivat@alum.mit.edu>:
>>
>> On 3/3/21 3:51 AM, Harald Alvestrand wrote:
>>> I'm searching for the source of a max length limit on the "a=mid" attribute.
>>> I couldn't find it in RFC 5888 (grouping framework) or RFC 8843 (BUNDLE).
>>> Does anyone remember where it's supposed to be?
>>> (I have code that will insist that it should be 16 bytes or less, but I'm trying to verify that this is the correct limit.)
>> Its defined as a token (from RFC4566/8866). And that is:
>>
>>   token = 1*(token-char)
>>
>> There is no upper limit on the length. You can't impose a limit for implementation convenience. But practically speaking it is limited by the length of the message body that contains it, so you could code using an offset+length into the message buffer.
> While the SDP side might be able to handle really long MID values I
> doubt the RTP header extension allow or support that. Maybe your 16
> byte length limitation comes from the RTP side?

I found that it is impossible to encode an 1-byte RTP header extension 
longer than 16 bytes (the length is a 4-bit field with a bias value of 
1). So in practice, it's an RTP restriction.

I think Postel once advised that one should always have length limits - 
"if you don't have a length limit, you just have an implementation 
defined limit, and that's worse".

So the next question (now that we've settled that the standards don't 
impose one) is: Should the standards specify a limit?

And the third question: if asked to handle a BUNDLEd connection where 
the MID is > 16 bytes, is it reasonable to just ignore the over-long MID 
value?

>
> Best
>    Nils
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic