Subject: [Tools-team] email document delivery service

From: stanislav shalunov <[email-masked]>
Date: 01 Feb 2005 16:19:36 -0500

At present, the I-D announcements include a way to request the
document to be sent to you in its entirety via email.  The particular
way this is done never worked for me (don't know if my MIME readers --
metamail and Gnus -- are deficient or the MIME in the messages is
broken), and I never bothered to get this part working as I am
perfectly happy with an rsync copy of the RFC and I-D repositories.
However, some IETF participants seem to like this service (it might
even work for them).

Should a way to deliver documents via email be provided in whatever we
specify that will supplement/replace the current announcements system?

If so, should this email delivery mechanism be a part of the
notification service or should it be a separate email delivery
service?

It's no big deal to set up a file server with procmail recipes or
something like that, but the question is whether the notifications
have no know the interface to that service...

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Al your Qaeda are belong to US.

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: "Alex Rousskov" <[email-masked]>
Date: Thu, 03 Feb 2005 17:14:04 -0700

> have no know the interface to that service...

I think there has been at least one debate regarding the usefullness of  
email draft delivery service on the RFC Editor "interest" list(?).  
Opinions varied.

If folks who spend IETF resources on email delivery service decide to keep  
it, I would argue that it should be separate from the notification  
service. A notification message should contain a URI of the new draft  
version or other event page, as applicable. Retrieving that resource (via  
HTTP, SMTP, or any other protocol) should not be a part of the  
notification mechanism. Motivated folks can write and share a script to  
automate the retrieval, of course.

Thanks,

Alex.

P.S. My apologies if this has been discussed already. I did not see this  
topic covered in the minutes.

---

From: stanislav shalunov <[email-masked]>
Date: 03 Feb 2005 19:51:28 -0500

"Alex Rousskov" <[email-masked]> writes:

> I think there has been at least one debate regarding the usefullness
> of  email draft delivery service on the RFC Editor "interest" list(?).
> Opinions varied.

I remember these debates.  I remember that there would be some who
would claim that the service is vital to their needs.  Depending on
how all the software is set up, it might even be convenient for some.

For example, one can imagine a user who reads all (or many) draft
announcements, and then requests some of them via email.  When they
come, they get stored in a convenient place.  That place is the only
place this hypothetical person (who might not even actually exist)
uses to store internet-drafts he reads.  The person is often poorly
and sporadically connected (a road warrior who reads email on
airplanes and is connected via slow dial-up every now and then), so
rsyncing at the same time as downloading email wastes his precious
dial-up capacity (he might want to read 1% of the drafts that come
out, not 100%), and waiting until he gets to a reasonable connection
increases his draft-reading latency.

For such a person, having a separate mechanism (Agora-like, perhaps)
to request URIs via email would not do the trick if their MUA does not
make it easy to send these requests.  Unless our hypothetical person
wrote his own MUA, it's unlikely that this third-party Agora-like
service would be integrated into his MUA.  On the other hand, if the
notification service included, say, mailto: URLs to retrieve the
documents, he would likely be able to easily continue using his
current arrangements.  That means, however, that the notification
service would need to know the interface to the email delivery
service.  Since the email delivery service isn't specified anywhere,
there's an obvious difficulty.

> If folks who spend IETF resources on email delivery service decide to
> keep  it, I would argue that it should be separate from the
> notification  service.

I agree.

> A notification message should contain a URI of
> the new draft  version or other event page, as applicable. Retrieving
> that resource (via  HTTP, SMTP, or any other protocol) should not be a
> part of the  notification mechanism. Motivated folks can write and
> share a script to  automate the retrieval, of course.

But that script wouldn't be enough to replace the current scheme (if
it works for anyone): you'd also need a mechanism to easily invoke
that script on a URI in the displayed message.

> P.S. My apologies if this has been discussed already. I did not see
> this  topic covered in the minutes.

Nope, it wasn't discussed.  Thanks a lot for your input!

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra

---

From: stanislav shalunov <[email-masked]>
Date: 03 Feb 2005 19:57:41 -0500

Internet-draft announcements, as they are currently generated, include
a MIME-based mechanism to request internet-drafts via email.  Do you
use this feature?  If you do, could you please let me know?

Background: the IETF Tools team is working on a draft,
draft-ietf-tools-notification-03.txt, that specifies the requirements
for a document notification service.  We'd like to better understand
how email document delivery is actually used.

This message is designed to be viewed at room temperature.

---

From: "Alex Rousskov" <[email-masked]>
Date: Thu, 03 Feb 2005 22:23:36 -0700

> that script on a URI in the displayed message.

IMHO, URI-cut-and-paste, save-message-to-a-well-known-folder, or any  
similar URI selection mechanism would work well enough for the extreme  
cases we can come up with. Furthermore, one can imagine a wrapper service  
that adds MIME retrieval magic to standard/plain notification messages.  
However, discussing this any further would most likely re-open the endless  
debate about how many users make a given free IETF service worth  
supporting.

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 04 Feb 2005 00:36:41 -0500

"Alex Rousskov" <[email-masked]> writes:

> Furthermore, one can imagine a wrapper service that adds MIME
> retrieval magic to standard/plain notification messages.

Fair enough.

> However, discussing this any further would most likely re-open the
> endless debate about how many users make a given free IETF service
> worth supporting.

Looks like we can't possible have any users, given that the service
doesn't work.

Simplifies things...

A fool's brain digests philosophy into folly, science into superstition,
and art into pedantry.  Hence University education.       -- G. B. Shaw

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Feb 2005 04:32:46 -0500

--On Thursday, February 03, 2005 7:57 PM -0500 stanislav 
shalunov <[email-masked]> wrote:

> Internet-draft announcements, as they are currently generated,
> include a MIME-based mechanism to request internet-drafts via
> email.  Do you use this feature?  If you do, could you please
> let me know?
>
> draft-ietf-tools-notification-03.txt, that specifies the
> requirements for a document notification service.  We'd like
> to better understand how email document delivery is actually
> used.

Please be a little bit careful about how and where this question 
is asked.  Most of the active participants in the IETF have 
reasonably good, online, access to the Internet with 
cost-effective bandwidth (at least much of the time).  But there 
are people for whom those things are not the case, but who want 
to track our work and should be able to do so.  They may or may 
not read the open IETF list but, given recent volume surges, I'd 
guess most of them do not.   For them, the email access, and 
maybe even the remote-body-part access, can be important 
features -- more important, perhaps, for RFC retrieval than for 
I-D retrieval, but important nonetheless.

While I'm on the subject,

--On Friday, February 04, 2005 8:41 AM +0000 Tim Chown 
<[email-masked]> wrote:

> Hi,
>
> Our anti-virus system tags all IETF draft announcements as
> being potentially dangerous.  I suspect because of the unusual
> options to fetch the data that are encoded in the MIME header.
>
> We would certainly like to see that feature removed from IETF
> announcements,  as it seems archaic.   This may not be within
> the remit of your draft, but  you may wish to consider what
> effect various MIME options have on anti-virus  systems, and
> potential vulnerabilities that lie within them.

Hmm.  There is a case to be made that those external body part 
options are as safe, or safer, than a delivered attachment: you 
can, in principle, inspect either before opening or executing 
it, but I can easily imagine one of those "a good/fun user 
experience is more important than security or bullet-proof-ness" 
MUAs being designed to provide better access for an actual 
virus-checker for the external body parts.  Certainly an 
external body part is as safe and probably safer than an 
imbedded URL, especially in an MUA that opens those URLs 
automatically.

So my instinctive response to that request is "have you 
considered getting your anti-virus software fixed?".

     john

---

From: Tony Hansen <[email-masked]>
Date: Fri, 04 Feb 2005 13:43:56 -0500

John C Klensin wrote:
> --On Friday, February 04, 2005 8:41 AM +0000 Tim Chown wrote:
> Hmm.  There is a case to be made that those external body part options 
> are as safe, or safer, than a delivered attachment: you can, in 
> principle, inspect either before opening or executing it, but I can 
> easily imagine one of those "a good/fun user experience is more 
> important than security or bullet-proof-ness" MUAs being designed to 
> provide better access for an actual virus-checker for the external body 
> parts.  Certainly an external body part is as safe and probably safer 
> than an imbedded URL, especially in an MUA that opens those URLs 
> automatically.
> 
> So my instinctive response to that request is "have you considered 
> getting your anti-virus software fixed?".

Our firewall software here also briefly tagged message/external-body 
attachments as dangerous. Instead of just removing the attachment, the 
software deleted the entire message and sent a note saying that they had 
done so. Whoever had installed the software just didn't get it; it took 
us a bit to get them to fix it.

Even more fearful, I have a feeling that they were just following 
instructions provided by the firewall software people, who SHOULD know 
better.

	Tony Hansen