<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(_at_)ietf(_dot_)org mailing lists by 2007-11-08. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf