Re: IETF Draft on mmsto:

1. If you want a "mailto" in which the content is specified but the 
destination is not specified, you would write:
	mailto:?subject=foo
Therefore, if you wanted an MMS message created, rather than an email 
message created, you would write:
	mmsto:?subject=foo
So, if this what you want, I can make that use case clearer in the text.

2. I fully share your concern about "mms:".  The "mms:" URI scheme is 
there to support services that do not want user interaction.  For 
example, a game that wants to send an MMS back to the game server in 
order to activate a new level.   This is just one example, but one that 
is real in the SMS world today.  I also have someone who called me about 
how to use "mms:" on the MM4 interface -- where one MMS relay/proxy 
identifies another MMS relay/proxy.  So, I think its still valid.  At 
issue is if the "mms:" is used by a rogue application or rogue 
content.... which is something I should make clear in the security 
consideration.

Thanks,
Ted


Bennett.Marks@nokia.com wrote:

> 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:02:05 UTC