Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt

From: Ben Campbell <[email-masked]>
Date: Thu, 09 Oct 2003 11:40:57 -0500

One of the original arguments for using SIP for this publication 
_at_all_ was the ability to use the SIP rendezvous mechanism. We 
expressly considered a use case where a third party service wanted to 
publish data for a user, but the ESC for that user resided at a _client_ 
device that moves around.

Sean Olson wrote:

> Consistency with what? PUBLISH was built as a
> REGISTER++. In that vein, the To: header is used to
> identify the resource while the Request-URI is used to
> identify the ESC. I don't see a point in "forwarding"
> of PUBLISH. Third party PUBLISHing, yes. 
> 
> --- [email-masked] wrote:
> 
>>The way Alice gets her PUBLISH to be delivered to
>>Bob is by registering her AOR (using REGISTER) with
>>a contact header that has Bob's URI with parameter
>>method=PUBLISH. Now, what is the use case for Alice
>>to do that? I don't know.
>>
>>About To-header vs. Request-URI: I favour
>>request-URI for consistency.
>>
>>Regards,
>>Hisham
>>
>>
>>>-----Original Message-----
>>>From: ext Paul Kyzivat [mailto:[email-masked]]
>>>Sent: Tuesday, September 30, 2003 4:40 PM
>>>To: Niemi Aki (NMP/Helsinki)
>>>Cc: Robert Sparks; [email-masked]
>>>Subject: Re: [Sip]
>>
>>Re:draft-ietf-sip-publish-00.txt
>>
>>>
>>>
>>>
>>>Aki Niemi wrote:
>>>
>>>>Hi,
>>>>
>>>>As long as I can remember, PUBLISH's use of To
>>
>>and From have been 
>>
>>>>consistent with REGISTER all the way down to
>>
>>explicitly 
>>
>>>allowing for 
>>>
>>>>third-party publications.
>>>
>>>The use of From, and 3rd party publications isn't
>>
>>in question 
>>
>>>here. It 
>>>is the unaffected by how the target is selected.
>>>
>>>I admit I haven't been following the development
>>
>>of PUBLISH closely 
>>
>>>enough to remember whether there has agreement on
>>
>>how the target is 
>>
>>>selected. That is why I asked. Apparently Robert
>>
>>thinks there was 
>>
>>>agreement that the request uri would be used,
>>
>>while you seem to think 
>>
>>>that To will be used.
>>>
>>>I think consistency argues for using the request
>>
>>uri, unless some 
>>
>>>compelling argument wins the day. But that is just
>>
>>my opinion.
>>
>>> > The use of Request-URI as identifying the
>>>
>>>>target resource has admittedly been ambiguously
>>
>>defined. 
>>
>>>The way the 
>>>
>>>>draft currently reads is that they are both kind
>>
>>of used - 
>>
>>>which works 
>>>
>>>>fine if they are the same.
>>>
>>>:-)
>>>
>>>
>>>>But I think Paul brings up an important issue
>>
>>about 
>>
>>>forwarding PUBLISH 
>>>
>>>>requests. What is the use case, and the
>>
>>semantics we are 
>>
>>>looking for?
>>>
>>>>1) Alice's PUBLISH gets forwarded to Bob, whose
>>
>>ESC rejects 
>>
>>>the request.
>>>
>>>>  -> Consequently a forwarded subscription will
>>
>>deliver only
>>
>>>>     Bob's presence
>>>>
>>>>2) Alice's PUBLISH gets forwarded to Bob, whose
>>
>>ESC 
>>
>>>composes the event 
>>>
>>>>state into Bob's presence document.
>>>>
>>>>  -> Consequently a forwarded subscription will
>>
>>deliver the union or
>>
>>>>     some combination of Bob's and Alice's
>>
>>presence
>>
>>>>3) Alice's PUBLISH gets forwarded to Bob, whose
>>
>>ESC 
>>
>>>establishes event 
>>>
>>>>state for Alice
>>>>
>>>>  -> Consequently a forwarded subscription will
>>
>>deliver 
>>
>>>Alice's presence
>>>
>>>>     which is now "parked" in Bob's Presence
>>
>>Server
>>
>>>>Out of these three, I especially like the
>>
>>properties of 3). 
>>
>>>It would 
>>>
>>>>allow one to have a static SIP address, e.g., 
>>>
>>>"sip:[email-masked]", 
>>>
>>>>which would be forwarded to whatever service
>>
>>provider one 
>>
>>>was using at 
>>>
>>>>the time, e.g., "sip:[email-masked]", 
>>>>"sip:[email-masked]". In practice,
>>
>>I could "park" the 
>>
>>>>presence of "sip:[email-masked]" into
>>
>>nokia.com, or 
>>
>>>foo.someisp.org's 
>>>
>>>>presence system.
>>>>
>>>>The problem is that by default, a presence
>>
>>server does 
>>
>>>*not* look at the 
>>>
>>>>To-field. It only looks at the Request-URI to
>>
>>determine the 
>>
>>>requested 
>>>
>>>>resource. So a subscription to
>>
>>"sip:[email-masked]" would 
>>
>>>deliver the 
>>>
>>>>presence of a completely different presentity.
>>>
>>>Yes. While (3) may be interesting in some ways, to
>>
>>be useful 
>>
>>>it requires 
>>>a change in the way subscribe works. And I think
>>
>>that would have many 
>>
>>>unintended consequences. While the scenario might
>>
>>be useful for 
>>
>>>presence, it wouldn't be very appealing for other
>>
>>packages, such as 
>>
>>>"dialog".
>>>
>>>
>>>>I don't much like 2), but that's probably
>>
>>because I don't quite 
>>
>>>>understand the use-case. What would the
>>
>>resulting presence 
>>
>>>document look 
>>>
>>>>like? Would it still have
>>
>>entity="pres:[email-masked]", and 
>>
>>>just have 
>>>
>>>>alice's tuples?
>>>
>>>I also can't think of a use case where this is
>>
>>valid. But 
>>
>>>neither can I 
>>>think of a use case where (3) is valid - I can't
>>
>>think of a business 
>>
>>>model where the operator of the presence server
>>
>>for Bob would 
>>
>>>want to do 
>>>this.
>>>
>>>I think (1) is the interesting use case, and it
>>
>>works regardless of 
>>
>>>whether the target is chosen using the request uri
>>
>>or the To uri.
>>
>>> > IMO, this sort of thing could be more easily
>>
>>achieved by
>>
>>>>configuring Alice's EPAs to publish presence
>>
>>directly to 
>>
>>>>sip:[email-masked].
>>>
>>>I think if Alice is going away and wants to
>>
>>forward calls to 
>>
>>>Bob, that 
>>>she should do something different with her
>>
>>presence. Probably 
>>
>>>configure 
>>>some static state indicating she is away, and
>>
>>listing Bob as an 
>>
>>>alternative contact. Her forwarding should not
>>
>>include 
>>
>>>subscriptions for 
>>>presence.
>>>
>>>If she neglects to do this then all the
>>
>>alternatives seem to provide 
>>
>>>comparably useless results.
>>>
>>>
>>>>So in my opinion, the key issue really is
>>
>>whether we see 3) 
>>
>>>as useful, 
>>>
>>>>and/or feasible. That is the only use-case I can
>>
>>think of 
>>
>>>right now that 
>>>
>>>>would strictly require using the To-field as the
>>
>>resource 
>>
>>>pointer. This 
>>>
>>>>would also require some clarification to RFC
>>
>>3265 on resource 
>>
>>>>identification, so it's not an entirely
>>
>>uncontroversial 
>>
>>>road to take 
>>>
>>>>either.
>>
> === message truncated ===
> 
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip