Re: IETF Draft on mmsto:

 > 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.

The purpose of the "mmsto:" URI is so that a browser (or some other 
client) knows to process the link using the MMS composer application.

 > 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,

Actually, nope.  The purpose of the "mmsto" URI scheme is to identify a 
_message_ that may be sent to an MMS recipient -- thats why the "mmsto:" 
URI scheme allows for optional header values.

In the I-D, I talk about identifying the device via several mechanisms 
RFC 3601 & RFC 2822 being two of them.

(Yes, I know what 2368 says, but I think that with _current practice_, 
"mailto:" has come to mean the message going over the wire rather than 
the mailbox since any browser or email client I use these days allows me 
to compose prior to sending or to cancel altogether)

 > Granted, the mailto scheme with its subject and body parameters
 > currently identifies some kind of actions, but I don't agree with this
 > either.

Looks like we will have to disagree about the role of "mmsto" as I am 
modeling it after "mailto".

 > 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.

See my response to Bennett.  Hopefully that clears it up.  The "mms" URI 
scheme is used for applications to send MMS message to other 
applications -- likely without direct user interaction.  In essence, the 
"mms" URI scheme should behave like the "http" URI scheme ala this quote 
from RFC 2368:

    In current practice, resolving URLs such as those in the "http"
    scheme causes an immediate interaction between client software and a
    host running an interactive server.

This is the behaviour I would expect when processing an "mms" URI.  But 
again, since it allows for you to attache content, I can't help but 
think it is referring to the message more than the actual recipient.




Daniel Brockman wrote:

> 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
> 
> 
> 
> 

-- 

Ted Wugofski
CTO Office
Openwave
+1 817 658 6195 (m)
+1 817 737 4533 (o)
ted.wugofski@openwave.com

Received on Monday, 29 September 2003 17:32:19 UTC