<USERAPP> suggestive parameter passing for clients

Many people have frequently asked how to pass client side applications
suggestive parameters from their HTML pages, such as in the instance of 
mailto: where many would like to suggest a SUBJECT.

 Netscape added a hack of the form 
mailto:user@server.com?subject="some%20subject"
This solution causes mail delivery problems and violates some specs.

 Others adopted a utilizing TITLE="some subject", but this is of limited 
value.
 
 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 suggestive parameter passing to 
client side applications in general.

 In the future parameter passing to local utilities beyond email 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="SUBJECT"	VALUE="My subject">
<PARAM NAME="CC"	VALUE="someone@otherserver.com">
<PARAM NAME="COLS"	VALUE="40">
</USERAPP>
 
 The value assigned to the USERAPP attribute would refer by name 
to the <USERAPP> tag set mentioned later in the page.

 The HREF would as always refer to a resource on the net.
clients must fullfill their currently specified function per their 
respective RFCs in the absence of USERAPP. USERAPP simply 
offers suggestions to client applications that are intended to allow
enhancement and clarification of the interaction in a suggestive manner.
client apps are free to ignore or modify any or all of the suggestive 
parameters.
 
 The USERAPP syntax is in no way intended to replace or subvert
the purpose of a URL, but rather is a seperate suggestive conversation
between the page author and the client application.

 Each tag between <USERAPP> and </USERAPP> would represent a parameter
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 apply this 
informational in relation to the URL value involved.
 
 The <A HREF> entry point to this mechanisim could also have cousins in
client side imagemaps, <FORMS> and other situations in which a client  
side application could benefit from suggestive parameters.

 Although the USERAPP spec would not define any of these name/value
pairs
it would provide some suggested guidelines that the vendors of client  
applications wishing to employ USERAPP support should use as a basis for 
pragmaticly selecting parameter names. 

 The following guidelines should be used in the order of their 
appearance.

 If an existing HTML attribute would accurately convey the meaning
of the parameter then the client should respond to that name in
obtaining the suggestive parameter. 

 If no HTML attribute properly conveys meaning, but the application in
the course of it's compliance with specifications would use or generate
a header that corresponds to a suggestive parameter, it should respond
to a name/value pair with the same name as that header.

 If there is a commonly accepted label used to describe a field in a
client application where a user provides information, this label
should be used.  

 A well conceived, brief and clear title which could be intuitivly used
by page authors.

 Nothing in this specification should prohibit multiple aliases for a
given parameter, but the last mentioned and recognized name for that
parameter should be the controlling value.

 This syntax is very similar in nature to the CSIM syntax and would   
provide a great deal of flexibility.

 This USERAPP suggestive parameter system has been developed over time
and has involved extensive email conversations with many individuals.
It's submission here is to provide an oppurtunity to further refine  
the proposed specification.

-- 
   ==============================================
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 Monday, 3 March 1997 21:41:54 UTC