Subject: Re: Fwd: Last Call: draft-wilde-sms-uri (URI Scheme for GSM Short Message Service) to Proposed Standard

From: Erik Wilde <[email-masked]>
Date: Sun, 02 Dec 2007 21:58:09 -0800

hello.

i would like to address the pFrom [email-masked] Tue Dec 04 18:25:46 2007
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>, <[email-masked]>,
	<[email-masked]>
Date: Sat, 1 Dec 2007 23:36:33 -0800
Cc: [email-masked], [email-masked], [email-masked]
Subject: secdir review of draft-ietf-sip-uri-list-conferencing-02.txt

This is a multipart message in MIME format.

--===============1389714702==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0018_01C83473.0346BCB0"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0018_01C83473.0346BCB0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  I have not
found any security-related problems with this draft.  These comments were
written primarily for the enefit of the security area directors.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

------=_NextPart_000_0018_01C83473.0346BCB0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visitedoints raised by cullen jennings regrading 
the last call draft draft-wilde-sms-uri (URI Scheme for GSM Short 
Message Service).

>> *From: *Cullen Jennings <[email-masked] <mailto:[email-masked]>>
>> *Date: *November 21, 2007 3:01:28 PM PST
>> *Subject: **Re: Last Call: draft-wilde-sms-uri (URI Scheme for GSM 
>> Short  Message Service) to Proposed Standard *
>>
>> 1) as far as I understand the needs to defining an address for sending 
>> SMS, I would want to understand why it would not be better to a tel 
>> URI than define a new type. Defining new types that have the same 
>> information just leads to lack of compatibility with existing 
>> applications and redundant information that gets out of sync. Let me 
>> provide a few examples. Today vcard often have mobile phone numbers in 
>> them and these are used by many applications for both phone call and 
>> sending SMS. Having a separate URI type would be very confusing - 
>> would this mean that the number in SMS URI could or could not be used 
>> for a MMS message? what about a voice call? Would you be able to send 
>> SMS to a tel URI? would we need a separate SMS entry in the vcard? 
>> There are several devices today (the iphone for example) that allow a 
>> tel URI to be put in a HTML page and the device to initiate an voice 
>> call or SMS to the tel URI. This is a good thing and is working well - 
>> publishing a second mechanism to do a subset of the same thing would 
>> only cause lack of interoperability between devices and documents that 
>> used the URIs.

that issue had been raised about a month ago (lisa dusseault informed me 
about that) and has been settled, i think, but i am not sure whether 
this has been done in a way visible on the ietf mailing list. here is my 
try of a short explanation:

for me, the telephone number is an end point address, like a dns name. 
there can be different services with whch one can interact on such an 
endpoint, for dns names this can be an http server and a ftp server. i 
think in makes sense to have two different uris here, even though the 
endpoint is the same. the same applies to tel/sms. it is true that there 
are devices which support both services, but for example many phones do 
not support mms, and if they do, that's a new way to communicate with 
that phone.

i do see the problem that i have to copy/paste phone numbers if i have a 
mobile that supports sms, but personally, i would not see that as a 
reason to fold to different communication protocols into one uri scheme.

>> 2) I am confused about if the goal is defining a URI for addressing 
>> SMS or if it is defining a REST style Web API for sending SMS.

it is doing the former and suggesting a way how the latter problem could 
be addressed.

>> The URI 
>> should refer to the address of the message and not carry the content 
>> of the message. Imagine a SIMPLE IM that that was addressed to a SMS 
>> URI. This would cause total confusion if the message could be either 
>> in the URI or in the body of the IM message.

i am sorry, i don't understand this. the uri works very similar to 
mailto uris, in that it addresses a receiver of a message. i may suggest 
a template for the message, but that can always be edited by the user 
composing the message. mailto supports the same body qualifier, which 
was the inspiration for the sms body qualifier.

>> Similarly 
>> the SMSC is sometime much more configuration information.

i agree. i guess the smsc still is some legacy from this idea of full 
configurability of everything the sms spec allows. we got rid of most of 
that already (the "telematic interworking" that was part of draft -08), 
and i will remove the smsc qualifier from the net draft, i am now 
convinced that this should not be part of a uri scheme.

>> The draft talks about appending 
>> query strings to web services but this seems a bit under-specified and 
>> I worry that using URLs other than the one provided is fraught with 
>> danger.

my hope was that there would be something like a standard way of how 
browsers can interact with web pages sup, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>I
have reviewed this document as part of the security directorate's =
ongoing
effort to review all IETF documents being processed by the IESG.&nbsp; I =
have not
found any security-related problems with this draft.&nbsp; These =
comments were
written primarily for the enefit of the security area directors.&nbsp; =
Document
editors and WG chairs should treat these comments just like any other =
last call
comments.<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0018_01C83473.0346BCB0--

--===============1389714702==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

--===============1389714702==--

---

From: Erik Wilde <[email-masked]>
Date: Sun, 02 Dec 2007 21:58:09 -0800

hello.

i would like to address the pporting the sending of sms 
messages. 
http://dret.net/netdret/docs/draft-wilde-sms-uri-13.html#smsservice is 
the section doing this, but i could understand if that is considered out 
of scope for the uri specification. i wait for some feedback on this, if 
i receive no objections, i'll leave it in the draft, but i have no 
problem whatsoever to remove it, the draft does not depend on that.

>> I would guess that advice around SMSC handling should be different 
>> based on if the SMS address is a short code or long code. In the 
>> context of a SMS being sent on a GSM device that is in a different 
>> carrier than the SMSC, is this going to work?

no. smsc will be removed, but of course the general problem remains the 
same. if the telephone number is context-dependent, it will not work 
outside of the context. the same is true for local telephone numbers for 
the tel uri scheme, or for relative http uris. if the creator of a uri 
does not make it global, it may break.

>> The draft does not seem to address if SMS short codes are valid to use 
>> or not. This seems sort of critical for deciding about the scope of 
>> these URI and in what context do they uniquely identify a resource.

short codes are simply numbers that are sold by telephone carriers for 
large amounts of money, right? so they will work in the same way as 
other numbers, and they may break if specified in a local format.

>> If there are multiple SMSC, what does that mean and how is order used.

the draft says "If multiple SMSC qualifiers are present, conforming 
software MUST interpret the first occurrence and ignore all other 
occurrences", but smsc will be removed anyway.

>> There are often billing and therefore authentication issues is sending 
>> an SMS and this does not seem to address them in a way that would 
>> allow interoperable implementations.

i don't really understand this. a sms uri is used by somebody, and its 
usage may incur a cost.  the security section states:

"In most networks, sending SMS messages is not a free service. 
Therefore, SMS clients MUST make sure that any action that incurs costs 
is acknowledged by the end user, unless explicitly instructed otherwise 
by the end user. If an SMS client has different ways of submitting an 
SMS message (such as a Web service and a phone line), then the end user 
MUST have a way to control which way is chosen. "

>> The stuff in para 5 of section 3 does not seem possible to implement 
>> without knowing all the things all the devices do which seems impossible.

unfortunately, yes. sms are used for all kind of configuration magic on 
phones, and some of this is standardized, but not everything. this is 
very unfortunate and insecure, but that's how it is.

>> I am very unclear in the use cases this draft imaginings, what 
>> "trusted means" might be used to populate the SMS message headers.

using something that is conformant with the sms spec. how could we 
improve this paragraph to make it clearer?

>> The syntax allows for many things that would not be a valid SMS 
>> address and this seem undesirable.

do you refer to the length of the phone numbers, or something else? we 
use the same phone number syntax as in rfc3986 (slightly simplified, 
because we don't have to support extensions).

thanks for the comments and kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

oints raised by cullen jennings regrading 
the last call draft draft-wilde-sms-uri (URI Scheme for GSM Short 
Message Service).

my hope was that there would be something like a standard way of how 
browsers can interact with web pages supporting the sending of sms 
messages. 
http://dret.net/netdret/docs/draft-wilde-sms-uri-13.html#smsservice is 
the section doing this, but i could understand if that is considered out 
of scope for the uri specification. i wait for some feedback on this, if 
i receive no objections, i'll leave it in the draft, but i have no 
problem whatsoever to remove it, the draft does not depend on that.

>> I would guess that advice around SMSC handling should be different 
>> based on if the SMS address is a short code or long code. In the 
>> context of a SMS being sent on a GSM device that is in a different 
>> carrier than the SMSC, is this going to work?

no. smsc will be removed, but of course the general problem remains the 
same. if the telephone number is context-dependent, it will not work 
outside of the context. the same is true for local telephone numbers for 
the tel uri scheme, or for relative http uris. if the creator of a uri 
does not make it global, it may break.

>> The draft does not seem to address if SMS short codes are valid to use 
>> or not. This seems sort of critical for deciding about the scope of 
>> these URI and in what context do they uniquely identify a resource.

short codes are simply numbers that are sold by telephone carriers for 
large amounts of money, right? so they will work in the same way as 
other numbers, and they may break if specified in a local format.

>> If there are multiple SMSC, what does that mean and how is order used.

the draft says "If multiple SMSC qualifiers are present, conforming 
software MUST interpret the first occurrence and ignore all other 
occurrences", but smsc will be removed anyway.

>> There are often billing and therefore authentication issues is sending 
>> an SMS and this does not seem to address them in a way that would 
>> allow interoperable implementations.

i don't really understand this. a sms uri is used by somebody, and its 
usage may incur a cost.  the security section states:

"In most networks, sending SMS messages is not a free service. 
Therefore, SMS clients MUST make sure that any action that incurs costs 
is acknowledged by the end user, unless explicitly instructed otherwise 
by the end user. If an SMS client has different ways of submitting an 
SMS message (such as a Web service and a phone line), then the end user 
MUST have a way to control which way is chosen. "

>> The stuff in para 5 of section 3 does not seem possible to implement 
>> without knowing all the things all the devices do which seems impossible.

unfortunately, yes. sms are used for all kind of configuration magic on 
phones, and some of this is standardized, but not everything. this is 
very unfortunate and insecure, but that's how it is.

>> I am very unclear in the use cases this draft imaginings, what 
>> "trusted means" might be used to populate the SMS message headers.

using something that is conformant with the sms spec. how could we 
improve this paragraph to make it clearer?

>> The syntax allows for many things that would not be a valid SMS 
>> address and this seem undesirable.

do you refer to the length of the phone numbers, or something else? we 
use the same phone number syntax as in rfc3986 (slightly simplified, 
because we don't have to support extensions).

thanks for the comments and kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)