I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-wilde-sms-uri-16.txt
Reviewer: Miguel Garcia <[EMAIL PROTECTED]>
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. <sms-body> is defined as:
sms-body = "body=" query
query is defined in RFC 3986 as:
query = *( pchar / "/" / "?" )
Notice that <query> 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, <query> is used as the <value> 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 <query> 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 <isdn-subsddress> with
<isdn-subaddress>
- Does Appendix B make sense?
- Appendix C is typically a section of its own: Acknowledgments.
/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
