Skip to content. | Skip to navigation

Sections
You are here: Home content generated doc.free neda Records 199902261 Presentation main Re: draft-rfced-info-banan-00.txt

Re: draft-rfced-info-banan-00.txt

Re: draft-rfced-info-banan-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-rfced-info-banan-00.txt



I apologize for the tone of my earlier message.   It was written
hastily and without proper respect.  I should have waited a while
before responding so as to better frame my argument.

I do have real concerns about the impact of this protocol on the Internet 
email system, should it be widely deployed.  

I understand the utility in publishing EMSD as a "point-of-record"
if it is widely deployed - so people can build tools that interoperate
with deployed devices.  So if you can convince us that widely deployed
devices are already using this protocol, that would weigh heavily 
in IESG's decision to recommend (or not) that your document be published.  
Even so, I feel certain that IESG would want to add a note to the 
document describing limitations of the approach and perhaps even 
recommending against implementing it in new devices.  Frankly, without 
such justification, I'd rather not take the time to do the thorough review 
that it would take to write up such a note, because that time would be 
better spent designing a new protocol.  

Such a protocol needs to give very careful consideration to not only 
packet/bandwidth efficiency, but also to implementation complexity 
(which has a profound effect on code quality and therefore operational
reliability).  Also, experience over many years indicates that mail 
gateways are a primary source of operational failures, and that such 
failures are notoriously difficult to diagnose and fix due to the lack 
of proper trace information.  If there's going to be a new Internet 
mail submission/relay/delivery protocol, the relationship between 
the new protocol and Internet Mail also needs to be carefully defined 
as part of the protocol design.  This will ensure that such gateways 
work as well as possible, minimizing the operational difficulties.

I believe that such design work would best be done in an IETF working
group, where we have a large community with substantial expertise in 
Internet email.    These people also have a significant interest in
making sure that the gateway issues are sorted out, since they will
be the ones who have to implement and operate the gateways that talk 
between MIME/SMTP and the new protocol.

Keith


Replies
Re: draft-rfced-info-banan-00.txt, Mohsen BANAN
Main Index | Thread Index
Document Actions
Libre/Halaal Internet Services Provided At LibreCenter By Neda

Member of By* Federation Of Autonomous Libre Services

This web site has been created based exclusively on the use of Halaal Software and Halaal Internet Application Services. It is part of the By* Federation of Autonomous Libre Services which in turn are part of the Halaal/Libre By* Digitial Ecosystem which incorporate the following software components: