Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - nits

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2004 12:19:42 -0400

I just did a fairly careful review of
draft-ietf-simple-message-sessions-08. I came up with a bunch of comments.

I will include the nits here, but in the interest of discussion I will
break the rest up into a number of separate threads.

	Paul

Section 3, near the end: "This document specifies MSRP behavior only
peer-to-peer session...". Is awkward wording. Suggest inserting "for a"
in front of "peer-to-peer".

Section 4.3, last paragraph: "... but some other systems choose to use a
value of "partial" to reduce the load on the servers caused by 200 OK
responses, but still allow error responses to be sent in many cases."
This will make sense later, but it doesn't make sense at this point in
the document because the linkage between the report and the 200 hasn't
been made. Suggest something like:

"... but some other systems choose to use a value of "partial" to reduce
the load on the servers. As will be seen in section 6.2, this will omit
200 OK responses and the load they cause, but still allow error
responses to be sent in many cases."

Section 4.4, 4th paragraph from end, there is a sentence fragment that
should be combined with the next sentence:
"If the receiving endpoint receives more than one message with the same
Message-ID. It SHOULD assume that the messages are duplicates."
Should be:
"If the receiving endpoint receives more than one message with the same
Message-ID it SHOULD assume that the messages are duplicates."

The word "insure" is used twice in this document, and in both cases is
should be "ensure".

Section 6.1.2 says: "An MSRP endpoint MUST be able to generate success
REPORT requests." But nowhere do I find a comparable statement about
failure reports. I think the endpoint MUST be able to do both.

Section 6.1.3, 1st paragraph: there is an instance of "respons" that
should be "response".

Section 6.3.1: s/If chunks data/If chunk data/

Section 7.1 says to use "*" to indicate willingness to accept any
content type. This has always seemed gratuitous to me, since the mime
syntax for types already allows "*/*" to mean that. I think it would
minimize future issues if we just accepted that instead of specifying
"*" as a special case. This would require a small change to the syntax 
of 'type' and 'subtype'.

Section 7.1 uses both "container types" and "compound types" to mean the
same thing. Can we just pick one and stick with it? (I don't care which
one.)

Section 7.1.5 says: "Instead, MSRP now specifies a default connection
direction." Its not a default, since you can't change it. I think what
is meant is: "MSRP now associates connection direction with the
direction the offer travels."

Section 10.5: Shows using a REGISTER to query for the contacts. There
really isn't anything wrong here, but it may cause some readers to
conclude that using REGISTER this way is something that should normally
be done. Might be worth a disclaimer that this is only shown for
purposes of clarifying the example.

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