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

From: Paul Hoffman <[email-masked]>
Date: Fri, 31 Aug 2007 08:56:47 -0700

At 8:47 AM -0700 8/31/07, Lisa Dusseault wrote:
>The SMS URI draft:
>
><http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-12.txt>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]>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.
>
>I'm hoping that Apps reviewers plus mailto schema experts can either 
>quell my qualms or inform them.  Any thoughts?

We have had no problems with mailto: and headers that I know of. The 
only complaint I ever hear is that it doesn't handle MIME messages.

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

---

From: "Larry Masinter" <[email-masked]>
Date: Sat, 1 Sep 2007 18:25:15 -0700

> > I'm uncomfortable with the vague way in which "SMS messages can
> > be concatenated to form longer messages" and the length limit,
> > especially since you're expecting clients to dynamically generate
> > sms messages for things like form submission. I think you either
> > need to define the length limit and how it applies, or else define
> > how, given a sms URI with a really long message body, how to turn
> > it into a sequence of sms messages.
>
> on the technical side, there are various ways how to encode a longer
> message as a sequence of sms messages, and for example, various device
> manufacturers of mobile phones choose various ways of doing this. there
> is no technical limit to the number of messages that can be
> concatenated, and the main concern is more about cost, because in a
> typical environment, users are charged for each sms message.

How does the sender of a long message know how to split up the message
so that the receiver will properly interpret it? Can they ever be
delivered out of order? Are the messages numbered?  Is there an
agreed-upon maximum length?

Do you need private out-of-band information to reconstruct the
original intended message from the sequence of SMS messages?

You're going out of your way to specify transmission parameters for
most other SMS capabilities, I'm not understanding how this part is
interoperable.

Larry

---

From: Erik Wilde <[email-masked]>
Date: Sat, 01 Sep 2007 22:51:21 -0700

hello larry.

> agreed-upon maximum length?

section 9.2.3.24.1 of 
http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip 
(the current sms spec) contains the details about concatenated sms 
messages. there is a standard format how to transmit them, but not all 
client use this, some use their own, in which case it is impossible to 
say anything about their constraints. if senders use the standard 
format, the following rules apply:

- the sender assumes that the recipient understands the concatenated 
format. if the recipient does not understand it (such as the stupid 
iphone), the messages appear as individual messages with weird control 
characters in them.

- delivery of sms messages in not ordered, but if the standard mechanism 
is used, messages can be reordered on the recipient side. if the sender 
or the recipient do not support the standard format, messages may appear 
out of order.

- the standard format has a numbering scheme, which is used for ordering 
the messages: "Each concatenated short message contains a reference 
number which together with the originating address and Service Centre 
address allows the receiving entity to discriminate between concatenated 
short messages sent from different originating SMEs and/or SCs."

- the standard states: "The maximum length of an uncompressed 
concatenated short message is 39015 (255*153) default alphabet 
characters, 34170 (255*134) octets or 17085 (255*67) UCS2 characters.
The maximum length of a compressed concatenated message is 34170 
(255*134) octets including the Compression Header and Compression Footer 
(see clause 3.9 and figure 9.2.3.24.1(a) below)." my guess is that most 
recipients (typically mobile phones) will implement smaller limits, but 
i have no facts about that. antti may have some details here.

> original intended message from the sequence of SMS messages?

no, the standard format has everything that is required to make things work.

> most other SMS capabilities, I'm not understanding how this part is

i do understand your point that we are talking about the "maximum SMS 
message size", and then not say anything about it. would your comment be 
addressed by adding a sentence quoting the maximum size defined by the 
standard or the maximum size supported by the sender, and using whatever 
is the smaller number?

thanks and cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Fri, 31 Aug 2007 11:22:11 -0700

hello everybody.

thanks for the feedback, i will try to address all the questions and 
will integrate these changes into a new version of the draft, which 
hopefully can be published very soon.

> Is there a registry of pid-value, or is this it? Isn't it likely
> that most of the values will be unimplemented? I suppose it's harmless.

the "registry" is in the sms spec, i updated the sms spec reference to 
point to the latest version, and 
http://www.3gpp.org/ftp/Specs/archive/23_series/23.040/23040-701.zip 
section "9.2.3.9 TP Protocol Identifier (TP PID)" is where the 
identifiers are listed. it is pretty much a closed list, because it is 
based on bit patterns and there are only few left... and yes, most of 
these probably will not be implemented, but since they are part of the 
spec, they could be implemented.

sadly, some devices do not give any reasonable feedback about the number 
of messages they are generating, the iphone for example supports sms 
messaging, but does not show you how many messages you will produce (and 
have to pay for). skype, on the other hand, faithfully shows to how many 
sms messages your longer message will be mapped.

so i don't see a reasonable way to limit the length, but maybe it would 
be appropriate to say that a client SHOULD make the user aware of the 
number of messages that will be sent? would that address your concerns?

> Sections 1.4.2& 2.5: the handling of "sms" in HTML forms references
> "just as they are packaged when using a "mailto" URI, but the definition of
> how
> that happens is a feature of HTML and not of the URI scheme.
> My recollection is that it isn't formally defined in the
> W3C HTML specification, but it's also not in any (not obsolete)
> IETF document. Same problem for web services. Perhaps those sections
> should be marked as non-normative, and instead become informational  --
> how the authors or their organizations intend to propose the
> described changes to the appropriate standards bodies for the
> relevant specifications.

i have the same recollection as you, that there is no formal standard 
about this anywhere. how would be go about marking these as informal? is 
there a formal way of doing this, or just add a sentence at the 
beggining saying "the text of the following subsection is informal and 
for informational purposes only"?

> I don't know why they need to specify section 3 at all -- every
> web service SMS gateway could define its own mechanism for sending
> SMS without making up funny URIs as a way of carrying the
> destination information. Is this just an example? 

this section probably is a result of my personal frustration with how 
badly most clients handle unknown uri schemes, and that a more 
systematic way of doing this would be a good idea. would it be ok to 
leave it in there and mark it as informal as well? if not, i can remove it.

> 4.4: of course it addresses a resource. That's why they're defining
> a Resource Identifier. I'd just delete the first two sentences
> and the "Instead, ". 

ok, done.

thanks a lot and kind regards,

dret.

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 31 Aug 2007 10:50:58 -0700

Larry

---

From: Erik Wilde <[email-masked]>
Date: Fri, 31 Aug 2007 11:22:11 -0700

hello everybody.

ok, done.

dret.

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 31 Aug 2007 10:50:58 -0700

Larry

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 2 Sep 2007 15:12:27 +0200

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,
-- 
Thomas Roessler, W3C  <[email-masked]>  +33-4-89063488