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 -)
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"?
(Lisa Dusseault) Yes
Alexey Melnikov (was Discuss) Yes
(Jari Arkko) No Objection
Comment (2008-09-25 for -)
No email
send info
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 email
send info
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 versions.
(Adrian Farrel) No Objection
(Russ Housley) (was Discuss) No Objection
(Dan Romascanu) No Objection
Comment (2008-09-25 for -)
No email
send info
send info
I support the issue raised by Magnus in his DISCUSS.