Subject: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Jan 2002 18:02:08 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 7:46 AM
Subject: I-D ACTION:draft-mrose-simple-exchange-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: IM Simple Exchange (IMSX)
	Author(s)	: M. Rose
	Filename	: draft-mrose-simple-exchange-00.txt
	Pages		: 27
	Date		: 07-Jan-02
	
The Common Presence and Instant Messaging profile (CPIM) is a set of
syntax and semantics for instant messaging (IM) and online presence
services, independent of the underlying transfer infrastructure.  The
Session Initiation Protocol (SIP) negotiates session information for
media streams.  This memo defines a BEEP profile, IMSX, for
exchanging CPIM messages after SIP has performed signalling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mrose-simple-exchange-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mrose-simple-exchange-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Wed, 9 Jan 2002 18:02:10 -0500

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 9 Jan 2002 15:24:09 -0800

> http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-00.txt

if you prefer the html version, go to:

    http://www.beepcore.org/beepcore/docs/profile-imsx.html

enjoy!

/mtr

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 10 Jan 2002 11:31:25 -0800 (PST)

Hi Marshall,

I have a few suggestions and questions on your draft.

1) In the security considerations section you use MUST strength for both
DIGEST-MD5 and TLS_RSA_WITH_3DES_EDE_CBC_SHA.  I think requiring TLS and
3DES is too restrictive, especially for small devices or lightweight
implementations.  I propose using MUST strength for authentication
and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for
privacy and "all".

2) Please briefly (one sentence) mention the I: and L: convention before
you use it in the examples.

3a) You mention middleboxes briefly, but I wasn't sure what you are really
recommending when you say it may be needed for  "proxies to transparently
rewrite the transport information "   I assume you mean SIP proxies?
This is *AN* approach, but we won't be able to get to end-to-end integrity
if this is required, hence my next question...

3b) I am assuming that IMSX assumes that the two BEEP entities will
communicate directly without relays.  How would this work with a
couple of BEEP relays involved?  What address would you advertise in SDP?
If this is possible, I think this is very useful for getting around the
middlebox traversal problem.

4) I didn't get a good sense from your examples how to come up with
unique cid: URLs (especially if the originator is behind a NAT).
Do these have to be unique for all users/sessions, per BEEP session, or
per beep request?

5) I think an example or call-flow showing multiplexed bidirectional
messages would be really useful.

6) I'm assuming that the proposed transformation between im: and sip: URLs
is to merely replace the scheme.  Is this correct?

thanks,
-rohan

On Wed, 9 Jan 2002, Marshall T. Rose wrote:

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

---

From: "Marshall T. Rose" <[email-masked]>
Date: Thu, 10 Jan 2002 16:27:17 -0800

> and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for

the particular wording you see, and the particular technologises list
reflect what the IESG is letting go through these days. in other words,
they've been returning drafts to working groups and individual submissions,
asking for language with these choices.

it is important to appreciate the distinction between what gets implemented
and what gets provisioned. the requirement is that tls be available in
implementations, not that it has to be used by administrators.

implementors are free to sell products with other technologies.
administrators are free to configure or not whatever comes with the
software.

so what all this means is that administrators responsible for people with
small devices won't turn privacy on. that's okay. what's important is that,
two administrators agreeing to use privacy know that there will be at least
one choice available, tls, regardless of what products they're using. they
can then make a reasoned cost-benefit analysis as to what gets provisioned.

> you use it in the examples.

ok.

> middlebox traversal problem.

i don't think the text could be any clearer: the IMSX peers have no interest
in the network topology. the SIP infrastructure is responsible for ensuring
end-to-end usability of the transport information. if middleboxes are
involved, then the SIP infrastructure will have to deal with this. the
problem is no different for any other application protocol making use of the
SIP infrastructure.

there is no explicit relaying model. if you want that, this is the wrong
architecture. if you want to solve the middlebox problem, this is the wrong
working group.

> Do these have to be unique for all users/sessions, per BEEP session, or

i think the email folks solved this problem long ago. generating a unique
url is trivial, particularly, since it is used to refer only to data
contained within the message...

> messages would be really useful.

well, there are lots of call-flow diagrams in the sip document, to pick one
and i guess i can copy it...

> is to merely replace the scheme.  Is this correct?

that's really for the group to decide...

/mtr

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 10 Jan 2002 18:08:42 -0800 (PST)

Hi Marshall,

Thanks for the quick response.  A few more comments inline...

> implementations, not that it has to be used by administrators.

the problem is that some lightweight SIP implementations (e.g phones) will
be unable to implement BEEP and TLS and RSA and 3DES.  this is not an
administrator level problem, it is an implementation burden.

if I haven't convinced you, then I will talk to the appropriate AD.  This
shouldn't be your problem.

> problem is no different for any other application protocol making use of the

How about:

"Note that with the introduction of middleboxes [7], such as firewalls and
network address translators, IMSX peers are responsible for using
transport addresses which are usable end-to-end by their peers, or sending
SIP through proxies or other entities which rewrite these addresses as
appropriate to allow end-to-end communication."   ??

> architecture. if you want to solve the middlebox problem, this is the wrong

sorry, I was thinking of APEX.

> contained within the message...

ok, you may want to mention that the url is unique only within the
message.

thanks again,
-rohan

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 11 Jan 2002 09:27:20 -0800

> shouldn't be your problem.

sure.

> appropriate to allow end-to-end communication."   ??

i don't think this works because of the "IMSX peers are responsible" part.
this implies some kind of topology-specific behavior on the part of IMSX,
which isn't there. IMSX doesn't know, nor care, about topology. that's
someone else's job... the requirement on the part of IMSX is stated in the
previous paragraph, to wit:

    As with any model based on dynamic rendezvous,
    it is critically important that each application faithfully record the
    appropriate transport information in the corresponding SDP
    announcement.

ok.

/mtr

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 11 Jan 2002 12:25:29 -0800 (PST)

On Fri, 11 Jan 2002, Marshall T. Rose wrote:
[snip]
>     appropriate transport information in the corresponding SDP

One of the ways that we are getting SIP intiated media through middleboxes
is to have the SIP UA "lie" about its address.  A SIP UA might use STUN to
get public addresses for RTP and RTCP media, or TURN to establish use of a
media relay.  What I meant by IMSX peer was the host that IMSX runs
on.  An alternate rewording would be "SIP User Agents implementing
IMSX are responsible..."   This is an alternative to the requirement
for a proxy to do rewriting.  Some relevant pointers to this method of
middlebox traversal are below.

draft-rosenberg-midcom-stun-00.txt
draft-rosenberg-midcom-turn-00.txt
draft-rosenberg-sipping-nat-scenarios-00.txt

hope this makes sense.
thanks,
-rohan

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 11 Jan 2002 16:16:36 -0800

> draft-rosenberg-sipping-nat-scenarios-00.txt

yes, it makes sense, i just question whether it belongs in imsx. how about
this text:

   Note that with the introduction of middleboxes [7], such as firewalls
   and network address translators, it may be necessary to rewrite the
   transport information in order to account for administratively-
   mandated media gateways or address translation.  Accordingly, SIP
   user agents are responsible for either directly rewriting the
   transport information, or, sending the SDP announcement through the
   appropriate intermediaries that will transparently rewrite the
   transport information.  In a phrase, "res ipsa loquitur".

/mtr

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 11 Jan 2002 16:18:27 -0800 (PST)

>    transport information.  In a phrase, "res ipsa loquitur".

sounds good.

thanks,
-rohan