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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 00:04:13 -0500

> -----Original Message-----
> From: warren montgomery [mailto:[email-masked]]
> Sent: Thursday, November 15, 2001 8:35 PM
> To: [email-masked]
> Subject: Re: [Simple] New I-D on IM transport
> 
> 
> I've been a lurker on this list for some time and I think the 
> draft is a
> good compromise on the positions. 

Thanks; I'm glad to have your input.

> One thing I observe is that an IMTP
> session routed throug relays really acts like a circuit -- 
> each message in
> that session follows the same route through the relays even 
> if there are
> multiple possibilities (say an enterprise with multiple relay 
> points that
> could be used).  If a relay fails for some reason, the session stops
> working.  This isn't necessarily bad, as it allows IMTP to meet the
> requirements for sequencing and flow control which could be 
> more difficult,
> but it may run contrary to user expectation.

This is no different than record-routing on a dialog. Generally, you need to
be careful about what you put into that record-route. You could put a host
name in there that resolves via SRV to provide some basic failover and even
load balancing capabilities. The same idea would be true here. When an IMTP
relay rewrites the SDP, the c line contains a domain name. You could also
use an IP address that uses routing tricks to support failover.

> 
> The session established also winds up being specific to a 
> user's endpiont
> (i.e. if the user might be available for IM at multiple endpoints, the
> process of session establishment will presumably pick one for 
> the session,
> after which moving to a new endpoint means negotiating 
> another session.

As Paul has pointed out, thats no different than for a voice call, where you
would normally use a re-INVITE to update the COntact header. We allow that
for this purpose exactly.

> Again not necessarily bad, but I could see an expectation of 
> being able to
> migrate from device to device transparently in an IM session 
> like using
> extension phones.

Moving amongst extension phones is a park/pickup or transfer kind of
function, and should be done the same way for IM as for voice, I would
argue. Yet another advantage of the session model....

-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

---

From: Tony Hansen <[email-masked]>
Date: Mon, 19 Nov 2001 10:31:42 -0500

Jonathan Rosenberg wrote:
> > ...

Yes indeed. Anything that can be done with one should be doable with the
other. (This may be a tautology:) And the more we make the models
comparable, the more easily it will be to do those things in similar
ways.

	Tony Hansen
	[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2001 09:29:06 -0500

Jonathan - I agreed with most of what you said in this reply, but there
was one point I take issue with:

[snip]

> When an IMTP relay rewrites the SDP, the c line contains a domain name.

The latest versions of SDP don't permit FQDNs in the c= line.
I never did hear why this change was made. While it often may be wise to
avoid FQDNs in sdp, it seems pretty heavy handed to forbid them, since
as you point out here there may be cases where they are useful.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2001 10:19:34 -0600

We ran into similar issues when we were trying to define how to use SDP 
to describe SIP based message sessions. I suspect that will be the 
harded part in finishing IMTP, and perhaps the part most in need of our 
attention.

Paul Kyzivat wrote:

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

---

From: [email-masked]
Date: Fri, 7 Dec 2001 14:14:24 -0600

Slightly off topic, but just offering an explanation...

> From: Paul Kyzivat [mailto:[email-masked]]
>

The issue as I understand it is that people want to be able to
design endpoints that do not necessarily have DNS capabilities.
I'm not going to defend this design decision.

If sending of FQDNs is a MAY, then being able to receive them
is necessarily a MUST, lest we end up with a protocol that isn't
compatible with itself.

Conversely, if receiving of FQDNs is not a MUST (to appease the
no-DNS-in-my-endpoint minority), then sending of FQDNs is a 
MUST NOT.

Personally, I think this is a case of letting a very small portion
of the tip of the tail wag the whole elephant...

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Dec 2001 18:23:33 -0500

FYI - it was draft-ietf-mmusic-sdp-new-02 and
draft-ietf-mmusic-sdp-new-03 where FQDNs in the c= line were illegal. In
the recently introduced draft-ietf-mmusic-sdp-new-04 they are legal
again.

I have no visibility into why these changes were made.

	Paul