Subject: [Simple] Removing a publication (PUBLISH) regardless of the ETag

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 11 Nov 2010 16:30:42 +0100

Hi, RFC 3903 states the following for removing an existing publication:

  To request the immediate removal of event state, an EPA MUST create a
  PUBLISH request with an Expires value of "0", and set the SIP-If-
  Match header field to contain the entity-tag of the event state
  publication to be removed.

My question is: would be possible to remove all the existing
publications for a user and a specific event without using
SIP-If-Match header?
This is, imagine that various EPA have published "Event: presence"
information for the same AoR, and I want to remove all of them with a
single PUBLISH. I expect that the following could work:

 PUBLISH sip:[email-masked] SIP/2.0
 Event: presence
 Expires: 0

Unfortunatelly I think that this is not valid/allowed by RFC 3903, am I wrong?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Nov 2010 16:41:09 -0600

> Unfortunatelly I think that this is not valid/allowed by RFC 3903, am I wrong?

My understanding is that it is not allowed. There were explicit decisions to limit an EPC to only be able to refresh, modify, or remove state that it published. This was based on implementation experience from REGISTER, where the ability to remove registrations created by other devices has been a major shoot-self-in-foot feature.

Do you have a use case in mind for which you would want to do this?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 00:00:22 +0100

> My understanding is that it is not allowed. There were explicit decisions to limit an EPC to only be able to refresh, modify, or remove state that it published. This was based on implementation exp…

Yes, but a device can un-register all the registrations for its AoR by
setting "Contact: *" in a REGISTER with "Expires: 0". It seems there
is not a similar "feature" for PUBLISH.

> Do you have a use case in mind for which you would want to do this?

Yes. I would like to give some consistency to active publications (for
event "presence") and registrations. For example, im XMPP a user
cannot publish presence status if he is not "registered" (reachable by
his watchers). IMHO it doesn't make sense to appear as "online" for
the watchers while the user is not registered (I mean "online for SIP
communication", and not "I'm online in mail" and such stuf present in
some RFC's which seems a no-sense for me).

In XMPP when a user gets disconnected or unreachable (i.e. TCP
connection is broken) the server automatically distributes
"unavailable" presence stanza to update the user presence status.

So what I want to achieve is the SIP registrar to monitor the
reachability of each registered user (by sending OPTIONS or whatever,
typically used to mantain NAT keep-alive) and to generate a PUBLISH
for event "presence" with "Expires: 0" to remove the active
publications of a user in case it gets unreachable (without waiting
for the expiration time of the publication).

However it could occur that different devices publish presence
information for same AoR. In SIP there is no concept of "resource" (as
in XMPP) so there is not a relationship between a registered device
and an EPA. This would invalidate what I want to achieve, but I also
have something in mind for impementing the "resource concept in SIP :)

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Nov 2010 17:04:23 -0600

On 11/15/10 5:00 PM, Iñaki Baz Castillo wrote:
> 2010/11/15 Ben Campbell<[email-masked]>:

Precisely. To rephrase what Ben said: REGISTER taught us that this was a 
_really_ _bad_ _idea_, so we did extra work to make sure it couldn't be 
done in PUBLISH. It wasn't an accident.

/a

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Nov 2010 00:05:19 +0100

On Nov 16, 2010, at 12:00 AM, Iñaki Baz Castillo wrote:

> and an EPA.

Couldn't you register a GRUU and use it to identify the PIDF of a certain UA that belongs to your address of record?

> This would invalidate what I want to achieve, but I also
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Nov 2010 17:09:11 -0600

> for the expiration time of the publication).

How would you see this work if a user has more than one active device?

To my knowledge there is no standardized way to do what you have in mind. One could always collocate the EPA with the registrar, or implement a proprietary interface to tell the EPA to invalidate all state for an [AoR, event]. But of course, that would be, proprietary.

> have something in mind for impementing the "resource concept in SIP :)

Actually, the eTag itself creates an implied relationship, or "resource", in that it defines the "piece of state for a given [AoR, event] published by a particular device."

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 00:18:58 +0100

2010/11/16 Adam Roach <[email-masked]>:
> _really_ _bad_ _idea_, so we did extra work to make sure it couldn't be done
> in PUBLISH. It wasn't an accident.

ok ok, understood :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 00:21:27 +0100

> Couldn't you register a GRUU and use it to identify the PIDF of a certain UA that belongs to your address of record?

Yes, but that is not defined. And also, associating the presence
status of the human making usage of such device is not clear.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Nov 2010 00:24:33 +0100

I can publish my GRUU using presence and subscribers can use this information to add a  right click menu option in their app to start a session only to that instance, like in XMPP.

For me is crystal clear :-)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 00:25:53 +0100

> I can publish my GRUU using presence and subscribers can use this information to add a  right click menu option in their app to start a session only to that instance, like in XMPP.

Yes, but your watchers have no way to know if the human using each
device/GRUU is "online" or "idle" or "away"... as <person> is not
related to a device/resource as in XMPP.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 00:29:04 +0100

2010/11/16 Ben Campbell <[email-masked]>:
> To my knowledge there is no standardized way to do what you have in mind.

I know. I don't speak about existing specifications :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 16 Nov 2010 10:39:36 +1100

How about RFC4827?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 00:41:36 +0100

> How about RFC4827?

That RFC just defines a way to publish permanent presence status, no more.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Nov 2010 00:55:01 +0100

Why cant you just use something like this?

    <tuple id="bs35r9">
       <status>
         <basic>open</basic>
       </status>
       <contact priority="0.8">sip:[email-masked]</contact>
     </tuple>

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 01:01:31 +0100

>        <contact priority="0.8">sip:[email-masked]</contact>

<activities> (online, idle, busy, away) is into <person> document, not
in <tuple>.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 16 Nov 2010 11:03:08 +1100

I don't think so. The RFC defines a way to manipulate presence documents
independent of a device. The RFC introduces 3 main use-cases, but does not
limit the use of the RFC to those cases.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Nov 2010 20:27:32 -0600

From section 3:

"As individual inputs, the presence states set by XCAP and SIP PUBLISH   are completely separated, and it is not possible to directly  manipulate the state set by one mechanism with the other."

On Nov 15, 2010, at 6:03 PM, Hisham Khartabil <[email-masked]> wrote:

> I don't think so. The RFC defines a way to manipulate presence documents independent of a device. The RFC introduces 3 main use-cases, but does not limit the use of the RFC to those cases.
> 
>

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 16 Nov 2010 13:47:01 +1100

Well that's no good :)

The scenario that Inaki is discussing talks about a user going offline from
one device, so I guess you don't really want to make unavailable all
presence information for that user, but only those related to the device
that went offline. Is that correct?

The concern here is that the presence info sent from that device may be
stale until it expires. A mechanism is needed allowing a 3rd party to
manipulate presence info published by a publishing party. I see security
concerns here.

In XMPP, how is the security concern mitigated? How is the 3rd party granted
permission by the user (publisher) to manipulate presence info published by
it?

Hisham

On 16 November 2010 13:27, Ben Campbell <[email-masked]> wrote:

> From section 3:
>
> "As individual inputs, the presence states set by XCAP and SIP PUBLISH
> are completely separated, and it is not possible to directly  manipulate the
> state set by one mechanism with the other."
>
>
> On 16 November 2010 10:41, Iñaki Baz Castillo < <[email-masked]>
> [email-masked]> wrote:
>
>> 2010/11/16 Hisham Khartabil < <[email-masked]>
>> [email-masked]>:
>> > How about RFC4827?
>>
>> < <[email-masked]>[email-masked]>
>>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 09:33:28 +0100

> that went offline. Is that correct?

Correct. But this is not easily feasible in SIMPLE as registrations
and publication don't mantain a relationship.

> permission by the user (publisher) to manipulate presence info published by

The server does all this job in behalf of the user. This is, in case
the user goes offline (without sending a "unavailable" <presence>
stanza) then his server generates such stanza for his active watchers.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Nov 2010 09:37:03 +0100

> <activities> (online, idle, busy, away) is into <person> document, not

Did you ask something about activities?

I thought you complained about not being able to target a specific UA like with XMPP. You actually can, by publishing your GRUU.

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Nov 2010 09:40:11 +0100

> and publication don't mantain a relationship.

This is purely an implementation issue, what stops your Presence Agent to act upon the lack of Register? They are both in the same server in the end and if is not your particular architecture should take care of it if is important aspect for you.

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 10:05:24 +0100

> Did you ask something about activities?

I said:

"[...] watchers have no way to know if the human using each
device/GRUU is "online" or "idle" or "away"... as <person> is not
related to a device/resource as in XMPP."

I'm not interested in <tuple><status></basic>open/closed as it mostly useless:

RFC 3863
-------------------------------------
4.1.4.  The <basic> element

   The <basic> element contains one of the following strings: "open" or
   "closed".

   The values "open" and "closed" indicate availability to receive
   INSTANT MESSAGES if the <tuple> is for an instant messaging address.
   They also indicate general availability for other communication
   means, but this memo does not specify these in detail.
-------------------------------------

What is a tuple for an "instant messaging address"??
<basic> says nothing interesting, in fact OMA states that it must be
always "open".

Many vendors use <basic> open/closed to mean user "online" /
"offline", which is incorrect.
IMHO <basic> node shouldn't exist.

> I thought you complained about not being able to target a specific UA like
> with XMPP. You actually can, by publishing your GRUU.

You can mantain two registrations (device-A and device-B).
You can also publish a <person> and a <tuple> from both.
You can use GRUU in the <tuple><contact> node.
But watchers have no way to determine which <person> belongs to each
<tuple> so watchers cannot know if you are "away" in your Android
phone or "busy" in your Blink softphone. Watchers will receive two
<tuple> ("Android" and "Blink") and two <person> (one "away" and the
other one "busy"), except in case the presence server merged those two
<person> nodes into one by following non clear/defined rules.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 10:11:49 +0100

> This is purely an implementation issue, what stops your Presence Agent to act upon the lack of Register? They are both in the same server in the end and if is not your particular architecture shoul…

How can the Presence Agent determine which publications to remove when
a specific device gets unregistered? what about if there are more than
one device registering/publishing for same AoR?
Will you store the PUBLISH source IP in the server and remove such
PUBLISH in case a user registered from same IP gets offline? It seems
a workaround, doesn't it? :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Nov 2010 10:53:19 +0100

Why everything forms one way or another a problem? Even if you have a solution in front of you would certainly find a way to make it now work.

Everyone could write a billion essays about things that do not work as expected or are unclear in the standards. What is the point? 

Better provide a solution, write some software, publish an RFC,  do something about it.

Anything is better than endlessly complaining about everything.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Nov 2010 11:08:03 +0100

> Anything is better than endlessly complaining about everything.

Adrian, I'm not complaining, where do you see that?.

I just asked about removing publications without knowing their ETag's,
just it. During the thread I was asked about the motivation for that
and I explained what I want to achieve.
Then various mails (including yours) try to say that what I want is
already possible with SIMPLE, and I reply that "it's not" (giving
technical arguments). Does it mean I'm complaining? Not at all ;)

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 16 Nov 2010 11:10:45 +0100

I addressed a single complain from your list, that is the targeting of a particular UA, this is why I limited the text in my reply to that section.

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 17 Nov 2010 10:29:44 +1100

> stanza) then his server generates such stanza for his active watchers.

How does the user grant the server permission?

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 17 Nov 2010 10:33:39 +1100

> I'm not interested in <tuple><status></basic>open/closed as it mostly
Yes, the server will merge the <person> nodes and how is does that is an
implementation issue. Doesn't that solve your problem with tuples?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 17 Nov 2010 09:36:16 +0100

> How does the user grant the server permission?

Why should the user grant the server permission for that? If the user
gets offline (i.e. it crashes) why cannot the server remote its active
publications and send "unavailable" presence to user's  watchers?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 17 Nov 2010 09:38:24 +0100

> implementation issue. Doesn't that solve your problem with tuples?

Imagine Alice is connected in two rdevices using XMPP. Then a watcher
can see that:
- resource "android-xmpp" is idle.
- resource "pidgin" is busy.

Can you do the same with SIMPLE by means of the merged <person> and two <tuple>?

-- 
Iñaki Baz Castillo
<[email-masked]>