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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




<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
ietf@xxxxxxxx mailing lists by 2007-11-08. Exceptionally,
comments may be sent to iesg@xxxxxxxx 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
IETF-Announce@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]