Subject: RE: [Simple] Message sessions

From: [email-masked]
Date: Wed, 26 Jun 2002 18:12:54 +0300

I also prefer simple-message-session for the same reasons provided by others.

I do have one objection though and that of course has something to do with the hop attribute and the proxy manipulating the body.

Now, Jonathan hates objections without alternate suggestion, so here is one :)

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.

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 25, 2002 4:22 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Simple] Message sessions
> 
> 
> 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
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jun 2002 14:28:07 -0400

[email-masked] wrote:
> 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.
> 
> Of course, we can just define one header called sip-message-media-path
> (or something similar), that this limits extensibility.
> 

In what way does this differ from:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt

-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