Subject: [Simple] draft-koskelainen-sip-group-00

From: [email-masked]
Date: Thu, 23 Aug 2001 11:42:58 -0500

I was curious about the status of this draft and
its possible inclusion into the MESSAGE work
within SIMPLE. The draft points out a number
of interesting problems and possible solutions
for dealing with requests sent to potentially
large groups (for example, instant messaging
to a chat room).

Adding a Message-Id: header seems like a very
good idea. I would prefer In-Reply-To: instead
of References:, but this addition seems sound
as well. The addition of a message sequence
header is my only hesitation. I think a Date:
timestamp is sufficient for all real world 
problems, given that MESSAGE is meant to be
rendered to a human user and not to a automaton.

Any comments?
Regards,
Sean Olson
Ericsson Inc.

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Fri, 24 Aug 2001 13:20:32 -0400 (EDT)

Hi,

Thanks for the comments.

This was an invidual submission, a discussion document
meant to raise the discussion around this topic.

SIMPLE WG is probably good place to continue this
work if there is enough interest. The 
draft-ietf-simple-im-01.txt document might be the
easiest route to progress with some of the issues found
useful in the discussion document?

I'd like to continue at least with the following issues:
- event package for group message delivery status notification
- message and thread identification mechanisms 
e.g. Message-id and References header (or In-Reply-To as you said)
- message sequencing (ordering information) since in some cases 
the 1-second granularity of Date header is not enough.
We were assuming that in some cases the recipient of the MESSAGE 
is not human (but application which require the exact ordering 
information).

Also, I'm not convinced that all group messaging issues are understood 
widely enough by implementors so some kind of informational RFC (or 
guideline chapter in simple-im draft) might be a good idea. 
Otherwise we'll see a lot of variations in implementation details
and interoperability is more difficult (group messaging is provided
in several different ways). 

br,
--
Petri

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Aug 2001 13:41:44 -0400

Petri,

I had one comment about this, wrt sequencing.
You state (in 5.3):

> Group messaging should enable ordering. This means that clients 
> should know in what order (or time) the messages were processed
> and sent by the server.
...
> Therefore server should add ordering information to the outgoing 
> message. 

Ordering added by the server is only useful if everybody receives all
the messages from the server. But as far as I know nobody has proposed a
model where a message sender receives its own messages back from the
server. As a result, the sender has to order its own messages relative
to those it receives, and there is no guarantee that it will do so the
same way as the server does.

There is a similar problem if you conference together two existing
conferences each with its own server. 

The idea of a single server coordinating all traffic is fundamentally
different from a protocol designed to work e2e with the possibility of
some endpoints acting as mixers for other endpoints.

	Paul Kyzivat
	Cisco Systems

"Petri K. Koskelainen" wrote:
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple