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

From: [email-masked]
Date: Wed, 21 Jul 2004 15:52:55 -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 Message Sessions Relay Protocol (MSRP)
	Author(s)	: C. Jennings, R. Mahy
	Filename	: draft-ietf-simple-msrp-relays-01.txt
	Pages		: 28
	Date		: 2004-7-21
	
The SIMPLE Working Group uses two separate models for conveying
   instant messages.  Pager-mode messages stand alone, 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-01.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-01.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-01.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, 22 Jul 2004 19:21:27 -0400

Rohan/Cullen,

I read thru the relays draft. It is starting to shape up. I consider 
this to be very critical work, and would like to help any way I can.

I made notes, attached below, while reading. I gather the doc is a 
snapshot of work in progress, so some of these may be too picky - just 
pointing out things that have been put off for now.

	Paul

Section 3 - Overview:

It would be helpful to have some explanation with the messages in this 
section - what point each is trying to illustrate.

    SEND requests are sent hop-by-hop.  (Each relay that receives a SEND
    request acknowledges receipt of the request before forwarding the
    content in other SEND requests.) All other requests are sent
    end-to-end.

This isn't consistent with the definitions. SEND requests are e2e by 
that definition, which says nothing about responses. They also have hop 
by hop responses. Other reqeusts are also e2e but don't have responses.

    When the Report-Failure header is set appropriately, MSRP Nodes
    respond to SEND requests by taking the last (rightmost) URI in the
                                           ^^^^^^^^^^^^^^^^???
    From-Path and placing that in a To-Path header in the response, and
    placing their URI in the From-Path of the response.  Likwise, when

Isn't it the *first* URI that should be used to address the previous hop?

4.4  Time-related headers

    Specifically an Expires header in an AUTH request indicates how long
    the provided URIs will be valid.

I am thinking this is going to cause a problem unless there is some way 
to renew one. Otherwise it is always possible that a session will want 
to extend beyond the expiration. This can of course be dealt with by 
switching to a new one, either before or after the old one expires. But 
if so, that needs to be pointed out.

If that can happen it will put a premium on ensuring the switchover from 
one stream to another is seamless. (I guess that is a good thing.)

5.2.3  Receiving AUTH requests

    When a relay receives an AUTH request, it must digest challenge the
    request.
    ...
    If there are additional URIs in the To-Path header, the relay
    attempts to forward the AUTH request to the remaining relays.

These sound like successive steps. But in reality I think they are 
alternatives - if the AUTH request is addressed *to* the relay then it 
must challenge it. If the the AUTH request is routed thru the relay 
(indicated by the presence of additional URIs in the To-Path) then it 
should forward it without challenging. Need different words to say this.

5.2.3  Receiving AUTH requests

    Note: A successful AUTH response returns a Route header which
    contains a base MSRP URI that the client can use to create a number
    of different URIs which are all associated with the current
    connection.

How are the new uris derived? The msrp url syntax doesn't permit slashes 
in the resource part. So to do this will require reserving a character 
from 'unreserved' as a delimiter. What there is to choose from are:

     -_.!~*'()

I gather you mean to start with something like:

     msrp:a.example.com:1234/agic456

and derive from it things like:

     msrp:a.example.com:1234/agic456!1
     msrp:a.example.com:1234/agic456!x
     msrp:a.example.com:1234/agic456!xy

7.  Finding MSRP Servers

    If the hostport of an msrps: URI is an IPv4 address or an IPv6
    reference and no port number is provided, use the default port number
    assigned by IANA.  If the hostport is a domain name and an explicit
    port number is provided, attempt to lookup a valid address record (A
    or AAAA) for the domain name.  Connect using the TLS over the default
    transport (TCP) with the default port number.
                             ^^^^^^^ ???

Shouldn't the explict port number be used here???

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 22 Jul 2004 17:50:31 -0700

On Jul 22, 2004, at 4:21 PM, Paul Kyzivat wrote:

> that definition, which says nothing about responses. They also have 
> hop by hop responses. Other reqeusts are also e2e but don't have 
> responses.

No, complete messages are sent e2e, but a SEND request is purely a one 
hop issue. I can send one 5 SEND requests with chunks of one message 
over one hop, the next hop can send 1 SEND request, and the last hop 
can send 3 SEND requests, all for the same message.

>    respond to SEND requests by taking the last (rightmost) URI in the

ah, possibly  ;-)

> I am thinking this is going to cause a problem unless there is some 
> way to renew one. Otherwise it is always possible that a session will 
> want to extend beyond the expiration. This can of course be dealt with 
> by switching to a new one, either before or after the old one expires. 
> But if so, that needs to be pointed out.
>
> If that can happen it will put a premium on ensuring the switchover 
> from one stream to another is seamless. (I guess that is a good 
> thing.)
>

if the request is addressed to the relay it challenges.  If the AUTH 
request is merely passing through a session-specific address on this 
relay that's fine.  Then there is someone trying to route through a 
random relay, without having authenticated to it, which is not allowed.

> How are the new uris derived? The msrp url syntax doesn't permit 
> slashes in the resource part. So to do this will require reserving a 
> character from 'unreserved' as a delimiter. What there is to choose 
> from are:
>
>     -_.!~*'()
>

i actually had semicolons in mind, but I screwed up

>    transport (TCP) with the default port number.

"... and no port number is provided..."

I'm trying to cover the relay discovery case here.  These URIs are not 
in an SDP.

thx,
-r