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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf