Subject: [Gen-art] Gen-ART review of IETF-LC draft-wilde-sms-uri-16.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 08 Sep 2008 13:01:24 +0200

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-masked]>
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-masked]
https://www.ietf.org/mailman/listinfo/gen-art