Subject: [Simple] Re: draft-olson-simple-publish-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Oct 2002 11:07:04 -0500

I question the need for the Stream header. Its use seems entirely analogous to the use of a common Callid header in REGISTER requests. Why is it necessary to introduce a new header for PUBLISH when it wasn't necessary for REGISTER?

	Paul

---

From: Sean Olson <[email-masked]>
Date: Mon, 28 Oct 2002 09:00:24 -0800 (PST)

The analogy breaks down in situations that need
more persistence of the stream identifier. If Call-ID
where to persist across all requests, across reboots,
and potentially across devices, then it would be a
perfect fit :) It may be that we find a better way
to accomplish this. The "Stream" header is a first
shot at satisfying the need for a compositor to
identify the source of a publication.

Thanks,
Sean Olson
Microsoft

--- Paul Kyzivat <[email-masked]> wrote:
> I question the need for the Stream header. Its use
> seems entirely analogous to the use of a common
> Callid header in REGISTER requests. Why is it
> necessary to introduce a new header for PUBLISH when
> it wasn't necessary for REGISTER?
> 
> 	Paul
> _______________________________________________
> simple mailing list
> [email-masked]
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Oct 2002 14:17:29 -0500

Sean Olson wrote:
> perfect fit :)

Hmm. If that analogy doesn't hold then it would be helpful to have a more complete description of the semantics of a stream. I guess the discussion of section 1.1.4 Publisher Instance is intended to provide this. But it doesn't line up especially well with the definition of Stream in 3.3. Section 3.3 focuses on providing a context within which to process messages in order, while 1.1.4 focuses on distinct publishing instances. From your comments, you suggest that a distinct instance might not always reside on the same device. Once you say that, the possibility arises that you might have two physical devices simultaneously claiming to have the same logical identity. And that messes up the suggested means of ordering messages within a stream. Actually, even moving a stream from one device to another might cause ordering to be messed up if there is significant clock skew.

Based on the available descriptions, I don't yet understand what I might want to use this feature for. You authors obviously have something in mind that motivates the exact options you have selected. Maybe a more specific example would help.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 00:28:12 -0500

inline.

Paul Kyzivat wrote:
 >
 > Sean Olson wrote:
 >
 >> The analogy breaks down in situations that need more persistence of
 >> the stream identifier. If Call-ID where to persist across all
 >> requests, across reboots, and potentially across devices, then it
 >> would be a perfect fit :)
 >
 >
 > Hmm. If that analogy doesn't hold then it would be helpful to have a
 > more complete description of the semantics of a stream. I guess the
 > discussion of section 1.1.4 Publisher Instance is intended to provide
 > this. But it doesn't line up especially well with the definition of
 > Stream in 3.3. Section 3.3 focuses on providing a context within
 > which to process messages in order, while 1.1.4 focuses on distinct
 > publishing instances. From your comments, you suggest that a distinct
 > instance might not always reside on the same device.

Yes. I think the idea is that you might want to, from one device, change 
the state published originally from another. Example would be, you left 
your work PC on, set your status to "working", and when you get home, 
want to change it to "out of the office", but from a different device.

I admit this is going to get complicated with soft-state refreshes, 
since the work PC will presumably continue to refresh the "working" 
status, resulting in an oscillation of the presence state. Thats clearly 
not what you want.

I suppose a better solution would be for the home PC to publish as a 
separate stream, but publish using the same tuple ID that is being used 
by the work PC. The compositor would them somehow know to select the 
tuple from the home PC as higher priority.

In that case, the stream identifier really is playing the same role as 
the call-id in register, or a dialog ID.

So, it seems we have a few options here:

* use a new header, as in the current doc
* use register-like semantics
* have PUBLISH establish a dialog

The current doc dismisses the idea of dialog establishment. But, since 
publications are soft-state, and if you assume a stream is always tied 
to a particular source, a dialog may make a lot of sense. I always 
regretted the "special case" behavior that REGISTER has, and would 
prefer not to propagate it...

-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