mailto: attaching subject
Lee Brown
I have a list of items on my web page. There is an order number
associated with each item. Im using mailto: link on each item number.
Can anyone tell me how to attach the order number to the subject field
in a mail message?
please email to llb...@awod.com
Thanks,
Lee Brown
Warren Steel
Lee Brown wrote:
> I have a list of items on my web page. There is an order number
> associated with each item. Im using mailto: link on each item number.
> Can anyone tell me how to attach the order number to the subject field
> in a mail message?
There is no universally reliable way to do this. Some
browsers will send the value of the TITLE= attribute as the
subject of mail:
<A HREF="mailto:us...@site.com" TITLE="order number 345">
Another relatively harmless way to indicate the subject is
to include it in the address itself--the information will be
transmitted in the To: header, not the Subject: header:
<A HREF="mailto:user.site.com (order 345)">
Neither of these methods will hinder the mail being sent.
Some browsers can use a third method, but this involves an
illegal URL, and will result in failure to send mail at all
from many browsers; so I won't suggest this method.
--HTML Baboon
Warren Steel mu...@olemiss.edu
Department of Music University of Mississippi
URL: http://www.mcsr.olemiss.edu/~mudws/
Tim McCarthy
Warren Steel <mu...@mail.olemiss.edu> wrote in article
<3236BA...@mail.olemiss.edu>...
[snip]
>
> Another relatively harmless way to indicate the subject is
> to include it in the address itself--the information will be
> transmitted in the To: header, not the Subject: header:
> <A HREF="mailto:user.site.com (order 345)">
>
> Neither of these methods will hinder the mail being sent.
> Some browsers can use a third method, but this involves an
> illegal URL, and will result in failure to send mail at all
> from many browsers; so I won't suggest this method.
>
This doesn't work on my system. The address is improperly formed. There is
no valid address with the "(order 345)" appended. The mail program spits
this out as invalid.
Q: What does the ISP mail program do with this address?
--
Tim McCarthy
pop...@tiac.net
Warren Steel
MegaZone wrote:
> Note that Warren meant: <A HREF="mailto:us...@site.domain (order 345)">
> He had a '.' instead of the '@'
Thanks, MZ. I sure did.
--
MegaZone
"Tim McCarthy" <pop...@tiac.net> shaped the electrons to say:
>This doesn't work on my system. The address is improperly formed. There is
>no valid address with the "(order 345)" appended. The mail program spits
>this out as invalid.
Note that Warren meant: <A HREF="mailto:us...@site.domain (order 345)">
He had a '.' instead of the '@'
-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 mega...@livingston.com
For support requests: sup...@livingston.com <http://www.livingston.com/>
Snail mail: 6920 Koll Center Parkway #220, Pleasanton, CA 94566
See me in person: Internet Expo, Boston, MA, October 16-17, Booth 422 ;-)
Arjun Ray
In <01bba036$a608e6e0$Loca...@popeye.tiac.net>, "Tim McCarthy"
<pop...@tiac.net> writes:
| Warren Steel <mu...@mail.olemiss.edu> wrote in article
| <3236BA...@mail.olemiss.edu>...
| [snip]
| >
| > Another relatively harmless way to indicate the subject is
| > to include it in the address itself--the information will be
| > transmitted in the To: header, not the Subject: header:
| > <A HREF="mailto:user.site.com (order 345)">
| This doesn't work on my system. The address is improperly formed.
| There is no valid address with the "(order 345)" appended. The mail
| program spits this out as invalid.
The address is correctly formed. Please see RFC 822, Section 3.1.4
"Structured Field Bodies", where parentheses are identified as
delimiters for comments, to be ignored by any program parsing the
field for information.
Your mail program is *fundamentally* broken.
Cheers,
ar
Tim McCarthy
Arjun Ray <ar...@nmds.com> wrote in article
<517ndo$i...@client2.news.psi.net>...
Not that I can see. Maybe I misread this.
---
RFC 822 Section 3.1.4
[end of section example]
So, for example, the folded body of an address field
":sysmail"@ Some-Group. Some-Org,
Muhammed.(I am the greatest) Ali @(the)Vegas.WBA
is analyzed into the following lexical symbols and types:
:sysmail quoted string
@ special
Some-Group atom
. special
Some-Org atom
, special
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atom
The canonical representations for the data in these addresses are the
following strings:
":sysmail"@Some-Group.Some-Org
and
Muhamm...@Vegas.WBA
---
We have: user.site.com (order 345)
This should resolve to: user.site.com
This is invalid.
But I also note the following:
---
3.4.2. WHITE SPACE
Note: In structured field bodies, multiple linear space ASCII
characters (namely HTABs and SPACEs) are treated as
single spaces and may freely surround any symbol. In
all header fields, the only place in which at least one
LWSP-char is REQUIRED is at the beginning of continua-
tion lines in a folded field.
When passing text to processes that do not interpret text
according to this standard (e.g., mail protocol servers), then
NO linear-white-space characters should occur between a period
(".") or at-sign ("@") and a <word>. Exactly ONE SPACE should
be used in place of arbitrary linear-white-space and comment
sequences.
---
So comments can/are stripped and replaced with a single space. The next
section clarifies this even further.
---
3.4.3. COMMENTS
A comment is a set of ASCII characters, which is enclosed in
matching parentheses and which is not within a quoted-string
The comment construct permits message originators to add text
which will be useful for human readers, but which will be
ignored by the formal semantics. Comments should be retained
while the message is subject to interpretation according to
this standard. However, comments must NOT be included in
other cases, such as during protocol exchanges with mail
servers.
---
I read this as saying any header comments are to be stripped out and
replaced with a single space. When used to resolve a address they play no
part and are ignored. When used to transmit the data they are replaced with
a space or removed and are not sent to the mail server.
AFAIK, the address is invalid and the mail program is correct in spitting
it back out. But even had the address been properly formed "us...@site.com
(order 345)" the message received by the mail server would have no comment.
--
Tim McCarthy
pop...@tiac.net
Warren Steel
I wrote:
> ... Another relatively harmless way to indicate the subject is
> to include it in the address itself--the information will be
> transmitted in the To: header, not the Subject: header: <A HREF="mailto:user.site.com (order 345)">
Tim wrote:
>This doesn't work on my system. The address is improperly formed.
>There is no valid address with the "(order 345)" appended. The mail
>program spits this out as invalid.
Arjun Ray wrote:
> The address is correctly formed. Please see RFC 822, Section 3.1.4
> "Structured Field Bodies", where parentheses are identified as
> delimiters for comments, to be ignored by any program parsing the
> field for information.
Arjun, the address in my example was simply mistyped, with
<A HREF="mailto:user.site.com (order 345)"> instead of the correct
<A HREF="mailto:us...@site.com (order 345)">
The comment method is OK, but the address itself was broken,
and Tim used it as a template for a test, and got the bounce
message. I'm replying to the list to make this clear--it was
my error.
--HTML Baboon
Gary Klass
Is there a way to attach text?
e.g. UNSUBSCRIBE Listname
Tim Harris
I haven't had any problems or heard of any with this setup.
Could be wrong thou.
My web site:
http://www.oregoncitylink.com
html at bottom of my page:
<A HREF=
"mailto:city...@teleport.com (Administration, Oregon CityLink)">
Send us mail</A>
This is what my To: field looks like in Eurdora when I get mail:
To: "Administration, Oregon CityLink" <city...@teleport.com>
Tim McCarthy
> I wrote:
> > ... Another relatively harmless way to indicate the subject is
> > to include it in the address itself--the information will be
> > transmitted in the To: header, not the Subject: header: <A
HREF="mailto:user.site.com (order 345)">
>
> Tim wrote:
> >This doesn't work on my system. The address is improperly formed.
> >There is no valid address with the "(order 345)" appended. The mail
> >program spits this out as invalid.
>
> Arjun Ray wrote:
> > The address is correctly formed. Please see RFC 822, Section 3.1.4
> > "Structured Field Bodies", where parentheses are identified as
> > delimiters for comments, to be ignored by any program parsing the
> > field for information.
>
> Arjun, the address in my example was simply mistyped, with
> <A HREF="mailto:user.site.com (order 345)"> instead of the correct
> <A HREF="mailto:us...@site.com (order 345)">
>
> The comment method is OK, but the address itself was broken,
> and Tim used it as a template for a test, and got the bounce
> message. I'm replying to the list to make this clear--it was
> my error.
>
Yeah, this seems to work. I just tested this message on my system and I get
the comment in the address field. It's a little different than the one Tim
Harris gets, though.
pop...@tiac.net (This is a comment) produces itself exactly on my system.
So my interpretation of RFC 822 comment doesn't appear to be true, although
I can't understand how else you interpret that line, "However, comments
must NOT be included in other cases, such as during protocol
exchanges with mail servers." Sure sounds like the comment is supposed to
be stripped. Obviously not true, though. Must be that it is internal to the
message transfer.
--
Tim McCarthy
pop...@tiac.net
Ian Burrell
In article <517ndo$i...@client2.news.psi.net>, Arjun Ray <ar...@nmds.com> wrote:
>| > <A HREF="mailto:user.site.com (order 345)">
>
>"Structured Field Bodies", where parentheses are identified as
>delimiters for comments, to be ignored by any program parsing the
>field for information.
>
The address isn't corectly formed (assuming the URL you meant is
"mailto:us...@site.com (order 345)"). Everything after the @ is not a
valid domain by RFC 822, section 6.1. RFC 1738 makes pretty clear
that what follows the mailto: is a single RFC822/SMTP compliant
addr-spec.
>Your mail program is *fundamentally* broken.
>
Nope. In RFC 1738 in section 3.5:
A mailto URL takes the form:
mailto:<rfc822-addr-spec>
where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
specified in RFC 822 [6]. Within mailto URLs, there are no reserved
characters.
Now rfc822-addr-spec is not a structured field body. It is a single
email address. The stuff before the ampersand, the local-part, can
contain almost anything ("My Name"@site.com is a valid email
address). But it isn't an RFC822 header and can't contain multiple
addresses, comments, route specification, and all the other stuff that
is possible in structured field bodies.
Most browsers are operate such that the URL data have comments and
processing is done before sending. I suspect that what most browsers
do is make a message with the header "To: <stuff after rfc822>", so an
address that follows the RFC822 header specification is valid.
However, a browser would be following the specs if it used the address
in the SMTP envelope destination with no processing, died with an
error of "invalid address", or used it somewhere else where a standard
email address is expected.
Perhaps the URL specification should be changed so that mailto: has a
list of RFC822 addresses that could be placed directly into the mail
header. Instead, there probably should be another method for sending
mail to multiple people, specifying the subject, and writing other
headers.
- Ian
--
-- Ian Burrell == ibur...@leland.stanford.edu **
<URL:http://www-leland.stanford.edu/~iburrell/>
Kitman's Law: Pure drivel tends to drive out ordinary drivel.
Pete Ruckelshaus
Lee Brown <llb...@awod.com> wrote in article <3236B1...@awod.com>...
> I have a list of items on my web page. There is an order number
> associated with each item. Im using mailto: link on each item number.
> Can anyone tell me how to attach the order number to the subject field
> in a mail message?
>
> please email to llb...@awod.com
>
> Thanks,
>
> Lee Brown
>
<a href="mailto:j...@blow.com?subject=MailJoeBlow">blah blah</a>
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <01bba0d7$80c30d60$Loca...@popeye.tiac.net>,
"Tim McCarthy" <pop...@tiac.net> wrote:
> pop...@tiac.net (This is a comment) produces itself exactly on my system.
>
> So my interpretation of RFC 822 comment doesn't appear to be true, although
> I can't understand how else you interpret that line, "However, comments
> must NOT be included in other cases, such as during protocol
> exchanges with mail servers."
As I read that paragraph, it's supposed to be left in the *message*
that the human reader will see, but programs processing the mail
should strip those when using the address. If you're familiar with
SMTP, when you send RCPT TO you must only specify an address, but
the DATA part may contain a To field with the complete address
and comments.
Irrelevant side-note: Netscape goes nuts over a comment of
(Arnoud "Galactus" Engelfriet)
So far I've seen To lines with up to ten levels of escaped quotes.
Galactus
- --
E-mail: gala...@htmlhelp.com .................... PGP Key: 512/63B0E665
Maintainer of WDG's HTML reference: <http://www.htmlhelp.com/reference/>
-----END PGP SIGNED MESSAGE-----
Arjun Ray
I wrote:
|> Please see RFC 822, Section 3.1.4 "Structured Field Bodies", where
|> parentheses are identified as delimiters for comments, to be
|> ignored by any program parsing the field for information.
In <3237FE...@mail.olemiss.edu>, Warren Steel
<mu...@mail.olemiss.edu> writes:
| Arjun, the address in my example was simply mistyped, with
| <A HREF="mailto:user.site.com (order 345)"> instead of the correct
| <A HREF="mailto:us...@site.com (order 345)">
|
| The comment method is OK, but the address itself was broken,
| and Tim used it as a template for a test, and got the bounce
| message. I'm replying to the list to make this clear--it was
| my error.
My error too, since I missed that typo. As a result, I interpreted
[Tim McCarthy]
= There is no valid address with the "(order 345)" appended. The mail
= program spits this out as invalid.
to mean that the mail program had simply failed to parse the comment,
in which case it would truly have been broken. My apologies to Tim for
having misunderstood his report.
However, on reconsideration, I still think a mail program isn't really
providing useful feedback if it registers a generic objection to the
input in its entirety. Consider the difference between
[Invalid address: user.site.com (order 345)] and
[Invalid address: user.site.com]
I would consider the first complaint misleading.
Tim's and Ian Burrell's followups raise other issues relevant to this
potential parsing problem. RFC 1738 requires the specific portion of a
mailto: URL to be an encoded RFC822 address specification. (That, BTW,
is a "huh?" because RFC 822 has no such animal: there are addr specs,
but no "encoded" addr specs.) Now, this could and generally does mean
that the lexical substitution 'mailto:' --> 'To: ' should yield a RFC
822 compliant header field, but certainly the converse is not true. In
fact, RFC 822 distinguishes between an "address" which is a structured
field -- allowing complex forms of addressing -- and an "address
specification" which is a "mailbox" only -- a single address, as Ian
points out. But comments are allowed as part of a single address (as
in the example Tim quotes from RFC 822), so Warren's example corrected
should "work".
Yet, in saying that it should "work", there is the distinct issue of a
delivery mechanism. In particular, a RFC 822 'To: ' header field
should *not* be used as is in SMTP (RFC 821) transfers: the RCPT verb
has a different set of requirements. e.g., multiple addresses (as
could be in a 'To:' header) have to be split out into separate RCPT
commands. Also, parentheses are "special" characters in SMTP and can't
appear outside quoted strings.
To me, putting all of this together means: a user-agent intending to
use SMTP to act on a mailto URL, will need a RFC 821 compliant address
for the RCPT verb, and thus will need to *parse* a RFC 822 address
specification for the relevant (single) address.
There's one final gotcha.
[Tim McCarthy]
= But even had the address been properly formed "us...@site.com
= (order 345)" the message received by the mail server would have no
= comment.
Yes and no. The address used in RCPT verb would have no comment (the
mail server would be within its rights to reject this with a 55x
response), but any 'To: ' header field in the *contents* of the
message -- transfered via the DATA verb -- can be retained intact.
This is in fact the secret of the comment hack under discussion:-)
Cheers,
ar
Tim McCarthy
[snip good stuff]
<Aside>
I didn't take any offense here. I thought your comment was valid. (There's
that word again!)
It made me check the spec again and that's always time well spent.
There's always more I don't know than I do.
Sometimes I forget.
Sometimes I don't understand something.
My system isn't the only system nor is it the best system. Same for my
opinion.
</Aside>
>
> However, on reconsideration, I still think a mail program isn't really
> providing useful feedback if it registers a generic objection to the
> input in its entirety. Consider the difference between
>
> [Invalid address: user.site.com (order 345)] and
> [Invalid address: user.site.com]
>
> I would consider the first complaint misleading.
To me, this is one of those lose-lose situations in programming. You are
reporting an error to a wide audience. The non-technical user looks for
clues based upon what he wrote. The technical user looks for precision.
Trying to satisfy both is difficult at best Also, the situation is one that
many programmers identify as a "bail-out" state where the program should
"gracefully shut down."
I think it's a toss-up, but in general, I agree with you that the second is
the better alternative.
[snip more technical information]
Your other points here are well taken.
My hope is that all this technical discussion points out to users of this
method just how fragile this mechanism is. Maybe "fragile" isn't the most
appropriate word here, but I want to convey the idea that using mailto: for
the purpose of transmitting data from a HTML page is the less attractive
method. Use CGI. This is what it is for. If you are going to the trouble of
creating a HTML page then CGI is something you really want to know.
>
> There's one final gotcha.
>
> [Tim McCarthy]
> = But even had the address been properly formed "us...@site.com
> = (order 345)" the message received by the mail server would have no
> = comment.
>
> Yes and no. The address used in RCPT verb would have no comment (the
> mail server would be within its rights to reject this with a 55x
> response), but any 'To: ' header field in the *contents* of the
> message -- transfered via the DATA verb -- can be retained intact.
> This is in fact the secret of the comment hack under discussion:-)
>
Your right. I tested this and it works on my system as well.
--
Tim McCarthy
pop...@tiac.net
Arjun Ray
[ posted and emailed ]
In <01bba03e$be0f2260$a352...@wanda.pond.com.pond.com>,
"Pete Ruckelshaus" <mud...@pond.com> offers the bogus "solution"
other respondents perhaps should not have declined to mention:
| <a href="mailto:j...@blow.com?subject=MailJoeBlow">blah blah</a>
Homework Assignment:
1. Read RFC 1738 for the specification of the 'mailto:' URL.
2. Read RFC 822 for the constraints on an address specification.
3. Then explain, in the light of RTFM, why your suggestion is
*supposed* to work.
Flunking grade automatically awarded for:
"It works on my browser!"
Cheers,
ar
Mark Kempster
Tim McCarthy wrote:
<snip>
> My hope is that all this technical discussion points out to users of this
> method just how fragile this mechanism is. Maybe "fragile" isn't the most
> appropriate word here, but I want to convey the idea that using mailto: for
> the purpose of transmitting data from a HTML page is the less attractive
> method. Use CGI. This is what it is for. If you are going to the trouble of
> creating a HTML page then CGI is something you really want to know.
>
> Tim McCarthy
> pop...@tiac.net
I agree that transmitting data via a mailto: is not the most elegant of methods,
but is cgi really the only viable working alternative? I'm trying to figure out
a non-cgi method to send nicely formatted form data to an email without posting
the form results to a cgi. Java isn't working (exactly as I want); HTML won't do
it "just so", either.
While cgi seems to be the current best bet, with more clients using bigger and better
machines, it seems reasonable to utilize some of their resources rather than send
everything back to a cgi.
Regarding the original post, I'm wondering about feeding the mailto: more than To:,
Cc: and Subject:. Is there any way to send it the body? And if so, is it possible
to send the message behind the scenes and avoid the mail screen ever popping up?
I'm going for the following scenario: (1)Form that gets all important sending data, plus
data to be included in message. (2)Client user pushes "submit". (3)Client computer
constructs mail message using own mailing resources and sends mail on its way without
showing a mail window to the user.
Thanks for comments.
Mark Kempster
John Switzer
Well, let's see - since HTML 3.x isn't officially out yet and since
many browsers are adding their own extensions that are either in the
still changing HTML 3.x spec or totally brand new, I think we can conclude
that the "official specs" are not the definitive last word on what can
and cannot work on a browser. We are currently in a "browser-led"
development on the web and it's a given that whenever the specs do reflect
what is being done out there, it'll only be because the developers have
slowed down and the market is consolidating (and not because everyone
suddenly decided that following outdated specs is a "good thing").
Extra demerits to everyone who thinks we should be using only HTML 1.0
until "the spec" arrives.
--
John Switzer | Wanted - systems engineer who can design a complex
| computer system to control a theme park. System
| MUST automatically boot up to full functionality
jswi...@aimnet.com | upon power-on. Contact Jurassic Park.
Tim McCarthy
Mark Kempster <md...@axe.humboldt.edu> wrote in article
<323D74...@axe.humboldt.edu>...
I recommend CGI because it is the more *reliable* method; the more
controllable method; the more commonly available method.
To me, the central issue is to get feedback from those who visit your site.
That feedback comes in a number of different forms.
mailto: is for user comments/mail. These are free format, say what you
think, want, like, hate, etc.. I would not try to automate this in any way.
You need to be able to read this type of feedback and deal with it. By
using the mail program on the users system your are accessing a familiar
tool, one that the user is most comfortable with. Use the mail program for
what it is and can do, which is mainly allow the user to compose a message,
not you.
Another type of feedback is forms. These are more structured and can be
handled in a more formal manner. You are collecting specific information,
user names, orders, item names, credit card numbers, street and town
addresses, etc. This information is important to *you* and you want to
insure that you get it *and* don't waste the users time collecting it. You
want it to be as painless as possible.
Your investment is in the time and effort you spend to make this data
collection page attractive and functional. The care you show here is
readily apparent to the user. An attractive page that fails to send mail,
which intrudes on the users system, brings up a mail program and then
causes a problem is more than likely a total loss of your investment.
What is nice here is that this operation is so common that you can more
than likely get a CGI script from your ISP. There is a benefit to them to
do this. Instead of having every user run a script that does much of the
same thing, they can control the process to a degree by providing a script
that runs properly on the system and which satisfies most, if not all, user
needs.
Also, since this is such a common operation, you don't have to work very
much harder than you did to learn HTML to get one to run. This is *exactly*
how I got my first one to work. Ask for help from your ISP, another user,
etc. You can use a cookie cutter approach and the result will be a method
that will *always* work, gets exactly what you want, and intrudes on the
user system very little. Once it is complete, then you can concentrate your
effort on processing the data *and completely forget about how it was
collected.* Browsers change and the spec may change. Hell, even perl can
change. But your script will run, and run, and run. It's is almost, run
once, run always.
Enough of my ranting.
You can always use this method. Wrong or right, and regardless of what T.
McCarthy thinks, as long as you are aware of what you are doing and what
your risks are, then you are on solid ground. You will recognize problems
and know how to go about resolving them.
The other question was filling out the fields for mailto: and also the
body. The former is a Netscape extension and I think the field names are
specified as TITLE or SUBJECT and CC. Check the spec or the Netscape
documents or maybe someone else knows the answer here. I hesitate to say
because, well, I don't use this method. <g> As for the body, I don't
believe there is such a attribute. But mailto: is currently under review so
that may change.
The form scenario you give is what I use in my CGI script. I construct a
mail message to myself and build it up as I desire. It gets sent to me
using my server mail program and then I create a "cookie" HTML page on the
fly that tells the user "Thank you, thank you, thank you and come back real
soon because I really like seeing you and your lovely
wife/husband/friend/dog/gerbil." The user just sees my message page. No
mail program. And of course, there is the problem that there is a time
delay, but it is pretty short IMO, so I mostly avoid the issue of "Press,
press, press that submit button."
--
Tim McCarthy
pop...@tiac.net
Arjun Ray
In <51ksof$k...@shell1.aimnet.com>,
jswi...@aimnet.com (John Switzer) writes:
| In article <51im69$6...@client2.news.psi.net>,
| Arjun Ray <ar...@nmds.com> wrote:
| >Flunking grade automatically awarded for:
| > "It works on my browser!"
| Well, let's see - since HTML 3.x isn't officially out yet
What's "officially"?
| and since many browsers are adding their own extensions
Correction: some browser vendors are emotionally committed to kludges.
| that are either in the still changing HTML 3.x spec
Published specs have version numbers and publication dates. What's
"changing"? *Un*published specs? What's in them?
| or totally brand new
Mistakes can be totally brand new. Especially monumentally stupid
ones.
| I think we can conclude that the "official specs" are not the
| definitive last word on what can and cannot work on a browser.
No browser is required to follow published specs -- let alone open
standards. Assignment #3 reads:
|> 3. Then explain, in the light of RTFM, why your suggestion is
|> *supposed* to work.
What *can* or *cannot* work on *a* browser is simply anecdotal
evidence. The issue here is what *should* or *could* work on *any*
browser. Please propose an answer reliably better than expectations
based on published specs.
| We are currently in a "browser-led" development on the web
Development? Retardation is the better term. But that's only in
relation to what the public is being gulled into accepting as
"advanced" technology.
| and it's a given that whenever the specs do reflect what is being
| done out there, it'll only be because the developers have slowed
| down and the market is consolidating (and not because everyone
| suddenly decided that following outdated specs is a "good thing").
Please read RFC 1602. You seem to be under the comfortable delusion
that there'll always be specs for what developers do: that the
developers can merrily develop away, and leave it to spec-ers to catch
up with specs because that's their job or duty or somesuch.
| Extra demerits to everyone who thinks we should be using only
| HTML 1.0 until "the spec" arrives.
Grade: D. Grace points for effort after misreading the assignment.
Cheers,
ar
Warren Steel
"Pete Ruckelshaus" <mud...@pond.com> offers the bogus "solution"
other respondents perhaps should not have declined to mention:
> <a href="mailto:j...@blow.com?subject=MailJoeBlow">blah blah</a>
*Much* earlier in this thread, I suggested two mailto:
links that (1) *will* send mail from all browsers, and (2)
will convey the intended subject on some browsers. As I
said at the time, I deliberately declined to mention the
solution you give above, because it will *fail to send mail
at all* on a substantial number of browsers, because of the
malformed URL and address.
Arjun Ray poses a Homework Assignment:
>1. Read RFC 1738 for the specification of the 'mailto:' URL.
>2. Read RFC 822 for the constraints on an address specification.
>3. Then explain, in the light of RTFM, why your suggestion is
> *supposed* to work.
>Flunking grade automatically awarded for:
> "It works on my browser!"
At which John Switzer replied irritably:
> Well, let's see - since HTML 3.x isn't officially out yet and since
> many browsers are adding their own extensions that are either in the
> still changing HTML 3.x spec or totally brand new, I think we can conclude
> that the "official specs" are not the definitive last word on what can
> and cannot work on a browser.
The original poster wanted a reliable solution. I omitted the
solution that I *know* to be unreliable. Arjun suggested *why*
it's unreliable. Your reply only shows that you don't like this
reality, and that you misunderstand the concept of "official
specs" on the Internet.
> We are currently in a "browser-led"
> development on the web and it's a given that whenever the specs do reflect
> what is being done out there, it'll only be because the developers have
> slowed down and the market is consolidating (and not because everyone
> suddenly decided that following outdated specs is a "good thing").
Perhaps you don't realize who's catching up to whom. Style
sheets are referred to in HTML 2.0, and have been deployed for
years, giving forward-looking authors and viewers the pleasures
of fonts, colors, and white space, long before Netscape introduced
crude and ineffective hacks to do the same thing, and long
before Microsoft finally implemented style sheets in IE 3.0.
Browsers have not led the development, they've obstructed it
at every turn.
> Extra demerits to everyone who thinks we should be using only HTML 1.0
> until "the spec" arrives.
Extra demerits to those who confirm their misunderstanding
by ignoring HTML 2.0 (RFC 1866) which is as close to a "standard
spec" as the Internet affords, and which "allows" two valid ways
of indicating the subject of a mailto: link.
<A HREF="mailto:us...@site.com" TITLE="your page"> and
<A HREF="mailto:us...@site.com (your page)">
(in the latter version, subject is shown as part of the
To: field.) Not every browser will send the subject with
these methods, but every properly configured browser
*will send mail,* which I assume is of greater importance.
--
J. Kivi Shapiro
In article <32382B...@rs6000.cmp.ilstu.edu>,
No.
- K.
--
ksha...@julian.uwo.ca or ki...@pobox.com (Kivi Shapiro)
Disclaimer: Why would I disclaim anything? It's all true!
Alan J. Flavell
On 16 Sep 1996, John Switzer wrote:
> In article <51im69$6...@client2.news.psi.net>, Arjun Ray <ar...@nmds.com> wrote:
> >2. Read RFC 822 for the constraints on an address specification.
> >3. Then explain, in the light of RTFM, why your suggestion is
> > *supposed* to work.
> >
> >Flunking grade automatically awarded for:
> > "It works on my browser!"
>
> Well, let's see - since HTML 3.x isn't officially out yet and since
> many browsers are adding their own extensions that are either in the
> still changing HTML 3.x spec or totally brand new, I think we can conclude
> that the "official specs" are not the definitive last word
Since the issue under discussion is a URL, and URLs are opaque as far as
HTML is concerned, the status of the current HTML specs and drafts is
irrelevant.
Try again.
Arjun referred you to the operative RFCs. I suppose it was asking
too much.
> Extra demerits to everyone who thinks we should be using only HTML 1.0
> until "the spec" arrives.
Extra demerits to anyone who devises a scheme that turns an otherwise
valid URL into something that doesn't work anymore on a standards-
compliant browser. Vendors love that sort of thing, because it gives
them an entirely spurious "competitive advantage". You as a customer
should be able to see through that kind of trick.
--
best regards
" 'cause this is real life, under-rehearsed, no proper tunes..." (V.Wood)
Tim McCarthy
Pete Ruckelshaus <mud...@pond.com> wrote in article
<01bba03e$be0f2260$a352...@wanda.pond.com.pond.com>...
Arjun jumps on this.
I will just comment.
We *just* finished going through this topic.
I don't understand this. It wears out the little gray cells.
I now have a small inkling of what Abigail must feel like.
I don't like trolls.
Rubbish or JavaScript.
Rubbish or JavaScript.
RubbaScript.
Javarish.
Jubbarish.
--
Tim McCarthy
pop...@tiac.net
"This is the public Internet. The general public Internet."
Warren Steel
Tim McCarthy wrote:
> > <a href="mailto:j...@blow.com?subject=MailJoeBlow">blah blah</a>
> Arjun jumps on this...
> We *just* finished going through this topic.
> I don't understand this. It wears out the little gray cells.
Perhaps I can explain what you can't understand. Say you,
Tim, are "Joe Blow," soliciting e-mail responses to something
on your web site. Frank Smith replies, using the mailto:
link given above. Frank Smith is using NCSA Mosaic, or
some browser other than Netscape 1.1+ or Lynx 2.5+. His
mail never reaches you, because of its malformed address.
Frank is never notified that his mail didn't go out, and
you don't know that he ever sent it. You lost a customer,
or advice, or a friend.
It's all a matter of priorities. The other methods (of
sending the subject in a mailto: link) do not promise to
send the subject in all cases, but they promise to deliver
the mail! The method above fails to do even that, in a
significant number of cases, and there is no fall-back.
Arjun is right to caution users before they make their
choice.
Alan J. Flavell
On 18 Sep 1996, Tim McCarthy wrote:
> We *just* finished going through this topic.
..
> I now have a small inkling of what Abigail must feel like.
Welcome to usenet ;-}
A bizarre combination of perfect memory (dejanews remembers all the
things I wish I had never said) and immediate forgetfulness ("how can
I get a 10 character indent with HTML").
> I don't like trolls.
Trolls are, at least, the result of a conscious decision.
Many postings on this group don't seem to have that quality.
Mumble...
Tim McCarthy
> Tim McCarthy wrote:
>
> > > <a href="mailto:j...@blow.com?subject=MailJoeBlow">blah blah</a>
>
> > Arjun jumps on this...
>
> Perhaps I can explain what you can't understand. Say you,
> Tim, are "Joe Blow," soliciting e-mail responses to something
> on your web site. Frank Smith replies, using the mailto:
> link given above. Frank Smith is using NCSA Mosaic, or
> some browser other than Netscape 1.1+ or Lynx 2.5+. His
> mail never reaches you, because of its malformed address.
> Frank is never notified that his mail didn't go out, and
> you don't know that he ever sent it. You lost a customer,
> or advice, or a friend.
>
> It's all a matter of priorities. The other methods (of
> sending the subject in a mailto: link) do not promise to
> send the subject in all cases, but they promise to deliver
> the mail! The method above fails to do even that, in a
> significant number of cases, and there is no fall-back.
> Arjun is right to caution users before they make their
> choice.
>
<sigh>
I thought this was what was said.
I thought this is what I said.
We agree. Completely. Totally.
This issue was discussed. The problem was recognized.
I don't understand how it was missed.
Unless This was a troll. A deliberate attempt to inflame and misinform.
--
Tim McCarthy
pop...@tiac.net
Warren Steel
I said:
[detailed explanation of why the suggested
<a href="mailto:j...@blow.com?subject=MailJoeBlow">blah blah</a> ]
is dangerously unreliable on the Web]
> It's all a matter of priorities. The other methods (of
> sending the subject in a mailto: link) do not promise to
> send the subject in all cases, but they promise to deliver
> the mail! The method above fails to do even that, in a
> significant number of cases, and there is no fall-back.
> Arjun is right to caution users before they make their
> choice.
Tim McCarthy wrote:
> <sigh>
> I thought this was what was said.
> I thought this is what I said.
> We agree. Completely. Totally.
> This issue was discussed. The problem was recognized.
> I don't understand how it was missed.
> Unless This was a troll. A deliberate attempt to inflame and misinform.
Now I see that you were irritated at the posting of the bogus
solution, not at Arjun's explanation. Based on experience here,
though, I'd say that neither the endlessly repeated questions
*nor* the repeated bogus answers are trolls. Repeated questions
come from those who don't know about FAQ files or are too lazy
to use them. Repeated bogus answers come from ... misinformed
persons. Those who post detailed and factual answers, and
supply pointers to FAQs and standards, are known in this
newsgroup as "baboons" and "hyenas." A troll is another
creature altogether. ;)