Note: This ballot was opened for revision 15 and is now closed.
Summary: Needs a YES. Needs 8 more YES or NO OBJECTION positions to pass.
Jari Arkko
Comment (2008-09-25 for -)
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.
[Chris Newman]
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"?
[Dan Romascanu]
Comment (2008-09-25 for -)
I support the issue raised by Magnus in his DISCUSS.
[Pasi Eronen]
Comment (2009-08-06 for -)
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.
datatracker.ietf.org
