Matt Lepinski wrote: > James, > > I do believe that the intent of Ted (as well as others in the GEOPRIV > working group, including myself) is that if a UAC specifies > "recipient=endpoint" then a compliant proxy will not 'read' the location > body. In particular, "recipient=endpoint" indicates that a SIP proxy in > the signaling path does not have permission to store the location (or > any derived information) for longer than is necessary to forward the SIP > message and does not have permission to send the location to any third > party (for any reason including location-based routing) other than the > next-hop SIP proxy. That is, the intent of "recipient=endpoint" that if > a call requires location-based routing in order to succeed, then the > call should fail.
RFC 2119 defines MUST NOT. It says: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. 7. Security Considerations These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification I can't see any failure of interoperability that results if a proxy "reads" the location body in violation of the user's preference described by "recipient=endpoint". I can also see application scenarios (ex: emergency) where applications can be assured of not operating unless the proxy violates this prohibition. So we've missed the #6 guidance on "MUST NOT". Can we justify a "MUST NOT" based on security considerations? Given (as in emergency) that there are applications in which the application MUST read the location, I don't think so. What we really have is guidance that says, in normal operation, proxies don't include the location in application logic when recipient=endpoint is specified by the user, because in general this indicator means that the user is asking the proy to NOT include the location in application logic by attaching this modifier. So we're at the level of a "SHOULD NOT", not a "MUST NOT" as described by RFC 2119. And even then I suspect the discussion of this requirement needs careful elucidation as to the problems resulting (or likely to result) if a proxy violates this requirement. -- Dean _______________________________________________ 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
