URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)
draft-wilde-sms-uri-20

I consider this an important specification, am glad it is being
produced, and believe the specification could be improved with an
additional revision considering some or all of the issues mentioned
in other discuss positions and mentioned here:

1. The document needs a normative reference to the HTML 4.01 specification which defines the format for the media type
application/x-www-form-urlencoded.

2. The following text is factually incorrect:

   ... As SMS transport is
   "out-of-band" as far as normal HTTP over TCP/IP is concerned, this
   provides a way to fill in forms offline, and send the data without
   making a TCP connection to the server, as the set-up time, cost, and
   overhead for a TCP connection are large compared to an SMS message.

With my iPhone, there are contexts where SMS is more expensive that
HTTP/TCP (e.g. local use if I'm over my prepaid SMS limit).  In
addition, SMS can be more expensive on the server infrastructure side;
a two-way email-to-SMS gateway has to track a large amount of state
because SMS has no extension fields for reply gateways.  That's special
SMS-only state that's unnecessary with simple stateless HTTP/TCP
connections.  Finally, I observe this contradicts the previous point
that SMS "is a major source of revenue" (which implies it's expensive
for end-users).

3. The URI scheme doesn't have an extensibility model as far as I can
tell.  In the case of the mailto URI we needed to add extensions to
the original proposal over time.  Whether or not the same will be true
for SMS, it would be helpful to clearly state: is more than one
key-value after the "?" permitted.  If so, are unknown keys "must
understand" or silently ignored?

4. You need to discuss how use of comma as a delimiter between addresses
interacts with use of comma within a telephone-subscriber (e.g., as
the RFC 3966 ABNF permits in the isub= parameter).
 [This is addressed by erratum 203 on RFC 3966 as mentioned in the
  appendix, but I missed that on first reading.  It's perhaps worth
  mentioning that erratum in the text as well the appendix since it's
  important.]

5. While you've defined the charset of the body parameter, the semantics
are not defined.  Is a newline permitted?  If so, how is a newline
encoded?  Perhaps a reference to 5198 would be helpful?

6. Why is this "provisional" rather than "Permanent"?