Fair enough, your distinction between field values and field value parameters is probably correct.
In that case I don't see anything in RFC 3261 which specifically says either way. Section 7.3 does refer to other sections, H4.2 and other RFCs... these may elaborate but I'm not sure. On 6 October 2015 at 10:51, Maxim Sobolev <sobo...@sippysoft.com> wrote: > I respectfully disagree on that, there are many places throughout RFC > where "header field values" refer specifically to the whole part after > "Foo:", not just some piece of it (see my other message with a specific > example referring to Vias). In fact I think "Via header" is kinda jargon, > which if defined properly consists of "Via header field name" + ":" + "Via > header field value". Bear in mind that header field name part is kinda > superfluous, you can have multiple values following the same name, i.e.: > > Route: <sip:al...@atlanta.com>, <sip:b...@biloxi.com>, > <sip:ca...@chicago.com> > > So preserving order is actually meaningful for values, not so much for the > full name+values. The following is equivalent in terms of the ordering > requirements for field values: > > Route: <sip:al...@atlanta.com> > Route: <sip:b...@biloxi.com>, > <sip:ca...@chicago.com> > > > On Mon, Oct 5, 2015 at 4:38 PM, David Cunningham < > dcunning...@voisonics.com> wrote: > >> If it had started "The Via headers in the response..." then I would agree >> with you. >> >> But it starts "The Via header field values in the response" so I >> interpret that to mean the order of the values within each individual Via >> header. >> >> I believe the order of the Via headers is dealt with in a different part >> of the RFC which describes when and where Via headers are added. >> >> >> On 6 October 2015 at 10:23, Maxim Sobolev <sobo...@sippysoft.com> wrote: >> >>> David, IMHO that "same ordering" clause refers to the "header values" >>> (i.e. individual "via" lines), not to the order of parameters within ONE >>> header value. Order of values is important, because it defines your return >>> path. Which is why the clause is there, I believe. Order of parameters on >>> the other hand has no particular meaning. >>> >>> On Mon, Oct 5, 2015 at 4:18 PM, David Cunningham < >>> dcunning...@voisonics.com> wrote: >>> >>>> Hi Maxim, >>>> >>>> Surely it says in the text you've quoted "and MUST maintain the same >>>> ordering"? >>>> >>>> >>>> On 6 October 2015 at 10:10, Maxim Sobolev <sobo...@sippysoft.com> >>>> wrote: >>>> >>>>> Sorry, I've obviously put colon instead of semi-colon in my example, >>>>> the >>>>> correct one should read: >>>>> >>>>> SIP/2.0/UDP 1.2.3.4;foo=bar;bar=baz >>>>> >>>>> vs. >>>>> >>>>> SIP/2.0/UDP 1.2.3.4;bar=baz;foo=bar >>>>> >>>>> >>>>> On Mon, Oct 5, 2015 at 4:06 PM, Maxim Sobolev <sobo...@sippysoft.com> >>>>> wrote: >>>>> >>>>> > Hi everybody, >>>>> > >>>>> > We came across a device that inserts some non-standard parameter >>>>> into one >>>>> > of the Via headers of request and has an issue dealing with >>>>> situation when >>>>> > this parameter is moved by our UAS to a different position of that >>>>> > particular Via header in the response. Therefore, my question is: >>>>> are we >>>>> > actually required to preserve order of parameters in each Via or >>>>> not? The >>>>> > RFC is not very clear on that matter, all it says is: >>>>> > >>>>> > 8.2.6.2 Headers and Tags >>>>> > >>>>> > [...] >>>>> > >>>>> > response MUST equal the CSeq field of the request. The Via header >>>>> > field values in the response MUST equal the Via header field >>>>> values >>>>> > in the request and MUST maintain the same ordering. >>>>> > >>>>> > To me, this boils down to the question of what we call "equal" field >>>>> values, can the field values below be considered equal: >>>>> > >>>>> > SIP/2.0/UDP 1.2.3.4:foo=bar;bar=baz >>>>> > >>>>> > vs. >>>>> > >>>>> > SIP/2.0/UDP 1.2.3.4:bar=baz;foo=bar >>>>> > >>>>> > Speaking from experience, it's probably bad idea to bet on UAS >>>>> keeping order the same when developing your own UAC code, but if somebody >>>>> decides to do it, can they claim that you are violating RFC if you don't? >>>>> > >>>>> > Thanks! >>>>> > >>>>> > -Maxim >>>>> > >>>>> > >>>>> >>>>> >>>>> -- >>>>> Maksym Sobolyev >>>>> Sippy Software, Inc. >>>>> Internet Telephony (VoIP) Experts >>>>> Tel (Canada): +1-778-783-0474 >>>>> Tel (Toll-Free): +1-855-747-7779 >>>>> Fax: +1-866-857-6942 >>>>> Web: http://www.sippysoft.com >>>>> MSN: sa...@sippysoft.com >>>>> Skype: SippySoft >>>>> _______________________________________________ >>>>> Sip-implementors mailing list >>>>> Sip-implementors@lists.cs.columbia.edu >>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>>> >>>> >>>> >>>> >>>> -- >>>> David Cunningham, Voisonics >>>> http://voisonics.com/ >>>> USA: +1 213 221 1092 >>>> UK: +44 (0) 20 3298 1642 >>>> Australia: +61 (0) 2 8063 9019 >>>> >>> >>> >>> >>> -- >>> Maksym Sobolyev >>> Sippy Software, Inc. >>> Internet Telephony (VoIP) Experts >>> Tel (Canada): +1-778-783-0474 >>> Tel (Toll-Free): +1-855-747-7779 >>> Fax: +1-866-857-6942 >>> Web: http://www.sippysoft.com >>> MSN: sa...@sippysoft.com >>> Skype: SippySoft >>> >> >> >> >> -- >> David Cunningham, Voisonics >> http://voisonics.com/ >> USA: +1 213 221 1092 >> UK: +44 (0) 20 3298 1642 >> Australia: +61 (0) 2 8063 9019 >> > > > > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > Tel (Canada): +1-778-783-0474 > Tel (Toll-Free): +1-855-747-7779 > Fax: +1-866-857-6942 > Web: http://www.sippysoft.com > MSN: sa...@sippysoft.com > Skype: SippySoft > -- David Cunningham, Voisonics http://voisonics.com/ USA: +1 213 221 1092 UK: +44 (0) 20 3298 1642 Australia: +61 (0) 2 8063 9019 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
