I've seen it handled in APIs where the user is required to '\0' terminate the string. In the event that they don't, it's expected that the application would crash. Of course, I don't like that approach.
In all honesty, if the user of the API is unable to determine the length of the strings they are passing, then maybe they should find another line of work ;) I totally agree that simplicity is great, but probably not at the risk of Access Violations. Joel Gerber Network Operations Specialist - Telephone Telephone Eastlink joel.ger...@corp.eastlink.ca T: 519.786.1241 -----Original Message----- From: Arun Arora [mailto:arun.arora....@gmail.com] Sent: November-13-15 8:02 AM To: Joel Gerber <joel.ger...@corp.eastlink.ca>; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Max length of To/ From headers Hmm.. What you say about length is correct and I totally agree with you. I have also seen rather different lengths, contents of the SIP headers depending upon the vendor/ implementation and that’s why I wanted to have other’s views on this. Also, w.r.t API design and its parameters, I tend to minimise the argument list to put all intelligence/ automation inside the library and API signature should be as simple as possible. And hence my concern about the length parameters. However, I guess their is no other way than to ask API USER to provide the length as well. A bit-of pain but required for stability of the API (otherwise maintenance is a pain:( ) Thanks, Arun PS: It might be possible to write a configuration-reader wrapper on top of the APIs i.e. function pointers for API-User to implement to handle the implementation specific configurations. But it is very crude idea for now. That’s for later on, if required... On 13/11/15, 6:19 PM, "Joel Gerber" <sip-implementors-boun...@lists.cs.columbia.edu on behalf of joel.ger...@corp.eastlink.ca> wrote: >Hello, > >If you are expecting the user to supply the entirety of the To/From headers, >than the only thing you can do is require the user to provide the length of >each so that you can assign memory storage within your object/function >appropriately. As Brett has said, and I have experienced in the field, you >cannot make any assumptions about the lengths of ANY SIP header field. I have >seen From headers get rather large because some implementations will include >uri-params and like to use rather large from-tags. > >For name-addr and addr-spec, it would probably be easier to make some sane >approximations, but you have to consider that the standard does not impose any >limit on these either. I would say the user of your API should be the one >cognizant of lengths, and provide them to your API appropriately. > > >Joel Gerber >Network Operations Specialist - Telephone Telephone Eastlink >joel.ger...@corp.eastlink.ca T: 519.786.1241 > >-----Original Message----- >From: sip-implementors-boun...@lists.cs.columbia.edu >[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of >Arun Arora >Sent: November-13-15 7:35 AM >To: Brett Tate <br...@broadsoft.com>; >sip-implementors@lists.cs.columbia.edu >Subject: Re: [Sip-implementors] Max length of To/ From headers > >Hmm.. That’s true, ‘No max should be there’ to support inter-op. > >However, for API design, I guess their is no way other than asking API-User to >Provide the length of Strings for To and From. > >I am designing the API to receive the To/ From header in form or 'name-addr' >or 'addr-spec' in order to avoid accessing any local db for getting >domain-name to use in To/ From. > >The motivation is to make the library as much agnostic as possible from the >local configurations saved in the implementation specific data-bases/ config >files. > >Any thoughts…? > >Thanks, >Arun > > > > >On 13/11/15, 5:58 PM, "Brett Tate" <br...@broadsoft.com> wrote: > >>> Is their any specific length of To/ From header defined by the >>> standard >> >>No. >> >> >>> In case no specific length is defined, is their any common-practice >>> for max length? >> >>RFC 3261 section 18.1.1 might provide you some guidance for message >>size minimums to support. The common practice is not cap the >>individual header sizes unless using really high maximum. From an >>individual header perspective, the Via, Call-ID, Route, Record-Route, >>and Contact tend to be larger than implementations originally might >>think (especially when using comma-separated format); thus vendors >>attempting to use maximum below 256 bytes for comma-separated segment >>usually have to increase their caps for interoperability reasons. > >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors