hello miguel.
thanks for your comments, and i am replying to them at the same time as
i am replying to the comments made by Leslie Daigle, because he referred
to many of the issues raised by your comments.
Miguel A. Garcia wrote:
Major issues:
- About the SMS URI scheme syntax. <sms-body> is defined as:
sms-body = "body=" query
query is defined in RFC 3986 as:
query = *( pchar / "/" / "?" )
Notice that <query> can contain the equal sign "="
RFC 3986 also says: as query components
are often used to carry identifying information in the form of
"key=value" pairs ....
And now for my point. So, query is typically used for indicating
"key=value" pairs. But here, <query> is used as the <value> inside the
"body" key. So, in other words, it is valid to have an SMS URI that
contains two equal signs, like this:
sms:+12125552121?body=param=myvalue
I think this might create ambiguity. I am not sure if the syntax allows
this combination on purpose or not. I would like the authors to confirm
that this is done on purpose, or perhaps replace <query> with something
that does not allow the "key=value" pair, perhaps "reg-name" (see
definition in RFC 3986).
thanks for raising that issue, and the URI you mentioned definitely is
an unintended side-effect of using <query> in the wrong place. i guess
<reg-name> is close but does allow <sub-delims> which includes '=', so
it would not help, and it is used for a different purpose. i therefore
think it might be simpler and clearer to introduce something
specifically for the SMS URI, as suggested by Leslie Daigle. so here is
the new version:
sms-body = "body=" escaped-sms
escaped-sms = *( unreserved / pct-encoded )
plus some text: "The syntax definition for <escaped-sms> refers to
the text of an SMS where all <reserved> (as per RFC 3986 <xref
target="RFC3986"/>) characters in the SMS text are percent-encoded,
please refer to RFC 3986 <xref target="RFC3986"/> for the details about
percent-encoding."
The problem here is if implementations might have a problem with the
double equal sign. Today this does not seem to be a problem, because
there is a single parameter. But it might be in the future if new
parameters are added. Besides, for human consumption, the URI looks
weird if a double equal sign is included.
i completely agree, even though it remains to be seen how much
implementations will actually follow the requirement to encode reserved
characters; but that's a different issue.
- On another topic, the scope of this specification is not clear. I
expected to be the definition of the SMS URI scheme, its registration,
etc. But I expected that SMS procedures are outside the scope of this
specification, and defined elsewhere. However, I found sentences that go
into what I consider to be the SMS specification or the SMS
implementation, but not the SMS URI scheme specification. For example:
SMS clients composing messages SHOULD use the standard
concatenation method based on the header in the TP-User Data field as
specified in the SMS specification
you are right that strictly speaking this is not part of a SMS URI
scheme. it is more a "best practice" we thought might be helpful for
implementors who have to decide how to implement the interface from
users composing SMS messages to submitting these messages to SMS APIs
which might provide them with both options for sending messages (through
concatenation) longer than just 1 message.
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.
again, just a hint as to what a typical user experience might look like.
When "sms" URIs are dereferenced, implementations MAY
create a message and present it to be edited before being sent, or
they MAY invoke additional services to provide the functionality
necessary for composing a message and sending it to the SMS message
endpoint. In either case, simply activating a link with an "sms" URI
SHOULD NOT cause a message to be sent without prior user
confirmation.
we thought it was important to make sure that implementations should not
just send messages when users follow an SMS URI. i think at some point
in time we even had "MUST NOT" here, because that would be even worse
than email messages just being sent by selecting a mailto: URI, since
SMS messages may cost money.
you are definitely right that strictly speaking these issues are not
part of the SMS URI scheme, but we thought they were important enough to
be included as guidance to implementors. do you suggest we take them
out, and if so, what shall we do with the guidance? provide no guidance
at all, or have a separate "guidance"/"best practices"/"implementation
considerations" document?
- I noticed that the draft considers Erratum 203 in RFC 3966. I think
this erratum is essential for this draft (I am not going to discuss the
reason here). I would suggest that this draft insists much more on this
erratum. I didn't find any reference to this erratum until I got to
Appendix A, and at that time I had spent quite a lot time reviewing the
unfixed RFC 3966. I suggest to add some text around Section 1.3.1,
Second paragraph, indicating that this Erratum is very important for the
draft. Perhaps you should replace the first sentence of that second
paragraph with:
"The syntax for telephone numbers is taken from [RFC3966]. Please
consider Erratum 203 in that specification. For the reader's
convenience, Appendix A contains a fixed syntax of the telephone number
URI scheme including Erratum 203."
good point, the erratum is essential and thus it should be mentioned
more explicitly. here is the updated text of the paragraph:
The syntax definition for <telephone-subscriber> is taken from RFC
3966 <xref target="RFC3966"/> (Section 5.1). Please consider Erratum 203
in that specification. For the reader's convenience, <xref
target="telephone-subscriber-syntax"/> contains a fixed syntax of the
telephone number URI scheme including Erratum 203, but RFC 3966 (plus
all applicable erratums) is the normative reference.
- In general, the Introduction section should be informative in nature
and should not contain normative statements. There are plenty of MAY,
SHOULD, and MUST in Sections 1.x
something is wrong with the numbering, because section 1.3 should be
section 2, and then everything before that is more informative in
nature. that leaves section 1 with statements about message
concatenation (1.2.1), and the "implementation guidance" or "best
practices" i mentioned above (1.2.4). i think there is some value in
providing expectations for the behavior of implementations, so i have to
admit that i am reluctant to remove all of these statements.
- In Section 1, I didn't find sense to the first sentence: "Compliant
software MUST follow this specification". Well, this is always the case.
true. probably some boilerplate we started from.
The notation for phone numbers is taken from [RFC3966] and its Erratum
203. Appendix A provides a corrected syntax of the telephone number
fixed.
- In the URI scheme definition, it usually helps if you add comments
indicating where some terms are originally defined. For example:
sms-uri = scheme ":" hier-part [ "?" sms-body ]
scheme = "sms"
hier-part = sms-recipient *( "," sms-recipient )
sms-recipient = telephone-subscriber ;defined in RFC 3966
sms-body = "body=" query ;query defined in RFC 3986
done.
- Expand "TP-User Data field" in last paragraph of Section 1.2.1.
this refers to various methods of SMS message concatenation that are
implemented in various devices, and suggests that implementations should
use the standardized mechanism (which came later than the original SMS
spec, which is why early implementations had no choice other than
implementing proprietary concatenation methods). but the paragraph
explains that, so what would you like to see added? here is a brief
summary of the protocol, but that's probably not what you're after:
http://en.wikipedia.org/wiki/Concatenated_SMS
- Unused references: [RFC2822]
nice catch, thanks.
- First paragraph in Appendix A: replace <isdn-subsddress> with
<isdn-subaddress>
- Does Appendix B make sense?
- Appendix C is typically a section of its own: Acknowledgments.
fixed, deleted, moved. thanks.
cheers,
erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
[email protected] - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
