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

From: [email-masked]
Date: Tue, 30 Sep 2003 18:44:02 +0300

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.
> 
> Covered above.
> 
> 	Paul
> 
> 
> _______________________________________________
> 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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 30 Sep 2003 13:44:21 -0500

> About To-header vs. Request-URI: I favour request-URI for consistency.

I concur with Robert's and Dean's memory that discussions in the 
original design team and in SIMPLE involved using r-uri.

It seems to me that if I register a contact that causes a PUBLISH 
request to be retargeted, then I mean for the request to be presented to 
the device specicified by the contact, for the resource specificed by 
the contact. If that is not what I intended, then I screwed up.

---

From: Sean Olson <[email-masked]>
Date: Tue, 30 Sep 2003 12:05:52 -0700 (PDT)

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.
> 
=== message truncated ===

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Sep 2003 16:13:38 -0400

> of PUBLISH. Third party PUBLISHing, yes. 

*If* this is the intent, then you should go the whole way, and specify 
that the request uri should identify only the domain when the request is 
first sent. This in turn requires the proxy for the domain to handle 
PUBLISH specially (as REGISTER is), either by implementing it, or by 
having special purpose logic to route it based on the To uri.

Trying to have it both ways, by routing based on the request uri but 
having the recipient select the target based on the To uri, is going to 
cause a mess.

	Paul