[Uri-review] draft-wilde-sms-uri-19 remaining editorials
Alfred Hönes <ah@TR-Sys.de> Mon, 12 October 2009 10:36 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031D928C18E for <uri-review@core3.amsl.com>; Mon, 12 Oct 2009 03:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.851
X-Spam-Level: ***
X-Spam-Status: No, score=3.851 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChkaUwaZPJO2 for <uri-review@core3.amsl.com>; Mon, 12 Oct 2009 03:36:19 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 0332B28C183 for <uri-review@ietf.org>; Mon, 12 Oct 2009 03:36:17 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA217493729; Mon, 12 Oct 2009 12:35:29 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA20028; Mon, 12 Oct 2009 12:35:27 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200910121035.MAA20028@TR-Sys.de>
To: dret@berkeley.edu, antti.vaha-sipila@nokia.com
Date: Mon, 12 Oct 2009 12:35:27 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org
Subject: [Uri-review] draft-wilde-sms-uri-19 remaining editorials
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2009 10:36:20 -0000
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@TR-Sys.de | +------------------------+--------------------------------------------+
- [Uri-review] draft-wilde-sms-uri-19 remaining edi… Alfred Hönes
- Re: [Uri-review] draft-wilde-sms-uri-19 remaining… Erik Wilde