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

From: [email-masked]
Date: Mon, 29 Sep 2003 19:05:50 +0300

Hi Paul,

Thanks for the comments - responses inline.

 > -----Original Message-----
 > From: ext Paul Kyzivat [mailto:[email-masked]]
 > Sent: 26 September, 2003 21:32
 > To: [email-masked]
 > Subject: [Sip] Re:draft-ietf-sip-publish-00.txt
 > 
 > 
 > I'm sorry to be late with comments on this draft - it just 
 > slipped down 
 > the priority queue until I saw the proposal for last call.
 > 
 > Below are a number of comments.
 > 
 > 	Paul
 > 
 > Section 3:
 > 
 > Last sentence  says "Both the source and the target of the
 > publication are naturally represented as an address-of-record.")
 > 
 > I don't think this is right. At least it is no more true than saying
 > "Both the source and the target of an invitation are naturally
 > represented as an address-of-record."
 > 
 > This is especially a problem for the source of publication. Certainly
 > the source isn't *uniquely* represented by an AOR - in typical cases
 > there may be many sources that all share an AOR. Nor is it 
 > necessary for
 > the source to have any AOR at all.

I don't think the current wording suggests uniqueness - the text is trying to state target and source as in To and From. 

 > The statement is closer to true for the target. I think we all expect
 > the typical usage to be that PUBLISH requests are aimed at an AOR and
 > then routed to an appropriate contact address by a proxy. 
 > But of course
 > this usage isn't required, any more than it is with invite. 
 > And while we
 > may understand expected typical usage with presence, 
 > different patterns
 > may be appropriate for other event packages.

Agreed. This is analogous to REGISTER in that To is the target AoR for the binding, and From is the creator of that address binding.

 > 
 > I'm not convinced that it is necessary to replace this sentence with
 > anything. If you feel a need to say something, how about:
 > 
 > "Often, publication requests will originate from endpoints associated
 > with an address-of-record and be directed to that address-of-record."

How about:

	The target of the publication is naturally represented by the address in 
	the To header field. Similarly, the address in the From header field 
	identifies the party responsible for the publication. 

In case of presence, the To could actually contain a pres: URI and not a (SIP or SIPS) AoR. This should probably be mentioned somewhere?

 > 
 > -----
 > 
 > Section 5:
 > 
 >     Request-URI: The Request-URI initially contains the 
 > address-of-record
 >        whose publication is to be created, removed, or modified. The
 >        address-of-record MUST be a SIP URI or SIPS URI. Unlike the
 >        REGISTER request, the Request-URI SHOULD contain both 
 > "userinfo"
 >        and "@" components.
 > 
 > I see no reason for this. The request-uri is all about routing, and 
 > routing is fully specified in 3261. There is no reason to 
 > muck with this 
 > here. 

I agree. Will remove that.

 > By the time the request arrives, the request-uri won't 
 > contain an 
 > AOR. Whether it had one initially or not is of no 
 > consequence. The ESC 
 > must decide what presence document to operate on based on 
 > the content of 
 > the message received. This decision will presumably be made 
 > based on the 
 > request-uri at that time, together with the presumed 
 > association of that 
 > with a particular AOR/presence document. (Or maybe it will 
 > be made based 
 > on the content of the To field.)

The intention is exactly that - the decision is based on the To field.

 > 
 > -----
 > 
 > Section 5:
 > 
 >     To: The To header field contains the address-of-record whose
 >        publication is to be created, removed, or modified. 
 > The To header
 >        field and the Request-URI field are typically the same. This
 >        address-of-record MUST be a SIP URI or SIPS URI.
 > 
 > I think there is some question whether the To should be used 
 > to select 
 > the presence doc or whether the request uri should be used. 
 > It depends 
 > on what we expect to happen in the case of forwarding.
 > 
 > Suppose sip:[email-masked] forwards everything to 
 > sip:[email-masked]. 
 > Then suppose something sends a PUBLISH to alice. This will 
 > get forwarded 
 > to the ESC registed for bob. Now, does it refuse the request 
 > because the 
 > To references alice, or does it update the presence of bob? 
 > I haven't 
 > decided what I think the right answer is. But I think it ought to be 
 > consistent with what happens to SUBSCRIBE requests addressed 
 > to alice.

Here I disagree. I think what happens should be consistent with what happens to REGISTER requests addressed to alice's registrar. If the PUBLISH lands on a UA that doesn't handle publications for the address in the To, it should reject it.

 > -----
 > 
 > Section 6:
 > 
 >     The Event State Compositor (ESC) is a UAS that processes 
 > and responds
 >     to PUBLISH requests, and maintains a list of 
 > publications for a given
 >     address-of-record. The ESC has to know (e.g., through 
 > configuration)
 >     the domain or set of domains for which it maintains event state.
 > 
 > This makes an assumption that a given ESC is responsible for 
 > a domain or 
 > domains. This need not be the case. It may simply be 
 > responsible for a 
 > few specific users. Proxy routing logic can get things to 
 > the right ESC. 
 > I think this could be reworded as:
 > 
 > "The ESC has to know (e.g., through configuration) the set 
 > of addresses 
 > for which it maintains event state."

Agreed. I will replace the text. 
 
 > -----
 > 
 > Section 6:
 > 
 >     A client may probe the ESC for the support of PUBLISH using the
 >     OPTIONS request defined in SIP [2]. In the response to such an
 >     OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of
 >     allowed methods in the Allow header field. Also, it 
 > SHOULD list the
 >     supported event packages in an Allow-Events header field.
 > 
 > It may be tricky to get this to work. If the ESC is itself 
 > registered as 
 > one of the contacts of the AOR, then a straightforward OPTIONS will 
 > fork, and only the first response will get back. That might 
 > not be from 
 > the ESC.
 > 
 > To get around that, it may be necessary to use callerprefs 
 > to direct the 
 > OPTIONS to the ESC, perhaps via something like:
 > 
 > 	OPTIONS sip:user@domain
 > 	To: sip:user@domain
 > 	From: sip:somebody@domain
 > 	Accept-Contact: *;methods="SUBSCRIBE";events="presence"
 > 
 > Having said that, I don't know how much of it needs to be in 
 > the spec. 
 > Maybe just a warning.

Agreed. I will add a note to this effect.
 
 > ------
 > 
 > Section 6:
 > 
 >     1.   The ESC inspects the Request-URI to determine whether this
 >          request is for a domain supported by the ESC. If 
 > not, the ESC
 >          SHOULD proxy the request to the addressed domain.
 > 
 > The ESC is a UA. UAs are typically not required to act as 
 > proxies. In 
 > any case, this bullet is all about standard 3261 behavior. 
 > Don't think 
 > it needs to be said.

I agree. This is leftovers from reuse of the steps in 3261 describing registrar behavior.
 
 > -------
 > 
 > Section 6:
 > 
 >     4.   The ESC SHOULD determine if the authenticated user 
 > is authorized
 >          to perform event state publication for the 
 > address-of-record of
 >          the To header field.
 > 
 > This goes to my question above about whether selection of the 
 > presentity/presence document should be based on the request uri or 
 > To-uri. Here it clearly specifys this.
 > 
 > The problem with this is that I don't believe it is consistent with 
 > SUBSCRIBE.
 >
 > -------
 > 
 > Section 6:
 > 
 >     5.   The ESC extracts the address-of-record from the To 
 > header field
 >          of the request.  If the address-of-record is not 
 > valid for the
 >          domain in the Request-URI, the ESC MUST send a 404 
 > (Not Found)
 >          response and skip the remaining steps.
 > 
 > Again I think this is over specifying. There need not be any 
 > specific 
 > relationship between the domain in the request uri and the 
 > domain in the 
 > To uri, though there often will be. But it could be completely 
 > reasonable for some server at sip:presenceRus.com to act as 
 > an ESC for 
 > users in any number of domains.
 > 
 > *If* the To address is to be used for choosing the presence 
 > document to 
 > be affected, it would be better to say:
 > 
 > "The ESC extracts the address-of-record from the To header 
 > field of the 
 > request. If the ESC does not manage event state for this address, it 
 > MUST send a 404 (Not Found) response and skip the remaining steps."

Agreed. In fact, RFC 3261 says UAS should reject with 403 if the To isn't known and not acceptable as such. Also, this part of step 5 should in my opinion be the very first thing the ESC does. So my proposal for changing the text and the steps would be:

	1.	The ESC inspects the To header field to determine whether this
		request is targeted for a resource, for which the ESC is responsible 
		for maintaining event state. If not, the ESC MUST return a 403 
		(Forbidden) and skip the remaining steps.

---

	5.	Next, the URI in the To header field is converted to a canonical 
		form. To do that, all URI parameters MUST be removed (including the 
		user-param), and any escaped characters MUST be converted to their 
		unescaped form. The result serves as an index into the list of resources 
		whose event state is maintained by the ESC.

Cheers,
Aki

 > 
 > [THE END]
 > 
 > 
 > 
 > 
 > 
 > 
 > _______________________________________________
 > 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: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Sep 2003 15:05:33 -0400

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:

1) consistency with REGISTER.

There are conceptual parallels between PUBLISH and REGISTER. With 
REGISTER it is To that determines what is updated by the request. So 
perhaps the same should be true for PUBLISH.

But not all paralles hold. In case of REGISTER, the request uri only 
identifies a server. REGISTER requests can't be routed the same as other 
requests because of this. Either the registrar must be collocated with a 
proxy for the domain of the To, or else a proxy must take the To into 
account when routing a REGISTER. PUBLISH isn't so special - it is 
expected to be routed like any normal non-register request. The username 
part of the request uri is significant in this routing.

In the case of REGISTER, the target of the request *is* the domain of 
the registration. It must be this way because it is responsible for 
defining the address-of-record for use by other messages. For this very 
reason it is unique and unlike other sip messages.

To further consistency with REGISTER, it might make sense to have the 
request uri only name the domain within with the presence document is 
defined. But that would negate the unique value of REGISTER.

2) consistency with "normal" messages

Normal requests are generally routed to a UA based on request uri, 
without regard for the To. AFAIK we expect the same of PUBLISH requests.

Also, UAs typically accept or reject a request based on the request uri, 
not the To uri. For instance, if an invite is directed first to Alice, 
forwarded to Bob, and then to a phone registered to Bob's AoR, the phone 
typically decides how to process it (e.g. what "line" on the phone it 
relates to) based on the Request URI. (The To uri may play some more 
minor role, like affecting alerting.)

3) consistency with SUBSCRIBE.

SUBSCRIBE and PUBLISH are in some sense two sides of the same coin. 
PUBLISH delivers information to an agent that compiles it for use in 
answering subscriptions. SUBSCRIBE is delivered to an agent that returns 
information compiled by publications, among other things. The agent for 
subscriptions needs to be associated with the agent for publications. It 
makes sense for them to be related by a consistent name, and to be 
routed in a consistent way.

If I subscribe to Alice's presence, but she redirects my subscription to 
Bob, then what is returned to me is a report on Bob's presence. 
Consistency would argue that if I publish to Alice and she redirects my 
publication to Bob, that my publication should affect Bob's presence.

4) general utility

Suppose there are two users: sip:[email-masked] and 
sip:[email-masked]. As part of getting setup, the following 
registrations are done:

	REGISTER sip:atlanta.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Contact: sip:[email-masked]
	   ;methods="SUBSCRIBE,PUBLISH"
	   ;events="presence"

	REGISTER sip:biloxi.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Contact: sip:[email-masked]
	   ;methods="SUBSCRIBE,PUBLISH"
	   ;events="presence"

Consistent with this, alice has a phone that both registers and 
publishes presence:

	REGISTER sip:atlanta.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Contact: sip:[email-masked]
	   ;methods="INVITE,OPTIONS,BYE,NOTIFY"
	   ;events="presence"

	PUBLISH sip:[email-masked]
	To: sip:[email-masked]
	From: sip:[email-masked]
	Event: presence

Then Alice goes on vacation. She configures a rule in the proxy that 
manages her address-of-record, causing all requests addressed to 
sip:[email-masked] to be forwarded to Bob. So what happens to 
requests for Alice?

According to current draft:

- INVITEs go to Bob and ring one of this devices
- PUBLISHs are routed to Bob's presence server.
   (sip:[email-masked]) But it looks without success for
   a presence document for sip:[email-masked].
   Without one of those, the result will be a 403 or 404 error.
- SUBSCRIBEs to Alice's presence go to Bob's presence server.
   If permitted, they result in notification of Bob's presence.
   Nothing about Alice's presence is present in the result.

If the request uri were to be used to select the document to update:

- INVITEs go to Bob and ring one of this devices
- PUBLISHs are routed to Bob's presence server.
   (sip:[email-masked]) It selects the presence document
   associated with the AoR that contact is registered with.
   (sip:[email-masked])
   The publish may succeed and update the document, or may fail
   authorization with a 401 or 403.
- SUBSCRIBEs to Alice's presence go to Bob's presence server.
   If permitted, they result in notification of Bob's presence.
   Aspects of Alice's presence may be present in this, or not
   depending on authorization.

In practice, its unlikely that Bob would want to authorize update of his 
presence by publications of Alice's presence. So the visible results to 
both publishers and subscribers will be similar regardless of which 
approach is taken.

IMO it is preferable to go with consistency with "normal" methods - 
selecting the presence document to update based on the request uri 
rather than the To uri.

More comments below.

	Paul

> 	identifies the party responsible for the publication. 

Well, this depends on the decision about how the presence doc is 
selected. If it is from To then this is fine. If it is the request uri 
then this isn't fine.

> In case of presence, the To could actually contain a pres: URI and not a (SIP or SIPS) AoR. This should probably be mentioned somewhere?

Are you suggesting that the ESC would register to an AoR of sip:foo@bar, 
but that the presence document itself might be identified by pres:foo@bar?

If so, that doesn't seem like a good thing to me. If there is no clear 
and explicit linkage between the name of the document and the address 
used to deliver requests referencing the document, then how do I figure 
out how to send a request to reference presence? This becomes an issue 
for every presence client.

OTOH, if all resolution is done via the request uri, the client never 
has any confusion. It simply puts whatever url it has into the To and 
request uris and then follows normal rules. Any special handling that is 
required to associate pres: and sip: urls is strictly a problem for the 
server.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Mon, 29 Sep 2003 15:00:34 -0500

> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Sep 2003 17:02:11 -0400

> discussion was that the resource being modified was identified by the

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

---

From: Aki Niemi <[email-masked]>
Date: Tue, 30 Sep 2003 11:43:43 +0300

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:
>>> 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:
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Sep 2003 09:39:55 -0400

Aki Niemi wrote:
> 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

:-)

> 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".

> 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

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.

> identification, so it's not an entirely uncontroversial road to take 

Covered above.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Sep 2003 10:50:14 -0500

> 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