URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)
RFC 5724

Note: This ballot was opened for revision 20 and is now closed.

(Chris Newman) Discuss

Discuss (2008-09-22 for -** No value found for 'p.get_dochistory.rev' **)
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

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

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"?

(Lisa Dusseault) Yes

(Alexey Melnikov) (was Discuss) Yes

(Jari Arkko) No Objection

Comment (2008-09-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I share the issue in 2nd part of Russ's Discuss: I also felt that the document brought in a bit too many details about the processing, formatting, and delivery of SMSes. This RFC does not define how SMSes are sent, it just defines URIs. Some overview is useful, of course.

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

Comment (2009-08-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think the document would benefit from including an example with a
non-global number (not starting with "+"), since the exact syntax used
for them changed very recently (when going from version -15 to -16),
and the change might not be obvious to someone who read the old

(Adrian Farrel) No Objection

(Russ Housley) (was Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2008-09-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the issue raised by Magnus in his DISCUSS.

(Robert Sparks) (was Discuss) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

(Cullen Jennings) (was Discuss) No Record