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.