headers
Pete Resnick | 4 Jan 1996 23:54

Comment period closed on draft-resnick-text-enriched-02.txt

This is just to let folks know that we are no longer taking comments on the
new text/enriched draft. I have sent a final copy of the draft to
internet-drafts which now has a complete references and acknowledgements
section, but no other changes. If there are any typographical problems that
you find before it goes on to RFC publication, please let me know.

Thanks to everyone for their input.

pr

--
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated
Home: (217)337-1905 / Fax: (217)337-1980
Permalink | Reply | 0 comments |
headers
Dr. Mark K. Joseph | 8 Jan 1996 20:23

mailto URLs

I would like to propose the following change to RFC1738, Uniform Resource
Locators (URL), (p.12):

3.5 MAILTO

    The mailto URL scheme can be used to designate part or all of an
internet mail message.  As
a minimum the mailto URL must designate the internet mail address of an
individual or service.
However, other mail message components such as a subject and a simple
message body can also be
specified.

A mailto URL takes the form:

    mailto:<rfc822-addr-spec>[# (*msg_element | subject)]
    ; '#' separates the minimum form from all mailto messsage elements

    msg_element     = (to_element | cc_element | subject_element |
body_element | x_element) [*msg_element]

    subject         = *text
    to_element      = "TO="<rfc822-addr-spec>
    cc_element      = "CC="<rfc822-addr-spec>
    subject_element = "SUBJECT="*text
    body_element    = "BODY="*text
    x_element       = "X-"<element name>"="<defined by extension type>    ;
local extension

    (Where body is a text string to be placed as the message body.  This
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 26 Jan 1996 15:38
Picon
Picon

I-D ACTION:draft-ietf-822ext-mime-conf-04.txt

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Internet Message Extensions 
Working Group of the IETF.                                                 

       Title     : Multipurpose Internet Mail Extensions (MIME) Part Five: 
                   Conformance Criteria and Examples                       
       Author(s) : N. Borenstein, N. Freed
       Filename  : draft-ietf-822ext-mime-conf-04.txt
       Pages     : 28
       Date      : 01/25/1996

STD 11, RFC 822, defines a message representation protocol specifying 
considerable detail about US-ASCII message headers, and leaves the message 
content, or message body, as flat US-ASCII text.  This set of documents, 
collectively called the Multipurpose Internet Mail Extensions, or MIME, 
redefines the format of messages to allow for    

 (1)   textual message bodies in character sets other than US-ASCII,        
 (2)   non-textual message bodies, 
 (3)   multi-part message bodies, and     
 (4)   textual header information in character sets other than US-ASCII.  

These documents are based on earlier work documented in RFC 934, STD 11, 
and RFC 1049, but extends and revises them. Because RFC 822 said so little 
about message bodies, these documents are largely orthogonal to (rather 
than a revision of) RFC 822.                                               

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prabhat Keni | 29 Jan 1996 19:25
Picon

Re: RE[2]: mailto URLs


Mike Braca <mb <at> ebt.com> writes:

> Hmmm, I just found out that Netscape is sending the headers through as a
> query, with '?'.  I dislike that also, but not as much as '#'. At least
> '?' has a history of being mangled.

> mailto:mb <at> ebt.com?SUBJECT=foo;CC=bar

Following is what Netscape does today.  Its similar in spirit to the
proposal which started this discussion with the following differences:

        o covers more headers.
	o Parses mailbox instead of addr-spec, so one could specify
          full names in addition to bare addresses.
        o Multiple addresses are allowed.
        o There's no mechanism to specify body.  Although, it'd be nice to
          be able to do that.

Quote from an internal email from a colleague:

> The syntax goes something like
> 
>  URL     :=  'mailto:' [ ADDRS ] [ HEADERS ]
>  ADDRS   :=  [ ADDR [ ',' ADDR ]* ]
>  ADDR    :=  <RFC822 address, hex-encoded if necessary>
>  HEADERS :=  '?' HNAME '=' HVALUE [ '&' HNAME '=' HVALUE ]
>  HNAME   :=  <a mail header name; currently we only support those
>               headers which you can edit in a mail composition window,
>               but it would be sensible to allow other headers as well
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald.T.Alvestrand | 30 Jan 1996 10:00
Picon
Picon

Re: RE[2]: mailto URLs

Note also that if you revise Mailto:, the ADs will want to have answered
the questions that were raised on Mailserver:, including:

- How to ensure a proper From: address
  (this is about THE most common question from mail admins these days;
  the keyword is Netscape 2.0)
- How to (request to) apply signature functions to the message
- How to make sure the user is aware of what he is doing
  (or is getting done in his name)

See http://domen.uninett.no/~hta/ietf/http-traps.html for some
examples of how to get mail sent from unsuspecting clients.

                 Harald A
Permalink | Reply | 0 comments |
headers
Jamie Zawinski | 30 Jan 1996 12:36
Picon

Re: RE[2]: mailto URLs

Harald.T.Alvestrand <at> uninett.no wrote:
> 
> Note also that if you revise Mailto:, the ADs will want to have answered
> the questions that were raised on Mailserver:, including:
> 
> - How to ensure a proper From: address
>   (this is about THE most common question from mail admins these days;
>   the keyword is Netscape 2.0)

I think the keyword you're thinking of is Netscape 1.1; in 2.0, we
complain if the user's return address doesn't contain an " <at> " followed
by at least one ".".  Which I think is the best we can do and have it
still work on systems that do address resolution in funny ways (for
example, on YP/NIS systems, or heavily firewalled systems, where you
don't have access to MX records at all.)

> - How to (request to) apply signature functions to the message
> - How to make sure the user is aware of what he is doing
>   (or is getting done in his name)

In the case of mailto: URLs opened with GET, this is no problem, since
all this does is bring up a message composition window, with certain
fields initialized; the user then has the ability to edit and review
what's going to happen, and any pre-delivery processing that would
normally occur would occur in this case as well.

In the case of mailto: URLs opened with POST (which sends the message
directly), perhaps there should be some confirmation before sending the
mail; I think there is only one difference between this type of POST and
POSTs to all other URLs, and that is the inclusion of the "From:"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane