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

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Nov 2007 15:01:28 -0800

<resend as I was told this did not make it the first time>

There are a wide variety of problems with this draft. I think the two  
big topics are

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.

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. 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. Now I can see  
the value defining some sort of REST like API to send a SMS -  
however, I have a hard time imagining that given what we know about  
URI at this point in time that using the URI to do this would be the  
best way. Similarly the SMSC is sometime much more configuration  
information. If what you want is something that could be embedded in  
a web site that caused a SMS application to launch and perhaps send  
an SMS, I wonder if a MIME type would be more appropriate here? 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. I understand this is modeled  
after mailto, what I am wondering is if that is the best model to  
accomplish this.

Some more minor issues that would need to be resolved.

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?

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.

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

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.

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.

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

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

Cullen <with my individual hat on>

On Oct 11, 2007, at 8:57 AM, The IESG wrote:

> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'URI Scheme for GSM Short Message Service '
>    <draft-wilde-sms-uri-13.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2007-11-08. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-13.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_id&dTag=8229&rfc_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 23 Nov 2007 15:29:19 -0500

On Nov 21, 2007, at 6:01 PM, Cullen Jennings wrote:

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

That's an interesting observation given that there has been IETF  
advice for the opposite.  Just recently in a RAI working group (http://www1.ietf.org/mail-archive/web/geopriv/current/msg04645.html 
):

     - Fields that can contain HTTP URLs without clear expectations on  
what kind of resource must be at the URL, can also be bad for  
interoperability

That was about BCP 56 and defining a new URI scheme for HELD.  If HELD  
is to have a new URI scheme, I would think that SMS would also  
qualify.  Unlike HELD which is just reusing HTTP, this draft points to  
the SMS specification and the things that are specific to SMS  
interoperability.  In particular, the extra information this draft  
specifies over what can be done is the smsc-qualifier and sms-body (to  
answer your question).  Maybe principles behind BCP 56 should be  
universally applied.

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

I don't understand the either/or nature of your example.  If a client  
recognizes a tel: uri and offers the end user the opportunity to both  
text and call the number, that's great.  But I see nothing wrong with  
the author of the content providing more clue that the number supports  
texting.  I certainly have phones associated with me that do not  
support SMS and some that do, and being able to tell people which I  
prefer to have text messages come to seems to be advantageous.

With regard to your mention of the iPhone, they seem to operate on the  
notion of something looking like a telephone number and not just being  
a tel: uri.

> SMS or if it is defining a REST style Web API for sending SMS.

This draft appears to be defining a URI for addressing SMS, and then  
going the extra step of illustrating how it would be used in web  
environments that pass around URIs embedded in the query parts of  
other URIs.  I didn't find it to be confusing.

> The URI should refer to the address of the message and not carry the  
> content of the message.

This is not without precedent.  RFC 2368 defines the specification of  
the body in the mailto: uri.

-andy

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 23 Nov 2007 13:00:19 -0800

On Nov 23, 2007, at 12:29 PM, Andrew Newton wrote:

> advice for the opposite.  Just recently in a RAI working group  
> (http://www1.ietf.org/mail-archive/web/geopriv/current/msg04645.html):
>
>     - Fields that can contain HTTP URLs without clear expectations  
> on what kind of resource must be at the URL, can also be bad for  
> interoperability
>
> That was about BCP 56 and defining a new URI scheme for HELD.  If  
> HELD is to have a new URI scheme, I would think that SMS would also  
> qualify.  Unlike HELD which is just reusing HTTP, this draft points  
> to the SMS specification and the things that are specific to SMS  
> specifies over what can be done is the smsc-qualifier and sms-body  
> (to answer your question).  Maybe principles behind BCP 56 should  
> be universally applied.

It's my post that's quoted above, but that isn't what I meant.  I  
meant that if we have a field, in XML or in another format like VCard  
that allows kind of URL whatsoever, then we'll have problems when  
clients use the field very creatively.  Some examples:

	- WebDAV (RFC4918) uses <href> elements to contain arbitrary URIs --  
not just HTTP URLs.  But in some contexts where the client is  
supposed to dereference the URL (instead of use it as a token), the  
spec restricts the URL -- e.g. a HTTP URL -- but not just any HTTP  
URL, the spec restricts the reference to point to a WebDAV resource.   
This is English-language spec restrictions, by the way, not XML  
schema or defining a new URI schema.

	- VCard (RFC2426) has a PHOTO field. This can contain a value that  
is typed as a URI.  Unfortunately, there's no advice at all about  
whether the URI could be an HTTP URL, FTP URL, IMAP URL, data: URL or  
other.  This has limited the use of that field to de facto,  
accidental  "standardization" -- since clients probably only support  
HTTP URLs in that field that's all anybody can ever use.

Being specific about the kind of URI that can appear in a specific  
application is a separate issue from whether a new URI type is needed  
to distinguish the kind of resource.   I'm the shepherd for the SMS  
URI spec, but I don't see how these issues relate, given that the SMS  
URI spec defines the URI itself, not any places for its use.

Lisa