Re: submission of "draft-wilde-sms-uri-14"

Erik

three quick comments, and a longer one

1)

I was surprised by:

    The user agent SHOULD inform the user about the possible security
    hazards involved when submitting the form (it is probably being sent
    as plain text over an air interface).

I thought that GSM messages were usually encrypted over the air ... (but 
I don't claim expertise).

2) That text occurs twice (section 1.3.5, and section 3)

It seems to me that such repetition is somewhat scrappy; maybe delete 
the copy in section 1.3.5

3)
[[
    SMS messages sent as a result of this URI MUST be sent as class 1 SMS
    messages, if the user agent is able to specify the message class.
]]
sounds like a SHOULD rather than a MUST to me - an optional MUST is not 
very helpful.

4) There are a variety of SHOULDs and MUSTs throughout - without a 
consistently compelling clarity about what class-of-products can conform 
with this specification. Often the cosntrained class-of-product is 
specified as the 'user agent', but how does this contrast, if at all, 
with 'the sending SMS client'. Which class-of-product is constrained by 
the phrase:
"It MUST NOT be transferred in the SMS message."
Which class-of-product is constrained by:

[[
Implementations MUST make sure that the <sms-body> characters are
    converted to a suitable character encoding before sending,
]]

Ditto:
[[

The SMS message
    MUST NOT contain any HTTP headers,
]]

which seems simply to be false, how about

sms:+1-555-333-2222?Cache-control:no-cache

While I assume this isn't what you mean to prohibit (from whom), it 
describes an SMS message with an HTTP header in the body.
(The user may wish to send this message to a colleague while debugging 
an HTTP client)

There appears to be an implicit, but somewhat unclear, processing model 
for sms URIs. In my opinion, this could be clarified, and perhaps made 
explicit, and then every RFC 2119 keyword should be reviewed in light of 
the processing model, to check that the appropriate component in that 
processing model is being constrained.

In section 1.3.5 it is unclear whether the user agent is a form on a web 
browser, or some other piece of software, hence it is unclear what the 
conformant piece of software might be.


section 1.3.3 is a bit odd -
   the SHOULDs and MUSTs in point 1 are not about processing, and so are 
in the wrong part of the document
   the SHOULDs in points 3, 4 and 5 seem inappropriate. All of these 
actions are in response to user interaction with the user agent, and 
that seems to be outside the scope of a specification. e.g. point 3, a 
user agent may provide an option that say, looks up the sms address in 
the local directory, and extracts the first name from the directory, and 
inserts the appropriate greeting "Dear Erik," - there are no 
interoperability considerations - this is just a feature that customers 
may like, or loathe. Hence to invoke an RFC 2119 SHOULD, with all its 
force, seems incorrect. Similarly, in point 4, the user agent may expose 
choice of delivery method to the end user, and the developer of the user 
agent does not need to worry about interoperability and there is no 
requirement that
[[
    the full implications must be understood and
    carefully weighed before choosing a different course.
]] RFC 2119

Further:

[[
    The character encoding used for form submissions MUST be UTF-8
    [RFC3629].  It should be noted, however, that user agents MUST
    percent-encode form submissions before sending them (this encoding is
    specified by the URI syntax [RFC3986]).
]]

is better written as
[[
    The character encoding used for form submissions is UTF-8
    [RFC3629].  It should be noted, however, that user agents
    percent-encode form submissions before sending them (this encoding is
    specified by the URI syntax [RFC3986]).
]]
The first MUST is not constraining any software, but is being used 
(inappropriately) to describe a piece of text. The second MUST is within 
the scope of RFC 3986, and not this document.



Overall, I think a full review of the SHOULDs and MUSTs is in order. 
There are too many; it is often unclear which software is constrained; 
they seem to be used merely as emphasis, rather than with awareness of 
RFC 2119 meaning. Some seem to merely reiterate other specifications, 
and are hence superfluos.



Jeremy

Received on Tuesday, 11 December 2007 09:54:51 UTC