Subject: Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt

From: Hiroshi Tamura <[email-masked]>
Date: Sat, 23 Jun 2001 14:41:44 +0900 (JST)

What about this one?

At Minneapolis meeting, we agreed to go to the final stage.
In fact, there are few issues in TODO in Appendix A.
But, it seems that there are some items to be considered
in REVIEW CHECKLIST.

At first, I would like to hear the editors' comment.

Folks,
any comments are welcome.

Regards,
--
Hiroshi Tamura, Co-chair of IETF-FAX WG
E-mail: [email-masked]

---

From: Graham Klyne <[email-masked]>
Date: Sat, 23 Jun 2001 09:40:46 +0100

Tamura-san,

Thank you for raising this.  (I should first apologize for taking far 
longer to get the draft to this state than I originally said I would.)

There is one issue I would like to clarify before requesting a last call, 
namely how a congested relay can avoid exacerbating the congestion condition.

The basic idea I am contemplating is that if a relay is congested, it can 
immediately reject a message by an error response to a MAIL FROM command 
with a TIMELY option specified.  (Otherwise, a new message -- especially if 
retries are being attempted -- may simply exacerbate the congestion.)

So I am asking:

Q: does this approach seem reasonable?

Q: assuming it's reasonable, what error code to use?  (a) an existing, or 
(b) a new code?  If (a) then the choices would seem to be:
   450 Requested mail action not taken: mailbox unavailable
   451 Requested action aborted: local error in processing
   452 Requested action not taken: insufficient system storage

(I think 450 is inappropriate, as it's specific to a mailbox.)

My preference would be to define a new code, something like:
   453 Message not accepted: relay busy
RFC2821 seems to say this would be OK. But, lacking a registry for SMTP 
error codes, is this likely to prove problematic, procedurally?

I think this is a simple matter, but I would like some input from those who 
better understand the procedural realities of developing email standards.

...

Also, a separate matter as a point of information.  I am liaising with Greg 
Vaudreil, who is working on a revised versions of the extended SMTP status 
codes specification, about the new status codes introduced by this draft.

...

Finally, concerning the REVIEW CHECKLIST:  there are many items here to 
which I would draw people's attention, but in the absence of any further 
comment on these items I don't think the document needs further 
change.  The CHECKLIST is intended to draw attention to some areas where 
more careful review might be in order.

#g
--

>any comments are welcome.

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

---

From: Hiroshi Tamura <[email-masked]>
Date: Sat, 23 Jun 2001 18:58:28 +0900 (JST)

Graham,
You are also working on Saturday :-<

> Q: does this approach seem reasonable?

It's ok for me.

> (I think 450 is inappropriate, as it's specific to a mailbox.)

Yes.

>    453 Message not accepted: relay busy

I think so, too.

> error codes, is this likely to prove problematic, procedurally?

I do not know how to register it, either.

> better understand the procedural realities of developing email standards.

Yes.
Does anybody know it or any good suggestion?

> codes specification, about the new status codes introduced by this draft.

Could you specify I-D or ML or something?
The people here may be interesting in it.

> more careful review might be in order.

OK, I understand what you intend. I just wanted to confirm it.

# Next my response may be too slow.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]

---

From: Graham Klyne <[email-masked]>
Date: Sat, 23 Jun 2001 21:48:48 +0100

>The people here may be interesting in it.

Part of the I-D announcement is copied below.

#g
--

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Extensions to Mail System Status Codes
         Author(s)       : G. Vaudreuil
         Filename        : draft-vaudreuil-1983ext-00.txt
         Pages           : 5
         Date            : 21-Jun-01

This document defines an additional set of extended status codes based
on new messaging applications and associated error states since the
creation of the original RFC 1893 document.  These include extended
media conversion codes for fax and voice messaging and results for
message tracking.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vaudreuil-1983ext-00.txt

------------
Graham Klyne
([email-masked])

---

From: Hiroshi Tamura <[email-masked]>
Date: Sat, 30 Jun 2001 14:05:35 +0900 (JST)

Graham,

Thanks for your information. Also, sorry for my very slow response.

> media conversion codes for fax and voice messaging and results for

Is it being discussed in VPIM WG or just come out?
It addresses the fax related codes.

Regards,