Document: draft-wilde-sms-uri-16.txt Reviewer: Miguel Garcia Review Date: 2008-09-08 IESG Telechat date: 11 Sept 2008 Summary: A couple of major issues should be addressed before progressing the draft. Major issues: - About the SMS URI scheme syntax. is defined as: sms-body = "body=" query query is defined in RFC 3986 as: query = *( pchar / "/" / "?" ) Notice that can contain the equal sign "=" RFC 3986 also says: as query components are often used to carry identifying information in the form of "key=value" pairs .... And now for my point. So, query is typically used for indicating "key=value" pairs. But here, is used as the inside the "body" key. So, in other words, it is valid to have an SMS URI that contains two equal signs, like this: sms:+12125552121?body=param=myvalue I think this might create ambiguity. I am not sure if the syntax allows this combination on purpose or not. I would like the authors to confirm that this is done on purpose, or perhaps replace with something that does not allow the "key=value" pair, perhaps "reg-name" (see definition in RFC 3986). The problem here is if implementations might have a problem with the double equal sign. Today this does not seem to be a problem, because there is a single parameter. But it might be in the future if new parameters are added. Besides, for human consumption, the URI looks weird if a double equal sign is included. - On another topic, the scope of this specification is not clear. I expected to be the definition of the SMS URI scheme, its registration, etc. But I expected that SMS procedures are outside the scope of this specification, and defined elsewhere. However, I found sentences that go into what I consider to be the SMS specification or the SMS implementation, but not the SMS URI scheme specification. For example: SMS clients composing messages SHOULD use the standard concatenation method based on the header in the TP-User Data field as specified in the SMS specification When a "sms" URI is activated, the user agent MAY start a program for sending an SMS message, just as "mailto" may open a mail client. When "sms" URIs are dereferenced, implementations MAY create a message and present it to be edited before being sent, or they MAY invoke additional services to provide the functionality necessary for composing a message and sending it to the SMS message endpoint. In either case, simply activating a link with an "sms" URI SHOULD NOT cause a message to be sent without prior user confirmation. Minor issues: - I noticed that the draft considers Erratum 203 in RFC 3966. I think this erratum is essential for this draft (I am not going to discuss the reason here). I would suggest that this draft insists much more on this erratum. I didn't find any reference to this erratum until I got to Appendix A, and at that time I had spent quite a lot time reviewing the unfixed RFC 3966. I suggest to add some text around Section 1.3.1, Second paragraph, indicating that this Erratum is very important for the draft. Perhaps you should replace the first sentence of that second paragraph with: The syntax for telephone numbers is taken from [RFC3966]. Please consider Erratum 203 in that specification. For the reader's convenience, Appendix A contains a fixed syntax of the telephone number URI scheme including Erratum 203. - In general, the Introduction section should be informative in nature and should not contain normative statements. There are plenty of MAY, SHOULD, and MUST in Sections 1.x - In Section 1, I didn't find sense to the first sentence: "Compliant software MUST follow this specification". Well, this is always the case. The notation for phone numbers is taken from [RFC3966] and its Erratum 203. Appendix A provides a corrected syntax of the telephone number Nits/editorial comments: - In the URI scheme definition, it usually helps if you add comments indicating where some terms are originally defined. For example: sms-uri = scheme ":" hier-part [ "?" sms-body ] scheme = "sms" hier-part = sms-recipient *( "," sms-recipient ) sms-recipient = telephone-subscriber ;defined in RFC 3966 sms-body = "body=" query ;query defined in RFC 3986 - Expand "TP-User Data field" in last paragraph of Section 1.2.1. - Unused references: [RFC2822] - First paragraph in Appendix A: replace with - Does Appendix B make sense? - Appendix C is typically a section of its own: Acknowledgments. =========================================================================================== Document Tag: draft-wilde-sms-uri-13 Document Title: URI Scheme for GSM Short Message Service Intended Status: Proposed Standard Shepherding AD: Lisa Dusseault [lisa@osafoundation.org] Reviewer: Michael A. Patton [MAP@MAP-NE.com] Review Date: 06-Nov-2007 IESG Telechat Date: unknown Summary: Almost Ready This draft is almost ready for publication as a Proposed Standard RFC. There is one dangling reference in the ABNF description that must be fixed for the document to provide for an unambiguous implementation. Major concern ------------- 1.3.3 item 1 refers to "gstn-phone" which was not defined by the ABNF. Did you intend this to refer to the "sms-number" or "sms-recipient"? If so, the proper one should be substituted, otherwise "gstn-phone" needs to be defined. ---------------------------------------------------------------- The following editorial issues are noted for the convenience of possible copy editors but are not part of the technical review. Clarity ------- Section 1: idnits complains about the 2119 boilerplate. I expect that's because you added a sentence in front of it. But, that sentence, "Compliant software MUST follow this specification" is a tautology. Furthermore that sentence uses a capitalized MUST before the RFC2119 reference defines it. I don't think that sentence needs to be there. But, if you must have it, I think it should come after the definition of what "MUST" means. Section 1 is titled "Introduction" but contains normative language. In fact, the "Introduction" is essentially the entire document. I think that section 1 should be split so each subsection becomes a section (i.e. the paragraph in 1 is section 1, 1.1 is section 2, 1.2 is section 3) retaining the subdivisions below but with one less layer. Appendix A seems extraneous for a published RFC. idnits reports: ** The document seems to lack an IANA Considerations section. (See Section 2.2 of http://www.ietf.org/ID-Checklist.html for how to handle the case when there are no actions for IANA.) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) == Unused Reference: 'RFC2822' is defined on line 851, but no explicit reference was found in the text Typos ----- 1.2.2.1: "is not subject of this memo" => "is outside the scope of this memo" 2.4 is just awkward language structure, I suggest instead: The "sms" scheme defines a way that a message may be composed which is then transmitted using the SMS message transmission method. This scheme can thus be compared to the "mailto" URI scheme [RFC2368]. See Section 1.3.3 for the details of operation. 2.6 is also awkward, I suggest: The "sms" URI scheme is intended to be used in a manner similar to the "mailto" URI scheme [RFC2368]. By using "sms" URIs, authors can embed information into documents which can be used as a starting point for initiating message composition. Whether the client is sending the message itself (for example over a GSM air interface) or redirecting the user to a third party for message composition (such as a Web service for sending SMS messages) is outside of the scope of the URI scheme definition.