RFC Discussion

This page will be used to encapsulate the discussion of the SAMP RFC from December 8, 2008 through January 16, 2009. Comments and responses will be included below. The SAMP protocol and its implementations are described in the documents linked to the SampProgress page.

Please add your comments here directly, or send mail to either the general Applications or specific SAMP mailing lists.


Comments:

  • Most of my comments on this document are editorial in nature – proper use of which and that, punctuation, and so on. I will be happy to share a detailed mark-up with the editors. To first order, almost all uses of “which” are incorrect and need to be replaced with “that”. I strongly prefer the Oxford comma (apples, bananas, and oranges), which is the standard for the astronomical literature in the US, but I know that in some countries and in newspapers this is not used. Wikipedia has a nice discourse on this: http://en.wikipedia.org/wiki/Serial_comma .

  • A general concern, though, is that it is not clear when the document is using the special words “must”, “should”, “may”, etc., in accord with RFC 2119 and when it is not. Sometimes the words appear in all-caps, but usually they do not. Sometimes the word “can” is used and it is ambiguous whether this means may, should, or must. And sometimes “should” it used when it seems like it really is a must. I note a few particular problems below, and others are in my more detailed mark-up.

  • Section 1.3 introduces the term “publish”, but then it is almost immediately abandoned and replaced by “send”. Are these synonyms, or am I misunderstanding the intent?

  • In Section 3.3, the string data type is described as a sequence of characters, with the examples being ASCII hex codes, it would appear. But this is not explicit and needs to be.

  • In 3.8 there is an example of the use of “can”: “The message can be encoded as a map with the following REQUIRED keys... “ I am not sure what the developer is supposed to make of this. If the keys are REQUIRED, isn’t this a “must”?

  • In 3.11, p. 22, 2nd bullet, there is another example: “mtype may not include wildcards.” It seems that “must” is the correct verb. There are several more “may”s in subsequent bullets that need to be clarified.

  • On p.23, just above 3.12, it says “...should complete...quickly.” What is “quickly”? There needs to be some point of reference, like in less time than something else, or so as not to block some other operation, or something similar.

  • In 3.12, p. 22, the section is called “Operations a Callable Client Must Support”, but immediately we see “may” language and a description of operations that the hub invokes. I find this to be confusing.

  • On p. 24, there is another “...should complete quickly” with no context.

  • 3.13, p. 24, ends with “... it is not to be used by the hub to signal a failed call.” Must not? Should not?

  • Section 4.2, it is not clear if these are musts or shoulds.

  • Section 5, p. 31, the term UCD needs to be defined and referenced.

  • Section 5.3, p. 33, the first paragraph is informal and not specific. Make a decision about how and where to document MTypes and describe it here clearly.

  • Section 5.4.1, all messages are described as “should”, but they seem like “must”.


Edit | Attach | Watch | Print version | History: r43 | r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2008-12-05 - BobHanisch
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback