Subject: Re: [Simple] PUBLISH and REGISTER relationship

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 10:31:41 -0400

The interim has motivated me to respond to this somewhat old thread.

I think there is a distinction, and it lies with the model of how 
presence works.

In my mind, there is an existing universe of data about users. This 
data is embedded in many, many places - in HLRs, in VLRs, in 
registrars, in corporate databases, in cell phones, in PBXs, etc. This 
data has meaning within the systems in which it resides, and there are 
protocols within those systems for manipulation of it. Protocols like 
LDAP, SIP REGISTER, SS7, etc.

Separate from that is a presence system. The presence system provides 
a "front end" for this data below, allowing interested parties to 
subscribe to it, and based on authorization policies, receive 
notifications to it. PUBLISH is an interface between these existing 
systems and the presence system, providing a standardized way to move 
information between them.

However, PUBLISH in no way replaces any of the above protocols.

So, in the specific case of SIP, the existing system is the registrar. 
It has state, manipulated by REGISTER, and consumed by proxies for 
call routing. Separately, ontop of this system, lies a presence 
server. The registrar would push registration state into the presence 
server using PUBLISH.

So, I would argue that a PUBLISH has no impact on registration state, 
unless there is some very odd, domain-specific policy that decides to 
make it that way. This isn't a PUBLISH specific issue. One can imagine 
that an enterprise has a web system where users login to the corporate 
website when they come to work. This login could trigger a sip 
registration to be created. We dont disallow this kind of thing, but 
there is no expectation that it exists as a general rule.

-Jonathan R.

Ben Campbell wrote:
> On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote:
> 
>>If we were creating the SIP protocol today I am not sure that both 
>>REGISTER and PUBLISH would have been
>>created. We would have created only one of them. Now we have both several 
>>questions may arise:
> 
> 
> I agree we may not have gone the same route if we were inventing from
> scratch. That is, of course, true of many things. However, REGISTER and
> PUBLISH have different purposes. REGISTER puts rendezvous info into the
> SIP network infrastructure--sort of a higer-layer route generation.
> PUBLISH carries presence info to be distributed to watchers. Now, that
> presence info _might_ be a superset of the rendezvous info, but it
> doesn't have to be.
> 
> 
>>* Is it "legal" for a system to add the contacts it got through PUBLISH to 
>>the registrar? 
> 
> 
> Assuming you mean in the broader sense of a location service, sure. It's
> legal to put contacts into a location service from _any_ source. It is
> up to the implementer to decide what sources make sense for his
> implementation. (This particular case might not be a good idea, but the
> protocol does not categorically rule out bad policy decisions.)
> 
> 
>>  Someone would like to reveal some contacts only to the users that can 
>>see her/his presence.
> 
> 
> Sure. But as above, don't equate policy with protocol rules. There are
> many policies a network could follow that would allow this bit of
> choice.
> 
> 
>>* Probably the same question from a different angle: What should be the 
>>awareness of the user
>>  to the system behavior. The user may think that if the PUBLISH have 
>>expired he/she is no longer
>>  available online while the system may use REGISTER in order to consider 
>>the user as online.
> 
> 
> I don't think we have fully defined what it means for a publication to
> expire. I would suggest it meanst that the watcher should consider the
> presence state to be indeterminant. Indeterminant is not the same thing
> as off-line.
> 
> I don't see why presence expiration should necessarily imply anything
> about registration state. Certainly, there is no protocol rule that
> prevents an AoR from working, even if presence state indicates the user
> is offline. If a user wants to make sure this does not happen, he could
> simply set the same expiration for registered contacts as he does for
> published presence state.
> 
> Personally, I don't think we can pre-define any relationship between
> REGISTER and PUBLISH. Such things are a matter of local policy. The
> architecture draft may suggest some possible useful policies, but should
> not preclude creativity in creating totally different policies.
> 
> 
> 
>>Avshalom
>>
>> 
>>
>>
>>
>>Paul Kyzivat <[email-masked]> 
>>07/05/2003 21:28
>>
>>To
>>Ben Campbell <[email-masked]>
>>cc
>>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG <[email-masked]>
>>Subject
>>Re: [Simple] PUBLISH and REGISTER relationship
>>
>>
>>
>>
>>
>>
>>I'm assuming you are questioning the relationship between requests that 
>>start out somethin like:
>>
>>                 REGISTER sip:example.com
>>                 To: sip:[email-masked]
>>                 ...
>>
>>and
>>
>>                 PUBLISH sip:[email-masked]
>>                 To: sip:[email-masked]
>>                 ...
>>
>>If so, I think there is some probable precedence of the REGISTER over 
>>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for 
>>address sip:[email-masked]. It is not routed according to the prior set 
>>of registered contacts for that address.
>>
>>OTOH, the PUBLISH, at least in principle, is just an ordinary message, 
>>and is routed based on the registered contacts, plus local policy of the 
>>proxy/registrar.
>>
>>So, the REGISTER *could* have been installing a contact for the presence 
>>server itself. In that case, prior to the register the PUBLISH might 
>>have failed, whereas after it might succeed. I don't think the converse 
>>is a likely scenario. (That before the publish the register would fail, 
>>but after the register would succeed.)
>>
>>I do agree that there are similarities between REGISTER and PUBLISH. I 
>>can imagine a system that supports PUBLISH and not REGISTER, and does 
>>all routing based on presence, using the contact addresses in presence 
>>tuples. That would be an unusual sip system today, though it may be less 
>>so in the future.
>>
>>I also agree with Ben that there is plenty of opportunity for local 
>>policy to determine what happens here. I expect there will be plenty of 
>>systems where the registrar, presence server, and proxy are all bundled 
>>together and cooperate via local configuration.
>>
>>                 Paul
>>
>>Ben Campbell wrote:
>>
>>>I think that is entirely a question of local policy. There is no
>>>protocol requirement for the two operations to be linked in any way, but
>>>a given service provider might choose to do so.
>>>
>>>If you _do_ link them, you are making assumptions about a relationship
>>>between the device doing the publishing and the device doing the
>>>registering that may or may not exist.
>>>
>>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote:
>>>
>>>
>>>>In a system that has both a registrar and a presence server what should 
>>
>>be 
>>
>>>>the relationships between
>>>>REGISTER and PUBLISH?
>>>>
>>>>* Should a REGISTER make the user on-line even though PUBLISH was not 
>>
>>sent 
>>
>>>>yet?
>>>>* Should PUBLISH be considered as a login to the system as REGISTER?
>>>>
>>>>To some extent it seems that PUBLISH and REGISTER have a similar 
>>>>functionality but one is for the registrar
>>>>while the other is for the presence server.
>>>>
>>>>Avshalom
>>>>
>>>>
>>>>_______________________________________________
>>>>Simple mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/simple
>>>
>>>
>>>_______________________________________________
>>>Simple mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/simple
>>>
>>
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 10:31:41 -0400

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: 30 May 2003 09:42:25 -0500

> there is no expectation that it exists as a general rule.

I will go further and say that there is no SIMPLE requirement that
REGISTER and PUBLISH are related in any way. REGISTER _might_ affect
presence state in the way you mention above, and probably will for most
systems. But if someone builds a system in which it does not, that
system is not in violation of any SIMPLE principle. Just because it is
extremely useful does not make it required.

---

From: Ben Campbell <[email-masked]>
Date: 30 May 2003 09:42:25 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 10:45:56 -0400

> extremely useful does not make it required.

Agreed.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 10:45:56 -0400

Agreed.

-Jonathan R.