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

Lars Eggert No Objection

(Chris Newman; former steering group member) Discuss

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

(Alexey Melnikov; former steering group member) (was Discuss) Yes

(Lisa Dusseault; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

I support the issue raised by Magnus in his DISCUSS.

(David Ward; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

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.

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

(Mark Townsley; former steering group member) No Objection

(Pasi Eronen; former steering group member) No Objection

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.

(Robert Sparks; former steering group member) (was Discuss) No Objection

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) (was Discuss) No Objection

(Cullen Jennings; former steering group member) (was Discuss) No Record