Re: IETF Draft on mmsto:

Hi Bennet,

> For the email scheme, far and away the most common usage pattern is the
reply, and hence the email address is in the primary (mandatory) position
before the "?". This is one common pattern for mobile, but the other equally
common pattern for sms and mms is forwarding a piece of fixed information
(i.e. a URL or image) to a new party. In this case the universal mode for
this is to have the composer "find" the address in the address book. The
current specification for mmsto: would require a default telephone # or
email address (the reply scenario), and make it non-intuitive for the
forwarding case, where I would pre-specify the "body" but not the address.
It would require the user to explicitly overwrite a bogus address supplied
with the scheme, and if not overwritten, the message would go back to the
default location, definitely not the desired result.

What you're talking about is "the action of sending x", where x is some
resource---presumably identified by a URI.  I don't know if this action
should be identifed by a URI, but if it should, I don't think the scheme
should be mmsto.  Rather, we should define a new scheme, let's call it
"send," that would identify the action of sending a resource to someone by
some means.  So for instance you could have

   send:http://www.example.com/?to=mailto:someome@example.com

or---to take your example of sending it to some unspecified
destination---simply

  send:http://www.example.com/

or you could even send it to an FTP server:

  send:http://www.example.com/?to=ftp://ftp.example.com/upload/

But we're lived without the send scheme for---what?---almost 20 years now.
How come we managed?  Well, I don't think this action should be explicitly
identified by an URI, just like I don't think clicking a button should not
be identified by an URI.  Simply add a "Send" option to the browser,
applicable to resources which can be identified by, e.g., a hyperlink, a
block of selected text, or the current document.  In fact, this is exactly
what browsers do today, for e-mail.  I don't see how mobile devices can't do
the same---i.e., having "Send MMS" as an action for, e.g., hyperlinks or
selected text.

To clarify:  I'm not suggesting that "send" actually be defined as a new URI
scheme; I merely want to point out that using the mmsto scheme to identify
an *action* seems abusive, since the scheme obviously is meant to identify
MMS destinations, just like the http scheme obviously is meant to identify
HTTP resources, not "the action of retrieving some resource via HTTP."
Granted, the mailto scheme with its subject and body parameters currently
identifies some kind of actions, but I don't agree with this either.  I
think the scheme should only identify e-mail addresses.  (As a side note, it
should probably have been called "email" from the beginning.)

> One other comment, I am not sure that "mms:" is appropriate for mobile
phone devices. It either allows the automatic issuance of an mms message
without acknowledgement, a big problems since MMS messages cost real money,
or there is a required acknowledgement step, in which case most vendors want
a consistent user experience, so why not simply use the composer as the
acknowledgement vehicle, which would allow single button acknowledgement and
review in the same step. Hence, we could have used mmsto: in the first
place. Of course there may be other use cases that I am not taking into
consideration.

I agree.  The "mms" vs "mmsto" distinction seems confusing at best.  Again,
it may just be that I don't see the right use cases for it.  I think the
purpose needs to be clarified.


Regards,
--
Daniel Brockman
daniel@brockman.nu

----- Original Message ----- 
From: <Bennett.Marks@nokia.com>
To: <uri@w3.org>
Sent: Monday, September 29, 2003 9:02 PM
Subject: IETF Draft on mmsto:



Ted,

I read the draft, (
http://www.ietf.org/internet-drafts/draft-wugofski-mms-uri-scheme-00.txt)
and understand that you have patterned the mmsto: after mailto:. I have one
concern. That is that on mobile phones the most common usage patterns for
mms and sms do not exactly match the usage patterns that are modeled for
email on the wired web.

For the email scheme, far and away the most common usage pattern is the
reply, and hence the email address is in the primary (mandatory) position
before the "?". This is one common pattern for mobile, but the other equally
common pattern for sms and mms is forwarding a piece of fixed information
(i.e. a URL or image) to a new party. In this case the universal mode for
this is to have the composer "find" the address in the address book. The
current specification for mmsto: would require a default telephone # or
email address (the reply scenario), and make it non-intuitive for the
forwarding case, where I would pre-specify the "body" but not the address.
It would require the user to explicitly overwrite a bogus address supplied
with the scheme, and if not overwritten, the message would go back to the
default location, definitely not the desired result.

Is there some way to add the ability to "null out" the recipient address,
which would force the composer to go through address assignment. Perhaps
explicit instructions to a composing application if the destination address
is specified as ""?

One other comment, I am not sure that "mms:" is appropriate for mobile phone
devices. It either allows the automatic issuance of an mms message without
acknowledgement, a big problems since MMS messages cost real money, or there
is a required acknowledgement step, in which case most vendors want a
consistent user experience, so why not simply use the composer as the
acknowledgement vehicle, which would allow single button acknowledgement and
review in the same step. Hence, we could have used mmsto: in the first
place. Of course there may be other use cases that I am not taking into
consideration.



Bennett Marks
Vice Chair OMA Mobile Applications Environment
Manager Infotainment Technology - MSW/SA
Nokia Mobile Phones / Mobile Software Unit
* 5 Wayside Rd., Burlington MA  01803         NOKIA
* bennett.marks@nokia.com
* +1 781 308 6556
* +1 781 993 1911

Received on Monday, 29 September 2003 16:51:09 UTC