Subject: Re: [Gen-art] Gen-ART review of IETF-LC draft-wilde-sms-uri-16.txt

From: Erik Wilde <[email-masked]>
Date: Mon, 03 Aug 2009 18:22:58 -0700

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 &lt;escaped-sms> refers to 
the text of an SMS where all &lt;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 &lt;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-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)