[fwd] Re: [APPS-REVIEW] Fwd: SMS URI spec question (from: tlr@w3.org)

archiving
-- 
Thomas Roessler, W3C  <tlr@w3.org>





----- Forwarded message from Thomas Roessler <tlr@w3.org> -----

From: Thomas Roessler <tlr@w3.org>
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: APPS-REVIEW@ietf.org, Martin Duerst <duerst@it.aoyama.ac.jp>,
	Larry Masinter <LMM@acm.org>, jwz@jwz.org,
	Paul Hoffman <phoffman@imc.org>
Date: Sun, 2 Sep 2007 15:12:27 +0200
Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question

On 2007-08-31 08:47:28 -0700, Lisa Dusseault wrote:

> http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt
>
> has a bunch of URL parameters which are instructions not only to
> the agent originating the SMS message (similar to the subject in 
> mailto:me@example.com;subject=HelloWorld ) but also instructions
> to the SMSC (SMS Center).  Some features even instruct the SMSC
> to send multiple messages, or gateway to a different protocol, or
> both.

Looking through the specification, there seems to be an
architectural decision in here to conflate the use of SMS facilities
to send text messages (for which a separate SMS URI scheme would
indeed seem very useful) with the use of these facilities as
infrastructure to do other things for which more or less
transport-independent URI schemes have already been defined. 

For these latter use case, having an infrastructure-specific URI
scheme is worrying.

Specifically, I've got some questions about the relation of this
specification to the tel:, fax:, mailto: URI schemes.

Starting with e-mail, the example in 2.4 has a phone number that's
(apparently) not used, which suggests that something might be wrong
with the proposed URL syntax in the first place.

More importantly, however, what's the rationale why a mailto URL
couldn't be used for the precise same use case?  Re-reading RFC
2368, I don't see any reason why a "mailto:" URI couldn't be
"dereferenced" by sending specially crafted SMSes that cause the
SMSC to produce and send the corresponding e-mail message.  On the
other hand, taking a form submission use case, it would seem like a
local policy decision on the user-agent side whether an e-mail to an
Internet mailbox is gatewayed through SMS or sent through SMTP
directly (or maybe through avian carriers).

Similarly, what's the rationale why the fax URI scheme (which comes
with an extension mechanism) couldn't be used to specify message
content along with a fax-ness of the recipient's number, without
ever using an SMS URI?

Similarly, what's the rationale why the voice services can't be
handled by the same approach?

I would also like to understand the rationale for specifying SMSCs
as part of the URI in more detail.  At best, this is a
layer-violating fix for SMS-related routing issues.  At worst, we're
just specifying mobile network specific URIs for classical Internet
services which can conveniently be tied to a particular network
operator.  Which would be worrying.

As Larry already pointed out, section 3 feels out of place, as it
seems to specify implementation details for a particular type of URI
handler.  If this section remains part of the document, however, it
might also be useful to say a word or two about safe and unsafe HTTP
methods.  You really don't want to trigger an SMS with a GET.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>  +33-4-89063488


----- End forwarded message -----

Received on Sunday, 2 September 2007 13:36:49 UTC