Thanks for the responses, reply in line. > These are interesting cases. I think they go beyond what is > specified, and hence are subject to creative implementation, > which in this case is probably a bad thing.
I raised the questions because someone noticed a vendor surprisingly indicating the server (instead of the "account") within the request-uri (similar to REGISTER instead of INVITE). Thus I decided to re-read RFC 3265 and RFC 3842 to see how to interpret the To contents. That was when I surprisingly noticed the section 3.5 account text concerning "Request-URI or To header". > I agree with the opinion that this should be treated much like an > INVITE. In particular, > - the request should be routed to a destination based on the R-URI. > - if it doesn't reach a server responsible for the R-URI then it > should fail > - if it does reach a server responsible for the R-URI, then that > server should first consider in that context, if there are > multiple contexts in which it might be processed. > > Beyond that, I suppose the To uri might be treated as additional > context to address what the resulting subscription might contain. Sounds like the appropriate interpretation to me. I'll assume rfc3842 wasn't attempting to remove rfc3265 section 3.1.2's usage of request-uri to "identify the resource for which event notification desired". I guess that I'll have to decide how lenient to be when SUBSCRIBE received from known user attempting to create message-summary subscription for its own account without populating an account within request-uri (and maybe not even within To). Thanks again, Brett _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
