Subject: Re: [APPS-REVIEW] Fwd: SMS URI spec question

From: Thomas Roessler <[email-masked]>
Date: Mon, 3 Sep 2007 09:49:51 +0200

On 2007-09-02 12:22:56 -0700, Larry Masinter wrote:

> I think when we revised the uri scheme registration rules, we
> gave up on the idea (most likely W3C policy) of trying to
> discourage URI schemes with narrow applicability by limiting
> registration, because the result was widespread use of
> unregistered schemes. And SMS is different enough from email to
> not fit nicely into mailto.

Umh...  I must have been unclear.  I'm *not* suggesting that "sms"
be replaced by "mailto", or that the scheme be rejected.

However, I am suggesting that "SMS to be turned into Internet e-mail
message at SMSC" is maybe better dealt with by a mailto URI;
likewise for the "text-to-voice" and "text-to-fax" gateway
functionalities and the tel and fax URI schemes.

Regards,
-- 
Thomas Roessler, W3C  <[email-masked]>  +33-4-89063488

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

---

From: "Larry Masinter" <[email-masked]>
Date: Sun, 2 Sep 2007 12:22:56 -0700

I think when we revised the uri scheme registration rules, we gave up on the idea (most likely W3C policy) of trying to discourage URI schemes with narrow applicability by limiting registration, because the result was widespread use of unregistered schemes. And SMS is different enough from email to not fit nicely into mailto. So I have no doubt that it should be registered, and just would focus on ensuring that the definition is clear enough that the players know what to do -- and not to mandate behavior that is unlikely to be implemented.

There are several players, including those who write software that interprets URIs to send SMS messages (handset protocol stack), or construct URIs from parameters (browsers) or supply those parameters (html forms) or the URIs themselves.

Is the supplier of a URI (or a form with a SMS target) expected to be aware of the nature of URI-interpreter's handling of long SMS messages?  (I can see how they might know about the SMS receiver since they supply the number.)
    
I think it comes down to whether you require the SMS-sender to always use the long-message standard (even if the lower level stack doesn't). If not, then it would be convenient to warn html form authors that sms messages longer than the single message length limit might not be sent interoperably.

 -----Original Message-----
From: 	Thomas Roessler [mailto:[email-masked]]
Sent:	Sunday, September 02, 2007 06:12 AM Pacific Standard Time
To:	Lisa Dusseault
Cc:	[email-masked]; Martin Duerst; Larry Masinter; [email-masked]; Paul Hoffman
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:[email-masked];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,

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 3 Sep 2007 14:19:37 +0200 (CEST)

On Sun, 2 Sep 2007, Larry Masinter wrote:

> I think when we revised the uri scheme registration rules, we gave up on 
> the idea (most likely W3C policy) of trying to discourage URI schemes 
> with narrow applicability by limiting registration, because the result 
> was widespread use of unregistered schemes. And SMS is different enough 
> from email to not fit nicely into mailto.

True, and this was agreed also by the draft editors during the quite long 
discussion which wa suseful to prepare the current draft.

>So I have no doubt that it 
> should be registered, and just would focus on ensuring that the 
> definition is clear enough that the players know what to do -- and not 
> to mandate behavior that is unlikely to be implemented.

I fully agree.

> There are several players, including those who write software that 
> interprets URIs to send SMS messages (handset protocol stack), or 
> construct URIs from parameters (browsers) or supply those parameters 
> (html forms) or the URIs themselves.
>
> Is the supplier of a URI (or a form with a SMS target) expected to be 
> aware of the nature of URI-interpreter's handling of long SMS messages? 
> (I can see how they might know about the SMS receiver since they supply 
> the number.)

I think the answer is YES. Has the "long SMS" handling is quite odd, 
implementers should take care of its possible effects (for example strings 
being cut into separate SMS messages!).

> I think it comes down to whether you require the SMS-sender to always 
> use the long-message standard (even if the lower level stack doesn't). 
> If not, then it would be convenient to warn html form authors that sms 
> messages longer than the single message length limit might not be sent 
> interoperably.

Also true. 
> methods.  You really don't want to trigger an SMS with a GET.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca