On 12/7/11 12:06 AM, Brez Borland wrote:
> On Tue, Dec 6, 2011 at 3:35 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
> <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> The examples below look like some sort of conformance test, rather than
> cases that would actually be encountered in practice. If so, I suppose
> either you are implementing the tester and looking for what response to
> expect, or else you have failed a conformance test and are looking for
> an argument about why the tester is wrong.
>
> For the most part 3261 does not mandate behavior for non-conforming
> cases. So in general for the cases you describe almost any behavior
> would be ok. It then becomes a "quality of implementation" issue, not a
> conformance issue.
>
> Also, you have two kinds of cases below:
> - repetition of headers that are only permitted to occur once
> (e.g. To, From, Call-ID)
> - repetition of headers that can appear more than once, but in a
> form that makes little sense. (E.g. Via)
>
> In the former case, the recipient might notice the duplication and
> object to it. Or it might not notice, and just process one of the
> instances of the header. Either is ok.
>
> In the latter case, you need to look into the details. E.g. for Via, as
> long as the vias get cleaned up while routing the response, and the
> response gets where it should, then all is well.
>
>
> A very good reasoning. I also think such behaviour should not occur in
> SIP elements, even if restriction to do so is not described anywhere in
> the docs.
Well, repeating a header that is defined to appear at most once is a
violation.
If you are referring to the Via case, I think it is very hard and not
worth the trouble to identify all the stupid things that someone might
do and ban them. There is a fine line between what is stupid and
useless, and that which actually has significance in some implementation.
Why do you care what is in the via headers added by other elements? It
really shouldn't be of interest to you, other than the top-most one that
you must use to forward a response.
> I would respond with 400 where Reason-Phrase describing first
> encountered failure in the request (i.e. first duplicated header). I
> probably wouldn't bother about duplicated Via headers much, as these
> have to be dealt with by the upstream elements only. But other headers
> mentioned, are the concern of the downstream elements, and I wouldn't
> allow pass this junk through because, as Paul mentioned there, depending
> on the implementation the receiver might, or might not, process the
> request. And sending request downstream with the uncertainty of it being
> handled is beneficial for nobody, and is irresponsible at the very least.
If you want to go to the trouble of detecting such invalid headers in
requests, then feel free to send an error response. That is your choice.
But I won't fault someone else for doing otherwise.
Note that duplicated headers could also appear in responses. In that
case you can't send an error response, so you will have to cope some
other way.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
