V3.0 Of the tickertape notification format specification - attachments and a suggested addition...

[I-Wanicki, Martin]

Dear all,

The recent discussion  about the Attachment field and mime types 
brought about (in my mind) an scenario/alternative/addition (take 
your pick) that may seem reasonable to Tickertape developers.

The use of the attachment field at this point in time seems to 
be predominately for passing url's around.
After some research I have come to the conclusion the url's have 
a completely encapsulated specification 
( http://www.ietf.org/rfc/rfc1738.txt ) that need not be wrapped 
in yet another specification (i.e. mime) 

The url protocol seems to function without mime perfectly well 
and as such I propose the addition of an optional attribute for 
the purpose of passing url's. 
A possible name for this might just be Url: or Hyperlink: or 
whatever name on which a reasonable consensus can be reached.

Regarding backward compatibility issues, the old MIME_ARGS 
attribute *may* be considered equivalent since it has been 
predominately used for url's.
The old (v2) supporting mime fields (MIME_TYPE and MIME_ENCODING) 
could reasonably be ignored or perhaps MIME_TYPE
could be inspected to see if the MIME_ARGS are likely to contain 
a url.

I'm not sure how other O.S's handle protocols but Microsoft Windows 
O.S's have clearly defined methods to handle existing protocols and 
introduce new handlers for new protocols 
(
http://msdn.microsoft.com/workshop/networking/pluggable/overview/appendix_a.
asp?frame=true )


All of this would seem to reduce unnecessary re-encapsulation of 
url's within a mime document and also facilitate content based 
routing on url's.

The only issue I can foresee that this proposal raises is that 
of multiple url's and what to do about supporting them in this 
scenario.

Perhaps support for multiple url's should be moved to the mime 
attachment or perhaps we define the Url field as containing either 
one or more url's with a caveat on separation (i.e. at most one url 
per line of text)



Regards,


Martin