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:24 -0500
Message-ID: <441AD2E2.6080907@dret.net>
To: Larry Masinter <LMM@acm.org>
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, Claudio.Allocchio@garr.it




hello.

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

yes.

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

i looked at rfc 3966 (the updated version of rfc 2806) and noticed that
'telephone-subscriber' allows '*par' after global and local numbers, 
which translates to parameters, extensions, and isdn subaddresses, and 
we don't want to have these par things. but even if we decide to not use 
'telephone-subscriber' but the two productions 'global-number-digits' 
and 'local-number-digits', the latter also allows the '*' and '#' signs 
you did not want to have. any suggestions how to resolve that? it was my 
understanding (and something that claudio allocchio pointed me to when i 
started writing the sms uri drafts) that rfc 3601 was intended to be 
used whenever phone numbers need to be used in internet standards.

> 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?

i have now combined all three drafts into one draft, which merges the 
security sections and contains the registration forms as sections.

> 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. 

new: "This attempt to collect information may be a privacy issue, and 
user agents MAY make users aware of that risk before composing or 
sending SMS messages."

> 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.

i don't get this one. is it not allowed to have a MUST if the control is 
at the user agent? i guess this is just what i want to do here, i want 
to say what a user agent MUST do under certain circumstances.

> 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.

do you suggest do re-write or re-phrase the whole section or just parts 
of it? right now it is a set of issues which are often unrelated, so i 
assume your comment is about all or most issues and not about specific 
one you find hard to understand?

> 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.

ok, as i said above, the new version will be only one draft, including 
the two registrations as sections. i want to improve this new draft a 
bit before i submit it again, mainly in the security section, which 
seems to be the biggest problem.

cheers and thanks for the comments,

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:57:36 GMT

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