On Nov 23, 2007, at 12:29 PM, Andrew Newton wrote:
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.
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf