hello.
i would like to address the points raised by cullen jennings regrading
the last call draft draft-wilde-sms-uri (URI Scheme for GSM Short
Message Service).
*From: *Cullen Jennings <fluffy@xxxxxxxxx <mailto:fluffy@xxxxxxxxx>>
*Date: *November 21, 2007 3:01:28 PM PST
*Subject: **Re: Last Call: draft-wilde-sms-uri (URI Scheme for GSM
Short Message Service) to Proposed Standard *
1) as far as I understand the needs to defining an address for sending
SMS, I would want to understand why it would not be better to a tel
URI than define a new type. Defining new types that have the same
information just leads to lack of compatibility with existing
applications and redundant information that gets out of sync. Let me
provide a few examples. Today vcard often have mobile phone numbers in
them and these are used by many applications for both phone call and
sending SMS. Having a separate URI type would be very confusing -
would this mean that the number in SMS URI could or could not be used
for a MMS message? what about a voice call? Would you be able to send
SMS to a tel URI? would we need a separate SMS entry in the vcard?
There are several devices today (the iphone for example) that allow a
tel URI to be put in a HTML page and the device to initiate an voice
call or SMS to the tel URI. This is a good thing and is working well -
publishing a second mechanism to do a subset of the same thing would
only cause lack of interoperability between devices and documents that
used the URIs.
that issue had been raised about a month ago (lisa dusseault informed me
about that) and has been settled, i think, but i am not sure whether
this has been done in a way visible on the ietf mailing list. here is my
try of a short explanation:
for me, the telephone number is an end point address, like a dns name.
there can be different services with whch one can interact on such an
endpoint, for dns names this can be an http server and a ftp server. i
think in makes sense to have two different uris here, even though the
endpoint is the same. the same applies to tel/sms. it is true that there
are devices which support both services, but for example many phones do
not support mms, and if they do, that's a new way to communicate with
that phone.
i do see the problem that i have to copy/paste phone numbers if i have a
mobile that supports sms, but personally, i would not see that as a
reason to fold to different communication protocols into one uri scheme.
2) I am confused about if the goal is defining a URI for addressing
SMS or if it is defining a REST style Web API for sending SMS.
it is doing the former and suggesting a way how the latter problem could
be addressed.
The URI
should refer to the address of the message and not carry the content
of the message. Imagine a SIMPLE IM that that was addressed to a SMS
URI. This would cause total confusion if the message could be either
in the URI or in the body of the IM message.
i am sorry, i don't understand this. the uri works very similar to
mailto uris, in that it addresses a receiver of a message. i may suggest
a template for the message, but that can always be edited by the user
composing the message. mailto supports the same body qualifier, which
was the inspiration for the sms body qualifier.
Similarly
the SMSC is sometime much more configuration information.
i agree. i guess the smsc still is some legacy from this idea of full
configurability of everything the sms spec allows. we got rid of most of
that already (the "telematic interworking" that was part of draft -08),
and i will remove the smsc qualifier from the net draft, i am now
convinced that this should not be part of a uri scheme.
The draft talks about appending
query strings to web services but this seems a bit under-specified and
I worry that using URLs other than the one provided is fraught with
danger.
my hope was that there would be something like a standard way of how
browsers can interact with web pages supporting the sending of sms
messages.
http://dret.net/netdret/docs/draft-wilde-sms-uri-13.html#smsservice is
the section doing this, but i could understand if that is considered out
of scope for the uri specification. i wait for some feedback on this, if
i receive no objections, i'll leave it in the draft, but i have no
problem whatsoever to remove it, the draft does not depend on that.
I would guess that advice around SMSC handling should be different
based on if the SMS address is a short code or long code. In the
context of a SMS being sent on a GSM device that is in a different
carrier than the SMSC, is this going to work?
no. smsc will be removed, but of course the general problem remains the
same. if the telephone number is context-dependent, it will not work
outside of the context. the same is true for local telephone numbers for
the tel uri scheme, or for relative http uris. if the creator of a uri
does not make it global, it may break.
The draft does not seem to address if SMS short codes are valid to use
or not. This seems sort of critical for deciding about the scope of
these URI and in what context do they uniquely identify a resource.
short codes are simply numbers that are sold by telephone carriers for
large amounts of money, right? so they will work in the same way as
other numbers, and they may break if specified in a local format.
If there are multiple SMSC, what does that mean and how is order used.
the draft says "If multiple SMSC qualifiers are present, conforming
software MUST interpret the first occurrence and ignore all other
occurrences", but smsc will be removed anyway.
There are often billing and therefore authentication issues is sending
an SMS and this does not seem to address them in a way that would
allow interoperable implementations.
i don't really understand this. a sms uri is used by somebody, and its
usage may incur a cost. the security section states:
"In most networks, sending SMS messages is not a free service.
Therefore, SMS clients MUST make sure that any action that incurs costs
is acknowledged by the end user, unless explicitly instructed otherwise
by the end user. If an SMS client has different ways of submitting an
SMS message (such as a Web service and a phone line), then the end user
MUST have a way to control which way is chosen. "
The stuff in para 5 of section 3 does not seem possible to implement
without knowing all the things all the devices do which seems impossible.
unfortunately, yes. sms are used for all kind of configuration magic on
phones, and some of this is standardized, but not everything. this is
very unfortunate and insecure, but that's how it is.
I am very unclear in the use cases this draft imaginings, what
"trusted means" might be used to populate the SMS message headers.
using something that is conformant with the sms spec. how could we
improve this paragraph to make it clearer?
The syntax allows for many things that would not be a valid SMS
address and this seem undesirable.
do you refer to the length of the phone numbers, or something else? we
use the same phone number syntax as in rfc3986 (slightly simplified,
because we don't have to support extensions).
thanks for the comments and kind regards,
erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
dret@xxxxxxxxxxxx - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf