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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Feb 2003 19:04:49 -0500

I think that any presence format that can be worked by a compositor needs to
have a concept of an atomic segment of presence. For PIDF, the tuple seems
like the easiest and most intuitive thing on which a compositor would act.
Perhaps if finer granularity and controls are needed for different <status>
elements in a tuple, that status could instead be split across multiple
tuples by the publisher.

This also doesn't mean that non-standard implementations of compositors
might not peer inside tuples and mutate their contents.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, February 11, 2003 8:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] PUBLISH: a dialog?
> 
> 
> 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.
> 
> 
> [email-masked] wrote:
> > 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
> >>>
> >>
> > 
> 
> -- 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 16 Feb 2003 23:40:45 -0500

> elements in a tuple, that status could instead be split across multiple

That depends on the semantic of what a tuple represents, I suppose, 
which we are also sorting out.

-Jonathan R.