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

From: [email-masked]
Date: Tue, 11 Feb 2003 18:33:59 +0200

Hi All,

I do remember one or two occasions where terms "user-plane" and "control-plane" have come up - for obvious reasons. ;) 

Personally I think the distinction is not so easy or even useful to make, especially here. A presence document might sometimes resemble a web page more than a media description (particularly an SDP delivered offer-answer-style). I'm assuming there are other reasons why a "publish session" similar to CPIM/TCP is not a good idea?

But I agree that Jonathan's proposal sounds reasonable. On whether to go with Stream or tuple id, I'd say tuple id. Crash recovery and sequencing aside, I think having a unique identifier for each published tuple has more value than having a unique identifier for each source of published tuples.

Cheers,
Aki

> -----Original Message-----
> From: ext Peterson, Jon [mailto:[email-masked]]
>
> A couple of comments here.
> 
> Firstly, I agree with Sean that publish is not 'media'. Personally, I
> recognize an informal distinction between 'signaling' and 
> 'media' (one that
> is perhaps grounded too much in traditional PSTN thinking), 
> where things
> like SDP would count as signaling, whereas bearer (be it 
> voice or instant
> messages) would count as media. However, I think we should 
> not use SDP to
> set up sessions for exchanging signaling, and I think
> publication/notification definitely falls into the 
> 'signaling' category.
> 
> Second, I have a hard time justifying a 'medialess' dialog 
> for PUBLISH. For
> some other methods, it may make sense to use a pre-existing 
> dialog that was
> established for other purposes to send this sort of signaling 
> information,
> but there really isn't any reason why such a pre-existing 
> dialog should be
> established between a PUA and a compositor (subscribing to 
> your own presence
> for this reason doesn't seem right to me - strictly, that's 
> subscribing to
> the PA, not the compositor, and the two may not be composed).
> 
> I am happy with Jonathan's suggestion that we pass over 
> dialogs in silence
> for now. The question would then be, do we need the Stream 
> header? Or would
> the tuple IDs in PIDF (and presumably a similar attribute in any other
> presence format) be sufficient to identify an atom of presence?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Sean Olson [mailto:[email-masked]]
> > Sent: Monday, February 10, 2003 8:33 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: [Simple] PUBLISH: a dialog?
> > 
> > 
> > There is a disconnect here. You can rightfully
> > argue that MESSAGE is media in the context of
> > a IM "session" (INVITE dialog). However, what I
> > was proposing is something much different. I was
> > proposing a signaling session established by an
> > INVITE. In this case, what is being exchanged is
> > literally SIP messages -- there is no simpler 
> > canonical form that can be transferred here such
> > as CPIM/TCP. And unlike the CPIM case, what I
> > am suggesting is that the PUBLISH request have
> > all the same characteristics as the dialog within 
> > which it is established, including Call-ID, route
> > set, etc. This is definitely not media.
> > 
> > --- [email-masked] wrote:
> > > I agree with what Aki's proposes. We purposefully
> > > rejected the use of MESSAGE within a dialog for
> > > various reasons including that; once you have
> > > established a dialog, a SIP message carries way too
> > > much information that it needs as a media protocol.
> > > The reasons apply here also.
> > > 
> > > I personally don't have any strong opinions
> > > regarding a PUBLISH having to do with dialogs. But
> > > if it does, then I prefer for the PUBLISH to
> > > establish the dialog rather than using SIP yet again
> > > as another form of media protocol.
> > > 
> > > If it will be INVITE to establish the publishing
> > > dialog, then, as Aki suggests, PIDF is the way to
> > > go, IMHO.
> > > 
> > > Regards,
> > > Hisham
> > > 
> > > > -----Original Message-----
> > > > From: ext [email-masked]
> > > [mailto:[email-masked]]
> > > > Sent: Monday, February 10, 2003 11:06 AM
> > > > To: [email-masked];
> > > [email-masked]
> > > > Cc: [email-masked]; [email-masked];
> > > Kiss Krisztian
> > > > (NRC/Tampere); [email-masked];
> > > [email-masked]
> > > > Subject: RE: [Simple] PUBLISH: a dialog?
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Inline.
> > > > 
> > > > > -----Original Message-----
> > > > > From: ext Anders Kristensen
> > > [mailto:[email-masked]]
> > > > > 
> > > > > Paul Kyzivat wrote:
> > > > > > 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?
> > > > > 
> > > > > 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.
> > > > 
> > > > We can also go down this path and forget PUBLISH
> > > altogether, 
> > > > and use a PDIF-over-TCP media - just like we've
> > > done away 
> > > > with MESSAGE in the message session work.
> > > > 
> > > > It seems to me we're going around in circles here.
> > > Where are 
> > > > the requirements driving this discussion? 
> > > > 
> > > > Cheers,
> > > > Aki
> > > > 
> > > > _______________________________________________
> > > > Simple mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > Simple mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/simple
> > 
> > 
> > __________________________________________________
> > 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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 Feb 2003 23:27:37 -0500

One point on identifiers.

We seem to be implicitly assuming that a tuple is the finest granularity 
of publication, and therefore a tuple ID will suffice. I can think of 
cases where I might want to publish an updated status for an existing 
tuple, without replacing the other statuses published elsewhere for that 
same tuple. If we use tuple id, we explicitly rule this out.

Using tuple ID also means that PUBLISH is bound to PIDF, or at least, 
any such format used would need to have the notion of a tuple with a 
unique ID.

I am not arguing against it, I just want to have all the facts on the table.

-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