Subject: RE: Sip digest, Vol 1 #1141 - 13 msgs Subject: Re: [Sip] Any one can confirm that "fork" only means

From: "MKaleem" <[email-masked]>
Date: Wed, 1 Oct 2003 12:27:33 -0700

Steve:

Fork could be either  parallel and/or sequential.
Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, September 30, 2003 9:00 AM
> To: [email-masked]
> Subject: Sip digest, Vol 1 #1141 - 13 msgs
> 
> 
> Send Sip mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/sip
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Sip digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Re:draft-ietf-sip-publish-00.txt (Paul Kyzivat)
>    2. Unsuscribe (Alejandro Islas)
>    3. sip-publish-00.txt (Samir Srivastava)
>    4. RE: sip-publish-00.txt (Samir Srivastava)
>    5. Any one can confirm that "fork" only means parellel 
> search and no
>        t covers sequential search? (Chen Zaifeng,BISC R&D SA(BJ))
>    6. Re: Re:draft-ietf-sip-publish-00.txt (Aki Niemi)
>    7. Re: sip-publish-00.txt (Aki Niemi)
>    8. Re: Any one can confirm that "fork" only means parellel search
>        and no t covers sequential search? (Steve Pellegrino)
>    9. Re: Re:draft-ietf-sip-publish-00.txt (Paul Kyzivat)
>   10. RE: Re:draft-ietf-sip-publish-00.txt 
> ([email-masked])
>   11. Re: Re:draft-ietf-sip-publish-00.txt (Dean Willis)
> 
> --__--__--
> 
> Message: 1
> Date: Mon, 29 Sep 2003 17:02:11 -0400
> From: Paul Kyzivat <[email-masked]>
> To: Robert Sparks <[email-masked]>
> CC: Aki Niemi <[email-masked]>, [email-masked]
> Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> 
> 
> 
> Robert Sparks wrote:
> > On Mon, 2003-09-29 at 14:05, Paul Kyzivat wrote:
> > 
> >>Aki,
> >>
> >>I think the one major issue here is whether the presence 
> document to 
> >>be
> >>affected should be chosen by the To-uri or the Request-uri. 
> Has this 
> >>been explicitly discussed before? I think it is a big 
> decision, and I 
> >>don't think it is a clear cut one. The following things 
> come to my mind 
> >>that are factors affecting, or affected by the decision:
> > 
> > 
> > This was discussed in SIMPLE (several times iirc) and the 
> outcome of 
> > the discussion was that the resource being modified was 
> identified by 
> > the Request-URI.
> 
> I didn't remember. If it has been decided that way, then there are a 
> number of tweaks to the language that need to be made. Most 
> of them were 
> pointed out in my original reply on this subject.
> 
> 	Paul
> 
> 
> 
> --__--__--
> 
> Message: 2
> Reply-To: "Alejandro Islas" <[email-masked]>
> From: "Alejandro Islas" <[email-masked]>
> To: <[email-masked]>
> Date: Mon, 29 Sep 2003 18:10:45 -0500
> Organization: Kb/TEL
> Subject: [Sip] Unsuscribe
> 
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_0011_01C386B5.0087ACC0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> I would like to unsuscribe my account [email-masked] from 
> the = [email-masked]  Alejandro Islas  Kb/TEL=20
> 
> ------=_NextPart_000_0011_01C386B5.0087ACC0
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 
> Transitional//EN"> <HTML><HEAD> <META 
> http-equiv=3DContent-Type content=3D"text/html; = 
> charset=3Diso-8859-1"> <META content=3D"MSHTML 
> 6.00.2713.1100" name=3DGENERATOR> <STYLE></STYLE> </HEAD> 
> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>I 
> would like to unsuscribe my account = <A=20 
> href=3D"mailto:[email-masked]">[email-masked]</A> from 
> the=20 [email-masked]</FONT></DIV> <DIV><FONT face=3DArial 
> size=3D2>&nbsp;Alejandro Islas<BR>&nbsp;Kb/TEL=20 
> </FONT></DIV></BODY></HTML>
> 
> ------=_NextPart_000_0011_01C386B5.0087ACC0--
> 
> 
> 
> --__--__--
> 
> Message: 3
> Date: Mon, 29 Sep 2003 18:10:18 -0700
> From: "Samir Srivastava" <[email-masked]>
> To: "Aki Niemi" <[email-masked]>
> Cc: <[email-masked]>
> Subject: [Sip] sip-publish-00.txt
> 
> Hi,
> 
> A) In Section 5, it states
> 
> "EPAs MUST NOT send a new PUBLISH request (not a 
> re-transmission)  until they have received a final response 
> from the ESC for the  previous one or the previous PUBLISH 
> request has timed out. "
> 
>  What's the reason for adding this exception? There may be 
> the cases  when PUBLISH request may be going through proxy 
> which may retransmit.  If it goes thru proxy callId, and Cseq 
> comparission is needed at ESC  as needed in the case of REGISTER.=20
> 
> B) Table 1 and 2 is incomplete.
> 
>   1. In 200 OK, Expires header is MUST. which is not shown.=20
>      Separte entry needed for 2xx.
> =20
>   2. Also Min-Expires header is missing in the table. which 
> is MUST for 423.
> 
> C) In the example Messages, mandatory "Max-Forward" Header is 
> missing from all=20
>    messages.
> 
> Thx
> Samir
> 
> 
> 
> 
> --__--__--
> 
> Message: 4
> Subject: RE: [Sip] sip-publish-00.txt
> Date: Mon, 29 Sep 2003 19:26:40 -0700
> From: "Samir Srivastava" <[email-masked]>
> To: "Samir Srivastava" <[email-masked]>,
>         "Aki Niemi" <[email-masked]>
> Cc: <[email-masked]>
> 
> 
> 
> -----Original Message-----
> From: Samir Srivastava=20
> Sent: Monday, September 29, 2003 6:10 PM
> To: Aki Niemi
> Cc: [email-masked]
> Subject: [Sip] sip-publish-00.txt
> 
> 
> Hi,
> 
> A) In Section 5, it states
> 
> "EPAs MUST NOT send a new PUBLISH request (not a 
> re-transmission)  until they have received a final response 
> from the ESC for the  previous one or the previous PUBLISH 
> request has timed out. "
> 
>  What's the reason for adding this exception? There may be 
> the cases  when PUBLISH request may be going through proxy 
> which may retransmit.  If it goes thru proxy callId, and Cseq 
> comparission is needed at ESC  as needed in the case of REGISTER.=20
> 
> >> I take back the proxy retransmission. Is there any case 
> due to reboot
>    etc when out of order requests are received at the ESC ?=20
> 
> B) Table 1 and 2 is incomplete.
> 
>   1. In 200 OK, Expires header is MUST. which is not shown.=20
>      Separte entry needed for 2xx.
> =20
>   2. Also Min-Expires header is missing in the table. which 
> is MUST for 423.
> 
> C) In the example Messages, mandatory "Max-Forward" Header is 
> missing from all=20
>    messages.
> 
> Thx
> Samir
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> --__--__--
> 
> Message: 5
> From: "Chen Zaifeng,BISC R&D SA(BJ)" 
> <[email-masked]>
> To: [email-masked]
> Date: Tue, 30 Sep 2003 11:13:24 +0800
> Subject: [Sip] Any one can confirm that "fork" only means 
> parellel search and no  t covers sequential search?
> 
> Dear All:
> 
> In RFC3261 page 15 there is such a description "A proxy 
> server can also send an INVITE to a number of locations at 
> the same time.  This type of parallel search is known as 
> forking." I think this is enough to say that fork only means 
> parellel search.
> 
> But some other people think that the description doesn't deny 
> the case of sequential seach, so any one can confirm that 
> "fork" only means parellel search and not covers sequential search?
> 
> Thanks!
> 
> Sincerely yours, 
> Chen Zaifeng
> --------------------------------------------------------------
> ------------
> Beijing International Switching System Corporation Ltd.
> R&D SA
> No. 14 Jiu Xian Qiao Road
> Beijing 100016, P. R. China
> Tel:  +86-10-8457 1921
> Fax: +86-10-6436 7732
> E-mail: <mailto:[email-masked]>
> 
> 
> 
> 
> 
> --__--__--
> 
> Message: 6
> Date: Tue, 30 Sep 2003 11:43:43 +0300
> From: Aki Niemi <[email-masked]>
> To: ext Paul Kyzivat <[email-masked]>
> CC: Robert Sparks <[email-masked]>, [email-masked]
> Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> 
> 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 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.
> 
> 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? IMO, this sort of thing could be more easily 
> achieved by 
> configuring Alice's EPAs to publish presence directly to 
> sip:[email-masked].
> 
> 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.
> 
> Thoughts?
> 
> Cheers,
> Aki
> 
> 
> On 30.09.2003 00:02, ext Paul Kyzivat:
> > 
> > 
> > Robert Sparks wrote:
> > 
> >> On Mon, 2003-09-29 at 14:05, Paul Kyzivat wrote:
> >>
> >>> Aki,
> >>>
> >>> I think the one major issue here is whether the presence 
> document to
> >>> be affected should be chosen by the To-uri or the 
> Request-uri. Has 
> >>> this been explicitly discussed before? I think it is a 
> big decision, 
> >>> and I don't think it is a clear cut one. The following 
> things come to 
> >>> my mind that are factors affecting, or affected by the decision:
> >>
> >>
> >>
> >> This was discussed in SIMPLE (several times iirc) and the 
> outcome of 
> >> the discussion was that the resource being modified was 
> identified by 
> >> the Request-URI.
> > 
> > 
> > I didn't remember. If it has been decided that way, then there are a
> > number of tweaks to the language that need to be made. Most 
> of them were 
> > pointed out in my original reply on this subject.
> > 
> >     Paul
> > 
> 
> 
> 
> 
> --__--__--
> 
> Message: 7
> Date: Tue, 30 Sep 2003 11:57:08 +0300
> From: Aki Niemi <[email-masked]>
> To: ext Samir Srivastava <[email-masked]>
> CC: [email-masked]
> Subject: Re: [Sip] sip-publish-00.txt
> 
> Hi Samir,
> 
> Comments inline,
> 
> On 30.09.2003 05:26, ext Samir Srivastava:
> > 
> > Hi,
> > 
> > A) In Section 5, it states
> > 
> > "EPAs MUST NOT send a new PUBLISH request (not a re-transmission)  
> > until they have received a final response from the ESC for the  
> > previous one or the previous PUBLISH request has timed out. "
> > 
> >  What's the reason for adding this exception?
> 
> This restriction is mainly due to congestion concerns. The same 
> restriction applies to MESSAGE requests.
> 
> >  There may be the cases
> >  when PUBLISH request may be going through proxy which may 
> retransmit.  
> > If it goes thru proxy callId, and Cseq comparission is 
> needed at ESC  
> > as needed in the case of REGISTER.
> > 
> >>> I take back the proxy retransmission. Is there any case due to 
> >>> reboot
> >    etc when out of order requests are received at the ESC ?
> 
> PUBLISH requests are process in the order that they arrive at 
> the ESC. 
> The If-Match header field is used to identify the specific state that 
> the request is targetting.
> 
> I don't quite understand the problem. Can you elaborate a bit?
> 
> > 
> > B) Table 1 and 2 is incomplete.
> > 
> >   1. In 200 OK, Expires header is MUST. which is not shown. 
> >      Separte entry needed for 2xx.
> >  
> >   2. Also Min-Expires header is missing in the table. which is MUST 
> > for 423.
> 
> Good catch. I will add both to the table.
> 
> > 
> > C) In the example Messages, mandatory "Max-Forward" Header 
> is missing 
> > from all
> >    messages.
> 
> Will add that in the next revision.
> 
> Cheers,
> Aki
> 
> > 
> > Thx
> > Samir
> > 
> > 
> > 
> > _______________________________________________
> > 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
> 
> 
> 
> 
> --__--__--
> 
> Message: 8
> Date: Tue, 30 Sep 2003 07:58:34 -0400
> From: Steve Pellegrino <[email-masked]>
> To: "Chen Zaifeng,BISC R&D SA(BJ)" <[email-masked]>
> CC: sip <[email-masked]>
> Subject: Re: [Sip] Any one can confirm that "fork" only means 
> parellel search  and no t covers sequential search?
> 
> Refer to section 16.6 that goes on to describe that the proxy 
> MAY choose 
> to forward the request to targets in the set (i.e. fork the request) 
> serially, in parallel, or using a combination of both.
> 
> Regards,
> Steve
> 
> 
> Chen Zaifeng,BISC R&D SA(BJ) wrote:
> 
> >Dear All:
> >
> >In RFC3261 page 15 there is such a description "A proxy 
> server can also 
> >send an INVITE to a number of locations at the same time.  
> This type of 
> >parallel search is known as forking." I think this is enough to say 
> >that fork only means parellel search.
> >
> >But some other people think that the description doesn't 
> deny the case 
> >of sequential seach, so any one can confirm that "fork" only means 
> >parellel search and not covers sequential search?
> >
> >Thanks!
> >
> >Sincerely yours,
> >Chen Zaifeng
> >-------------------------------------------------------------
> -------------
> >Beijing International Switching System Corporation Ltd.
> >R&D SA
> >No. 14 Jiu Xian Qiao Road
> >Beijing 100016, P. R. China
> >Tel:  +86-10-8457 1921
> >Fax: +86-10-6436 7732
> >E-mail: <mailto:[email-masked]>
> >
> >
> >
> >
> >_______________________________________________
> >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
> >
> >  
> >
> 
> 
> 
> --__--__--
> 
> Message: 9
> Date: Tue, 30 Sep 2003 09:39:55 -0400
> From: Paul Kyzivat <[email-masked]>
> To: Aki Niemi <[email-masked]>
> CC: Robert Sparks <[email-masked]>, [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
> 
> 
> 
> --__--__--
> 
> Message: 10
> From: [email-masked]
> Subject: RE: [Sip] Re:draft-ietf-sip-publish-00.txt
> Date: Tue, 30 Sep 2003 18:44:02 +0300
> To: <[email-masked]>, <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>
> 
> 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=3DPUBLISH. 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
> >=20
> >=20
> >=20
> >=20
> > Aki Niemi wrote:
> > > Hi,
> > >=20
> > > As long as I can remember, PUBLISH's use of To and From 
> have been=20  
> > >consistent with REGISTER all the way down to explicitly=20
> > allowing for=20
> > > third-party publications.
> >=20
> > The use of From, and 3rd party publications isn't in question=20  
> >here. It=20  is the unaffected by how the target is selected.
> >=20
> > I admit I haven't been following the development of PUBLISH 
> closely=20
> > enough to remember whether there has agreement on how the 
> target is=20
> > selected. That is why I asked. Apparently Robert thinks there was=20
> > agreement that the request uri would be used, while you 
> seem to think=20
> > that To will be used.
> >=20
> > I think consistency argues for using the request uri, unless some=20
> > compelling argument wins the day. But that is just my opinion.
> >=20
> >  > The use of Request-URI as identifying the
> > > target resource has admittedly been ambiguously defined.=20
> > The way the=20
> > > draft currently reads is that they are both kind of used -=20
> > which works=20
> > > fine if they are the same.
> >=20
> > :-)
> >=20
> > > But I think Paul brings up an important issue about=20
> > forwarding PUBLISH=20
> > > requests. What is the use case, and the semantics we are=20
> > looking for?
> > >=20
> > > 1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects=20
> > the request.
> > >=20
> > >   -> Consequently a forwarded subscription will deliver only
> > >      Bob's presence
> > >=20
> > > 2) Alice's PUBLISH gets forwarded to Bob, whose ESC=20
> > composes the event=20
> > > state into Bob's presence document.
> > >=20
> > >   -> Consequently a forwarded subscription will deliver 
> the union or
> > >      some combination of Bob's and Alice's presence
> > >=20
> > > 3) Alice's PUBLISH gets forwarded to Bob, whose ESC=20
> > establishes event=20
> > > state for Alice
> > >=20
> > >   -> Consequently a forwarded subscription will deliver=20
> > Alice's presence
> > >      which is now "parked" in Bob's Presence Server
> > >=20
> > > Out of these three, I especially like the properties of 3).=20
> > It would=20
> > > allow one to have a static SIP address, e.g.,=20
> > "sip:[email-masked]",=20
> > > which would be forwarded to whatever service provider one=20
> > was using at=20
> > > the time, e.g., "sip:[email-masked]",=20 
> > > "sip:[email-masked]". In practice, I could "park" 
> > > the=20 presence of "sip:[email-masked]" into nokia.com, or=20
> > foo.someisp.org's=20
> > > presence system.
> > >=20
> > > The problem is that by default, a presence server does=20
> > *not* look at the=20
> > > To-field. It only looks at the Request-URI to determine the=20
> > requested=20
> > > resource. So a subscription to "sip:[email-masked]" would=20
> > deliver the=20
> > > presence of a completely different presentity.
> >=20
> > Yes. While (3) may be interesting in some ways, to be useful=20  it 
> >requires=20  a change in the way subscribe works. And I think that 
> >would have many=20  unintended consequences. While the 
> scenario might 
> >be useful for=20  presence, it wouldn't be very appealing for other 
> >packages, such as=20  "dialog".
> >=20
> > > I don't much like 2), but that's probably because I don't 
> quite=20 
> > > understand the use-case. What would the resulting presence=20
> > document look=20
> > > like? Would it still have entity=3D"pres:[email-masked]", and=20
> > just have=20
> > > alice's tuples?
> >=20
> > I also can't think of a use case where this is valid. 
> But=20  neither 
> >can I=20  think of a use case where (3) is valid - I can't 
> think of a 
> >business=20  model where the operator of the presence server for Bob 
> >would=20  want to do=20
> > this.
> >=20
> > I think (1) is the interesting use case, and it works 
> regardless of=20
> > whether the target is chosen using the request uri or the To uri.
> >=20
> >  > IMO, this sort of thing could be more easily achieved by
> > > configuring Alice's EPAs to publish presence directly to=20 
> > > sip:[email-masked].
> >=20
> > I think if Alice is going away and wants to forward calls 
> to=20  Bob, 
> >that=20  she should do something different with her presence. 
> >Probably=20  configure=20
> > some static state indicating she is away, and listing Bob as an=20
> > alternative contact. Her forwarding should not include=20
> > subscriptions for=20
> > presence.
> >=20
> > If she neglects to do this then all the alternatives seem 
> to provide=20
> > comparably useless results.
> >=20
> > > So in my opinion, the key issue really is whether we see 3)=20
> > as useful,=20
> > > and/or feasible. That is the only use-case I can think of=20
> > right now that=20
> > > would strictly require using the To-field as the resource=20
> > pointer. This=20
> > > would also require some clarification to RFC 3265 on resource=20 
> > > identification, so it's not an entirely uncontroversial=20
> > road to take=20
> > > either.
> >=20
> > Covered above.
> >=20
> > 	Paul
> >=20
> >=20
> > _______________________________________________
> > 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 =20
> 
> 
> --__--__--
> 
> Message: 11
> Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt
> From: Dean Willis <[email-masked]>
> To: Aki Niemi <[email-masked]>
> Cc: ext Paul Kyzivat <[email-masked]>,
>         Robert Sparks <[email-masked]>, [email-masked]
> Date: Tue, 30 Sep 2003 10:50:14 -0500
> 
> On Tue, 2003-09-30 at 03:43, 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 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.
> 
> As I recall, the original design team was unanimous in its 
> decision to indicate the target of PUBLISH using the request URI.
> 
> REGISTER is unfortunately somewhat broken. This is an 
> artifact of the originally-slightly-broken source-routing 
> model of SIP ala 2543, which is "much beter now". We wouldn't 
> design REGISTER that way now, and I see no need to replicate 
> REGISTER's annoying quirks going forward. I actually have 
> some hope that PUBLISH can eventually be used to replace 
> REGISTER -- after all, REGISTER is just the action of 
> publishing a contact (and, with caller-pref, some capabilities).
> 
> --
> Dean
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> 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
> 
> End of Sip Digest
> 

_______________________________________________
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