Subject: [APPS-REVIEW] Review of SMS URI spec

From: Lisa Dusseault <[email-masked]>
Date: Tue, 16 Oct 2007 12:22:03 -0700

Hi,

I'd like to get reviews of the SMS URI spec that was submitted to me  
for publication:

http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-13.txt

You can always send review comments to the authors and to the IETF  
list, but you can also just send comments to me if that's easiest.   
I'm always interested in opinions on the disposition of the document  
(should the IETF standardize it on the standards track) as well as  
the suitability of the features and syntax.  There have been some  
other reviews and fair interest in implementing for an individual  
submission.

BTW Jonathan recommended Henning and Vijay specifically for getting  
IPTel expertise in the reviews; Graham is the expert reviewer for  
URIs.  I just noticed that this document doesn't have an IANA section  
which is surely a problem.

Last Call ends Nov 8 and I intend to get the authors to do another  
revision then; of course I will still want to hear of serious issues  
if they're discovered after that, but before would really be better :)

Thanks,
Lisa

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 17 Oct 2007 10:47:10 -0500

Lisa Dusseault wrote:
> Hi,
> 
> I'd like to get reviews of the SMS URI spec that was submitted to me for 
> publication:
> 
> You can always send review comments to the authors and to the IETF list, 
> but you can also just send comments to me if that's easiest.  
[...]

Lisa: My review is below.  Please forward to the author as
appropriate.

Overall, I am disposed to the IETF standardizing this.  I believe
there is sufficient interest in such a URI that if we (i.e., the
IETF) do not fill the void, ad-hoc solutions will step in to do so.

IMHO, one of the biggest point where the draft is silent is in its
interaction with non-browser user agents (i.e., SIP user agents,
or H.323 user agents, for example.)  I do not know whether this
sort of an interaction falls within the bounds of the draft, and
I will let the APPS area and the authors decide if it does, but
I do want to point it out.  The draft, in S1.2.4, does an
excellent job of showing how the sms URI scheme can be used
by web browsers and email clients.  But what happens when a SIP
user agent is presented with a sms URI?  It can do one of
the following:
   1) Convert it to a a tel URI and attempt to route it onwards
    using ENUM or other appropriate technology (although,
    certain parameters of the sms URI like "smsc" and "body" may
    not map well to a tel URI.)
   2) Convert it to a tel URI, use ENUM to convert that to a sip
    URI, and THEN change the sms body to a SIP IM and deliver it to
    the SIP URI.
   3) Access a web service, as depicted in S1.4.1, and allow
    subsequent interaction between the (human) user and the web
    service.
   4) Present some sort of an error to the (human) user about not
    being able to support the sms URI (for example, if I try the
    sms URI -- sms:+16305551212 -- in Firefox, I get a dialog box
    saying "Firefox doesn't know how to open this address, because
    the protocol (sms) isn't associated with any program".)

Since I suspect that dealing with SIP or H.323 intricacies is not
part of this draft, it should probably have a blanket statement
saying that non-browser (and non-email) user agents should behave
as in (4) above when presented with the sms URI that they do not
understand.

One more important comment before moving on to the rest of the
document is that in S3 (Security considerations), the easiest
of security problems -- buffer overflow -- is not addressed.
Having a simple sentence along the lines of "Implementations MUST
ensure that the individual SMS messages are less than 140 octets.
Implementations MUST also ensure that if message concatenation is
being used, the number of segment messages sent does not overwhelm
the receiver."  (Note: I am not sure whether the last sentence
can be realized in practice, so the authors are free to ignore it,
or bid down the normative strength to a SHOULD.)

The rest of my comments are:

* S1.2.2: s/SMS messages MAY be submitted/SMS messages may be submitted

* S1.2.3: The U in URI and URN stands for "Uniform", not "Universal."

* S1.2.3, last paragraph: I would suggest taking out the phrase
   "...and it often is unclear how to separate these concepts."
   Clearly, people have tried to do so and there is enough literature
   around this: the authors provide a reference a couple of lines
   down, and in addition, S1.1.3 of rfc3986 also clarifies this.
   Maybe rewrite the last paragraph as something along these
   lines:
   OLD:
    URIs often are mentioned together with Universal Resource Names
    (URNs) and/or Uniform Resource Locators (URLs), and it often is
    unclear how to separate these concepts.  For the purpose of this
    memo, only the term URI will be used, referring to the most
    fundamental concept.  The World Wide Web Consortium (W3C) has
    issued a note [uri-clarification] discussing the topic of URIs,
    URNs, and URLs in detail.
   NEW:
    URIs often are mentioned together with Uniform Resource Names
    (URNs) and/or Uniform Resource Locators (URLs).  For the purpose
    of this memo, only the term URI will be used, referring to the
    most fundamental concept (for a further clarification on the
    topic of differentiating a URI from a URN or a URL, please see
    [uri-clarification] and Section 1.1.3 of RFC 3986 [RFC3986].)

* S1.2.4.2: I am more curious than anything else: do there exist
  web servers with SMS interfaces that get a HTML form over SMS?

* S1.3.2: Coalesce the following paragraphs for readability:
   OLD:
    The syntax definition for "phonedigit" is taken from RFC 3966
    [RFC3966].

    The syntax definition for "query" is taken from RFC 3986 [RFC3986],
    please refer to that document.
   NEW:
    The syntax definition for "phonedigit" is taken from RFC 3966
    [RFC3966].  The syntax definition for "query" is taken from RFC
    3986 [RFC3986]; please refer to the individual document for
    the definition of these.

* S1.3.5, last paragraph: Before the last sentence, probably insert
   a new one as follows: "In either case, the user agent MUST notify
   the user of this action."

* The example in S1.4.1 would be better if it appears in S1.4 itself.
   It goes a long way in making the text of S1.4 understandable.  I
   don't see a reason to have such a germane example in a different
   section.

* Need IANA consideration section: ideally, S2 (URI Scheme
   Registration) would be part of an IANA consideration section.
   The text is all there, you just need to modify the section headings.

* In S3, paragraphs 2,3,4 have nothing to do with security, as far
   as I can see.  These are best put either in S1.2, or in a separate
   section of their own entitled "General considerations for SMS
   messages".

HTH.

Ciao.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs