Subject: Does anyone use message/external-body?

From: "Dan Kohn" <[email-masked]>
Date: Thu, 14 Nov 2002 21:46:41 -0800

For the last several years, all I-Ds and RFCs publication announcements
have included message/external-body attachments to provide for automated
retrieval of the associated document.  This causes very little
distraction for those of us who prefer to use http or mailto URIs, while
providing useful functionality for those using the external-body MIME
type.

However, this raises a question: does *anyone* use external-body in
association with I-D announcements?  External-body was specified in RFC
1341 in 1992, 2.5 years before URIs were first specified in RFC 1738.  I
suspect that the use of external-body has been almost wholly, if not
completely, supplanted.  Of MUAs, I think that at least mh supports the
functionality, but is anyone using it?

And so I'd ask, should this

    Content-Type: Message/External-body;
	    access-type="mail-server";
          server="[email-masked]"
    
    Content-Type: text/plain
    Content-ID: <[email-masked]>
    
    ENCODING mime
    FILE /internet-drafts/draft-ietf-manet-lanmar-05.txt

Be replaced with:

<mailto:[email-masked]&body=FILE%20/internet-drafts/draft-ietf-manet-
lanmar-05.txt>

(in addition to the http URI, which is what I believe we all use
anyway).  If there are actually people using the functionality (and who
wouldn't be just as happy with a mailto URI), than I would stick with
it, as it is a minimal distraction for the rest of us.  But if it's no
longer being used, I don't think the ietf-announce list needs to be the
only one using external-body, just because it was invented here.

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>  

  Randomly generated quote:
Information is the currency of democracy.  - Thomas Jefferson

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Nov 2002 09:22:32 -0500

> I suspect that the use of external-body has been almost wholly, if not

I use mh, but I don't use message/external-body.  It's not that the feature
is a bad idea, it's that mh's user interface for it is too annoying to use.

I'd like to know what could be done to encourage other UAs to implement it,
and in a user-friendly manner.  (no, using HTML tags doesn't provide the 
same functionality)

Keith

---

From: Matt Crawford <[email-masked]>
Date: Fri, 15 Nov 2002 08:42:34 -0600

> association with I-D announcements?

I access new I-Ds and RFCs through the message/external-body subparts
of the announcement, and I sometimes send out documents of my own
(not always IETF-related) using the same mecahnism.

I hope that lays your questions to rest.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 15 Nov 2002 13:17:47 -0600

> association with I-D announcements?

Several MUAs support message/external-body, but they don't all work with
the I-D announcements. Specifically, some MUAs only render the entities if
a Content-Transfer-Encoding MIME header field is defined, and the I-Ds
don't define that MIME header field with those entities. The result is
that Netscape, Mozilla and some others don't render those links, meaning
that the message/external-body entities cannot be used by users with the
affected MUAs. This obviously limits usability.

Even though fixing the MUAs would be the best fix in the long-term, adding
the CTE MIME header field to these entities would at least allow more MUAs
to render the entities appropriately. Since this is a mandatory header
field for some entities, there is some argument that the missing CTE is
the problem anyway.

As to the larger question, I'm opposed to replacing the external links
with URLs. There are just as many known problems with rendering long URLs
as there are with message/external-body entities (eg, your example folded
and became unusable in Mozilla). Besides, the IETF should eat its own dog
food, and message/external-body is an important type. Now if we could just
make it work with some of the popular MUAs...

While we're on the topic of troublesome messages from the IETF, it's also
interesting to note that the I-D submission response messages are also
malformed, containing two different Subject header fields:

  Subject: Re: draft-ietf-crisp-lw-user-00.txt
  Subject: Autoreply from Internet Draft Submission Manager

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: John Stracke <[email-masked]>
Date: 15 Nov 2002 16:30:07 -0500

On Fri, 2002-11-15 at 14:17, Eric A. Hall wrote:
    As to the larger question, I'm opposed to replacing the external links
    with URLs. There are just as many known problems with rendering long URLs
    as there are with message/external-body entities (eg, your example folded
    and became unusable in Mozilla).
    
But you can put URLs into message/external-body (see RFC-2017).  This
would be easy for receiving MUAs to implement, since most have access to
a browser one way or another; and it would be easier for users to work
with, since people are accustomed to URLs by this point.  Some MUAs
already let you drag a link from a browser, or specify an attachment by
URL; adding the option to send it as a message/external-body instead of
inline would be a very small extra for users to learn.

-- 
/================================================================\
|John Stracke          | http://www.centivinc.com |HTML OK       |
|Principal Engineer    |=========================================|
|Centiv                |"Simply vanished--like an old oak table."|
[email-masked]|--Lord Percy, _Black Adder II_           |
\================================================================/

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Nov 2002 17:14:37 -0500

> a Content-Transfer-Encoding MIME header field is defined, 

How bizarre.  You mean those MUAs can default to 7bit for other bodyparts
but not for message/external-body?  And that multiple implementors have
made this same error?  

> field for some entities, there is some argument that the missing CTE is

The RFC is quite clear that in the absence of a content-transfer-encoding 
field it is interpreted as 7bit.  And while for some types it is a 
practical necessity (try encoding a JPEG image using only octets between
0x01-0x7f with 0x0d 0x0a pairs every 80 or so octets) as far as
the MIME standards are concerned it's not mandatory for any kind of body 
part.   Certainly it's not needed for message/external-body.

But I do think it would be an interesting experiment to add the line

content-transfer-encoding: 7bit

to the external body parts of those notices, just to see how many more 
MUAs worked with them.

Keith

---

From: [email-masked] (Paul Ebersman)
Date: Fri, 15 Nov 2002 09:32:58 -0800

moore> I use mh, but I don't use message/external-body.  It's not that
moore> the feature is a bad idea, it's that mh's user interface for it
moore> is too annoying to use.

You're using MH as your MUA and you are complaining about something
not having a user-friendly interface? B^)

MH is modular. Write your own or use a more user-friendly and modern
mailer... Don't bitch about possible new technology when you're using
software that hasn't been updated in multiple years.

For reference, I do use MH. I just don't bitch about its ugliness.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 16 Nov 2002 21:10:35 -0600

on 11/15/2002 4:14 PM Keith Moore wrote:
>> Several MUAs support message/external-body, but they don't all work
>> with the I-D announcements. Specifically, some MUAs only render the
>> entities if a Content-Transfer-Encoding MIME header field is defined,
>>
>>
>
> How bizarre.  You mean those MUAs can default to 7bit for other
> bodyparts but not for message/external-body?

That's right. They aren't applying the default CTE to the entity headers
inside the message/external-body entity.

> And that multiple implementors have made this same error?

Netscape has had this problem since 3.x, and Mozilla still has it
(presumably they are all the same code tree). I seem to remember others
having the same problem but I can't find my testing notes.

>> Even though fixing the MUAs would be the best fix in the long-term,
>> adding the CTE MIME header field to these entities would at least
>> allow more MUAs to render the entities appropriately. Since this is a
>> mandatory header field for some entities, there is some argument that
>> the missing CTE is the problem anyway.
>
> The RFC is quite clear that in the absence of a
> content-transfer-encoding field it is interpreted as 7bit.

Well, yeah, I don't disagree with the default interpretation. "Some
argument" specifically refers to those times when the docs aren't 7bit
(plenty of examples of I-Ds with 8bit text, despite the rules there too),
which eventually nests into ~it should always be declared.

> to the external body parts of those notices, just to see how many more

It makes NS/Moz usable anyway.

---

From: [email-masked]
Date: Sun, 17 Nov 2002 06:23:34 -0800 (PST)

> functionality, but is anyone using it?

I use it all the time. I use it mostly for I-D announcements, but I
also occasionally construct and send a message/external-body object myself.

				Ned

---

From: Lloyd Wood <[email-masked]>
Date: Sun, 17 Nov 2002 16:10:38 +0000 (GMT)

my own experience is that mh's user interface for mh is too annoying
to use.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Nov 2002 11:11:14 -0500

At 1:17 PM -0600 11/15/02, Eric A. Hall wrote:

>  There are just as many known problems with rendering long URLs

If people would only enclose URLs in angle-brackets, these problems 
could be avoided.

- Why do so few people use angle-brackets?
- Why do so few browsers permit you to paste URLs enclosed in angle-brackets?

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Nov 2002 11:11:19 -0500

>  <URL>

Eudora converts message/external-body to the appropriate URL on 
display.  I find this handy.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 21 Nov 2002 10:22:10 -0700 (MST)

> From: Randall Gellens <[email-masked]>

> ...

The second question answers the first for some of us.  If you want to
write text containing URLs that will be useful to as many people as
possible, you follow the spirit of standards even if that requires
ignoring their letter.

Vernon Schryver    [email-masked]