Subject: RE: [Sip] Issue #113, wrt Content Sequencing

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 17:02:36 -0400

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2001 6:14 AM
> To: SIP List
> Subject: [Sip] Issue #113, wrt Content Sequencing
> 
> 
> On the one hand, I would love to find a generic mechanism for 
> ordering and
> detecting loss in overlapped non-INVITE content.  However, we 
> hashed over
> this issue in the SIP-events discussion.  Namely, content 
> sequencing and
> recovery is inherently content-specific.  Thus I would propose Strict
> Sequencing (if needed) in the content, as Jonathan originally 
> proposed.

I think the first question we need to ask is whether we even want to solve
the problem of overlapping non-INVITE. 

One of the bigger motivating factors was the MESSAGE method. However, simple
has converged upon NOT using MESSAGE for message transport in the session
model. As a result, that need has disappeared.

Are there other burning needs? This is one of those things where there may
not be a need now, but it could be a big issue down the road when someone
comes up with a need.

Notifications for rapid presence changes, like second-granularity geo-loc
updates, might be a need.

A more radical view is that if you want second-granular presence updates,
you are better off setting up the notifications as a "media stream" as we
are doing for IM, and use just SUBSCRIBE as is to set it up....

THoughts? Lets resolve this.

-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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Aug 2001 12:19:27 -0700

While an *average* rate of > 1/RTT probably calls for a real transport
protocol, it would be really nice to be able to send an occasional
message with a shorter spacing, particularly given the loss case (i.e.,
where it could be seconds before the answer comes back, thus delaying
the second message). Thus, I agree with Jonathan, that dumping this
feature could get us into trouble later. The increase in protocol
complexity seems close to zero and the increase in implementation
complexity modest.