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 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. In this regard
I think of it again like INVITE. If I call Alice, and the call is
forwarded to Bob, then the call will eventually be processed on behalf
of Bob, not Alice. But Bob may still note that the call was *to* Alice,
and process it differently than he might if the the call had been *to*
Bob. (He might for instance say: "Hello, this is Bob, answering on
behalf of Alice".)
Analogously, if Bob receives a SUBSCRIBE that is To:Alice, then he might
adjust what is included in the subscription on that basis.
Thanks,
Paul
Vikram Chhibber wrote:
> 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 <i...@aliax.net> 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: us...@example.com and request-uri is example.com?
>>>
>>> 2) To: example.com and request-uri is us...@example.com?
>>>
>>> 3) To: gro...@example.com and request-uri is us...@example.com?
>>>
>>> 4) To: us...@example.com and request-uri is gro...@example.com?
>>>
>>> 5) To: known-u...@example.com and request-uri is unknown-u...@example.com?
>>>
>>> 6) To: unknown-u...@example.com and request-uri is known-u...@example.com?
>> 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 <i...@aliax.net>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
