I agree with Dale, especially about not forwarding a malformed URI.

OTOH, I don't believe that forwarding nodes are *obligated* to verify 
the validity of everything in a message they forward. So for instance if 
a node notices that the domain is not its own, and so forwards based on 
the domain name it might just not validate the user part at all. Or if 
it forwards based on the Route header it may barely notice the R-URI.

So, I think 400 is certainly acceptable in this case, but other error 
responses are also acceptable.

        Thanks,
        Paul

[EMAIL PROTECTED] wrote:
>    From: Paul Kyzivat <[EMAIL PROTECTED]>
> 
>    The UA receiving this must (by definition) be the UAS. It *ought* to be 
>    the intended recipient of the request (leaving aside some B2BUAs which 
>    have different issues). As the intended recipient, the URI ought to be 
>    one it knows about. Since this one is malformed (and the UA probably 
>    wouldn't *intend* to support malformed ones) this URI must be something 
>    unknown to the UAS. In that case a good response is 404 Not Found.
> 
> I would say that 400 is acceptable also, because the UA may not be
> even able to parse the incoming message enough to decide what
> precisely it didn't like about.
> 
> If the UA is one that never forwards messages, it seems plausible that
> it might take a liberal interpretation of an un-escaped character that
> should be escaped but otherwise has no interpretation.  If the UA is
> considering sending the message on, I would argue strongly that it
> should reject the message, because it can't forward the message in a
> strictly compliant way without making guesses as to what the sender
> meant, and it does not have the implicit information "if I received
> it, it must have been intended for me".
> 
> Dale
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to