[Simple] Re: draft-ietf-simple-msrp-relays-01.txt

[Paul Kyzivat <pkyzivat at cisco.com>]

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






_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple