Subject: [Simple] New I-D on IM transport

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 14 Nov 2001 17:41:20 -0500 (EST)

Sounds ok. However, couple of comments..

I would add two more requirements: 
1: Threading (and sub-threading) e.g. in text chat like of session 
   there may be several topics or threads going-on
2: Message identification (to identify certain message afterwards)

Thus, two new IMTP headers would be needed: Message-id and References. 
This would be similar to NNTP.

Also, Subject header is needed (e.g. in chat session it is useful 
to indicate the thread or topic)

Also:

   "The proxies in this configuration are aware that IMs need to flow
   through the relays. As a result, they rewrite the SDP in the INVITE
   and 2xx as it passes through the proxies. The rewrites change the IM
   session IDs and connection addresses to point to the relays instead"

Solution without SDP rewriting in proxies would be preferred..

BR,
--
Petri

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 15 Nov 2001 15:12:31 -0600

Sorry, clicked on wrong thread...

Hi Jonathan.

As I was skimming through the document, I noticed that you included a
requirement for NAT/Firewall traversal, but in the document, the IM
transport doesn't really seem to address this very well by including in
section 6.2 a firewall setup that basically removes the firewall in the
picture for all intents and purposes.

I know this is a strawman, so would the intent going forward be to simply
have a nailed up TLS connection to clients that have their own firewalls,
back to the proxy/relay? The reason I ask is because that would be pretty
expensive in terms of network resources to have this connection up all the
time for so many endpoints (in an ISP model).

Continuing to read...

Regards,

Brian Stucker

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 2:17 PM
To: [email-masked]'
Subject: [Simple] New I-D on IM transport

Folks,

I've just submitted a new I-D to the archives which proposes a compromise
solution for the IM transport in the session model. Until it appears, you
can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt

This draft was co-authored by Christian Huitema, Robert Osborne, Avshalom
Houri, and myself, in the hopes of making forward progress on this issue.
The compromise is to use a protocol called IMTP which is is a subset of SIP,
so that it can be forwarded through SIP proxies with proper configuration,
but at the same time, only uses reliable transports, and does not use things
like forking, record-routing, redirection, and so on.

The draft also proposes requirements, which I have gathered from the list
discussion. 

Thanks,
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
 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Nov 2001 23:53:46 -0500

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 4:13 PM
To: Jonathan Rosenberg; [email-masked]'
Subject: RE: [Simple] New I-D on IM transport

>As I was skimming through the document, I noticed that you included a
requirement for 
>NAT/Firewall traversal, but in the document, the IM transport doesn't
really seem to 
>address this very well by including in section 6.2 a firewall setup that
basically removes 
>the firewall in the picture for all intents and purposes.

Huh?? I don't get it. The connection between R1 and R2 would presumably be
TLS, and the firewall would have a static rule allowing these two elements
to talk to each other over TLS. That addresses the inter-enterprise problem
that kicked off much of the discussion on SIP as a transport.

>I know this is a strawman, so would the intent going forward be to simply
have a nailed up 
>TLS connection to clients that have their own firewalls, back to the
proxy/relay? The 
>reason I ask is because that would be pretty expensive in terms of network
resources to 
>have this connection up all the time for so many endpoints (in an ISP
model).

In Figure 2, there is not a tls connection to each client. Perhaps you are
talking about some other kind of configuration, for example, a residential
one? I.e., Section 2 of draft-rosenberg-sipping-nat-scenarios? In that case,
you would presumably use a TURN server to enable this to work.

-Jonathan R.
---

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2001 2:17 PM 
To: [email-masked]' 
Subject: [Simple] New I-D on IM transport 

Folks,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Nov 2001 23:59:32 -0500

inline.

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 6:33 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] New I-D on IM transport
> 
> 
> I just did a quick scan of this. This seems to balance out some of the
> conflicting requirements that have been preventing closure on this
> subject. 
> 
> I will probably have more comments after I think about it a bit, but I
> see one problem now, with using the comedia draft for connection
> management. I think you authors see it too, based on comments (from
> various places) in the text:
> 
>    Streams that use IMTP are always connection oriented, and therefore
>    use the SDP connection oriented media attributes [10] to 
> allow for a
>    single connection to be used for messaging in both directions.
>    ...
>         Need to get the port from somewhere too... maybe just
>         specify a default port for IMTP? May not work with muli-
>         user machines.
>         ...
>         Need a little more rigor in port handling and connection
>         reuse, to ensure that the comedia rules and SIP transport
>         rules are in sync.
>    ...
>    If A wants to send a message to B, it looks for an open TCP
>    connection to 5.6.7.8. If one exists, that is used. If not, one is
>    opened.
>    ...
>    R1 then looks up the request URI, and finds a binding...
>    Since there is an existing TLS
>    connection to that address, this connection is reused:
> 
> All of these say to me that what you want is not what is described in
> the comedia draft. That draft:
> 
> - requires port numbers

I think we need that also.

> 
> - assumes that one (or two) connections will be established uniquely
>   for each independently negotiated media stream (is that the 
>   right word?). There is no provision for sharing a connection,
>   except for sharing one for the two directions of a single stream.

Thats no different that what we have here. There is one connection between a
pair of relays, and we want to reuse that for all messaging between the
relays.

> 
> This is clearly not what you want or assume. You would like to use
> pretty much any connection of the proper type to the corresponding
> endpoint. 

I don't want to establish a new connection if one exists, so there should
generally be only one connection to a specific endpoint.

> This is sufficient because you have the session 
> identifier to
> demultiplex messages sharing the connection. That is what you 
> need, but
> it isn't what comedia provides.

Congestion control would argue for a single connection, though, even though
its not needed for demux.

> 
> A related problem is that SDP requires the port number field of the m=
> line to be a number. You have put the session identifier there, but it
> isn't strictly numeric. I think SDP is much too rigid about 
> this, but I
> doubt if we are permitted to change it. You probably need to put the
> session identifier somewhere else.

Probably. This was just a strawman, and certainly there are more details to
work out.

> 
> Rather than attempt to use comedia, I think it would be 
> better to define
> the IMTP transports so that they make/find connections in the same way
> that SIP does, but drawing the information to do it from different
> sources: address from c=, port from m= port field, transport (TCP/TLS)
> imiplied from m= transport field. Perhaps something like the 
> a=direction
> field is still needed to force the connection to be opened 
> one way even
> when traffic will first flow the other way. If so, while similar to
> comedia it is still a very different way of managing connections.

I think we definitely want to use the SIP rules for finding connections, and
to use the SDP fields as they are defined as much as possible. I'm not
convinced that rules out a reference to comedia, but it doesn't matter much.
I think we generally agree on what we want to happen, its just a question of
the right way to specify it.

-Jonathan R.

---

---

From: "Brian Stucker" <[email-masked]>
Date: Sat, 17 Nov 2001 13:32:46 -0600

Yes, I'm referring to the residential case. Sorry, should have been more
direct.

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, November 16, 2001 10:54 PM
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg;
[email-masked]'
Subject: RE: [Simple] New I-D on IM transport

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 4:13 PM
To: Jonathan Rosenberg; [email-masked]'
Subject: RE: [Simple] New I-D on IM transport

requirement for 
really seem to 
basically removes 

have a nailed up 
proxy/relay? The 
resources to 
model).

-Jonathan R.
---

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2001 2:17 PM 
To: [email-masked]' 
Subject: [Simple] New I-D on IM transport 

Folks,