[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] Re: draft-ietf-simple-msrp-relays-01.txt
On Jul 22, 2004, at 4:21 PM, Paul Kyzivat wrote:
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.
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.
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?
ah, possibly ;-)
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.
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.
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
i actually had semicolons in mind, but I screwed up
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???
"... 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
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple