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

[Paul Kyzivat <[e-mail]>]

On 3/4/21 12:40 AM, Nils Ohlmeier wrote:
> When Firefox started putting its original MID values of ‘mid0’, ‘mid1’ etc into the RTP header extension we received several complaints about wasting bytes on the wire. Because of that we switched to ‘0’, ‘1’, … to save bytes. So it seems everyone is interested in using as little bytes as possible for this.
> 
> In other words: I believe 16 bytes should be enough.

I don't see any conceptual problem with imposing a limit. But when 
imposing a limit retroactively there is the potential for breaking some 
existing implementations in the wild. I think that is unlikely, but hard 
to verify.

	Thanks,
	Paul

> Best
>    Nils
> 
>> On 3Mar, 2021, at 14:43, Martin Thomson <[e-mail]> wrote:
>>
>> What Justin said.
>>
>> Does anyone *need* more than 16 bytes?
>>
>> On Thu, Mar 4, 2021, at 08:55, Justin Uberti wrote:
>>> We have limits on a lot of values for exactly this reason - UDP packets
>>> have a finite length, and therefore when it comes to RTP packetization,
>>> overly long values make things screech to halt.
>>>
>>> So I think defining such a limit would be a good idea, but I think
>>> you'd have to reject it rather than ignore it to get deterministic
>>> behavior (which seems like another upside to me).
>>>
>>> On Wed, Mar 3, 2021 at 1:43 PM Sergio Garcia Murillo
>>> <[e-mail]> wrote:
>>>> If length is >16, shouldn't the 2 byte header extension be used instead? that would allow mid values up to 256 bytes.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>>
>>>> El mié., 3 mar. 2021 22:40, Harald Alvestrand <[e-mail]> escribió:
>>>>>
>>>>> On 3/3/21 4:06 PM, Nils Ohlmeier wrote:
>>>>>>> Am 3/3/21 um 06:31 schrieb Paul Kyzivat <[e-mail]>du>:
>>>>>>>
>>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>