Yes, in all these cases, the R-URI should be considered for identifying the target resource, but I am not sure what the "To header" is doing in RFC 3842 as pointed out by Brett.
If the Request-URI or To header in a message-summary subscription corresponds to a group or collection of individual messaging accounts, the notifier MUST specify to which account the message- summary body corresponds. On Mon, Apr 20, 2009 at 3:25 PM, Iñaki Baz Castillo <[email protected]> wrote: > El Martes, 21 de Abril de 2009, Brett Tate escribió: >> My specific questions are how to interpret the following upon receipt of >> SUBSCRIBE at example.com (notifier) where user1, group1, and known-user are >> known and unknown-user is unknown at example.com. >> >> 1) To: [email protected] and request-uri is example.com? >> >> 2) To: example.com and request-uri is [email protected]? >> >> 3) To: [email protected] and request-uri is [email protected]? >> >> 4) To: [email protected] and request-uri is [email protected]? >> >> 5) To: [email protected] and request-uri is [email protected]? >> >> 6) To: [email protected] and request-uri is [email protected]? > > This is really annoying for me and I would simplify it a lot: > > IMHO, even if this RFC talks about To uri (not too much in fact), the > SUBSCRIBE must be created according to the same rules of INVITE, MESSAGE..., > this is, the UAC creating the request must copy the RURI into the To header. > Period. > > Said that, if a server receives a message-summary SUBSCRIBE with RURI being > different from To, it could reject/drop it, or it could ignore the To uri. But > the important uri is the RURI. > > > -- > Iñaki Baz Castillo <[email protected]> > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
