Re: "Mailto" Command

The quoted at the end of the page outlines a long standing issue 
regarding mailto in particular, but client-side parameter passing in
general. I will paste here a generic responce and proposal I have been
suggesting for a long time now.

===================== Standard responce to email problem =======
 Today I figure to keep from breaking older software we would have to
add
 something, but as long as we are pretending to be standard gods for a
 moment perchance one should consider parameter passing to local
 applications in general.
 
 In the future parameter passing to local utilities beyond email such as
 video conferencing will also become an issue, so some off the cuff  
 syntax not to be take too literally might be 
 
 <A HREF=mailto:user@server.com USERAPP="#sendmail">email me</A>
 <USERAPP NAME="SENDMAIL">
 <PARAM NAME="TO" VALUE="user@server.com">
 <PARAM NAME="SUBJECT" VALUE="My subject">
 <PARAM NAME="CC" VALUE="someone@otherserver.com">
 </USERAPP>
 
 The value assigned to the USERAPP attribute would refer some generic 
 functionality such as sendmail, videoconference, chat or whatever.
 The HREF would only apply to those situations in which support for
 USERAPP was not avaiable or was disabled, and would do whatever
 HREF does now.
 
 Each <PARAM> tag between <USERAPP> and </USERAPP> would represent a  
 name value pair and the client could use whatever it understood and
 ignore the rest. Nothing would be encoded in a manner that could not be
 freely entered from the keyboard and the application would also receive
 the HREF value when called.
 
 This syntax is very similar in nature to the client side imagemap hack
 and would provide a great deal of flexibility.
 
 The <A HREF> entry point to this mechanism would also have cousins in
 client side imagemaps, <FORMS> and per-chance some link to a
 content-type mechanism for good measure.
===================== End Standard responce to email problem =======

Ingo Macherius wrote:
> Dan Connolly said:
> | It's important to keep the HTML spec independent of the URL specs.
> | Note that the HTML spec doesn't mandate any list of graphics formats
> | either.
> So if this is a FAQ and an frequently requested feature, why it is not
> added to HTML in a clean way ? This can not be done following the same
> mechanism as used with <applet>:
>         <applet ...>
>                 <param ...>
>                 Text for non Java Browsers
>         </applet>
> 
> This is defining a semantic for the <applet> mixed content model, where
> element content is used by an aware application and discarded by 
> others. Character content is discarded by the aware and displayed by 
> the unaware application. The trick is having all elements EMPTY.
> 
> Similarily one could try something like this to enhance mailto: anchors
>         <a href="mailto:...">
>                 <mailheader key="Subject" VALUE="Re: ACME 
> advertisement">
>                 <mailheader key="CC"      VALUE="big@brother.com">
>                 Click here for free demo
>         </a>
> 
> But in this case the decision whether to process or discard the 
> <mailheader>
> tags *are* dependant on the URLīs protocol part. The role of mailto is
> to make <a> a *typed* anchor, something like
> 
>         <a class="mailto" href="joe@user.org">
> 
> So is it really possible to give the requested functionality without
> a dependence of URL and HTML ? A cheap way out is to add tons of new
> attributes to <a>, but is this desireable ?


-- 
   ==============================================
Unix,C++,TCP/IP,Dynamic HTML,Servers,Proxies,Agents
__ ============================================== __
\/  =      Dr. Clue (A.K.A. Ian A. Storms)     =  \/
   ==============================================
\/ HTML/CGI Guide W/ C++ Source code
http://users.abac.com/cgi-bin/drclue/F1.cgi/HTML/HTML.html

Received on Sunday, 6 April 1997 20:52:06 UTC