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: Larry Masinter <LMM@acm.org>
Date: Mon, 13 Mar 2006 09:34:49 -0800
To: "'Tim Kindberg'" <timothy@hpl.hp.com>, "'Erik Wilde'" <net.dret@dret.net>
Cc: 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, Claudio.Allocchio@garr.it
Message-id: <000801c646c4$6e4e5700$5cf0070a@corp.adobe.com>

I think the idea with "?body=" is to be compatible with mailto.

There's a problem with using full 'gstn-phone' from 3601
in the 'sms-recipients' field, because if you trace
back in the RFC 3601 BNF, if you trace through the
BNF, the character # is allowed in DTMF,
which is allowed in phone-string, which is
allowed in local-phone, etc.
allows '#' in DTMF, and DTMF is part of 'phone-string'
which is allowed in 'dial-number', etc.

Maybe you would be better of sticking to RFC 2806
("URLs for telephone calls") syntax and using
'telephone-subscriber'. 

The security considerations are confusing, since 
sms-service document contains warnings about SMS URIs.
Maybe either combining the drafts? Or combining the
security considerations together?

There's a word order problem in the security considerations
of -sms-service-, the last sentence says
'user agents MAY users make aware of that risk'.
I'm not sure MAY is appropriate here. 

Back in the sms-uri document, the wording of 
"if an sms URI contains a pid-qualifier and the user agent
supports the qualifier and its value, then the user agent MUST ..."

since the MUST is preconditioned by a situation entirely
within the user agent's control.


You might want to review RFC 3552 (BCP 72) on "Guidelines for
Writing RFC Text on Security Considerations"; it would
help if you were clearer about the identification of threat,
the threat mitigation methods recommended ('never send
SMS without user's confirmation') and the residual risk
remaining after threat mitigation has been deployed.

There is no need to have a separate 'registration request'
Internet Draft; I'm surprised your reading of RFC 4395
made you think there was. I would just include the registration
template.

In fact, I would prefer it if you would combined
the three documents into one: description of service, 
syntax of URI, and registration template.

Larry



> Hi Erik,
> 
> First, thanks for the effort you're putting into this and apologies if 
> it's rather late in the day to say what I'm about to say.
> 
> It's a small point but could I make a plea for a less verbose way of 
> specifying the body?  It seems redundant to prepend "?body=" before the 
> body text. You could instead have a syntax like:
> 
> sms-uri         =  scheme ":" sms-recipients [ ":"  sms-body ]
> scheme          =  "sms"
> sms-recipients  =  sms-recipient *( "," sms-recipient )
> sms-recipient   =  gstn-phone sms-qualifier
> sms-qualifier   =  *( smsc-qualifier / pid-qualifier )
> smsc-qualifier  =  ";smsc=" SMSC-sub-addr
> pid-qualifier   =  ";pid=" PID-sub-addr
> sms-body        =  query
> 
> My main motivation for keeping things short and sweet is that, as you 
> may be aware, one of the principal uses for this syntax is to put sms 
> messages into 2D barcodes for reading and sending by camera phones (see 
> www.activeprint.org). The effective capacity of such a 2D code (given 
> current camera phone optics) is about 1-200 bytes so it's nice to be 
> "lean and mean".

> Erik Wilde wrote:
> > 
> > 
> > 
> > 
> > hello.
> > 
> > a uri scheme for sms messages has been under development now for quite 
> > some time. the registration process for new uri schems is now defined by

> >  rfc 4395, and thus the drafts have now been prepared for final approval

> > as a registered uri scheme. new drafts have been released today (they 
> > will not be accessible for the next days through the ietf channels due 
> > to the pre-meeting cut-off and subsequent delay) at the following uris:
> > 
> > http://dret.net/netdret/docs/draft-wilde-sms-uri-12.txt
> > http://dret.net/netdret/docs/draft-wilde-sms-uri-12.html
> > http://dret.net/netdret/docs/draft-wilde-sms-service-12.txt
> > http://dret.net/netdret/docs/draft-wilde-sms-service-12.html
> > 
> > the registration draft itself is a new document (a short one), prepared 
> > according to the guidelines given in rfc 4395:
> > 
> > http://dret.net/netdret/docs/draft-wilde-sms-uri-registration-00.txt
> > http://dret.net/netdret/docs/draft-wilde-sms-uri-registration-00.html
> > 
> > any feedback regarding the two older drafts and the new registration 
> > draft is greatly appreciated. it is planned to submit all drafts to the 
> > ietf as soon as possible for publication respectively registration, 
> > targeting the 66th ietf meeting in montreal (summer 2006).
> > 
> > many 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)
> > 
> > 
> 
> -- 
> 
> Tim Kindberg
> hewlett-packard laboratories
> filton road
> stoke gifford
> bristol bs34 8qz
> uk
> 
> purl.org/net/TimKindberg
> timothy@hpl.hp.com
> voice +44 (0)117 312 9920
> fax ++44 (0)117 312 8003
> 
> 
Received on Monday, 13 March 2006 17:35:43 GMT

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