Rohan Mahy wrote:
Michael,
At issue here is what the default implementor is likely to do. With a
new 4xx, the misguided but well-meaning implementor is likely to try
to "helpfully" "repair" the error without thinking about or
understanding the security context.
Using a Warning code raises the bar significantly, but still allows
automata to at least log what happened.
As I said, a receiver is completely at liberty to prevent the downgrade
by not
accepting the downgraded request. Problem solved by those who care. On
the other hand I think it's pretty presumptuous that we "know" in all cases
whether it's wrong to "repair" the error. Paul brought up several examples.
Also: if the receiver allows non-SIPS requests why shouldn't you infer that
they want you to "repair" the request? It sure seems like this is a
misguided
attempt at forcing ineffectual nannyware which is a pointless enterprise for
IETF protocols.
Mike
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
