On Nov 21, 2007, at 6:01 PM, Cullen Jennings wrote:
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.
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.
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.
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 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf