Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol

From: [email-masked]
Date: Thu, 23 Aug 2001 07:11:54 -0500

Howdy

watching and putting some pieces together and I have this to offer...

There appear to be two significant issues:

1. the IESG wants to tank MESSAGE method for MESSAGE sessions or 'chat' like
conversations between known SIP UAs based on SIP Extension Rules, i.e. looks
like a transport protocol

2. using the MESSAGE method for simple 'paged' instant messages or one-off
instant messages is OK.
	
although one could argue it is still a mis-use of ideal SIP.  This is
because it is still carrying a payload and not necessarily initiating a
'session'  Unless the session is a human-based session, i.e. "come here
watson" or "can I ask you a quick question?" which would then create the
need for a 'session of MESSAGES' or physical appearance, either of which
SHOULD be handled by another protocol.

However, having another protocol for 'sessions of MESSAGEs' leads to the
issues Robert O. brought up, which were then refuted by Jonathon R. on the
basis of internet-drafts and scalability issues.  Moreover, the fact that
the MESSAGE extension was being perceived as a 'transport' violates the use
of SIP extension (ID sip-guidelines-02.txt section 3.1.)

SIP is supposed to act more like Chuck Wollery from 'the love connection' -
to use a colloquialism, i.e. bringing together

Jonathon R. would like to have end-to-end session of MESSAGEs to travel
between the clients directly as this supports the scalability and original
voice use of the SIP server.  On the other hand this doesn't support the
fundamental design requirements of IM as stated in rfc2779 2.4.3/2.4.4.
Which means, prior to supporting that end-to-end communication, the SIP
server would have to determine if 'that was allowed' based on the security
requirements Vasilis and Robert O have been talking about, which is also
required per rfc2779.

Those fundamental services can be easily implemented at the SIP server if
SIP was the method used to send 'sessions of MESSAGES' - problem here, IESG
doesn't like it.  There is a good reason why it is liked it's 'convenient',
but conveniences are not always a value.

So what we have is the need to 'reuse or create security features' adjunct
by the modular/portability needs and requirements of SIP/Signaling

The intermediary/PROXY MUST be created and supported as a basic feature of
the IM 'session of MESSAGEs' design.

In Robert Os case he would want the development of that intermediary to play
off of the domain and security information designed into the SIP server
(thus making it portable across SIP and the IM proxy).

This is easily designed if you have a unified configuration-directory where
the SIP Server and IM Message proxy pull configuration information,
otherwise, it looks like a complex proposition.

Should the protocol used for 'sessions of MESSAGEs' define how the
intermediary would be used? Yes, it has to, if it is to meet the design
requirement of rfc2779 2.4.3/4

In addition, to support end-to-end signaling the SIP server needs to have
logic on whether or not that end-to-end signaling is allowed or whether it's
end-to-end-to-end-to-end :) - this meets the rfc2779 2.4.3/4 requirement,
regardless of natiness.

So in retrospect:

MESSAGE SIP extension can't be used for sessions of IMs other wise it looks
like a transport mechanism and should be implemented separately

You need to design in the ability to use an intermediary per rfc 2779
2.4.3/4 (at a minimum)

We will have to figure out a way to get the bonus of domain/security from
SIP server into an IM intermediary.  A simple solution exists in using SIP
server to determine use of initiating sessions through an intermediary?
That is session initiation.

Jonathon R. has some good solutions for the intermediary in other IDs he has
written, but the reality is the communication looks more like 'direct
chatting' than text based audio/video conference, which is why the IESG
probably frowned on using RTP - wasn't there so I can't say for sure.  At a
high level these look the same, but at a low level the solution breaks down,
i.e. no video frames or audio sequencing in the protocol mechanism.  Which
is probably why ID cpim-msgfmt specifies the use of an existing text based
format, RFC822.

As an aside, I would also presume this is why sctp may not be a necessary
choice for the instant message 'signaling', to use a term from voice drafts,
given the sctp's primary use, albeit congestion management at the
intermediary/PROXY.  IMs are only text per node, am I naive to think it's a
moot point or would there be congestion issues at the intermediary???

Lastly, Jonathon R appears convinced that the communication should be
end-to-end.
(http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html),
but over TCP :)!  That works great if you are trying to scale the servers
and you want to put two callers together, but with IM, it's not voice and
it's like email, but more importantly, as stated in rfc2779, the
security/control needs to be built in.  I am just pointing out the
'vision/scope' of rfc2779 that says 'when you are heads down discussing
technical stuff, don't forget these requirements'  Jonathon didn't write
that RFC2779 so he probably isn't thinking with that light bulb on.

I would not want to see the IMsession design based on 'phone-calls' as
that's the 'way SIP has been predominatly used', but instead, to take a
different and assuredly positive approach.

I am not intending to offend anyone and I took some time to listen to the
forum, prior to submitting my points.  TIA

Joshua

--
Joshua L. Konkle
Business Technology Architect
Digital Knowledge
http://www.digitalknowledge.net

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 Aug 2001 13:48:59 -0500

I read this differently. The IESG objected to using SIP as an end-to-end
transport because all of the routing stuff is useless overhead in these
cases.

The IESG did not address those cases where the messages are traversing the
proxy network.

I have proposed that there are real reasons to have messages traverse the
proxy network -- the vast majority of reasons for having a proxy network at
all apply to messaging. This include firewall traversal, retransmission
delegation, network validation of identity, privacy mechanisms, gateways
between administrative domains, and so on.

-_
Dean
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 23, 2001 7:11 AM
Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>