W3C home > Mailing lists > Public > uri@w3.org > March 2006

Re: submission of "draft-wilde-sms-uri-registration-00", "draft-wilde-sms-uri-12", and "draft-wilde-sms-service-12"

From: Erik Wilde <net.dret@dret.net>
Date: Mon, 20 Mar 2006 09:57:12 -0500
Message-ID: <441AC548.6060005@dret.net>
To: Aaron Irvine <Aaron.Irvine@openwave.com>
Cc: Tim Kindberg <timothy@hpl.hp.com>, uri-review@ietf.org, uri@w3.org, Bennett.Marks@nokia.com, Ted Hardie <hardie@qualcomm.com>, Antti Vähä-Sipilä <antti.vaha-sipila@nokia.com>, Basavaraj.Patil@nokia.com, Markus.Isomaki@nokia.com, alastair_angwin@UK.IBM.COM, Ileana.Leuca@cingular.com, martti.ala-rantala@nokia.com




hello.

> Tim Kindberg wrote:
>> sms-uri         =  scheme ":" sms-recipients [ ":"  sms-body ]
> An idea worth considering, but ":" sms-body would be confused with potential ":" port-number, so I'd suggest if you really want to avoid the mailto-like ?body= then:

as larry masinter already mentioned, the idea was to be compatible with 
mailto:, and unless here is a major outcry to save a small number of 
characters, i'd prefer to stick with the current syntax.

> sms-uri         =  scheme ":" sms-recipients [ "/"  sms-body ]
> Although no longer query-like it could have disadvantages.

while it may not be totally convincing to view the body as a "query 
string", using the "?" for separating it, the "/" is reserved for 
hierarchical schemes and i think using this character would not be 
considered good style.

> http://dret.net/netdret/docs/draft-wilde-sms-uri-12.txt says:
>> Implementations MAY choose to silently discard (or convert) characters in  >the sms-body that are not supported by the SMS character set they are using
>> to send the SMS message.
> Depending on language this can be a very bad thing, as removing a diacritical here or even dropping a letter there can change the meaning of a message.  The user would not want this done silently, so the implementations SHOULD if possible ask for confirmation.

you are right that silently discarding or converting characters is not a 
good idea. i have changed the sentence to:

"Implementations MAY choose to discard (or convert) characters in the 
sms-body that are not supported by the SMS character set they are using 
to send the SMS message. If they do discard or convert characters, they 
MUST notify te user."

> Alternatively, or in addition, there could be a parameter ";transliteration=%c4%88:Ch,%c4%89:ch" telling the implementation how to fallback on certain characters.

i think this maybe a bit too much, so i will ignore this for now.

> Another parameter, ";lang=ISO639", would be useful for text to speech for example.  But note that ;transliteration= should take precedence over ;lang= when the implementation decides what to do with characters needing fallback.

but text2speech would occur on the recipient side of the sms, right? and 
how would you send the lang information across? i agree that having lang 
information would be useful, but sms does not support this.

> In http://dret.net/netdret/docs/draft-wilde-sms-uri-12.txt I didn't see mention of SMS port numbers.  In JSR-120 and higher versions (how Java midlets send SMS's), there is smsurl which can be of the form sms://+358401234567:6578 (allowing port numbers would be very useful, but of course there might be security concerns).

this is something i need to be enlightened about. what are sms port 
numbers? i always thought port numbers are specific for internet 
protocols, and sms messages use gstn numbers for addressing. so what 
*is* an sms port number and what would you like to use it for? after a 
brief look into jsr-205 it seems to me that this is something that is 
specific for the wma architecture, and not a general sms concept.

thanks and kind regards,

erik wilde    tel:+41-44-6325132 - fax:+41-44-6321035
   mailto:net.dret@dret.net - http://dret.net/netdret/
   computer engineering and networks laboratory  (tik)
   swiss federal institute of technology zurich (ethz)
Received on Monday, 20 March 2006 14:58:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:36 GMT