> FWIW, I agree with Dale. I think the intent is case sensitive > for the very reasons that Dale mentioned.
Maybe we are talking at cross purposes here. The intent of the magic cookie inventor seems likely to be for the comparison to be case sensitive - otherwise why bother with the mixed case cookie. The intent of RFC3261 is for the comparison to be case insensitive - see RFC3261 section 7.3.1. 'When comparing header fields...'. So, which intent do we honour? I think we should follow the RFC. I think the purpose of Bug 661 is to highlight the ambiguity, but I can see that the text in the bug description isn't completely unambiguous! > Actually, I am not quite sure how to interpret the textual > description in the bugs database. I interpret it to mean > that what is called out in the spec is the need to ensure > that the branch id *following* the magic cookie be compared > case insensitive (which is fine by me). I'm not sure that that is the most natural reading. I interpret it as saying that the entire tag should be compared insensitively despite the apparent case sensitivity of the cookie. But to be honest, I don't think it really matters, if the following rules apply to the UAC: 1) Never permute the case of branch IDs between retransmissions. 2) Always generate branch IDs that differ by more than just the case of some letters. The first rule is likely to be followed by everything, whether they realise it or not. The second rule won't cause many problems even if it is broken - the chance of two branch IDs being generated that only differ by the case of some letters, and that both are used within 32 seconds on the same dialog, seem small at best[1]. So, to conclude, I think the 'magic cookie' should be compared case insensitively. But if you want to compare it sensitively, I don't think bad things will happen very often, if ever. Regards, Michael Procter [1] Yes, you could arrange a generator to violate this more frequently, but if you are aware of the problem, you are more likely to avoid it rather than try to cause it. I hope. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
