Subject: [Simple] Comments and nits on draft-ietf-simple-msrp-relays-10.txt

From: Hans Persson <[email-masked]>
Date: Fri, 29 Jun 2007 17:10:47 +0200

I just did a long-overdue rereading of the msrp-relays draft. Here are
some comments and nits for your enjoyment.

=== Comments ===

Section 5.1, para 2:

This talks about discovery and should give a reference to section 8.

I'm having trouble figuring out how I would manage to find a relay that
isn't "my own". The time when I'm most likely to want to automatically
discover the relay I need is when I'm in someone else's network
(visiting another company, at a hotel, in a hotspot, etc). 

Assume this setup:

    me ----- company X relay ----- internet ----- my home relay

How can the discovery process help me find company X's relay? Let's
assume that they are a security-conscious company that only allows known
traffic out through designated proxies, so ICE won't help me.

Section 7:

>    quoted-string       = QUOTE *( %x20-21 / %x23-7E ) QUOTE

Designed by Americans, apparently. Is this really enough? There could be
international characters in domain names (realms), for instance.

Section 9.4, first para:

> A client can use unprotected TCP for peer-to-peer MSRP, but any time
>   a client communicates with a relay, it MUST use TLS.

The last bit is not true. See the note at the end of 9.2.

=== Editorial nits ===

In general: RFC references are sometimes written "RFC-XXXX", sometimes
"RFC XXXX" and sometimes "RFCXXXX". Decide on one alternative.

Section 3, the para split over pages 6 and 7: 

A number of occurences of "Failure-Report" should be "Failure-Report
header".

Section 3, para just before ladder diagram (which doesn't have a "Figure
X" legend, BTW):

> The following example show a typical MSRP session.

"shows"

Section 3, second para before second ladder diagram (also lacking
legend):

> (Receivers still need to be prepared to receive out-of-order
>   chunks however.)  

Insert comma after "chunks".

Section 3.1, para 3:

> A typical challenge response flow is shown below:

"challenge-reponse"

Section 6.1:

This starts out by describing how to accept a TLS connection, but then
halfway through we may suddenly have a TCP connection. I know that's
valid, but the language is confusing.

Section 6.4.1, para 2:

> If there is a problem further processing the SEND request, or in the

Move "further" further ahead, to after "request".

Section 6.4.1, para 2:

> hop.  If after 32 seconds, the next hop has not sent any response,

Insert comma after "If".

Section 6.4.1, para 2:

> If after 32 seconds, the next hop has not sent any response,
>   then the relay MUST construct a REPORT with a status code of 408 to
>   indicate a timeout error happened sending the message, and send the
>   REPORT to the original sender of the message.

This means, presumably, addressing the REPORT to the original sender but
sending it to the last hop.

Section 6.4.3, para 2:

> If the response is a non 200 response, and the original request was a

"non-200"

Section 8, first para:

> (The only message in this specification that can have an MSRP URL
>    without an explicit port number is in the To-Path header in an AUTH
>   request.)

Change "message" to "header" and change "is in" to "is".

Section 8, para 3:

> defined, since AUTH are only sent over TLS.)  If no SRV records are

Insert "requests" after "AUTH".

Section 11, second SDP:

All other examples with folded lines have a note about that line folding
isn't really part of MSRP, but only for readability, but that's missing
here.

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210857   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple