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
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

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

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

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