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

Of course.  I was trying to critique the way Bennett apparently planned to
use it ("making a resource forwardable via MMS," as opposed to "making
someone contactable via MMS"---compare, for the mailto scheme, "making some
text sendable via e-mail" vs. "making someone contactable via e-mail").
However, on a second thought, nevermind.  It's not very important, as I'm
sure everybody will just use their best judgement and everything will turn
out alright in the end.

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

By this logic, there should be two separate http schemes:  one for end users
and one for web services.  Right?  Why can't the mobile device in your game
example simply provide two API functions:  "SendMms" and "OpenMmsComposer"?
I think this would be much less confusing than I guess having a
"InterpretUri" function that would either send a message directly or open up
a composer, depending on the URI itself.


--
Daniel Brockman
daniel@brockman.nu

----- Original Message ----- 
From: "Ted Wugofski" <ted.wugofski@openwave.com>
To: "Daniel Brockman" <daniel@brockman.nu>
Cc: <Bennett.Marks@nokia.com>; <uri@w3.org>
Sent: Monday, September 29, 2003 11:29 PM
Subject: 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 Tuesday, 30 September 2003 02:13:08 UTC