Michael,
The semantics of a request to a sip: resource are different from a
request to a sips: resource. If there are no Contacts registered
against a sips: resource, then the correct thing for the proxy to do
is to send a 480. This is the same thing the proxy would do if there
were no Contacts registered against a sip: resource.
We are not talking about a ciphersuite downgrade here. Providing an
error response code that encourages a client to downgrade is just
plain irresponsible.
thanks,
-rohan
On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote:
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
