Subject: RE: [Simple] I-D on IM transport proposal

From: "Christian Huitema" <[email-masked]>
Date: Fri, 3 May 2002 10:16:13 -0700

Jonathan,

In the message-session draft, you state that:

   The INVITE is processed normally by proxies. However, some proxy on
   the path might decide that the messaging stream needs to pass through
   an intermediary. To do that, it modifies the SDP, adding a "hop"
   attribute, containing a SIP URI for the hop. This URI need not be the
   URI of the proxy at all, but MUST always have a transport of TCP.

You explain further that this is indeed a violation of the general SIP
requirement, which state that proxies should leave the SIP payload
alone. Indeed, we are trying to move towards S-MIME security, which
would prevent such mangling.

I believe that the hop concept is fine, but that we must find a model in
which the "hop" requirement is inserted by the end system (UA), not the
proxy. We have to look at the main scenario that might require this hop
concept -- use of a different infrastructure for message sessions and
generic signaling. And we have to provide ways for the host to discover
that they should use this infrastructure: either configuration, or
dynamic discovery. For example, if the host sends too many messages
through the "signaling only" proxy, the proxy could send an error
response, indicating congestion and possibly suggesting an alternate
path.

-- Christian Huitema

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 6:59 PM
> To: [email-masked]
> Subject: [Simple] I-D on IM transport proposal
> 
> Folks,
> 
> I have just submitted an I-D that describes in detail the proposal for
> the IM session model which I hinted at (or is it hand-waved at) during
> IETF 53. The proposal uses the loose route capabilities of SIP to
avoid
> the problems we had with the original usage of MESSAGE. Until the
draft
> appears in the archives, you can pick up a copy at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-
> 00.txt
> 
> I sincerely apologize for the delay in getting this out. Part of the
> reason is that this intermediary issue is really broader than the IM
> session model, and so I also wrote a separate I-D that describes a
> proposal on how to address the bigger issue. Until that one appears,
you
> can pick it up at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-
> 00.txt
> 
> These are written so as to be decoupled, i.e., the message session
> proposal does not use the ideas in the session-policy draft, but it
> references it and discusses the issues that motivated it.
> 
> I must also, according to the policies of rfc2026, inform the group
that
> I believe dynamicsoft may have IPR associated with these drafts. Yet,
> fear not. It is being made available under our "its free if you don't
> bug us" policy, which you can find described at
> http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt.
> 
> Thanks,
> Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Vasilis Polychronidis <[email-masked]>
Date: Mon, 20 May 2002 04:34:57 -0700

Dear Jonathan great ID..
This multiple hop idea is great!
Now I would like to understand how we can accomplish conferencing with 
multiple
conferencing servers (multiple intermediaries).
About Christian's idea of having the UA inserting the hops I think it is 
a good one too however
this should only happen after the UA is authenticated with the proxy.
The UA is not a trusted entity and should not be allowed to do such 
things as adding hops without
prior authentication with the proxy.

In principle this ID can be used to establish messaging session via 
intermediaries that talk
SIP, CPIM/TCP , CPIM/HTTP, etc.

BR,

-Vasilis Polychronidis