[Uri-review] draft-wilde-sms-uri-19 remaining editorials

[Alfred Hönes <ah at TR-Sys.de>]

Hello,
I once more have followed up to the most recent version of your
SMS URI draft, draft-wilde-sms-uri-19, and would like to point
out the remaining editorials I found in that memo.


(1)  Section 2.2, penultimate paragraph -- word omissison

Please add the missing "of" :

   The syntax definition for <escaped-value> refers to the text of an
   SMS where all <reserved> (as per RFC 3986 [RFC3986]) characters in
   the SMS text are percent-encoded, please refer to RFC 3986 [RFC3986]
|  for the definition <unreserved> and <pct-encoded>, and the details
   about percent-encoding.
---
   The syntax definition for <escaped-value> refers to the text of an
   SMS where all <reserved> (as per RFC 3986 [RFC3986]) characters in
   the SMS text are percent-encoded, please refer to RFC 3986 [RFC3986]
|  for the definition of <unreserved> and <pct-encoded>, and the details
                     ^^^^
   about percent-encoding.


(2)  Section 2.3, last list item

The draft says:
                  vvvvvvvv
|  5.  If the URI consists of a comma-separated list of recipients
       (i.e., contains multiple <sms-recipient> parts), all of them are
       processed in this manner.  [...]

Since the 'sms' URIs now can contain many more components, the phrase
"[the URI] consists of ..."  has become even more inappropriate.
I suggest to simpy use "contains" instead:

                  vvvvvvvv
|  5.  If the URI contains of a comma-separated list of recipients
       (i.e., contains multiple <sms-recipient> parts), all of them are
       processed in this manner.  [...]

(3)  Section 2.5, first paragraph -- terminology

Please use precise terminology as defined in the IETF and avoid the
sloppy replacement of "header field" by "header" only.  By definition
of protocol layering, each (sub-)layer can only add a single header
to is payload (SDU), when encapsulating these to produce its own PDUs.

Therefore, please correct:

|             [...].  The SMS message MUST NOT contain any HTTP headers,
   only the form data.  The media type is implicit.  It MUST NOT be
   transferred in the SMS message.  Since the SMS message contains the
   form field values, the body <sms-field> of an "sms" type URI used for
   an HTML form will be ignored.
---vvvvvv                                                             v
|             [...].  The SMS message MUST NOT contain any HTTP header
|  fields, only the form data.  The media type is implicit.  It MUST NOT
   be transferred in the SMS message.  Since the SMS message contains
   the form field values, the body <sms-field> of an "sms" type URI used
   for an HTML form will be ignored.

(4)  Section 4

As explained in item (3) above, I'd like to see the wording adjusted
in the 5th paragraph of Section 4, as follows:

                  [...].  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.  Gateways that accept SMS messages
   e.g. in e-mail messages or Web forms and pass them on to an SMSC,
   SHOULD implement this kind of "firewalling" approach as well.
---
                  [...].  Any SMS client SHOULD make sure that malicious
   use of such messages is not possible, for example by filtering out
|  certain SMS User Data header fields.  Gateways that accept SMS
            v    v             ^^^^^^             v
|  messages (e.g., in e-mail messages or Web forms) and pass them on to
|  an SMSC SHOULD implement this kind of "firewalling" approach as well.
          ^

Following preferred RFC Editor style, I also have added a comma and
inserted a pair of parentheses to avoid having to add two more commas,
whereas the last comma already present has been elided to match the
non-placement of a comma in front of "that accept", the beginning of
the relevant sub-clause.

Note: The 7th para already uses "User Data Header".


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+