Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-04.txt

From: [email-masked]
Date: Wed, 22 Jun 2005 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Relay Extensions for the Message Sessions Relay Protocol (MSRP)
	Author(s)	: C. Jennings, R. Mahy
	Filename	: draft-ietf-simple-msrp-relays-04.txt
	Pages		: 28
	Date		: 2005-6-22
	
The SIMPLE Working Group uses two separate models for conveying
   instant messages.  Pager-mode messages stand alone and are not part
   of a SIP (Session Initiation Protocol) session, whereas Session-mode
   messages are setup as part of a session using the SIP protocol.  MSRP
   (Message Sessions Relay Protocol) is a protocol for near-real-time,
   peer-to-peer exchange of binary content without intermediaries, which
   is designed to be signaled using a separate rendezvous protocol such
   as SIP.  This document introduces the notion of message relay
   intermediaries to MSRP and describes the extensions necessary to use
   them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-ietf-simple-msrp-relays-04.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-ietf-simple-msrp-relays-04.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.
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jun 2005 10:42:00 -0400

Just a couple of little things:

In the 2nd and 3rd REPORT messages on page 7, there seems to be an extra 
From-Path header.

Last paragraph of 3.1 - says that the URI can only be used once. So the 
client will need to do a separate AUTH for each session. I thought we 
were going to permit the client to add extra data on the end and use the 
result for multiple sessions.

    When sending an AUTH request, the client MAY add an Expires header to
    request a MSRP URI that is valid for no longer than the provided
    interval (an whole number of seconds).  The server will include an
    Expires header in a successful response indicating how long its URI
    from the Use-Path will be valid.  Note that each server can return an
    independent expiration time.

If we are authenticating with a pair of relays R1 and R2, getting uris 
U1 and U2 with expiration times E1 and E2, what happens if E1 ne E2? It 
seems that a particular session using a path with U1 and U2 will only be 
good for the min(E1,E2). This might be worth pointing out. Something like:

    Note that each server can return an independent expiration time.
    A session will become inoperable after the shortest expiration
    time of URIs on its path passes.

Perhaps this is sufficiently obvious that it need not be said - I don't 
feel strongly about it.

	Paul