Subject: RE: [Simple] Message sessions

From: [email-masked]
Date: Tue, 25 Jun 2002 16:21:51 +0300

Hi,

I would also prefer simple-message-session, mainly because of the ability to have a unified mechanism for both the paging mode and the session mode IM. Also, having SIP MESSAGE as the session transport may have benefits in multiparty sessions. 

However, I don't see any reason why simple-exchange shouldn't progress as well. Ultimately these are session IM "codecs", and I don't think having several of them hurts as long as there is one that by default is supported by all implementations.

So perhaps we should have simple-message-session as a WG item for SIMPLE, but encourage simple-exchange to progress as well. Maybe towards Informational RFC status, if not standards track? 

Cheers,
Aki 

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, June 19, 2002 8:41 PM
> To: Dean Willis
> Cc: Peterson, Jon; [email-masked];
> [email-masked]
> Subject: Re: [Simple] Message sessions
> 
> 
> I would prefer simple-message-session. I don't want to have to 
> administer two very different types of devices, with 
> different (and, in 
> the case of mrose, undefined) network management.
> 
> I still agree with the argument in simple-message that a unified 
> mechanism for page and session is very desirable. Transitioning and 
> gatewaying will be much easier.
> 
> I don't see why mrose has an advantage in "standardized relay 
> elements 
> to be added as needed". What can be added there that can't be 
> added in 
> simple-message?
> 
> I'm afraid I find the "firewall discovery" item too vague to 
> understand 
> what exactly the advantage would be.
> 
> The overall system complexity, in terms of explaining what's going on 
> and in terms of implementing, seem far less in a unified system where 
> page and session mode share conceptual elements where this 
> makes sense.
> 
> Dean Willis wrote:
> > Jon asked:
> > 
> >>Now that the presence and watcherinfo work has gone forward to the
> > 
> > IESG, we
> > 
> >>need to return to the issue of message sessions - we are quite a bit
> > 
> > overdue
> > . . .
> > 
> >>Two proposals have been made for session protocols:
> >>
> >>http://www.ietf.org/internet-drafts/draft-mrose-simple-excha
nge-01.txt
>>
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi
> on-0
> 
>>0.txt
> 
> 
> I personally lean towards the mrose approach. BEEP does a decent job of
> the message delivery operation. It allows standardized relay elements to
> be added as needed and provides for a sort of path-discovery that would
> appear to be beneficial in firewall traversal scenarios. It provides a
> nice layering distinctiuon between "can I talk to you" and "may I talk
> to the network".
> 
> --
> Dean
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

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

---

From: [email-masked]
Date: Thu, 27 Jun 2002 08:45:11 +0300

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, June 26, 2002 9:28 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: Niemi Aki (NET/Espoo); [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> [email-masked] wrote:
> > We define 2 new headers, media-type and media-path.
> > 
> > We define media-type to contain message/sip
> > 
> > media-type: message/sip
> > 
> > We define media-path to contain what the hop attribute 
> contains. This
> > works much like path-header except that it's specifying the 
> path of the
> > media and that it reaches the UAs.
> > 
> > These headers are of course reflected in the response so 
> that both UAs
> > learn the media path.
> > 
> > Of course, we can just define one header called 
> sip-message-media-path
> > (or something similar), that this limits extensibility.
> > 
> > I haven't thought about this thoroughly, so flame me.
> 
> In what way does this differ from:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-se
> ssion-policy-00.txt

Sorry, I haven't read that one yet. But I scanned it quickly and looked the examples. It is probably not that different.

- Hisham

> 
> -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
> 
>