Subject: RE: [Simple] PUBLISH: a dialog?

From: [email-masked]
Date: Thu, 6 Feb 2003 21:00:04 +0200

Hi Paul,

One way to get this optionality is to use the SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH always create a dialog, but also allow the infinitely short dialog created by a PUBLISH using Expires: 0.

It would sort of be a "push" of presence, similar to "fetch" in the subscription side.

Cheers,
Aki

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 06 February, 2003 17:37
> To: [email-masked]
> Cc: 'Jonathan Rosenberg'; Kiss Krisztian (NRC/Tampere);
> [email-masked]; [email-masked]
> Subject: Re: [Simple] PUBLISH: a dialog?
> 
> 
> I agree with Sean that we ought to think of PUBLISH as a fixed-up 
> REGISTER. But I agree with Brian that using Call-ID/CSeq as they are 
> used in REGISTER is  probably a mistake, and fails to learn from the 
> mistakes of REGISTER.
> 
> It would be nice if use of dialogs for PUBLISH was optional. If there 
> will be substantial traffic, then it may be useful to set up 
> a dialog. 
> If there isn't substantial traffic, or if the endpoints don't want to 
> bear the cost (as in the case Jonathan described) it might be 
> better to 
> forego a dialog.
> 
> Using the dialog mechanism of 3261, there is the option of sending 
> PUBLISH messages through a dialog established for some other purpose, 
> such as a subscription. If we even want to *permit* that, 
> then we can't 
> use Call-ID/CSeq in some conflicting way.
> 
> What we don't get with 3261 is a way to have an "optionally dialog 
> establishing" method. If PUBLISH isn't dialog establishing, 
> but we want 
> to use it in a dialog and don't have one already, there is no 
> perfectly 
> suited mechanism to get one. One possibility might be to make a 
> medialess invite. But there are many problems with that. It 
> seems like 
> an ugly solution.
> 
> An obvious technique might be for the publisher to subscribe 
> to its own 
> presence - something that is likely to be common. Then it could send 
> PUBLISH within the resulting dialog.
> 
> Or, we could consider a mechanism for "optionally dialog 
> creating" methods.
> 
> 	Paul
> 
> Sean Olson wrote:
> > Dialog state for PUBLISH will be a mistake. The more I 
> think about it,
> > the clearer it
> > becomes to me that PUBLISH should be a fixed-up REGISTER. 
> The hardest
> > problem is figuring
> > out when and how to tear down dialog state for PUBLISH 
> particularly if
> > it is the compositor
> > that wants to tear down the dialog. I am recommending that we use
> > Call-ID/CSeq in PUBLISH in
> > an analogous way to the way it is used in REGISTER itself.
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of
> > Jonathan Rosenberg
> > Sent: Wednesday, February 05, 2003 8:25 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [Simple] PUBLISH: a dialog?
> > 
> > 
> > I am still on the fence on this issue. Some responses and thoughts
> > inline:
> > 
> > [email-masked] wrote:
> >  > Hi All,
> >  >
> >  > I am supporting the dialog initiating PUBLISH method, 
> since that  >
> > seems to be a step forward to meet some of the requirements 
> posted to  >
> > SIMPLE list recently:  >
> > 
> http://mailman.dynamicsoft.com/pipermail/simple/2002-December/
> 002103.htm
> > l
> >  >  First, I believe the dialog concept would be preferable 
> to provide
> > 
> >>"feedback" to the PUA about the actual result of the publishing  >
> > 
> > transaction, whether the published XML was successfully 
> composed to  >
> > the presence document or not.
> > 
> > I agree with that, but I dont see why you need a dialog. I 
> had in mind 
> > that the response to PUBLISH is a 200 OK if the published data was 
> > accepted, and the response contains the "raw" presence data 
> from other 
> > publishers. This raw data could be used by a PUA to, for example, 
> > overwrite the presence data from another PUA.
> > 
> >  > Secondly, in a multi-PUA scenario, a
> >  > dialog would also be useful to provide feedback about 
> other PUAs'  >
> > activities, e.g. the publishing PUA could learn the presence  >
> > information (including the tuple ids) published by other PUAs.
> > 
> > I am not as sure there is a need to know when the published data 
> > changes, as to be able to fetch it. Considering our one and 
> only use 
> > case (going home and then setting the presence from my PC 
> at work to 
> > unavailable, since i left it running), the home device 
> doesn't need to 
> > know about changes in published information. It just needs 
> to query to 
> > find out the set of published data.
> > 
> > Does anyone have some use cases to motivate a notification 
> feature on 
> > the publication side?
> > 
> > Jon Peterson wrote:
> > 
> >>However, it isn't clear today if it is necessary to have a 
> longer-term
> > 
> > 
> >>identifier in the headers of the PUBLISH method, 
> considering that the 
> >>presence information itself may contain its own identifiers 
> (like the 
> >>tuple ID in PIDF) that could be reused as needed (such as 
> the case in 
> >>which one device overwrites presence published by another).
> > 
> > 
> > I think that, if the only thing you need sequencing for is 
> to determine 
> > the most recent tuple or status, the identifiers in the 
> tuples, along 
> > with the timestamps, will suffice. You also need to know 
> the source of 
> > the publisher, but you don't need a dialog for that.
> > 
> > I would argue that the need for some kind of sequencing beyond the 
> > timestamps in the tuples arises if we support differential 
> (not partial)
> > 
> > publication. In that case, I think you do need some kind of 
> sequencing 
> > outside of the tuple id. But, if we don't do that, even partial 
> > publication doesn't need sequencing outside of the pidf.
> > 
> > The counter-arguments is that its probably a good thing to provide 
> > sequencing of published presence data independent of the 
> document type. 
> > We may have other formats beyond pidf for specific vertical 
> sources of 
> > presence data.
> > 
> > The real benefit of the dialog state is the efficiency of 
> avoiding going
> > 
> > through proxies for updates and refreshes. You WILL need to 
> refresh, 
> > because published presence is soft-state. Managing the 
> soft-state may 
> > actually be hard if there is no sequencing provided by the SIP 
> > mechanism. The Call-ID/CSeq are required in REGISTER in order to do
> > this.
> > 
> > Here is an argument against dialogs. One can imagine that a 
> PUA might 
> > actually be this big server that is, for example, 
> collecting geolocation
> > 
> > for a large number of users and publishing it into the 
> presence system. 
> > It would be nice to not require additional state on that 
> box in order to
> > 
> > do the publication. If it could periodically sample the geoloc, 
> > construct a presence doc, timestamp it, and send it in a PUBLISH, 
> > without needing to remember the call-id or cseq, that would 
> be a good 
> > thing, I think.
> > 
> > 
> > One final comment. If we do add dialog support, we need to add the 
> > machinery to clean them up. There needs to be a way for 
> both sides to 
> > indicate termination of the dialog.
> > 
> > -Jonathan R.
> > 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 06 Feb 2003 14:39:13 -0500

Another option might be to follow the MESSAGE "methodology"; allow 
PUBLISH to be sent in a dialog-less mode or within an INVITE initiated 
dialog. Then obviously BYE could be used by either party to terminate 
the dialog.

Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Feb 2003 00:51:08 -0500

Unfortunately, the element which decides whether this is a dialog (the 
PUA) may not be the one who really wants it to be (the proxy, to avoid 
getting swamped with messages).

Anyway, I don't want to complicate things by trying to come up with a 
method which can either create a dialog or not. I think thats a recipe 
for trouble.

Sending PUBLISH over a dialog created by somethign else is better, but 
will introduce complexity into the compositor, which know will have to 
handle PUA which set up dialogs and those which don't.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Sean Olson <[email-masked]>
Date: Sat, 8 Feb 2003 10:17:03 -0800 (PST)

The Expires: is useful for soft-state; something
we must have for PUBLISH. But it is horrible for
indicating dialog state. It is especially horrible
if the compositor wishes to terminate the dialog
early.

--- [email-masked] wrote:
> Hi Paul,
> 
> One way to get this optionality is to use the
> SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH
> always create a dialog, but also allow the
> infinitely short dialog created by a PUBLISH using
> Expires: 0.
> 
> > > Cc: [email-masked];
> > >>tuple ID in PIDF) that could be reused as needed
=== message truncated ===

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Sat, 8 Feb 2003 10:18:20 -0800 (PST)

I think this is the best option as well.
I might go so far as to suggest that allowing 
methods other than INVITE to establish a dialog
is asking for problems.

--- Anders Kristensen <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 08 Feb 2003 19:48:51 -0500

I agree that this is a reasonable approach.

It does however open up some new issues that would need to be sorted out 
- not a fundamental problem, just more work. Specifically, what should a 
UAS do when receiving a "medialess" invitation? This probably depends on 
the purpose of the invitation. In the case we are discussing the purpose 
is simply to establish a dialog to carry PUBLISH messages, but it could 
be preparatory to a reinvitation with media, or whatever. If the UAS 
happens to be capable, should it alert?

	Paul

P.S. Describing this approach as "following the MESSAGE methodology" is 
a bit of a misnomer. Establishing a dialog for the purpose of creating a 
"message session" has been forbidden.

Sean Olson wrote:
>>>It would sort of be a "push" of presence, similar
>>
>>to "fetch" in the subscription side.
>>
>>>Cheers,
>>>Aki
>>>
>>>
>>>
>>>>Cc: 'Jonathan Rosenberg'; Kiss Krisztian
>>>
>>(NRC/Tampere);
>>
>>>>I agree with Sean that we ought to think of
>>>
>>PUBLISH as a fixed-up 
>>
>>>>REGISTER. But I agree with Brian that using
>>>
>>Call-ID/CSeq as they are 
>>
>>>>used in REGISTER is  probably a mistake, and fails
>>>
>>to learn from the 
>>
>>>>mistakes of REGISTER.
>>>>
>>>>It would be nice if use of dialogs for PUBLISH was
>>>
>>optional. If there 
>>
>>>>will be substantial traffic, then it may be useful
>>>
>>to set up 
>>
>>>>a dialog. 
>>>>If there isn't substantial traffic, or if the
>>>
>>endpoints don't want to 
>>
>>>>bear the cost (as in the case Jonathan described)
>>>
>>it might be 
>>
>>>>better to 
>>>>forego a dialog.
>>>>
>>>>Using the dialog mechanism of 3261, there is the
>>>
>>option of sending 
>>
>>>>PUBLISH messages through a dialog established for
>>>
>>some other purpose, 
>>
>>>>such as a subscription. If we even want to
>>>
>>*permit* that, 
>>
>>>>then we can't 
>>>>What we don't get with 3261 is a way to have an
>>>
>>"optionally dialog 
>>
>>>>establishing" method. If PUBLISH isn't dialog
>>>
>>establishing, 
>>
>>>>but we want 
>>>>to use it in a dialog and don't have one already,
>>>
>>there is no 
>>
>>>>perfectly 
>>>>suited mechanism to get one. One possibility might
>>>
>>be to make a 
>>
>>>>medialess invite. But there are many problems with
>>>
>>that. It 
>>
>>>>seems like 
>>>>an ugly solution.
>>>>
>>>>An obvious technique might be for the publisher to
>>>
>>subscribe 
>>
>>>>to its own 
>>>>presence - something that is likely to be common.
>>>
>>Then it could send 
>>
>>>>Or, we could consider a mechanism for "optionally
>>>
>>dialog 
>>
>>>>creating" methods.
>>>>
>>>>	Paul
>>>>
>>>>Sean Olson wrote:
>>>>
>>>>
>>>>>Dialog state for PUBLISH will be a mistake. The
>>>>
>>more I 
>>
>>>>think about it,
>>>>
>>>>
>>>>>the clearer it
>>>>>becomes to me that PUBLISH should be a fixed-up
>>>>
>>REGISTER. 
>>
>>>>The hardest
>>>>
>>>>
>>>>>problem is figuring
>>>>>out when and how to tear down dialog state for
>>>>
>>PUBLISH 
>>
>>>>particularly if
>>>>
>>>>
>>>>>it is the compositor
>>>>>that wants to tear down the dialog. I am
>>>>
>>recommending that we use
>>
>>>>>an analogous way to the way it is used in
>>>>
>>REGISTER itself.
>>
>>>>>From: [email-masked]
>>>>
>>[mailto:[email-masked]] 
>>
>>>>On Behalf Of
>>>>
>>>>
>>>>>Jonathan Rosenberg
>>>>>Cc: [email-masked]; [email-masked];
>>>>
>>[email-masked]
>>
>>>>>I am still on the fence on this issue. Some
>>>>
>>responses and thoughts
>>
>>>>>inline:
>>>>>
>>>>>>I am supporting the dialog initiating PUBLISH
>>>>>
>>method, 
>>
>>>>since that  >
>>>>
>>>>>seems to be a step forward to meet some of the
>>>>
>>requirements 
>>
>>>>posted to  >
>>>>
>>>>>SIMPLE list recently:  >
>>>>>
>>>>>> First, I believe the dialog concept would be
>>>>>
>>preferable 
>>
>>>>to provide
>>>>
>>>>
>>>>>>"feedback" to the PUA about the actual result of
>>>>>
>>the publishing  >
>>
>>>>>transaction, whether the published XML was
>>>>
>>successfully 
>>
>>>>composed to  >
>>>>
>>>>>I agree with that, but I dont see why you need a
>>>>
>>dialog. I 
>>
>>>>had in mind 
>>>>
>>>>
>>>>>that the response to PUBLISH is a 200 OK if the
>>>>
>>published data was 
>>
>>>>>accepted, and the response contains the "raw"
>>>>
>>presence data 
>>
>>>>from other 
>>>
>>>>>publishers. This raw data could be used by a PUA
>>>>
>>to, for example, 
>>
>>>>>>dialog would also be useful to provide
>>>>>
>>feedback about 
>>
>>>>other PUAs'  >
>>>>
>>>>>activities, e.g. the publishing PUA could learn
>>>>
>>the presence  >
>>
>>>>>information (including the tuple ids) published
>>>>
>>by other PUAs.
>>
>>>>>I am not as sure there is a need to know when the
>>>>
>>published data 
>>
>

---

From: Anders Kristensen <[email-masked]>
Date: Sun, 09 Feb 2003 12:40:46 -0500

> happens to be capable, should it alert?

The intent to send PUBLISH'es over a dialog could be "negotiated" 
through an m= line of the sdp in the INVITE similar to what we're doing 
for session-mode MESSAGEs.

> "message session" has been forbidden.

OK, I wasn't aware of that. Where does it say that, actually? Seems a 
bit odd to me at first blush.

Anders

>> I might go so far as to suggest that allowing methods other than 
>> INVITE to establish a dialog
>> is asking for problems.
>>
>>> Another option might be to follow the MESSAGE
>>> "methodology"; allow PUBLISH to be sent in a dialog-less mode or within
>>> an INVITE initiated dialog. Then obviously BYE could be used by either
>>> party to terminate the dialog.
>>>
>>> Anders
>>>
>>>
>>>>> a dialog. If there isn't substantial traffic, or if the
>>>>
>>>>
>>> endpoints don't want to
>>>
>>>>> better to forego a dialog.
>>>>>
>>>>> then we can't use Call-ID/CSeq in some conflicting way.
>>>>>
>>>>> but we want to use it in a dialog and don't have one already,
>>>>
>>>>
>>> there is no
>>>
>>>>> perfectly suited mechanism to get one. One possibility might
>>>>
>>>>
>>> be to make a
>>>
>>>>> seems like an ugly solution.
>>>>>
>>>>> to its own presence - something that is likely to be common.
>>>>
>>>>
>>> Then it could send
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Feb 2003 22:50:19 -0500

Anders Kristensen wrote:
>> It does however open up some new issues that would need to be sorted 
>> out - not a fundamental problem, just more work. Specifically, what 
>> should a UAS do when receiving a "medialess" invitation? This probably 
>> depends on the purpose of the invitation. In the case we are 
>> discussing the purpose is simply to establish a dialog to carry 
>> PUBLISH messages, but it could be preparatory to a reinvitation with 
>> media, or whatever. If the UAS happens to be capable, should it alert?
> 
> 

I would prefer to decouple this from our deliverable. That is, I would 
prefer to specify PUBLISH as not having anything to do with dialogs, and 
separately, if we deem it necessary, work out what it means to use 
INVITE to set up a publication session.

> 
>>
>>     Paul
>>
>> P.S. Describing this approach as "following the MESSAGE methodology" 
>> is a bit of a misnomer. Establishing a dialog for the purpose of 
>> creating a "message session" has been forbidden.
> 
> 

It says it in rfc3428, section 2:

> There may be a temptation to simulate a session of IMs by initiating
>    a dialog, then sending MESSAGE requests in the context of that
>    dialog.  This is not an adequate solution for IM sessions, in that
>    this approach forces the MESSAGE requests to follow the same network
>    path as any other SIP requests, even though the MESSAGE requests
>    arguably carry media rather than signaling.  IM applications are
>    typically high volume, and we expect the IM volume in sessions to be
>    even higher.  This will likely cause congestion problems if sent over
>    a transport without congestion control, and there is no clear
>    mechanism in SIP to prevent some hop from forwarding a MESSAGE
>    request over UDP.

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: 13 Feb 2003 14:45:21 -0600

> INVITE to set up a publication session.

I agree enthusiastically.

> It says it in rfc3428, section 2:

Actually it says SHOULD NOT. So forbidden may be a bit strong of a term.