Publication of EMSD as an Informational RFC

[Mohsen BANAN <mohsen@neda.com>]

More than 7 weeks ago, on October 23, 1998 I submitted
a protocol specification titled:

	Efficient Mail Submission and Delivery (EMSD) Protocol

   ftp://ftp.ietf.org/internet-drafts/draft-rfced-info-banan-00.txt

to the RFC-Editor for timely publication as an
Informational RFC.


As of now, more than 7 weeks since the initial
submission, the specification has not been published
yet. The RFC Editor has not even responded to my request
for providing a time frame in which we can expect to see
the EMSD protocol published as an Informational RFC.


Such seemingly unjustified and unexplained delays by the
RFC Editor are completely unacceptable.


It is the responsibility of the RFC Editor to determine
the suitability of non-ietf non-standards track
documents in a *timely* manner.

The RFC Editor has had more than adequate time to review
the EMSD specification and convey to us any concerns
with respect to suitability for publication. The RFC
Editor has expressed none.  In the case of EMSD protocol
for the reasons that I have enumerated before, the
suitability of the specification is obvious.

Yet, as it was the case with the publication of
RFC-2188, the RFC Editor seems to have again simply
stopped progress towards publication and is awaiting
instructions from the IESG. 

If indeed that is again the case, then something is
terribly wrong.


The last response we received from the RFC Editor was:

>>>>> On Tue, 24 Nov 98 12:39:40 PST, rfc-ed@ISI.EDU said:

  RFC-Editor> Thank you for your additional message.  Since it is important to obtain
  RFC-Editor> the IESG's feedback, we have noted their deferred request.  We defer
  RFC-Editor> making a decision until the IESG has had a chance to comment.  We would
  RFC-Editor> be happy to chat further about this in Orlando.

As I have said before, the IESG has had more than an
adequate chance to comment on this specification.

The initial two week timeout expired on November 17,
1998. Since then, the IESG has had an additional 4 weeks
to comment.

Further as the RFC Editor must know, according to
Sections 4.2.2 and 4.2.3 of RFC-2026, the purpose and
scope of the IESG review is well defined and limited to
identification of over lap and conflict between EMSD and
the work of IETF groups. Such a determination by the
IESG must be done within a reasonable period of time
(Section 4.2.3).  Such a determination can be done very
quickly.

Furthermore, some IESG members have already said that
they want to produce protocols that compete with
EMSD. Therefore, the IESG appears to have the incentive
of delaying publication of EMSD as an Informational
RFC. It has also already been publicly stated that from
the IESG's perspective review of non IETF working group
documents (such as EMSD) are of a low priority to IESG.


In view of the above, an independent and strong RFC
Editor is expected to prevent the IESG from delaying
publication of non-IETF non-standards track documents.
However, as it was the case with the publication of
RFC-2188, the RFC Editor appears to be simply awaiting
orders and instructions from the IESG.


If in fact the RFC Editor is not adequately equipped
with knowledge and experience to do what the procedures
of RFC-2026 demands of the RFC Editor, then please let
that be known.


If in fact the RFC Editor is only providing the
equivalent of secretarial services to IESG/IETF and the
real decision in publication of non-IETF non-standards
track documents is made by the IESG, then please let
that be known.



The key questions here are the same ones that I asked 
nearly 2 years ago with respect to the publication of
RFC-2188.


  o What do "reasonable period of time" and "timely"
    mean to the RFC Editor and the IESG?

  o What does the IESG and the RFC Editor think the
    scope and purpose of IESG review of the non IETF
    non standard track RFCs are?

  o What is the RFC Editor expected to do when the IESG
    does not review the document in a reasonable period
    of time?


These questions remain unanswered.


I consider anything more than 7 weeks, *not timely*.

Related to my complaint about the publication of
RFC-2188,

>>>>> On Sun, 8 Nov 1998 10:22:21 -0800, "Marshall Rose"
 >>>>> <mrose.netnews@lists.dbc.mtview.ca.us> said:

  Marshall> 2. ... however, the fault i assign to the "power
  Marshall> conspiracy" in the IETF is simple: they should have told you "yes" or "no"
  Marshall> sooner, like within 6 weeks. if they'd said "no", well, you'd have a
  Marshall> different complaint, but it wouldn't be for lack of timeliness.

  Marshall> 3. publication of rfcs is upto the rfc editor, with the caveat that on
  Marshall> matters that deal with ongoing on near-term IETF standardization matters,
  Marshall> the IESG gets to advise. ...


others suggested 6 weeks as a reasonable time.




Publication of the EMSD Protocol is in the best interest
of the Internet technical community for reasons which
include:


  - Protocols specifically designed for submission and
    final delivery of mail are needed in today's
    Internet mail environment. EMSD is one such protocol
    which can work with and also compete with other such
    protocols. Wide publication of such a protocol is a
    good thing.


  - Protocols which focus on "Efficiency" of Mail 
    Submission and Delivery  in the wireless
    environment are needed.  Two-Way Paging over
    Wireless-IP is a natural and expected evolution
    of paging networks. EMSD can serve as a basis for
    Two-Way Paging over Wireless-IP.

    Existing Internet protocols do not deal with
    efficiency properly. Wide publication of an application
    protocol which emphasizes efficiency is a
    good thing.


  - Examples of application protocols which use 
    Efficient Short Remote Operations (ESRO) -- 
    which has already been published as RFC-2188 -- are
    of use to those interested in using ESRO. EMSD is
    one such application of ESRO.


  - EMSD protocol specification has been verified in a
    number of ways.  EMSD and ESRO
    specifications under the titles of:
	"Limited Size Messaging" (used with the CDPD Network)
    and 
	"pACT" (used with AT&T's Narrowband PCS Network)

    have gone through a great deal of review by a large
    number of engineers.

 - Independent implementations based on earlier releases of
   EMSD and ESRO specifications have been made by 
   Neda (server and client), PCSI (client), Aldiscon
   (server), Sema Group UK (server). The independent 
   implementations have interoperated successfully.


  - The rationale for design decisions of EMSD are
    documented in Appendix C of the spec. Whether or not
    these are "good" or "bad" design decisions are mostly
    a matter of opinion at this time. Test of time and
    usage will decide that. EMSD spec will server as a 
    point of record and a point of reference for that
    purpose.



Since publication of the EMSD Protocol is in the best
interest of the Internet technical community and since
it is the responsibility of the RFC Editor to publish
such information, I expect that the RFC Editor will not
allow further delays and censorship of the EMSD
specification.



Having waited 7 weeks since the initial submission of
the EMSD specification, I respectfully request that the
RFC Editor publish the EMSD Protocol as an Informational
RFC without any further delays.


Respectfully Yours,


Mohsen Banan.