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

[Ballot discuss]
As far as I can tell, the document doesn't discuss how to compare two sms: URIs for equality. Should it? (Would these ever go into address books? Is it important to know when two of these containing the same list, but with the elements in different order, are the same list?)

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Permanent URI Schemes" registry at
http://www.iana.org/assignments/uri-schemes.html

URI Scheme Description Reference
---------- ----------- ---------
sms GSM Short Message Service [RFC-wilde-sms-uri-19]

[Ballot discuss]
Updated as per revision -18:

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?
What about Unicode normalization?

[Ballot comment]
I would rather have this URI scheme be "permanent" (instead of "provisional") with change controller not necessarily being IETF, but RFC 4395 doesn't seem to allow for that.

[Ballot discuss]
Updated as per revision -18:

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?
What about Unicode normalization?

[Ballot comment]
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.

[Ballot discuss]
Miguel Garcia did a Gen-ART Review raised a concern with the SMS URI
  scheme syntax:  the current URI does not consider extensibility.  Since
  this point was raised, more than one solution has emerged.  Please put
  one of them into the document.

[Ballot discuss]
Taking over DISCUSS from Chris Newman:

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:

  [HTML401]  Raggett, D., et al., "HTML 4.01 Specification", W3C
              Recommendation, December 1999.
              Available at .

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

[Ballot discuss]
The draft is definitely going the right direction. I felt the 15 version was very broken but I think this 16 version is about right but needs some work on the details and is then ready for IETF review. Having the IESG be where the draft starts getting discussed is inappropriate and this should be sent to the appropriate lists and needs a new IETF LC because the document reviewed in IETF LC has very little in common with this one. Before it even goes out for IETF LC, I encourage people to try and get some folks familiar with the issues to read it. This draft is on the right track and I'm sure it it will get approved in the near future, it just has some details that need a bit of work.

[Ballot discuss]
The draft is definitely going the right direction. I felt the 15 version was very broken but I think this 16 version is about right but needs some work on the details and is then ready for IETF review. Having the IESG be where the draft starts getting discussed is inappropriate and this should be sent to the appropriate lists and needs a new IETF LC because the document reviewed in IETF LC has very little in common with this one. Before it even goes out for IETF LC, I encourage people to try and get some folks familiar with the issues to read it. This draft is on the right track and I'm sure it it will get approved in the near future, it just has some details that need a bit of work.

[Ballot comment]
Draft says
    MUST make sure
  that character sets are correctly mapped
but provides no idea on how one might do that

The encoding of the body is really confusing. Is it packed 7 bit or 8 bit data. What I am saying is the body 140 octets or 160 octets?


The whole section on text concatenation has IETF specifying normative behavior of something that is normatively specified in 3GPP document.

There needs to be some discussion about representing SMS short codes.

The 3rd and 4th para in section 1.2.2.1 seem sort of irrelevant

Seem like many of the normative references are actually informative

Need to say how this is used to do HTML forms

Example numbers need to be take out of invalid example set

I don't know how the parser will disambiguate the ? in the sms-body and the ? in the telephone-subscriber. Have you checked this grammar. If you defined the body= tag as part of tel URI extension, this problem would go away and the syntax of the URI would remain the same.

Discussion is needed of what parts of the query need to be escaped and how this is encoded

The , that separates the heir-part needs to be distinguishable form the parser from the , that in the telephone-subscriber.

The idea that a UA SHOULD provide a message composition service to modify the body seem very wrong to me. Do you mean MAY here? I can just imagine a screen on my cell phone to modify the contents of an HTML post.

Are all the percent encoding characters in RFC 3629 legal in this query part of this URI?

Did this new proposal get reviewed on URI list

When I read
Any SMS client SHOULD make sure that malicious
  use of such messages is not possible, for example by filtering out
  certain SMS User Data headers.
I have no idea how to implement that or what to do

It would be nice to be able to express here are two short codes, one for AT&T, one for MCI, and then a global number with the implied semantics of send the body to whichever one of these is best for your UA but only send it to one of them. This would allow a UA to use a possibly free one with local context but if it was not in a context where that worked to use a global one.

Need to sort out extension model

[Ballot comment]
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.

[Ballot comment]
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.

Section 1.3.5 would benefit from one sentence saying that when "sms"
URI is used in HTML form, the "sms-body" part (if present) is ignored.

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

[Ballot discuss]
Section 1.3.4 contains example phone numbers that appears to be valid ones. The first I find has or are used by the president of the US. The second seems to point to cellphone in California that aren't listed.

As it is known that publication in specification of address or reachability information can result in unwanted traffic I would recommend that these numbers are changed to example ones that are certain for the foreseeable future to don't lead to any individual or organization.

[Ballot 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).

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

[Ballot discuss]
Miguel Garcia did a Gen-ART Review that revealed two major concerns
  and some minor ones. 

  First, the SMS URI scheme syntax.  is defined as:

    sms-body      = "body=" query

  And, query is defined in RFC 3986 as:

    query      = *( pchar / "/" / "?" )

  Notice that  can contain the equal sign, and RFC 3986 says
  that query components are often used to carry "key=value" pairs.
  I suspect that more than one equal sign might lead to implementation
  surprises, so the syntax should be adjusted or there should be text
  to highlight this situation to the reader.
 
  Second, the scope of this specification is not clear. Are the SMS
  procedures PART of the scope of this specification?  There seems to be
  more in this document than the SMS URI scheme specification.
  As one example, consider this text:

    When a "sms" URI is activated, the user agent MAY start a program
    for sending an SMS message, just as "mailto" may open a mail client.

IANA Evaluation comments:

Upon approval, IANA will register the following in the Provisional URI Schemes registry at http://www.iana.org/assignments/uri-schemes.html:

URI Scheme: sms
Description: Short Message Service
Reference: [RFC-wilde-sms-uri-15.txt]

Todos later:
- Deal with the question of whether this duplicates functionality already covered by the tel: URI. 
- Deal with IANA issue: "The document isn't clear about what actions are being requested. It mentions registration, but doesn't contain an IANA Considerations section."