[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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. 



-----Original Message-----
From: 	Thomas Roessler [mailto:tlr at w3.org]
Sent:	Sunday, September 02, 2007 06:12 AM Pacific Standard Time
To:	Lisa Dusseault
Cc:	APPS-REVIEW at ietf.org; Martin Duerst; Larry Masinter; jwz at jwz.org; 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:me at 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 at w3.org>  +33-4-89063488


_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW at ietf.org
https://www1.ietf.org/mailman/listinfo/apps-review


------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio at garr.it
                        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


_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW at ietf.org
https://www1.ietf.org/mailman/listinfo/apps-review