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

[Martin Thomson <[e-mail]>]

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
>