remove old msgtrk I-D

10 files changed, 0 insertions, 4678 deletions

diff --git a/doc/devel/I-D/draft-ietf-msgtrk-model-00.txt b/doc/devel/I-D/draft-ietf-msgtrk-model-00.txt
deleted file mode 100644
index 7a8b3285..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-model-00.txt
+++ /dev/null
@@ -1,444 +0,0 @@
-Internet Draft						       T. Hansen
-draft-ietf-msgtrk-model-00.txt			       AT&T Laboratories
-Valid for six months						  K. Lin
-					   Lotus Development Corporation
-						       September 8, 1999
-
-
-
-			 Message Tracking Model
-
-		    <draft-ietf-msgtrk-model-00.txt>
-
-			 Authors' version: 1.6
-
-     Status of this Memo
-
-     This document is an Internet-Draft	and is in full conformance  with
-all provisions of Section 10 of	RFC2026.
-
-     Internet-Drafts are working documents of the  Internet  Engineering
-Task  Force  (IETF), its areas,	and its	working	groups.	 Note that other
-groups may also	distribute working documents as	Internet-Drafts.
-
-     Internet-Drafts are draft documents valid	for  a	maximum	 of  six
-months	and may	be updated, replaced, or obsoleted by other documents at
-any time.  It is  inappropriate	 to  use  Internet-Drafts  as  reference
-material or to cite them other than as "work in	progress."
-
-     The  list	of  current   Internet-Drafts	can   be   accessed   at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft	Shadow Directories can	be  accessed  at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed	on  the	 MSGTRK	 working
-group mailing list, ietf-msgtrk[-request]@imc.org.
-
-Copyright Notice
-
-     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can	I  track
-the messages?  Message tracking	is the ability to find out the path that
-a particular message has  taken	 through  a  messaging	system	and  the
-current	 routing status	of that	message.  This document	provides a model
-of message tracking that can be	used for understanding the Internet-wide
-
-
-
-Hansen,Lin						        [Page 1]
-
-Internet Draft		 Message Tracking Model	       September 8, 1999
-
-
-message	 infrastructure	 and  to  further  enhance those capabilities to
-include	message	tracking.
-
-1.  Problem Statement
-
-     Consider sending a	package	through	 a  package  delivery  companys.
-Once you've sent a package, you	would like to be able to find out if the
-package	has been delivered or  not,  and  if  not,  where  that	 package
-currently  is and what its status is.  Note that the status of a package
-may not	include	whether	it was delivered to its	addressee, but just  the
-destination.   Many  package carriers provide such services today, often
-via a web interface.
-
-     Message tracking extends that capability to the Internet-wide  mes-
-sage  infrastructure,  analogous to the	service	provided by package car-
-riers:	the ability to quickly locate where a message (package)	is,  and
-to  determine whether or not the message (package) has been delivered to
-its final destination.	An Internet-standard  approach	will  allow  the
-development  of	 message  tracking  applications  that	can operate in a
-multi-vendor messaging environment, and	will encourage the operation  of
-the function across administrative boundaries.
-
-2.  Definitions
-The following terms are	relevant to message tracking.  The terms  Track-
-ing  User  Agent and Tracking Server are new, while all	other terms have
-been collected here from other sources.
-
-     Originating Mail User Agent (MUA)
-	       The originating mail user agent is the software	used  to
-	       compose and originate a message.	 It is the software sit-
-	       ting on a person's desktop.
-
-     Originating Mail Submission Agent (MSA)
-	       The Mail	Submission Agent accepts a message from	 a  User
-	       Agent,  adds or modifies	whatever headers are appropriate
-	       for the message's traversal  through  the  Internet,  and
-	       injects	the  message  into  the	 network  via  a Message
-	       Transfer	Agent.	(The UA	and MSA	are often combined  into
-	       the same	program.)
-
-     Message Transfer Agent (MTA)
-	       A Message Transfer Agent	accepts	a message and  moves  it
-	       forward towards its destination.	 That destination may be
-	       local or	reached	via another MTA.  It  may  use	a  local
-	       queue   to  store  the  message	before	transferring  it
-	       further.	 Any MTA may generate a	 Non-Delivery  Notifica-
-	       tion.
-
-
-
-
-Hansen,Lin						        [Page 2]
-
-Internet Draft		 Message Tracking Model	       September 8, 1999
-
-
-     Intermediate Message Transfer Agent (MTA)
-	       An Intermediate MTA is an MTA that accepts a message  for
-	       transfer	somewhere else.
-
-     Final Message Transfer Agent (MTA)
-	       A Final MTA is an MTA that accepts a  message  for  local
-	       delivery.   It  is  the	final  place  that  a message is
-	       accepted.  The final  MTA  is  what  sends  any	Delivery
-	       Status Notificatons (DSNs).
-
-     Foreign Message Transfer Agent
-	       A foreign MTA provides delivery of messages  using  other
-	       protocols than those specified for Internet mail, such as
-	       an X.400	mail system.
-
-     Gateway Message Transfer Agent (GW-MTA)
-	       A gateway MTA accepts a message for transfer to a foreign
-	       MTA outside of the Internet protocol space.
-
-     Local Delivery Agent (DA)
-	       The local Delivery Agent	 delivers  the	message	 to  the
-	       local  message store.  (The MTA and DA are often	combined
-	       into the	same program.)
-
-     Delivery Status Notification (DSN)
-	       A Delivery Status Notification [RFC-DSN]	is  produced  by
-	       an MTA when a message is	unsuccessfully delivered, either
-	       to its next hop or the final message store, or when it is
-	       successfully  delivered,	 either	to a foreign MTA or to a
-	       local delivery agent.  Positive	notifications  are  only
-	       performed [RFC-ESMTP-DSN] when specifically requested.
-
-     Non-Delivery Notification (NDN)
-	       A non-delivery notification is  a  special  form	 of  DSN
-	       indicating unsuccessful delivery.
-
-     Message Disposition Notification (MDN)
-	       A Message Disposition Notification is used to report  the
-	       disposition  of	a message after	it has been successfully
-	       delivered to a recipient.
-
-     Tracking User Agent (TUA)
-	       A tracking user agent wants to find information on a mes-
-	       sage  on	 the  behalf  of a user.  It is	the requestor or
-	       initiator of such a request.  (The MUA and TUA  could  be
-	       combined	into the same program.)
-
-     Tracking Server
-
-
-
-Hansen,Lin						        [Page 3]
-
-Internet Draft		 Message Tracking Model	       September 8, 1999
-
-
-	       A tracking server  provides  tracking  information  to  a
-	       tracking	client.	 It is the repository of the information
-	       about a message for the traversal  through  a  particular
-	       MTA.   (The  tracking  server and MTA may run on	the same
-	       system.)
-
-3.  Entities
-
-     The entities  involved  in	 message  tracking  are:   message  user
-agents,	 message  submission  agents,  message transfer	agents,	tracking
-user agents and	tracking servers.
-
-4.  Interaction	Models
-
-     There are several models by which messages	can be tracked,	 and  by
-which information can be requested and gathered.
-
-4.1.  Pre-Hoc Model
-
-     The pre-hoc model,	also known as the "passive or "ask now"	 models,
-requires  the  user agent to put into the message envelope an indication
-that some form of tracking is to be performed.	The tracking information
-can  be	 sent  back  immediately  (as a	form of	telemetry) or stored for
-later retrieval.
-
-     Forms of tracking information that	could potentially  be  requested
-are  as	 follow.   Note	that mechanisms	already	exist for requesting the
-information marked with	a (+).	The references for such	 mechanisms  are
-listed at the end of each such entry.
-
-     **	  send a DSN of	a message arriving at an intermediate MTA
-
-     **	  (+) send a DSN of a message being rejected while at an  inter-
-	  mediate MTA [RFC-DSN]
-
-     **	  (+) send a DSN of a message leaving an  intermediate	MTA  and
-	  going	to another MTA [RFC-DELIVERY-BY]
-
-     **	  send a DSN of	a message arriving at a	final MTA
-
-     **	  (+) send a DSN of a message being rejected while  at	a  final
-	  MTA [RFC-DSN]
-
-     **	  (+) send a DSN of a message being delivered to a  user's  mes-
-	  sage store [RFC-DSN]
-
-     **	  (+) send a DSN of a message being delivered to a  foreign  MTA
-	  [RFC-DSN]
-
-
-
-Hansen,Lin						        [Page 4]
-
-Internet Draft		 Message Tracking Model	       September 8, 1999
-
-
-     **	  (+) send an MDN of a message being read by an	end  user  [RFC-
-	  MDN]
-
-     **	  indicate that	logging	of the	message's  traversal  should  be
-	  performed for	later retrieval
-
-     **	  indicate that	logging	of the	message's  traversal  should  be
-	  sent to a 3rd	party
-
-4.2.  Post-Hoc Model
-
-     The post-hoc model, also known as the "query" or "ask later" model,
-requires an active query by a user's user agent	to either the intermedi-
-ate MTAs and final MTA,	or to a	 third	party,	to  find  the  message's
-status	as  known  by  that MTA.  The responses	might be something like:
-the message  has  been	queued	for  later  delivery,  the  message  was
-delivered  locally, the	message	was delivered to another MTA, ask a dif-
-ferent tracking	server,	I know but can't tell you, or I	don't know.  The
-post-hoc  model	 may  or  may not require an earlier pre-hoc declaration
-that logging of	the message's traversal	should	occur.	 (Note	that  no
-mechanisms currently exist for requesting such information.)
-
-4.3.  Hybrid Models
-
-     A number of hybrid	 models	 exist.	  In  a	 hybrid	 model,	 pre-hoc
-mechanisms are combined	with post-hoc mechanisms to provide a total mes-
-sage tracking  solution.   The	model  would  include  existing	 pre-hoc
-mechanisms,  possible  new  pre-hoc  mechanisms,  and new mechanisms for
-post-hoc tracking.  A UA may be	required to start the process by  estab-
-lishing	pre-hoc	information which is then communicated with the	MTAs.  A
-tracking user agent would then use all possible	information  sources  to
-answer the question of "what happened to message XX"?
-
-5.  Security
-
-     The security aspects of message tracking revolve around the follow-
-ing areas:
-
-     **	  Who is permitted to request tracking information?
-
-     **	  How does a tracking user agent prove that they  are  permitted
-	  to request such information?
-
-     **	  How does the tracking	user agent identify the	 messages  being
-	  tracked?
-
-
-
-
-
-
-Hansen,Lin						        [Page 5]
-
-Internet Draft		 Message Tracking Model	       September 8, 1999
-
-
-5.1.  Who is Permitted to Request Tracking Information?
-
-     Only the originators of messages are allowed to  track  their  mes-
-sages.	An originator may delegate this	responsibility to a third party.
-
-5.2.  How Does a Tracking User Agent Prove that	They  are  Permitted  to
-Request	Such Information?
-
-     One possible mechanism to prove that a tracking request  comes  the
-originator  is for the originator to calculate a one-way hash A	from the
-message	ID + time stamp	+ a per-user secret.  The user	then  calculates
-another	 one-way hash B	to be the hash of A.  The user includes	B in the
-submitted message, and retains A.  Later, when the user	makes a	 message
-tracking  request to the messaging system or tracking entity, it submits
-A in the tracking request.  The	entity receiving  the  tracking	 request
-then  uses  A to calculate B, since it was already provided B, verifying
-that the requestor is authentic.  In summary,
-
-     A = H(message ID +	time stamp + secret)
-
-     B = H(A)
-
-This is	similar	in technique to	the methods used for One-Time  Passwords
-[RFC-OTP].
-
-     If	the originator of a message were to delegate his or her	tracking
-request	 to a third party by sending them A, this would	be vulnerable to
-snooping over unencrypted sessions.  The user can decide on  a	message-
-by-message basis if this risk is acceptable.
-
-5.3.  How does the tracking  user  agent  identify  the	 messages  being
-tracked?
-
-     Every  [RFC-822]-compliant	 message  is  supposed	to   contain   a
-Message-Id header.  This header	could be used to be the	primary	means of
-message	identification.
-
-6.  References
-
-
-     [RFC-DSN] Moore, K., and G. Vaudreuil, "An	Extensible Message  For-
-	       mat for Delivery	Status Notifications", RFC 1894, Univer-
-	       sity of Tennessee, Octel	Network	Services, January 1996.
-
-     [RFC-ESMTP-DSN]
-	       Moore, K., "SMTP	Service	Extension  for	Delivery  Status
-	       Notifications",	RFC 1891, University of	Tennessee, Janu-
-	       ary 1996.
-
-
-
-Hansen,Lin						        [Page 6]
-
-Internet Draft		 Message Tracking Model	       September 8, 1999
-
-
-     [RFC-SMTP]Postel, J., "Simple Mail	Transfer Protocol", STD	10,  RFC
-	       821, USC/Information Sciences Institute,	August 1982.
-
-     [RFC-822] Crocker,	D., "Standard for the Format  of  ARPA	Internet
-	       Text Messages", STD 11, RFC 822,	UDEL, August 1982.
-
-     [RFC-MDN] Fajman, R., "An Extensible  Message  Format  for	 Message
-	       Disposition Notifications", RFC 2298, National Institutes
-	       of Health, March	1998.
-
-     [RFC-DELIVER-BY]
-	       Newman, D., "Deliver By SMTP Service  Extension",  draft-
-	       newman-deliver-02.txt, Innosoft,	January	1999.
-
-     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw,	M., "A	One-Time
-	       Password	System", RFC 2289, Bellcore, Kaman Sciences Cor-
-	       poration, Nesser	& Nesser Consulting, Bellcore,	February
-	       1998.
-
-7.  Acknowledgements
-
-     This document is the product of input from	 many  people  and  many
-sources.   It owes much	to earlier work	by Gordon Jones, Bruce Ernst and
-Greg Vaudreuil.
-
-8.  Authors' Addresses
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1 732 576-3207
-     E-Mail: tony@att.com
-
-     Ken Lin
-     Lotus Development Corporation
-     640 Lee Road
-     Wayne, PA 19087
-
-     Phone: +1 610 251-3380
-     E-Mail: ken_lin@lotus.com
-
-9.  Full Copyright Statement
-
-     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
-
-     This document and translations of it may be copied	and furnished to
-others,	 and derivative	works that comment on or otherwise explain it or
-
-
-
-Hansen,Lin						        [Page 7]
-
-Internet Draft		 Message Tracking Model	       September 8, 1999
-
-
-assist in its implmentation may	be prepared, copied, published and  dis-
-tributed, in whole or in part, without restriction of any kind,	provided
-that the above copyright notice	and this paragraph are included	 on  all
-such copies and	derivative works.  However, this document itself may not
-be modified in any way,	such as	by  removing  the  copyright  notice  or
-references  to	the  Internet  Society	or other Internet organisations,
-except as needed for the purpose of  developing	 Internet  standards  in
-which  case  the procedures for	copyrights defined in the Internet Stan-
-dards process must be followed,	or as  required	 to  translate	it  into
-languages other	than English.
-
-     The limited permissions granted above are perpetual and will not be
-revoked	by the Internet	Society	or its successors or assigns.
-
-     This document and the information contained herein	is  provided  on
-an  "AS	 IS" basis and THE INTERNET SOCIETY AND	THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR	IMPLIED,  INCLUDING  BUT
-NOT  LIMITED TO	ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS	OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY  OR
-FITNESS	FOR A PARTICULAR PURPOSE.
-
-     This document expires March 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen,Lin						        [Page 8]
diff --git a/doc/devel/I-D/draft-ietf-msgtrk-model-01.txt b/doc/devel/I-D/draft-ietf-msgtrk-model-01.txt
deleted file mode 100644
index c7c32d24..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-model-01.txt
+++ /dev/null
@@ -1,562 +0,0 @@
-
-
-
-
-
-
-Internet Draft						       T. Hansen
-draft-ietf-msgtrk-model-01.txt			       AT&T Laboratories
-Valid for six months						  K. Lin
-					   Lotus Development Corporation
-							  March	10, 2000
-
-
-
-		Message	Tracking Model and Requirements
-
-		    <draft-ietf-msgtrk-model-01.txt>
-
-			 Authors' version: 1.11
-
-     Status of this Memo
-
-     This document is an Internet-Draft	and is in full conformance with
-all provisions of Section 10 of	RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also	distribute working documents as	Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of	six
-months and may be updated, replaced, or	obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in	progress."
-
-     The list of current Internet-Drafts can be	accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft	Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed	on the MSGTRK working
-group mailing list, ietf-msgtrk[-request]@imc.org.
-
-Copyright Notice
-
-     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can	I track
-the messages?  Message tracking	is the ability to find out the path that
-a particular message has taken through a messaging system and the
-current	routing	status of that message.	 This document provides	a model
-of message tracking that can be	used for understanding the Internet-wide
-
-
-
-Hansen,Lin						        [Page 1]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-message	infrastructure and to further enhance those capabilities to
-include	message	tracking, as well as requirements for proposed message
-tracking solutions.
-
-1.  Problem Statement
-
-     Consider sending a	package	through	a package delivery company.
-Once you've sent a package, you	would like to be able to find out if the
-package	has been delivered or not, and if not, where that package
-currently is and what its status is.  Note that	the status of a	package
-may not	include	whether	it was delivered to its	addressee, but just the
-destination.  Many package carriers provide such services today, often
-via a web interface.
-
-     Message tracking extends that capability to the Internet-wide mes-
-sage infrastructure, analogous to the service provided by package car-
-riers:	the ability to quickly locate where a message (package)	is, and
-to determine whether or	not the	message	(package) has been delivered to
-its final destination.	An Internet-standard approach will allow the
-development of message tracking	applications that can operate in a
-multi-vendor messaging environment, and	will encourage the operation of
-the function across administrative boundaries.
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT",	"RECOMMENDED",	"MAY", and "OPTIONAL" in this
-document are to	be interpreted as described in RFC 2119	[RFC-KEYWORDS].
-
-2.  Definitions
-The following terms are	relevant to message tracking.  The terms Track-
-ing User Agent and Tracking Server are new, while all other terms have
-been collected here from other sources.
-
-     Originating Mail User Agent (MUA)
-	       The originating mail user agent is the software used to
-	       compose and originate a message.	 It is the software sit-
-	       ting on a person's desktop.
-
-     Originating Mail Submission Agent (MSA)
-	       The Mail	Submission Agent accepts a message from	a User
-	       Agent, adds or modifies whatever	headers	are appropriate
-	       for the message's traversal through the Internet, and
-	       injects the message into	the network via	a Message
-	       Transfer	Agent.	(The UA	and MSA	are often combined into
-	       the same	program.)
-
-     Message Transfer Agent (MTA)
-	       A Message Transfer Agent	accepts	a message and moves it
-	       forward towards its destination.	 That destination may be
-
-
-
-Hansen,Lin						        [Page 2]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-	       local or	reached	via another MTA.  It may use a local
-	       queue to	store the message before transferring it
-	       further.	 Any MTA may generate a	Non-Delivery Notifica-
-	       tion.
-
-     Intermediate Message Transfer Agent (MTA)
-	       An Intermediate MTA is an MTA that accepts a message for
-	       transfer	somewhere else.
-
-     Final Message Transfer Agent (MTA)
-	       A Final MTA is an MTA that accepts a message for	local
-	       delivery.  It is	the final place	that a message is
-	       accepted.  The final MTA	is what	sends any Delivery
-	       Status Notificatons (DSNs).
-
-     Foreign Message Transfer Agent
-	       A foreign MTA provides delivery of messages using other
-	       protocols than those specified for Internet mail, such as
-	       an X.400	mail system.
-
-     Gateway Message Transfer Agent (GW-MTA)
-	       A gateway MTA accepts a message for transfer to a foreign
-	       MTA outside of the Internet protocol space.
-
-     Local Delivery Agent (DA)
-	       The local Delivery Agent	delivers the message to	the
-	       local message store.  (The MTA and DA are often combined
-	       into the	same program.)
-
-     Delivery Status Notification (DSN)
-	       A Delivery Status Notification [RFC-DSN]	is produced by
-	       an MTA when a message is	unsuccessfully delivered, either
-	       to its next hop or the final message store, or when it is
-	       successfully delivered, either to a foreign MTA or to a
-	       local delivery agent.  Positive notifications are only
-	       performed [RFC-ESMTP-DSN] when specifically requested.
-
-     Non-Delivery Notification (NDN)
-	       A non-delivery notification is a	special	form of	DSN
-	       indicating unsuccessful delivery.
-
-     Message Disposition Notification (MDN)
-	       A Message Disposition Notification is used to report the
-	       disposition of a	message	after it has been successfully
-	       delivered to a recipient.
-
-     Tracking User Agent (TUA)
-	       A tracking user agent wants to find information on a
-
-
-
-Hansen,Lin						        [Page 3]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-	       message on the behalf of	a user.	 It is the requestor or
-	       initiator of such a request.  (The MUA and TUA could be
-	       combined	into the same program.)
-
-     Tracking Server
-	       A tracking server provides tracking information to a
-	       tracking	client.	 It is the repository of the information
-	       about a message for the traversal through a particular
-	       MTA.  (The tracking server and MTA may run on the same
-	       system.)
-
-3.  Entities
-
-     The entities involved in message tracking are:  message user
-agents,	message	submission agents, message transfer agents, tracking
-user agents and	tracking servers.
-
-4.  Requirements
-
-     These are requirements that any message tracking solution must be
-able to	satisfy:
-
-     The message tracking solution:
-
-     **	  MUST scale to	the internet.
-
-     **	  MUST be easy to deploy.
-
-     **	  SHOULD maximize the reuse of existing, already deployed tech-
-	  nology and infrastructure.
-
-     **	  SHOULD extend	existing protocols and not invent new ones.
-
-     **	  SHOULD have a	low implementation cost.  (This	makes it easy to
-	  incorporate into existing products.)
-
-     **	  MUST restrict	tracking of a message to the originator	of the
-	  message (or a	delegate).
-
-     **	  MUST be able to do authentication.
-
-     **	  MAY allow an originator to delegate this responsibility to a
-	  third	party.
-
-     **	  SHOULD have the property that	they would allow per-message
-	  delegation of	the tracking responsibility.
-
-     **	  MUST require a tracking user agent to	prove that they	are
-
-
-
-Hansen,Lin						        [Page 4]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-	  permitted to request the tracking information.
-
-     **	  MUST be able to uniquely identify messages.
-
-     **	  MUST require every message to	have unique identification.
-
-5.  Interaction	Models
-
-     There are several models by which tracking	of messages can	be
-enabled, by which messages can be tracked, and by which	information can
-be requested and gathered.
-
-5.1.  Tracking Enabling	Models
-
-     Either the	envelope or message header must	contain	enough informa-
-tion to	track a	message	and securely retrieve information about	the mes-
-sage.  Any message that	does have enough information to	track it is by
-definition not trackable.
-
-     If	there is not enough information	available in current standard
-envelopes or message headers, then the current standards will need to be
-extended.  Either the MUA or MSA must determine	the additional informa-
-tion and enable	the tracking by	adding the additional information to
-either the envelope or header.
-
-     This leads	to two tracking	enabling models:  passive enabling and
-active enabling.
-
-5.1.1.	Passive	Enabling Model
-The "passive enabling" model assumes that there	is sufficient informa-
-tion available.	 No UA or MSA interaction occurs to turn tracking on; it
-is on by default.
-
-5.1.2.	Active Enabling	Model
-
-     The "active  enabling" model requires that	the MUA	and MSA	exchange
-information when the message is	submitted.  This exchange indicates that
-logging	of the message's traversal should be performed,	as well	as pro-
-viding enough additional information to	allow the message to be	tracked.
-This information will need to be passed	on to subsequent MTAs as needed.
-
-5.2.  Tracking Request Models
-There are several models by which tracking information may be requested.
-
-5.2.1.	Passive	Request	Model
-
-     The "passive request" model requires active enabling to indicate
-that some form of tracking is to be performed.	The tracking information
-
-
-
-Hansen,Lin						        [Page 5]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-can be sent back immediately (as a form	of telemetry) or sent to a 3rd
-party for later	retrieval.
-
-5.2.2.	Passive	Request	Tracking Information
-
-     Forms of passive tracking information that	could potentially be
-requested are  as  follows.  Note that mechanisms already exist	for
-requesting the information marked with a (+).  The references for such
-mechanisms are listed at the end of each such entry.
-
-     **	  send a DSN of	a message arriving at an intermediate MTA
-
-     **	  (+) send a DSN of a message being rejected while at an inter-
-	  mediate MTA [RFC-DSN]
-
-     **	  (+) send a DSN of a message leaving an intermediate MTA and
-	  going	to another MTA [RFC-DELIVER-BY]
-
-     **	  send a DSN of	a message arriving at a	final MTA
-
-     **	  (+) send a DSN of a message being rejected while at a	final
-	  MTA [RFC-DSN]
-
-     **	  (+) send a DSN of a message being delivered to a user's mes-
-	  sage store [RFC-DSN]
-
-     **	  (+) send a DSN of a message being delivered to a foreign MTA
-	  [RFC-DSN]
-
-     **	  (+) send an MDN of a message being read by an	end user [RFC-
-	  MDN]
-
-5.3.  Active Request Model
-
-     The "active request" model	requires an active query by a user's
-user agent to either the intermediate MTAs and final MTA, or to	a third
-party, to find the message's status as known by	that MTA.  Active
-request	will work with either passive enabling or active enabling.
-
-5.3.1.	Server Chaining	vs. Server Referrals
-When a tracking	server has been	asked for tracking information,	and the
-message	has been passed	on to another MTA of which this	tracking server
-has no tracking	knowledge, there are two modelling choices:
-
-     **	  the first tracking server will contact the next tracking
-	  server to query for status and pass back the combined	status
-	  (server chaining), or
-
-
-
-
-Hansen,Lin						        [Page 6]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-     **	  the first tracking server will return	the address of the next
-	  MTA and the tracking client has the responsibility of	contact-
-	  ing the next tracking	server (server referrals).
-
-5.3.2.	Active Request Tracking	Information
-Forms of active	tracking information that could	potentially be requested
-are as follows.	 (Note that no mechanisms currently exist for requesting
-such information.)
-
-     **	  the message has been queued for later	delivery
-
-     **	  the message was delivered locally
-
-     **	  the message was delivered to another MTA,
-
-     **	  the message was delivered to a foreign MTA
-
-     **	  ask a	different tracking server,
-
-     **	  I know but can't tell	you,
-
-     **	  I don't know.
-
-5.4.  Combining	DSN and	MDN Information	with Message Tracking Informa-
-tion
-
-     The information that would	be retrieved by	message	tracking and the
-information that is returned for DSN and MDN requests all attempt to
-answer the question of "what happened to message XX"?  The information
-provided by each is complementary in nature, but similar.  A tracking
-user agent could use all three possible	information  sources  to present
-a total	view of	the status of a	message.
-
-     Both DSN and MDN notifications utilize the	formats	defined	by RFC
-1892 [RFC-REPORT].  This suggests that the information returned	by mes-
-sage tracking solutions	should also be similar.
-
-6.  Security
-
-     This is a security	model for message identification and authentica-
-tion that could	be deployed.  (There may be others.)
-
-     A Tracking	User Agent must	prove that they	are permitted to request
-tracking information about a message.  Every [RFC-822]-compliant message
-is supposed to contain a Message-Id header.  One possible mechanism is
-for the	originator to calculate	a one-way hash A from the message ID +
-time stamp + a per-user	secret.	 The user then calculates another one-
-way hash B to be the hash of A.	 The user includes B in	the submitted
-
-
-
-Hansen,Lin						        [Page 7]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-message, and retains A.	 Later,	when the user makes a message tracking
-request	to the messaging system	or tracking entity, it submits A in the
-tracking request.  The entity receiving	the tracking request then uses A
-to calculate B,	since it was already provided B, verifying that	the
-requestor is authentic.	 In summary,
-
-     A = H(message ID +	time stamp + secret)
-
-     B = H(A)
-
-Another	possible mechanism for A is to ignore the message ID and time
-stamp and just use a one-way hash from a large (>128 bits) random
-number.	 B would be calculated as before.  In summary,
-
-     A = H(large-random-number)
-
-     B = H(A)
-
-This is	similar	in technique to	the methods used for One-Time Passwords
-[RFC-OTP].  The	success	of these techniques is dependent on the	random-
-ness of	the per-user secret or the large random	number,	which can be
-incredibly difficult in	some environments.
-
-     If	the originator of a message were to delegate his or her	tracking
-request	to a third party by sending them A, this would be vulnerable to
-snooping over unencrypted sessions.  The user can decide on a message-
-by-message basis if this risk is acceptable.
-
-7.  References
-
-
-     [RFC-822] Crocker,	D., "Standard for the Format of	ARPA Internet
-	       Text Messages", STD 11, RFC 822,	UDEL, August 1982.
-
-     [RFC-DELIVER-BY]
-	       Newman, D., "Deliver By SMTP Service Extension",	draft-
-	       newman-deliver-02.txt, Innosoft,	January	1999.
-
-     [RFC-DSN] Moore, K., and G. Vaudreuil, "An	Extensible Message For-
-	       mat for Delivery	Status Notifications", RFC 1894, Univer-
-	       sity of Tennessee, Octel	Network	Services, January 1996.
-
-     [RFC-ESMTP-DSN]
-	       Moore, K., "SMTP	Service	Extension for Delivery Status
-	       Notifications", RFC 1891, University of Tennessee, Janu-
-	       ary 1996.
-
-     [RFC-KEYWORDS]
-
-
-
-Hansen,Lin						        [Page 8]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-	       Bradner,	S., "Key words for use in RFCs to Indicate
-	       Requirement Levels", RFC	2119, Harvard University, March
-	       1997.
-
-     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
-	       Disposition Notifications", RFC 2298, National Institutes
-	       of Health, March	1998.
-
-     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw,	M., "A One-Time
-	       Password	System", RFC 2289, Bellcore, Kaman Sciences Cor-
-	       poration, Nesser	& Nesser Consulting, Bellcore, February
-	       1998.
-
-     [RFC-REPORT]
-	       Vaudreuil, G., "The Multipart/Report Content Type for the
-	       Reporting of Mail System	Administrative Messages", RFC
-	       1892, Octel Network Services, January 1996.
-
-     [RFC-SMTP]Postel, J., "Simple Mail	Transfer Protocol", STD	10, RFC
-	       821, USC/Information Sciences Institute,	August 1982.
-
-8.  Acknowledgements
-
-     This document is the product of input from	many people and	many
-sources.  It owes much to earlier work by Gordon Jones,	Bruce Ernst and
-Greg Vaudreuil.
-
-9.  Authors' Addresses
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1 732 576-3207
-     E-Mail: tony@att.com
-
-     Ken Lin
-     Lotus Development Corporation
-     640 Lee Road
-     Wayne, PA 19087
-
-     Phone: +1 610 251-3380
-     E-Mail: ken_lin@lotus.com
-
-10.  Full Copyright Statement
-
-     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
-
-
-
-
-Hansen,Lin						        [Page 9]
-
-Internet Draft	Message	Tracking Model and Requirements	  March	10, 2000
-
-
-     This document and translations of it may be copied	and furnished to
-others,	and derivative works that comment on or	otherwise explain it or
-assist in its implmentation may	be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind,	provided
-that the above copyright notice	and this paragraph are included	on all
-such copies and	derivative works.  However, this document itself may not
-be modified in any way,	such as	by removing the	copyright notice or
-references to the Internet Society or other Internet organisations,
-except as needed for the purpose of developing Internet	standards in
-which case the procedures for copyrights defined in the	Internet Stan-
-dards process must be followed,	or as required to translate it into
-languages other	than English.
-
-     The limited permissions granted above are perpetual and will not be
-revoked	by the Internet	Society	or its successors or assigns.
-
-     This document and the information contained herein	is provided on
-an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR	IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE	INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS	OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS	FOR A PARTICULAR PURPOSE.
-
-     This document expires September 10, 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen,Lin					               [Page 10]
diff --git a/doc/devel/I-D/draft-ietf-msgtrk-model-02.txt b/doc/devel/I-D/draft-ietf-msgtrk-model-02.txt
deleted file mode 100644
index 9f928637..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-model-02.txt
+++ /dev/null
@@ -1,556 +0,0 @@
-Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-model-02.txt                         AT&T Laboratories
-Valid for six months                                              K. Lin
-                                           Lotus Development Corporation
-                                                           July 14, 2000
-
-
-
-                Message Tracking Model and Requirements
-
-                    <draft-ietf-msgtrk-model-02.txt>
-
-                         Authors' version: 1.12
-
-     Status of this Memo
-
-     This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed on the MSGTRK working
-group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
-with the word "subscribe" in the body (on a line by itself) to the
-address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
-be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can I track
-the messages?  Message tracking is the ability to find out the path that
-
-
-
-Hansen,Lin                                                      [Page 1]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-a particular message has taken through a messaging system and the
-current routing status of that message.  This document provides a model
-of message tracking that can be used for understanding the Internet-wide
-message infrastructure and to further enhance those capabilities to
-include message tracking, as well as requirements for proposed message
-tracking solutions.
-
-1.  Problem Statement
-
-     Consider sending a package through a package delivery company.
-Once you've sent a package, you would like to be able to find out if the
-package has been delivered or not, and if not, where that package
-currently is and what its status is.  Note that the status of a package
-may not include whether it was delivered to its addressee, but just the
-destination.  Many package carriers provide such services today, often
-via a web interface.
-
-     Message tracking extends that capability to the Internet-wide mes-
-sage infrastructure, analogous to the service provided by package car-
-riers:  the ability to quickly locate where a message (package) is, and
-to determine whether or not the message (package) has been delivered to
-its final destination.  An Internet-standard approach will allow the
-development of message tracking applications that can operate in a
-multi-vendor messaging environment, and will encourage the operation of
-the function across administrative boundaries.
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS].
-
-2.  Definitions
-The following terms are relevant to message tracking.  The terms Track-
-ing User Agent and Tracking Server are new, while all other terms have
-been collected here from other sources.
-
-     Originating Mail User Agent (MUA)
-               The originating mail user agent is the software used to
-               compose and originate a message.  It is the software sit-
-               ting on a person's desktop.
-
-     Originating Mail Submission Agent (MSA)
-               The Mail Submission Agent accepts a message from a User
-               Agent, adds or modifies whatever headers are appropriate
-               for the message's traversal through the Internet, and
-               injects the message into the network via a Message
-               Transfer Agent.  An MSA is used, in lieu of the first MTA
-               by MUA's that do not create fully-compliant Internet mes-
-               sages, to submit messages into the SMTP delivery network.
-
-
-
-Hansen,Lin                                                      [Page 2]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-     Message Transfer Agent (MTA)
-               A Message Transfer Agent accepts a message and moves it
-               forward towards its destination.  That destination may be
-               local or reached via another MTA.  It may use a local
-               queue to store the message before transferring it
-               further.  Any MTA may generate a Non-Delivery Notifica-
-               tion.
-
-     Intermediate Message Transfer Agent (MTA)
-               An Intermediate MTA is an MTA that accepts a message for
-               transfer somewhere else.
-
-     Final Message Transfer Agent (MTA)
-               A Final MTA is an MTA that accepts a message for local
-               delivery.  It is the final place that a message is
-               accepted.  The final MTA is what sends any Delivery
-               Status Notificatons (DSNs).  (Intermediate MTA's may also
-               send a DSN if it relays to a non-DSN aware MTA.)
-
-     Foreign Message Transfer Agent
-               A foreign MTA provides delivery of messages using other
-               protocols than those specified for Internet mail, such as
-               an X.400 mail system.
-
-     Gateway Message Transfer Agent (GW-MTA)
-               A gateway MTA accepts a message for transfer to a foreign
-               MTA outside of the Internet protocol space.
-
-     Local Delivery Agent (DA)
-               The local Delivery Agent delivers the message to the
-               local message store.  (The MTA and DA are often combined
-               into the same program.)
-
-     Delivery Status Notification (DSN)
-               A Delivery Status Notification [RFC-DSN] is produced by
-               an MTA when a message is unsuccessfully delivered, either
-               to its next hop or the final message store, or when it is
-               successfully delivered, either to a foreign MTA, to a
-               local delivery agent, or a non-DSN aware MTA.  Positive
-               notifications are only performed [RFC-ESMTP-DSN] when
-               specifically requested.
-
-     Non-Delivery Notification (NDN)
-               A non-delivery notification is a special form of DSN
-               indicating unsuccessful delivery.
-
-     Message Disposition Notification (MDN)
-               A Message Disposition Notification is used to report the
-
-
-
-Hansen,Lin                                                      [Page 3]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-               disposition of a message after it has been successfully
-               delivered to a recipient.
-
-     Tracking User Agent (TUA)
-               A tracking user agent wants to find information on a mes-
-               sage on the behalf of a user.  It is the requestor or
-               initiator of such a request.  (The MUA and TUA could be
-               combined into the same program.)
-
-     Tracking Server
-               A tracking server provides tracking information to a
-               tracking client.  It is the repository of the information
-               about a message for the traversal through a particular
-               MTA.  (The tracking server and MTA may run on the same
-               system.)
-
-3.  Entities
-
-     The entities involved in message tracking are:  message user
-agents, message submission agents, message transfer agents, tracking
-user agents and tracking servers.
-
-4.  Requirements
-
-     These are requirements that any message tracking solution must be
-able to satisfy:
-
-     The message tracking solution:
-
-     **   MUST scale to the internet.
-
-     **   MUST be easy to deploy.
-
-     **   SHOULD maximize the reuse of existing, already deployed tech-
-          nology and infrastructure.
-
-     **   SHOULD extend existing protocols and not invent new ones.
-
-     **   SHOULD have a low implementation cost.  (This makes it easy to
-          incorporate into existing products.)
-
-     **   MUST restrict tracking of a message to the originator of the
-          message (or a delegate).
-
-     **   MUST be able to do authentication.
-
-     **   MAY allow an originator to delegate this responsibility to a
-          third party.
-
-
-
-Hansen,Lin                                                      [Page 4]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-     **   SHOULD have the property that they would allow per-message
-          delegation of the tracking responsibility.
-
-     **   MUST require a tracking user agent to prove that they are per-
-          mitted to request the tracking information.
-
-     **   MUST be able to uniquely identify messages.
-
-     **   MUST require every message to have unique identification.
-
-5.  Interaction Models
-
-     There are several models by which tracking of messages can be
-enabled, by which messages can be tracked, and by which information can
-be requested and gathered.
-
-5.1.  Tracking Enabling Models
-
-     Either the envelope or message header must contain enough informa-
-tion to track a message and securely retrieve information about the mes-
-sage.  Any message that does not have enough information to track it is
-by definition not trackable.
-
-     If there is not enough information available in current standard
-envelopes or message headers, then the current standards will need to be
-extended.  Either the MUA or MSA must determine the additional informa-
-tion and enable the tracking by adding the additional information to
-either the envelope or header.
-
-     This leads to two tracking enabling models:  passive enabling and
-active enabling.
-
-5.1.1.  Passive Enabling Model
-The "passive enabling" model assumes that there is sufficient informa-
-tion available.  No UA or MSA interaction occurs to turn tracking on; it
-is on by default.
-
-5.1.2.  Active Enabling Model
-
-     The "active  enabling" model requires that the MUA and MSA exchange
-information when the message is submitted.  This exchange indicates that
-logging of the message's traversal should be performed, as well as pro-
-viding enough additional information to allow the message to be tracked.
-This information will need to be passed on to subsequent MTAs as needed.
-
-5.2.  Tracking Request Models
-There are several models by which tracking information may be requested.
-
-
-
-
-Hansen,Lin                                                      [Page 5]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-5.2.1.  Passive Request Model
-
-     The "passive request" model requires active enabling to indicate
-that some form of tracking is to be performed.  The tracking information
-can be sent back immediately (as a form of telemetry) or sent to a 3rd
-party for later retrieval.
-
-5.2.2.  Passive Request Tracking Information
-
-     Forms of passive tracking information that could potentially be
-requested are  as  follows.  Note that mechanisms already exist for
-requesting the information marked with a (+).  The references for such
-mechanisms are listed at the end of each such entry.
-
-     **   send a DSN of a message arriving at an intermediate MTA
-
-     **   (+) send a DSN of a message being rejected while at an inter-
-          mediate MTA [RFC-DSN]
-
-     **   (+) send a DSN of a message leaving an intermediate MTA and
-          going to another MTA [RFC-DELIVER-BY]
-
-     **   send a DSN of a message arriving at a final MTA
-
-     **   (+) send a DSN of a message being rejected while at a final
-          MTA [RFC-DSN]
-
-     **   (+) send a DSN of a message being delivered to a user's mes-
-          sage store [RFC-DSN]
-
-     **   (+) send a DSN of a message being delivered to a foreign MTA
-          [RFC-DSN]
-
-     **   (+) send an MDN of a message being read by an end user [RFC-
-          MDN]
-
-5.3.  Active Request Model
-
-     The "active request" model requires an active query by a user's
-user agent to the MSA, intermediate MTAs and final MTA, or to a third
-party, to find the message's status as known by that MTA.  Active
-request will work with either passive enabling or active enabling.
-
-5.3.1.  Server Chaining vs. Server Referrals
-When a tracking server has been asked for tracking information, and the
-message has been passed on to another MTA of which this tracking server
-has no tracking knowledge, there are two modelling choices:
-
-
-
-
-Hansen,Lin                                                      [Page 6]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-     **   the first tracking server will contact the next tracking
-          server to query for status and pass back the combined status
-          (server chaining), or
-
-     **   the first tracking server will return the address of the next
-          MTA and the tracking client has the responsibility of contact-
-          ing the next tracking server (server referrals).
-
-5.3.2.  Active Request Tracking Information
-Forms of active tracking information that could potentially be requested
-are as follows.  (Note that no mechanisms currently exist for requesting
-such information.)
-
-     **   the message has been queued for later delivery
-
-     **   the message was delivered locally
-
-     **   the message was delivered to another MTA,
-
-     **   the message was delivered to a foreign MTA
-
-     **   ask a different tracking server,
-
-     **   I know but can't tell you,
-
-     **   I don't know.
-
-5.4.  Combining DSN and MDN Information with Message Tracking Informa-
-tion
-
-     The information that would be retrieved by message tracking and the
-information that is returned for DSN and MDN requests all attempt to
-answer the question of "what happened to message XX"?  The information
-provided by each is complementary in nature, but similar.  A tracking
-user agent could use all three possible information  sources  to present
-a total view of the status of a message.
-
-     Both DSN and MDN notifications utilize the formats defined by RFC
-1892 [RFC-REPORT].  This suggests that the information returned by mes-
-sage tracking solutions should also be similar.
-
-6.  Security
-
-     This is a security model for message identification and authentica-
-tion that could be deployed.  (There may be others.)
-
-     A Tracking User Agent must prove that they are permitted to request
-tracking information about a message.  Every [RFC-822]-compliant message
-
-
-
-Hansen,Lin                                                      [Page 7]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-is supposed to contain a Message-Id header.  One possible mechanism is
-for the originator to calculate a one-way hash A from the message ID +
-time stamp + a per-user secret.  The user then calculates another one-
-way hash B to be the hash of A.  The user includes B in the submitted
-message, and retains A.  Later, when the user makes a message tracking
-request to the messaging system or tracking entity, it submits A in the
-tracking request.  The entity receiving the tracking request then uses A
-to calculate B, since it was already provided B, verifying that the
-requestor is authentic.  In summary,
-
-     A = H(message ID + time stamp + secret)
-
-     B = H(A)
-
-Another possible mechanism for A is to ignore the message ID and time
-stamp and just use a one-way hash from a large (>128 bits) random
-number.  B would be calculated as before.  In summary,
-
-     A = H(large-random-number)
-
-     B = H(A)
-
-This is similar in technique to the methods used for One-Time Passwords
-[RFC-OTP].  The success of these techniques is dependent on the random-
-ness of the per-user secret or the large random number, which can be
-incredibly difficult in some environments.
-
-     If the originator of a message were to delegate his or her tracking
-request to a third party by sending them A, this would be vulnerable to
-snooping over unencrypted sessions.  The user can decide on a message-
-by-message basis if this risk is acceptable.
-
-7.  References
-
-
-     [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
-               Text Messages", STD 11, RFC 822, UDEL, August 1982.
-
-     [RFC-DELIVER-BY]
-               Newman, D., "Deliver By SMTP Service Extension", draft-
-               newman-deliver-02.txt, Innosoft, January 1999.
-
-     [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For-
-               mat for Delivery Status Notifications", RFC 1894, Univer-
-               sity of Tennessee, Octel Network Services, January 1996.
-
-     [RFC-ESMTP-DSN]
-               Moore, K., "SMTP Service Extension for Delivery Status
-
-
-
-Hansen,Lin                                                      [Page 8]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-               Notifications", RFC 1891, University of Tennessee, Janu-
-               ary 1996.
-
-     [RFC-KEYWORDS]
-               Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", RFC 2119, Harvard University, March
-               1997.
-
-     [RFC-MDN] Fajman, R., "An Extensible Message Format for Message
-               Disposition Notifications", RFC 2298, National Institutes
-               of Health, March 1998.
-
-     [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw, M., "A One-Time
-               Password System", RFC 2289, Bellcore, Kaman Sciences Cor-
-               poration, Nesser & Nesser Consulting, Bellcore, February
-               1998.
-
-     [RFC-REPORT]
-               Vaudreuil, G., "The Multipart/Report Content Type for the
-               Reporting of Mail System Administrative Messages", RFC
-               1892, Octel Network Services, January 1996.
-
-     [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-               821, USC/Information Sciences Institute, August 1982.
-
-8.  Acknowledgements
-
-     This document is the product of input from many people and many
-sources.  It owes much to earlier work by Gordon Jones, Bruce Ernst and
-Greg Vaudreuil.
-
-9.  Authors' Addresses
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1 732 576-3207
-     E-Mail: tony@att.com
-
-     Ken Lin
-     Lotus Development Corporation
-     640 Lee Road
-     Wayne, PA 19087
-
-     Phone: +1 610 251-3380
-     E-Mail: ken_lin@lotus.com
-
-
-
-
-Hansen,Lin                                                      [Page 9]
-
-Internet Draft  Message Tracking Model and Requirements    July 14, 2000
-
-
-10.  Full Copyright Statement
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-     This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implmentation may be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind, provided
-that the above copyright notice and this paragraph are included on all
-such copies and derivative works.  However, this document itself may not
-be modified in any way, such as by removing the copyright notice or
-references to the Internet Society or other Internet organisations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-     The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-     This document and the information contained herein is provided on
-an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-     This document expires January 14, 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen,Lin                                                     [Page 10]
diff --git a/doc/devel/I-D/draft-ietf-msgtrk-mtqp-00.txt b/doc/devel/I-D/draft-ietf-msgtrk-mtqp-00.txt
deleted file mode 100644
index f7f485a1..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-mtqp-00.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-mtqp-00.txt                          AT&T Laboratories
-Valid for six months
-                                                            July 1, 2000
-
-
-
-                    Message Tracking Query Protocol
-
-                    <draft-ietf-msgtrk-mtqp-00.txt>
-
-                         Authors' version: 1.3
-
-     Status of this Memo
-
-     This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed on the MSGTRK working
-group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
-with the word "subscribe" in the body (on a line by itself) to the
-address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
-be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can I track
-the messages?  Message tracking is the ability to find out the path that
-a particular message has taken through a messaging system and the
-
-
-
-Hansen,Allman                                                   [Page 1]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-current routing status of that message.  This document describes the
-Message Tracking Query Protocol that is used in conjunction with exten-
-sions to the ESMTP protocol to provide a complete message tracking solu-
-tion for the Internet.
-
-     NOTE: This is a straw proposal for the Message Tracking Query Pro-
-tocol.
-
-1.  Introduction
-
-     The Message Tracking Models and Requirements document [RFC-TRACK-
-MODEL] discusses the models that message tracking solutions could fol-
-low, along with requirements for a message tracking solution that can be
-used with the Internet-wide message infrastructure.  This memo and its
-companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete
-message tracking solution that satisfies those requirements.  The memo
-[RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides
-the information necessary to track messages.  This memo defines a proto-
-col that can be used to query the status of messages that have been
-transmitted on the Internet via SMTP.  The memo [RFC-TRACK-TSN]
-describes the message/tracking-status MIME media type that is used to
-report tracking status information.  Using the model document's termi-
-nology, this solution uses active enabling and active requests with both
-request and chaining referrals.
-
-1.1.  Terminology
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in [RFC-KEYWORDS].
-
-     All syntax descriptions use the ABNF specified by [RFC-ABNF].
-Unless otherwise noted, any terminal nodes not defined here are defined
-in [RFC-ABNF].
-
-2.  Basic Operation
-
-     The Message Tracking Query Protocol (MTQP) is similar to many other
-line-oriented Internet protocols, such as [POP3] and [NNTP].  Initially,
-the server host starts the MTQP service by listening on TCP port ????.
-When a client wishes to make use of the service, it establishes a TCP
-connection with the server host.  When the connection is established,
-the MTQP SERVER SENDS A GREETING.  The client and MTQP server then
-exchange commands and responses (respectively) until the connection is
-closed or aborted.
-
-     Commands in MTQP consist of a case-insensitive keyword, possibly
-followed by one or more parameters.  All commands are terminated by a
-
-
-
-Hansen,Allman                                                   [Page 2]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-CRLF pair.  Keywords and parameters consist of printable ASCII charac-
-ters.  Keywords and parameters are separated by whitespace (one or more
-space or tab characters).  A command line is limited to 998 characters
-before the CRLF.
-
-     Responses in MTQP consist of a status indicator that indicates suc-
-cess or failure, possibly followed by whitespace and additional informa-
-tion.  Successful commands may also be followed by additional lines of
-data.  All response lines are terminated by a CRLF pair and are limited
-to 998 characters before the CRLF.  There are several status indicators:
-"+OK" indicates success; "+OK+" indicates a success followed by addi-
-tional lines of data, a multi-line success response; "-TEMP" indicates a
-temporary failure; "-ERR" indicates a permanent failure; and "-BAD"
-indicates a protocol error (such as for unrecognized commands).
-
-     A multi-line success response may take one of two forms.  If the
-end of the +OK+ line contains the character "{", a number, and the char-
-acter "}" before the CRLF, then the rest of the response consists of
-that number of characters.
-
-     If the multi-line success response does not end with "{number}",
-each subsequent line is terminated by a CRLF pair and limited to 998
-characters before the CRLF.  When all lines of the response have been
-sent, a final line is sent consisting of a single period (".", decimal
-code 046) and a CRLF pair.  If any line of the multi-line response
-begins with a period, the line is "dot-stuffed" by prepending the period
-with a second period.  When examining a multi-line response, the client
-checks to see if the line begins with a period.  If so, and other octets
-other than CRLF follow, the first octet of the line (the period) is
-stripped away.  If so, and if CRLF immediately follows the period, then
-the response from the MTQP server is ended and the line containing the
-".CRLF" is not considered part of the multi-line response.
-
-     An MTQP server MUST respond to an unrecognized, unimplemented, or
-syntactically invalid command by responding with a negative -BAD status
-indicator.  A server MUST respond to a command issued when the session
-is in an incorrect state by responding with a negative -ERR status indi-
-cator.
-
-     An MTQP server MAY have an inactivity autologout timer.  Such a
-timer MUST be of at least 10 minutes' duration.  The receipt of any com-
-mand from the client during that interval should suffice to reset the
-autologout timer.
-
-3.  Initialization
-
-     Once the TCP connection has been opened by an MTQP client, the MTQP
-server issues an initial status response indicates its readiness.  If
-
-
-
-Hansen,Allman                                                   [Page 3]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-the status response is positive (+OK or +OK+), the client may proceed
-with other commands.
-
-     If the server has any options enabled, they are listed as the
-multi-line response of the initial status response, one per line.  An
-option specification consists of an identifier, optionally followed by
-option-specific parameters.  An option specification may be continued
-onto additional lines by starting the continuation lines with white
-space.
-
-     No options are defined in this document.
-
-     Example #1 (no options):
-     S: +OK MTQ server ready
-
-     Example #2 (service temporarily unavailable):
-     S: -TEMP Service down for admin, call back later
-
-     Example #3 (service permanently unavailable):
-     S: -ERR Service down
-
-     Example #4 (alternative for no options):
-     S: +OK+ MTQ server ready
-     S: .
-
-     Example #5 (options available):
-     S: +OK+ MTQ server ready
-     S: Option1 parameters
-     S: Option2
-     S: Option3 a very long
-     S:  list of parameters
-     S: .
-
-4.  TRACK Command
-
-     Syntax:
-          "TRACK" 1*WS tracking-id 1*WS authorization-cookie *WS CRLF
-
-          tracking-id = TBD
-
-          authorization-cookie = TBD
-
-     When the client issues the TRACK command, the MTQP server retrieves
-tracking information about an email message.  A successful response MUST
-be multi-line, consisting of a [MIME] mail message whose default
-content-type is message/tracking-status, as defined in [RFC-TRACK-TSN].
-This message contains the tracking information about the email message
-that used the given tracking-id.  The tracking-id and authorization-
-
-
-
-Hansen,Allman                                                   [Page 4]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-cookie are defined in [RFC-TRACK-ESMTP].  The authorization-cookie is
-expressed in hexadecimal.
-
-     Example #6
-     C: TRACK <tracking-id> 1234567890ABCDEF
-     S: +OK+ Tracking information follows
-     S: Content-Type: message/tracking-status
-     S:
-     S: ... details go here ...
-     S: .
-
-5.  NOOP Command
-
-     Syntax:
-          "NOOP" opt-text CRLF
-
-     When the client issues the NOOP command, the MTQP server resets the
-inactivity autologout timer.  The server MUST respond with a successful
-response (+OK or +OK+).  All parameters to the NOOP command are ignored.
-
-6.  QUIT Command
-
-     Syntax:
-          "QUIT" *WS CRLF
-
-     When the client issues the QUIT command, the MTQP session ter-
-minates.  The QUIT command has no parameters.  The server MUST respond
-with a successful response.  The client may close the session from its
-end immediately after issuing this command.
-
-7.  Pipelining
-
-     The MTQP client may elect to transmit groups of MTQP commands in
-batches without waiting for a response to each individual command.  The
-MTQP server MUST process the commands in the order received.  The fol-
-lowing two examples are identical:
-
-     Example #7
-     C: TRACK <tracking-id> 1234567890ABCDEF
-     S: +OK+ Tracking information follows
-     S:
-     S: ... details go here ...
-     S: .
-     C: NOOP
-     S: +OK Status okay
-
-     Example #8
-     C: TRACK <tracking-id> 1234567890ABCDEF
-
-
-
-Hansen,Allman                                                   [Page 5]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-     C: NOOP
-     S: +OK+ Tracking information follows
-     S:
-     S: ... details go here ...
-     S: .
-     S: +OK Status okay
-
-8.  URL Format
-
-     The MTQP URL scheme is used to designate MTQP servers on Internet
-hosts accessible using the MTQP protocol.  An MTQP URL takes one of the
-following forms:
-
-     mtqp://<mserver>/track/<tracking-id>:<cookie>
-     mtqp://<mserver>:<port>/track/<tracking-id>:<cookie>
-
-     The first form is used to refer to an MTQP server on the standard
-port, while the second form specifies a non-standard port.  Both of
-these forms specify that the TRACK command is to be issued using the
-given tracking id and authorization cookie.  The path element "/track/"
-is case insensitive, but the tracking id may not be.
-
-8.1.  MTQP URL Syntax
-
-     This is an ABNF description of the MTQP URL.  Terminal nodes not
-defined here are defined in either [RFC-URL] or [RFC-ABNF].
-
-     mtqp-url = "mtqp://" net_loc "/track/" tracking-id ":" cookie
-
-     tracking-id = TBD
-
-     cookie = 16HEXDIG
-
-9.  IANA Considerations
-
-     TBD - registering extensions
-
-10.  Security Considerations
-
-     Security considerations discussed in [RFC-TRACK-MODEL] and [RFC-
-TRACK-ESMTP] are relevant.
-
-11.  Protocol Syntax
-
-     This is an ABNF description of MTQP.
-     command-response = success-response / temp-response / error-response / bad-response
-
-     temp-response = "-TEMP" opt-text CRLF
-
-
-
-Hansen,Allman                                                   [Page 6]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-     opt-text = [WSP *(VCHAR / WSP)]
-
-     error-response = "-ERR" opt-text CRLF
-
-     bad-response = "-BAD" opt-text CRLF
-
-     success-response = single-line-success / multi-line-success / multi-char-success
-
-     single-line-success = "+OK" opt-text CRLF
-
-     multi-char-success = "+OK+" opt-text "{" 1*DIGIT "}" *WSP CRLF *OCTET
-          ; the number of characters specified by {number} ; must be
-          sent
-
-     multi-line-success = "+OK+" opt-text CRLF *dataline dotcrlf
-
-     dataline = *998OCTET CRLF
-
-     dotcrlf = "." CRLF
-
-     option-list = *option-line
-
-     option-line = rulename opt-text *[CRLF WSP opt-text] CRLF
-
-12.  References
-
-     [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet
-Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
-November 1996.
-
-
-     [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto-
-col", University of Southern California / Information Sciences Insti-
-tute, August 1982.
-
-     [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
-ARPA Internet Text Messages", University of Delaware, August 1982.
-
-     [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
-BNF for Syntax Specifications: ABNF", November 1997.
-
-     [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
-and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July
-1994.
-
-     [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
-Indicate Requirement Levels", March 1997.
-
-
-
-
-Hansen,Allman                                                   [Page 7]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-     [RFC-MD5] RFC 1321, R. Rivest, "The MD5 Message-Digest Algorithm",
-April 1992.
-
-     [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-02.txt, T. Hansen, K.
-Lin, "Message Tracking Models and Requirements", AT&T Laboratories,
-Lotus Development Corporation, ???? 2000.
-
-     [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-*.txt, E. Allman, "SMTP
-Service Extension for Message Tracking", Sendmail, Inc., ???? 2000.
-
-     [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The
-Message/Tracking-Status MIME Extension", Sendmail, Inc., ???? 2000.
-
-     [RFC-URL] RFC 1808, R. Fielding, "Relative Uniform Resource Loca-
-tors", June 1995.
-
-13.  Authors' Addresses
-
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1.732.576.3207
-     E-Mail: tony@att.com
-
-14.  Full Copyright Statement
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-     This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implmentation may be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind, provided
-that the above copyright notice and this paragraph are included on all
-such copies and derivative works.  However, this document itself may not
-be modified in any way, such as by removing the copyright notice or
-references to the Internet Society or other Internet organisations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-     The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-     This document and the information contained herein is provided on
-an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-
-
-
-Hansen,Allman                                                   [Page 8]
-
-Internet Draft      Message Tracking Query Protocol         July 1, 2000
-
-
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-     This document expires January 1, 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen,Allman                                                   [Page 9]
-
diff --git a/doc/devel/I-D/draft-ietf-msgtrk-mtqp-01.txt b/doc/devel/I-D/draft-ietf-msgtrk-mtqp-01.txt
deleted file mode 100644
index fc6bc4ae..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-mtqp-01.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-Internet Draft                                                 T. Hansen
-draft-ietf-msgtrk-mtqp-01.txt                          AT&T Laboratories
-Valid for six months                                   November 21, 2000
-
-
-
-                    Message Tracking Query Protocol
-
-                    <draft-ietf-msgtrk-mtqp-01.txt>
-
-                         Authors' version: 1.5
-
-     Status of this Memo
-
-     This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed on the MSGTRK working
-group mailing list, ietf-msgtrk@imc.org.  To subscribe, send a message
-with the word "subscribe" in the body (on a line by itself) to the
-address ietf-msgtrk-request@imc.org.  An archive of the mailing list may
-be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can I track
-the messages?  Message tracking is the ability to find out the path that
-a particular message has taken through a messaging system and the
-current routing status of that message.  This document describes the
-
-
-
-Hansen                                                          [Page 1]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-Message Tracking Query Protocol that is used in conjunction with exten-
-sions to the ESMTP protocol to provide a complete message tracking solu-
-tion for the Internet.
-
-1.  Introduction
-
-     The Message Tracking Models and Requirements document [RFC-TRACK-
-MODEL] discusses the models that message tracking solutions could fol-
-low, along with requirements for a message tracking solution that can be
-used with the Internet-wide message infrastructure.  This memo and its
-companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete
-message tracking solution that satisfies those requirements.  The memo
-[RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides
-the information necessary to track messages.  This memo defines a proto-
-col that can be used to query the status of messages that have been
-transmitted on the Internet via SMTP.  The memo [RFC-TRACK-TSN]
-describes the message/tracking-status MIME media type that is used to
-report tracking status information.  Using the model document's termi-
-nology, this solution uses active enabling and active requests with both
-request and chaining referrals.
-
-1.1.  Terminology
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in [RFC-KEYWORDS].
-
-     All syntax descriptions use the ABNF specified by [RFC-ABNF].  Ter-
-minal nodes not defined elsewhere in this document are defined in [RFC-
-ABNF], [RFC-URI], [RFC-TRACK-ESMTP] or [RFC-SMTPEXT].
-
-1.2.  To Do
-
-     provide information on finding an MTQP server
-
-     provide TTL info, maximum times for keeping info
-
-     determine the TCP port to use
-
-2.  Basic Operation
-
-     The Message Tracking Query Protocol (MTQP) is similar to many other
-line-oriented Internet protocols, such as [POP3] and [NNTP].  Initially,
-the server host starts the MTQP service by listening on TCP port TBD.
-When a client wishes to make use of the service, it establishes a TCP
-connection with the server host.  When the connection is established,
-the MTQP server sends a greeting.  The client and MTQP server then
-exchange commands and responses (respectively) until the connection is
-
-
-
-Hansen                                                          [Page 2]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-closed or aborted.
-
-2.1.  Commands
-
-     Commands in MTQP consist of a case-insensitive keyword, possibly
-followed by one or more parameters.  All commands are terminated by a
-CRLF pair.  Keywords and parameters consist of printable ASCII charac-
-ters.  Keywords and parameters are separated by whitespace (one or more
-space or tab characters).  A command line is limited to 998 characters
-before the CRLF.
-
-2.2.  Responses
-
-     Responses in MTQP consist of a status indicator that indicates suc-
-cess or failure.  Successful commands may also be followed by additional
-lines of data.  All response lines are terminated by a CRLF pair and are
-limited to 998 characters before the CRLF.  There are several status
-indicators:  "+OK" indicates success; "+OK+" indicates a success fol-
-lowed by additional lines of data, a multi-line success response; "-
-TEMP" indicates a temporary failure; "-ERR" indicates a permanent
-failure; and "-BAD" indicates a protocol error (such as for unrecognized
-commands).
-
-     A status indicator MAY be followed by a series of machine-
-parseable, case-insensitive response information giving more data about
-the errors.  These are separated from the status indicator and each
-other by a single slash character ("/", decimal code 47).  Following
-that, there MAY be white space and a human-readable text message.
-
-     In a multi-line success response, each subsequent line is ter-
-minated by a CRLF pair and limited to 998 characters before the CRLF.
-When all lines of the response have been sent, a final line is sent con-
-sisting of a single period (".", decimal code 046) and a CRLF pair.  If
-any line of the multi-line response begins with a period, the line is
-"dot-stuffed" by prepending the period with a second period.  When exa-
-mining a multi-line response, the client checks to see if the line
-begins with a period.  If so, and octets other than CRLF follow, the
-first octet of the line (the period) is stripped away.  If so, and if
-CRLF immediately follows the period, then the response from the MTQP
-server is ended and the line containing the ".CRLF" is not considered
-part of the multi-line response.
-
-     An MTQP server MUST respond to an unrecognized, unimplemented, or
-syntactically invalid command by responding with a negative -BAD status
-indicator.  A server MUST respond to a command issued when the session
-is in an incorrect state by responding with a negative -ERR status indi-
-cator.
-
-
-
-
-Hansen                                                          [Page 3]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-2.3.  Optional Timers
-
-     An MTQP server MAY have an inactivity autologout timer.  Such a
-timer MUST be of at least 10 minutes in duration.  The receipt of any
-command from the client during that interval should suffice to reset the
-autologout timer.  An MTQP server MAY limit the number of commands or
-total connection time to prevent denial of service attacks.
-
-3.  Initialization and Option Response
-
-     Once the TCP connection has been opened by an MTQP client, the MTQP
-server issues an initial status response indicates its readiness.  If
-the status response is positive (+OK or +OK+), the client may proceed
-with other commands.
-
-     The initial status response MUST include the response information
-"/MTQP".  Negative responses MUST include a reason code as response
-information.  The following reason codes are defined here; unrecognized
-reason codes added in the future may be treated as equivalent to
-"unknown".
-     "/" "unavailable"
-     "/" "admin"
-     "/" "unknown"
-     "/" "referral" "=" net_loc
-
-     If the server has any options enabled, they are listed as the
-multi-line response of the initial status response, one per line.  An
-option specification consists of an identifier, optionally followed by
-option-specific parameters.  An option specification may be continued
-onto additional lines by starting the continuation lines with white
-space.  The option identifier is case insensitive.  Option identifiers
-beginning with the characters "vnd." are reserved for vendor use.
-
-     One option specification is defined here:
-
-     STARTTLS
-
-This capability MUST be listed if the optional STARTTLS command is sup-
-ported by the MTQP server.  It has no parameters.
-
-     Example #1 (no options):
-     S: +OK/MTQP MTQP server ready
-
-     Example #2 (service temporarily unavailable):
-     S: -TEMP/MTQP/admin Service down for admin, call back later
-
-     Example #3 (service permanently unavailable):
-     S: -ERR/MTQP/unavailable Service down
-
-
-
-Hansen                                                          [Page 4]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-     Example #4 (alternative for no options):
-     S: +OK+/MTQP MTQP server ready
-     S: .
-
-     Example #5 (options available):
-     S: +OK+/MTQP MTQP server ready
-     S: starttls
-     S: Option2 with parameters
-     S: Option3 with a very long
-     S:  list of parameters
-     S: .
-
-     Example #6 (Referred to another server):
-     S: -ERR/MTQP/referral=server42.example.com:37
-
-4.  TRACK Command
-
-     Syntax:
-          "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF
-
-          mtrk-secret = base64
-
-     Envid is defined in [RFC-TRACK-ESMTP].  Mtrk-secret is the secret S
-described in [RFC-TRACK-ESMTP], encoded using base64.
-
-     When the client issues the TRACK command, the MTQP server retrieves
-tracking information about an email message.  A successful response MUST
-be multi-line, consisting of a [MIME] body part.  The default content-
-type for this MIME body part is message/tracking-status, as defined in
-[RFC-TRACK-TSN].  The response contains the tracking information about
-the email message that used the given tracking-id.  Multiple responses
-would be reported using a multipart/mixed body part with
-message/tracking-status internals.  The tracking-id and authorization-
-cookie are defined in [RFC-TRACK-ESMTP].
-
-     TBD: Give details on different modes of responses and how they map
-into message/tracking-status
-
-     Example #7 :
-     C: TRACK <tracking-id> 1234567890ABCDEF
-     S: +OK+ Tracking information follows
-     S: Content-Type: message/tracking-status
-     S:
-     S: ... details go here when ...
-     S: ... draft-ietf-msgtrk-trkstat becomes available ...
-     S: .
-
-
-
-
-
-Hansen                                                          [Page 5]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-5.  COMMENT Command
-
-     Syntax:
-          "COMMENT" opt-text CRLF
-
-          opt-text = [WSP *(VCHAR / WSP)]
-
-     When the client issues the COMMENT command, the MTQP server MUST
-respond with a successful response (+OK or +OK+).  All optional text
-provided with the COMMENT command are ignored.
-
-6.  STARTTLS Command
-
-     Syntax:
-          "STARTTLS" CRLF
-
-     TLS [TLS], more commonly known as SSL, is a popular mechanism for
-enhancing TCP communications with privacy and authentication.  An MTQP
-server MAY support TLS.  If an MTQP server supports TLS, it MUST include
-"STARTTLS" in the option specifications list on protocol startup.
-
-     If the server returns a negative response, it MAY use one of the
-following response codes:
-     "/" "unsupported"
-     "/" "unavailable"
-
-     After receiving a positive response to a STARTTLS command, the
-client MUST start the TLS negotiation before giving any other MTQP com-
-mands.
-
-     If the MTQP client is using pipelining, the STARTTLS command must
-be the last command in a group.
-
-6.1.  Processing After the STARTTLS Command
-
-     After the TLS handshake has been completed, both parties MUST
-immediately decide whether or not to continue based on the authentica-
-tion and privacy achieved. The MTQP client and server may decide to move
-ahead even if the TLS negotiation ended with no authentication and/or no
-privacy because most MTQP services are performed with no authentication
-and no privacy, but some MTQP clients or servers may want to continue
-only if a particular level of authentication and/or privacy was
-achieved.
-
-     If the MTQP client decides that the level of authentication or
-privacy is not high enough for it to continue, it SHOULD issue an MTQP
-QUIT command immediately after the TLS negotiation is complete.  If the
-MTQP server decides that the level of authentication or privacy is not
-
-
-
-Hansen                                                          [Page 6]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-high enough for it to continue, it SHOULD reply to every MTQP command
-from the client (other than a QUIT command) with a negative "-BAD"
-response and a response code of "/insecure".
-
-6.2.  Result of the STARTTLS Command
-
-     Upon completion of the TLS handshake, the MTQP protocol is reset to
-the initial state (the state in MTQP after a server starts up).  The
-server MUST discard any knowledge obtained from the client prior to the
-TLS negotiation itself. The client MUST discard any knowledge obtained
-from the server, such as the list of MTQP options, which was not
-obtained from the TLS negotiation itself.
-
-     At the end of the TLS handshake, the server acts as if the connec-
-tion had been initiated and responds with an initial status response
-and, optionally, a list of server options.  The list of MTQP server
-options received after the TLS handshake MUST be different than the list
-returned before the TLS handshake.  In particular, a server MUST NOT
-return the STARTTLS option in the list of server options after a TLS
-handshake has completed.
-
-     Both the client and the server MUST know if there is a TLS session
-active.  A client MUST NOT attempt to start a TLS session if a TLS ses-
-sion is already active.
-
-7.  QUIT Command
-
-     Syntax:
-          "QUIT" CRLF
-
-     When the client issues the QUIT command, the MTQP session ter-
-minates.  The QUIT command has no parameters.  The server MUST respond
-with a successful response.  The client may close the session from its
-end immediately after issuing this command.
-
-8.  Pipelining
-
-     The MTQP client may elect to transmit groups of MTQP commands in
-batches without waiting for a response to each individual command.  The
-MTQP server MUST process the commands in the order received.
-
-     Specific commands may place further constraints on pipelining.  For
-example, STARTTLS must be the last command in a batch of MTQP commands.
-
-     The following two examples are identical:
-
-     Example #8 :
-     C: TRACK <tracking-id> 1234567890ABCDEF
-
-
-
-Hansen                                                          [Page 7]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-     S: +OK+ Tracking information follows
-     S:
-     S: ... details go here ...
-     S: .
-     C: TRACK <tracking-id-2> ABCDEF1234567890
-     S: +OK+ Tracking information follows
-     S:
-     S: ... details #2 go here ...
-     S: .
-
-     Example #9 :
-     C: TRACK <tracking-id> 1234567890ABCDEF
-     C: TRACK <tracking-id-2> ABCDEF1234567890
-     S: +OK+ Tracking information follows
-     S:
-     S: ... details go here ...
-     S: .
-     S: +OK+ Tracking information follows
-     S:
-     S: ... details #2 go here ...
-     S: .
-
-9.  URL Format
-
-     The MTQP URL scheme is used to designate MTQP servers on Internet
-hosts accessible using the MTQP protocol.  An MTQP URL takes one of the
-following forms:
-
-     mtqp://<mserver>/track/<envid>/<mtrk-secret>
-     mtqp://<mserver>:<port>/track/<envid>/<mtrk-secret>
-
-     The first form is used to refer to an MTQP server on the standard
-port, while the second form specifies a non-standard port.  Both of
-these forms specify that the TRACK command is to be issued using the
-given tracking id and authorization cookie.  The path element "/track/"
-is case insensitive, but the envid and mtrk-secret may not be.
-
-9.1.  MTQP URL Syntax
-
-     This is an ABNF description of the MTQP URL.
-
-     mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret
-
-10.  IANA Considerations
-
-     The service name to be registered with the Internet Assigned Number
-Authority (IANA) is "MTQP".
-
-
-
-
-Hansen                                                          [Page 8]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-     This document requests that IANA maintain one new registry: MTQP
-options.
-
-     Additional options for this protocol whose names do not begin with
-"vnd."  MUST be defined in a standards track or IESG approved experimen-
-tal RFC.  New MTQP options MUST include the following information:
-
-     option identifier
-     option parameters
-     added commands
-     standard commands affected
-     specification reference
-     discussion
-
-     Additional options for this protocol whose names begin with "vnd."
-MUST be registered with IANA on a Firt Come First Served basis.
-
-11.  Security Considerations
-
-     Security considerations discussed in [RFC-TRACK-MODEL] and [RFC-
-TRACK-ESMTP] are relevant.
-
-     The security of tracking information is dependent on the randomness
-of the secret chosen for each message and the level of exposure of that
-secret.  If different secrets are used for each message, then the max-
-imum exposure from tracking any message will be that single message for
-the time that the tracking information is kept on any MTQP server.  If
-this level of exposure is too much, TLS may be used to reduce the expo-
-sure further.
-
-     It should be noted that message tracking is not an end-to-end
-mechanism.  Thus, if an MTQP client/server pair decide to use TLS
-privacy, they are not securing tracking queries with any prior or suc-
-cessive MTQP servers.
-
-     Both the STMP client and server must check the result of the TLS
-negotiation to see whether acceptable authentication or privacy was
-achieved.  Ignoring this step completely invalidates using TLS for secu-
-rity.  The decision about whether acceptable authentication or privacy
-was achieved is made locally, is implementation-dependant, and is beyond
-the scope of this document.
-
-     The SMTP client and server should note carefully the result of the
-TLS negotiation.  If the negotiation results in no privacy, or if it
-results in privacy using algorithms or key lengths that are deemed not
-strong enough, or if the authentication is not good enough for either
-party, the client may choose to end the MTQP session with an immediate
-QUIT command, or the server may choose to not accept any more MTQP
-
-
-
-Hansen                                                          [Page 9]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-commands.
-
-     A man-in-the-middle attack can be launched by deleting the
-"STARTTLS" option response from the server.  This would cause the client
-not to try to start a TLS session.  An MTQP client can protect against
-this attack by recording the fact that a particular MTQP server offers
-TLS during one session and generating an alarm if it does not appear in
-an option response for a later session.
-
-     If TLS is not used, a tracking request is vulnerable to replay
-attacks, such that a snoop can later replay the same handshake again to
-potentially gain more information about a message's status.
-
-     Before the TLS handshake has begun, any protocol interactions are
-performed in the clear and may be modified by an active attacker.  For
-this reason, clients and servers MUST discard any knowledge obtained
-prior to the start of the TLS handshake upon completion of the TLS
-handshake.
-
-12.  Protocol Syntax
-
-     This is a collected ABNF description of the MTQP protocol.
-     conversation = command-response *( client-command command-response )
-
-     # client side
-     client-command = track-command / starttls-command / quit-command / comment-command
-
-     track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF
-
-     mtrk-secret = base64
-
-     starttls-command = "STARTTLS" CRLF
-
-     quit-command = "QUIT" CRLF
-
-     comment-command = "COMMENT" opt-text CRLF
-
-     # server side
-     command-response = success-response / temp-response / error-response / bad-response
-
-     temp-response = "-TEMP" response-info opt-text CRLF
-
-     opt-text = [WSP *(VCHAR / WSP)]
-
-     error-response = "-ERR" response-info opt-text CRLF
-
-     bad-response = "-BAD" response-info opt-text CRLF
-
-
-
-
-Hansen                                                         [Page 10]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-     success-response = single-line-success / multi-line-success
-
-     single-line-success = "+OK" response-info opt-text CRLF
-
-     multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf
-
-     dataline = *998OCTET CRLF
-
-     dotcrlf = "." CRLF
-
-     option-list = *option-line
-
-     option-line = identifier opt-text *[CRLF WSP opt-text] CRLF
-
-     identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_")
-
-
-13.  Acknowledgements
-
-     The description of STARTTLS is based on [RFC-SMTP-TLS].
-
-14.  References
-
-     [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet
-Mail Extensions (MIME) Part One: Format of Internet Message Bodies",
-November 1996.
-
-     [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto-
-col", University of Southern California / Information Sciences Insti-
-tute, August 1982.
-
-     [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of
-ARPA Internet Text Messages", University of Delaware, August 1982.
-
-     [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented
-BNF for Syntax Specifications: ABNF", November 1997.
-
-     [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud,
-and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July
-1994.
-
-     [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to
-Indicate Requirement Levels", March 1997.
-
-     [RFC-MD5] RFC 1321, R. Rivest, MIT Laboratory for Computer Science
-and RSA Data Security, Inc., "The MD5 Message-Digest Algorithm", April
-1992.
-
-
-
-
-Hansen                                                         [Page 11]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-     [RFC-SMTPEXT] RFC 2554, J. Myers, Netscape Communications, "SMTP
-Service Extension for Authentication", March 1999.
-
-     [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for
-Secure SMTP over TLS", Internet Mail Consortium, January 1999.
-
-     [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-00.txt, E. Allman, T.
-Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc.,
-AT&T Laboratories, TBD 2000.
-
-     [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes-
-sage Tracking Models and Requirements", AT&T Laboratories, November
-2000.
-
-     [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The
-Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000.
-
-     [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni-
-form Resource Identifiers (URI): Generic Syntax", August 1998.
-
-15.  Authors' Addresses
-
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1.732.576.3207
-     E-Mail: tony@att.com
-
-16.  Full Copyright Statement
-
-     Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-     This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implmentation may be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind, provided
-that the above copyright notice and this paragraph are included on all
-such copies and derivative works.  However, this document itself may not
-be modified in any way, such as by removing the copyright notice or
-references to the Internet Society or other Internet organisations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-     The limited permissions granted above are perpetual and will not be
-
-
-
-Hansen                                                         [Page 12]
-
-Internet Draft      Message Tracking Query Protocol    November 21, 2000
-
-
-revoked by the Internet Society or its successors or assigns.
-
-     This document and the information contained herein is provided on
-an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-     This document expires May 21, 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hansen                                                         [Page 13]
-
diff --git a/doc/devel/I-D/draft-ietf-msgtrk-protocol-00.txt b/doc/devel/I-D/draft-ietf-msgtrk-protocol-00.txt
deleted file mode 100644
index e223f995..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-protocol-00.txt
+++ /dev/null
@@ -1,500 +0,0 @@
-Internet Draft						       E. Allman
-draft-ietf-msgtrk-protocol-00.txt			  Sendmail, Inc.
-Valid for six months					       T. Hansen
-						       AT&T Laboratories
-							  March	10, 2000
-
-
-
-			 SMTP Service Extension
-			  for Message Tracking
-
-		  <draft-ietf-msgtrk-protocol-00.txt>
-
-			 Authors' version: 1.1
-
-     Status of this Memo
-
-     This document is an Internet-Draft	and is in full conformance with
-all provisions of Section 10 of	RFC2026.
-
-     Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups.  Note that other
-groups may also	distribute working documents as	Internet-Drafts.
-
-     Internet-Drafts are draft documents valid for a maximum of	six
-months and may be updated, replaced, or	obsoleted by other documents at
-any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in	progress."
-
-     The list of current Internet-Drafts can be	accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt.
-
-     The list of Internet-Draft	Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-     This memo and its companions are discussed	on the MSGTRK working
-group mailing list, ietf-msgtrk[-request]@imc.org.  An archive of the
-mailing	list may be found at http://www.ietf.org/archive/msgtrk.
-
-Copyright Notice
-
-     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
-
-Abstract
-
-     Customers buying enterprise message systems often ask: Can	I track
-the messages?  Message tracking	is the ability to find out the path that
-a particular message has taken through a messaging system and the
-
-
-
-Allman,Hansen						        [Page 1]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-current	routing	status of that message.	 This document provides	exten-
-sions to the ESMTP protocol to enhance its capabilities	to include mes-
-sage tracking.
-
-1.  Introduction
-
-     The Message Tracking Models and Requirements document [RFC-TRACK-
-MODEL] discusses the models that message tracking solutions could fol-
-low, along with	requirements for a message tracking solution that can be
-used with the Internet-wide message infrastructure.  This memo defines
-an extension to	the SMTP service that provides a message tracking solu-
-tion that satisfies those requirements.	 Using the model document's ter-
-minology, it uses active enabling and active requests with request
-referrals.
-
-....
-
-This document is very drafty; its purpose is to	promote	discussion.
-Sections that are obviously in need of filling out have	comments begin-
-ning with "--".
-
-
-1.1.  Terminology
-
-     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT",	"RECOMMENDED", "MAY", and "OPTIONAL" in	this
-document are to	be interpreted as described in RFC 2119	[RFC-KEYWORDS].
-
-
-
-2.  Framework for the Message Tracking Service Extension
-
-     The Message Trackng extension to SMTP is laid out as follows:
-
-     **	  the name of the SMTP service defined here is "Message	Track-
-	  ing";
-
-     **	  the EHLO keyword value associated with the extension is
-	  "TRACK";
-
-     **	  the TRACK keyword has	no parameters;
-
-     **	  the TRACKID parameter	is added to the	MAIL FROM command;
-
-     **	  a new	SMTP verb, "MTRK", is defined.
-
-     The rest of this memo defines how support for the extension effects
-     the behavior of a message transfer	agent.
-
-
-
-Allman,Hansen						        [Page 2]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-3.  Message Tracking Enabling
-
-     An	SMTP client wishing to request message tracking	support	for a
-message	may issue the EHLO command to start an SMTP session, to	deter-
-mine if	the server supports any	of several service extensions.	If the
-server responds	with code 250 to the EHLO command, and the response
-includes the EHLO keyword TRACK, then the Message Tracking extension (as
-described in this memo)	is supported.  In general, an ESMTP server which
-implements this	service	extension will propagate message tracking infor-
-mation when relaying mail to other SMTP-based MTAs that	also support
-this extension,	and make a "best effort" to record when	messages are
-passed into other environments.
-
-4.  Additional Parameter for the MAIL FROM Command
-
-     The extended MAIL FROM command is issued by a client when it wishes
-to request that	a server maintain tracking information for the message.
-The extended MAIL FROM command is identical to the MAIL	commands defined
-in [RFC-821], except that the additional parameter may appear after the
-recipient address.  The	general	syntax for extended SMTP commands is
-defined	in [RFC-ESMTP].
-
-4.1.  The TRACKID parameter of the ESMTP MAIL FROM Command
-
-     The TRACKID esmtp-keyword on the extended MAIL FROM command speci-
-fies whether or	not the	message	should be tracked by the server.  If the
-TRACKID	esmtp-keyword is used, it MUST have an associated esmtp-value,
-which is constructed as	described next.
-
-4.2.  Creating the TRACKID Parameter
-
-     The TRACKID parameter consists of two parts: a per-message	authen-
-tication string, the Auth String, and a	per-message tracking identifica-
-tion string, the Tracking ID.
-
-4.2.1.	Tracking ID
-
-     A key requirement of message tracking is the ability to uniquely
-identify a message with	a globally and temporally unique signature.  The
-Message-Id: header is required by [RFC-822] to identify	a message, and
-is usually required to be globally and temporally unique.  So it is
-almost sufficient for tracking identification.	However, a Message ID
-will be	reused under certain circumstances, such as when a message is
-resent,	and such messages must be able to be tracked separately	from the
-original message.  The Tracking	ID is REQUIRED to be the same value as
-used for the Message ID, without the angle brackets, and augmented by a
-colon ":" and a	generational counter.  The generational	counter	will be
-an unsigned integer value that SHOULD start at the value of 0.	For
-
-
-
-Allman,Hansen						        [Page 3]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-example, if the	value of the Message-ID: header	is
-"<123456.89012391@domain.example>", then the value of the tracking ID
-will be	"123456.89012391@domain.example:0".  If	a message is ever resent
-or retransmitted for any other reason by an end-user client, then the
-generational counter MUST be incremented by one.  (The generational
-counter	MAY additionally be incremented	by a small (<10) random	number.)
-
-4.2.2.	Secret Value
-
-     For messages to be	tracked, the mail user agent must use a	secret
-value.	This secret value MAY be a per-message secret, such as a 128-bit
-(16-byte) random number.
-
-4.2.3.	Stored Authentication Value
-
-     The value of the Tracking ID, T, is concatentated with the	secret
-value, S, and passed through the [RFC-MD5] one-way hash	function, to
-create the Stored Authentication Value,	A.
-
-     A = H(T + S)
-
-
-4.2.4.	Transmitted Authentication String
-
-     The Transitted Authentication String, B, is created by passing the
-Stored Authentication Value, A,	through	the MD5	one-way	hash function,
-producing a 16-byte value.  This value is then expressed as a series of
-32 hexadecimal digits, either lower- or	upper-case, transmitted	in
-internet byte order (low-endian	???? ) [RFC-????].
-
-     B = hex(H(A))
-
-4.2.5.	The TRACKID Parameter
-
-     The TRACKID parameter, P, is created from the transmitted authenti-
-cation string, B, a colon ":", and the tracking	ID, T.
-
-     P = B + ":" + T
-
-
-5.  Message Tracking Requests
-
-     The MTRK command is issued	by the client host when	it wishes to
-determine the current status of	a message previously sent to that server
-host.  The syntax of this command is as	follows:
-
-     MTRK <stored-authentication-value>:<tracking-id><CR><LF>
-
-
-
-
-Allman,Hansen						        [Page 4]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-<tracking-id> is the tracking ID, T, of	a message previously sent to
-this server.  The <stored-authentication-value>	is the Stored Authenti-
-cation Value A (as calculated above) for that message.	The <stored-
-authentication-value> is expressed as a	series of 32 hexadecimal digits,
-either lower- or upper-case, transmitted in internet byte order	[RFC-
-????].	This command may be issued at any time once a session is esta-
-blished, as long as there is not a transaction occurring.  Thus, this
-command	is illegal between a MAIL FROM:	command	and the	end of the DATA
-commands and responses.
-
-things to add:
--- data	to be returned
--- states to be	returned
--- format to be	returned
--- responses to	the verb, 250, 4xx, 5xx
-
-
-other things to	consider:
--- firewalls? (treat as	gateway	MTAs and let them do chaining?)
--- affect on SUBMIT? can we ask	MSA to return the A and	B hash?
--- use message-id directly and require message-id to be	in first 1k of
-message?
-
-
-6.  Examples
-
-     --	examples go here
-
-6.1.  Message Tracking Enabling
-
-
-     S:	220 smtp.example.com ESMTP server ready
-     C:	EHLO example.example.com
-     S:	250-smtp.example.com
-     S:	250 TRACK
-     C:	MAIL FROM:<user@example.com>
-	 TRACKID=1234567890123456789012:12345.54321@example.com:0
-     S:	250 <user@example.com> sender ok
-     C:	RCPT TO:<user2@example.com>
-     S:	25o <user2@example.com>	recipient ok
-     C:	DATA
-     S:	354 okay, send message
-     C:	Message-Id: <12345.54321@example.com>
-     C:	(rest of message here)
-     C:	.
-     S:	250 message accepted
-     C:	QUIT
-     S:	221 goodbye
-
-
-
-Allman,Hansen						        [Page 5]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-6.2.  Message Tracking Request
-
-     S:	220 smtp.example.com ESMTP server ready
-     C:	EHLO example.example.com
-     S:	250-smtp.example.com
-     S:	250 TRACK
-     C:	MTRK 1234567890123456789012:12345.54321@example.com:0
-     S:	-- response to be determined
-
-7.  Security Considerations
-
-     things to add:
--- text	about no more than a single message can	be lost
--- man in the middle attack
--- see RFC 1894	for security considerations on DSNs and	RFC 2298 on MDNs
-
--- We probably cannot get away with the	following statement:
-
-This RFC does not discuss security issues and is not believed to raise
-any security issues not	already	endemic	in electronic mail and present
-in fully conforming implementations of [RFC821], or otherwise made pos-
-sible by [MIME].
-
-
-8.  References
-
-     [RFC-821] Postel, J., "Simple Mail	Transfer Protocol", STD	10, RFC
-821, University	of Southern California / Information Sciences Institute,
-August 1982.
-
-[RFC-822] Crocker, D., "Standard for the Format	of ARPA	Internet Text
-Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
-[RFC-ESMTP] Klensin, J., Freed,	N., Rose, M., Stefferud, E., and D.
-Crocker, "SMTP Service Extensions", RFC	1651, MCI, Innosoft, Dover Beach
-Consulting, Inc., Network Management Associates, Inc., Silicon Graphics,
-Inc., July 1994.
-
-[RFC-MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-April 1992.
-
-[RFC-MODEL] Hansen, T.,	"Message Tracking Models and Requirements", RFC
-????, AT&T Laboratories, ???? 2000.
-
-[RFC-????]  something on internet byte order
-
-
-
-
-
-
-Allman,Hansen						        [Page 6]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-9.  Authors' Addresses
-
-     Eric Allman
-     Sendmail, Inc.
-     street address
-     city, state zip
-
-     Phone: +1
-     E-Mail: eric@sendmail.com
-
-     Tony Hansen
-     AT&T Laboratories
-     Lincroft, NJ 07738
-     USA
-
-     Phone: +1 732 576-3207
-     E-Mail: tony@att.com
-
-10.  Full Copyright Statement
-
-     Copyright (C) The Internet	Society	(1999).	 All Rights Reserved.
-
-     This document and translations of it may be copied	and furnished to
-others,	and derivative works that comment on or	otherwise explain it or
-assist in its implmentation may	be prepared, copied, published and dis-
-tributed, in whole or in part, without restriction of any kind,	provided
-that the above copyright notice	and this paragraph are included	on all
-such copies and	derivative works.  However, this document itself may not
-be modified in any way,	such as	by removing the	copyright notice or
-references to the Internet Society or other Internet organisations,
-except as needed for the purpose of developing Internet	standards in
-which case the procedures for copyrights defined in the	Internet Stan-
-dards process must be followed,	or as required to translate it into
-languages other	than English.
-
-     The limited permissions granted above are perpetual and will not be
-revoked	by the Internet	Society	or its successors or assigns.
-
-     This document and the information contained herein	is provided on
-an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR	IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE	INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS	OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS	FOR A PARTICULAR PURPOSE.
-
-     This document expires September 10, 2000.
-
-
-
-
-
-Allman,Hansen						        [Page 7]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-11.  Appendix A	-- Sample Code
-
-     For the sake of illustration, we provide the following sample C
-code for the creation of the saved and transmitted authentication
-strings.  The code is based on MD5 code	as described in	[RFC-MD5].  The
-input is a secret and transaction ID, the output is two	33-byte	strings
-containing the values of the two authentication	strings, encoded as hex
-digits,	and NUL-terminated.
-
--- I have not yet compiled this	code or	verified that it does indeed
-generate network byte order.
-     /*
-     **	Function: trackauth
-     */
-     #include <md5.h>
-
-     void
-     trackauth(
-		     /*	input parameters ... */
-	 unsigned char*	secret;		    /* pointer to secret */
-	 int secret_len;		    /* length of secret	*/
-	 unsigned char*	transaction_id;	    /* pointer to transaction ID */
-	 int transaction_id_len;	    /* length of transaction ID	*/
-		     /*	output parameters ... */
-	 unsigned char saved_auth_str[33];  /* A: saved	authentication string */
-	 unsigned char trans_auth_str[33];  /* B: transmitted auth. string */
-     )
-     {
-	 MD5_CTX context;		    /* MD5 engine */
-	 unsigned char outbuf[16];	    /* where to	store the context */
-	 register int i, j;		    /* counters	*/
-	 static	char hexdigits[] = "0123456789abcdef";
-
-	 MD5Init(&context);
-	 MD5Update(&context, secret, secret_len);
-	 MD5Update(&context, transaction_id, transaction_id_len);
-	 MD5Final(outbuf, &context);
-	 for (i	= 0, j = 0; i <	16; i++)
-	     {
-	     saved_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
-	     saved_auth_str[j++] = hexdigits[(outbuf[i]	>> 4) &	0xF];
-	     }
-	 saved_auth_str[j] = '\0';
-
-	 MD5Init(&context);
-	 MD5Update(&context, saved_auth_str, 16);
-	 MD5Final(outbuf, &context);
-	 for (i	= 0, j = 0; i <	16; i++)
-
-
-
-Allman,Hansen						        [Page 8]
-
-Internet Draft	    SMTP Message Tracking Extensions	  March	10, 2000
-
-
-	     {
-	     trans_auth_str[j++] = hexdigits[outbuf[i] & 0xF];
-	     trans_auth_str[j++] = hexdigits[(outbuf[i]	>> 4) &	0xF];
-	     }
-	 trans_auth_str[j] = '\0';
-     }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman,Hansen						        [Page 9]
diff --git a/doc/devel/I-D/draft-ietf-msgtrk-smtpext-00.txt b/doc/devel/I-D/draft-ietf-msgtrk-smtpext-00.txt
deleted file mode 100644
index 28d27f11..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-smtpext-00.txt
+++ /dev/null
@@ -1,430 +0,0 @@
-Internet Draft                                               E. Allman
-draft-ietf-msgtrk-smtpext-00.txt                        Sendmail, Inc.
-Valid for six months                                         T. Hansen
-Updates: RFC 1891                                    AT&T Laboratories
-                                                     December 14, 2000
-
-
-
-
-                        SMTP Service Extension
-                         for Message Tracking
-
-                  <draft-ietf-msgtrk-smtpext-00.txt>
-
-Status of This Memo
-
-     This  document  is  an  Internet-Draft and is in full conformance
-with all provisions of Section 10  of  RFC2026.   Internet-Drafts  are
-working  documents  of the Internet Engineering Task Force (IETF), its
-areas, and its working groups.  Note that other groups may  also  dis-
-tribute working documents as Internet-Drafts.
-
-     Internet-Drafts  are  draft  documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by  other  documents
-at  any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at:
-
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at:
-
-    http://www.ietf.org/shadow.html
-
-
-     This document is a submission by the MSGTRK Working Group of  the
-Internet  Engineering Task Force (IETF).  Comments should be submitted
-to the msgtrk@imc.org mailing list.  An archive of  the  mailing  list
-may be found at
-
-    http://www.ietf.org/archive/msgtrk
-
-
-     Distribution of this memo is unlimited.
-
-
-1.  Abstract
-
-        This  memo  defines an extension to the SMTP service whereby a
-   client may mark a message for future tracking.
-
-Internet Draft     Message Tracking ESMTP Extension  December 14, 2000
-
-
-2.  Other Documents and Conformance
-
-        The model used for Message Tracking is  described  in  [DRAFT-
-   MTRK-MODEL].
-
-        Doing  a Message Tracking query is intended as a "last resort"
-   mechanism.  Normally, Delivery Status  Notifications  (DSNs)  [RFC-
-   DSN-SMTP]  and  Message  Disposition Notifications (MDNs) [RFC-MDN]
-   would provide the primary delivery status.  Only if the message  is
-   not  received,  or there is no response from either of these mecha-
-   nisms should a Message Tracking query be issued.
-
-        The definition of the base64 token is  imported  from  section
-   6.8 of [RFC-MIME].
-
-        Syntax notation in this document conforms to [RFC-ABNF].
-
-        The  key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL"
-   in  this  document  are  to be interpreted as described in RFC 2119
-   [RFC-KEYWORDS].
-
-
-3.  SMTP Extension Overview
-
-        The Message Tracking SMTP service extension uses the SMTP ser-
-   vice  extension  mechanism described in [RFC-ESMTP].  The following
-   service extension is hereby defined:
-
-    (1)   The name of the SMTP service extension  is  "Message  Track-
-          ing".
-
-    (2)   The  EHLO  keyword  value  associated with this extension is
-          "MTRK".
-
-    (3)   No parameters are allowed  with  this  EHLO  keyword  value.
-          Future documents may extend this specification by specifying
-          options.
-
-    (4)   One optional parameter using the keyword "MTRK" is added  to
-          the  MAIL  FROM  command.   In addition, the ENVID and ORCPT
-          parameters (as defined in RFC  1891  sections  5.4  and  5.2
-          respectively)   MUST   be   supported,  with  extensions  as
-          described below.
-
-    (5)   The maximum length of a MAIL FROM command line is  increased
-          by  40  characters by the possible addition of the MTRK key-
-          word and value.  Note that a further extension of 614  char-
-          acters  for  the  ORCPT  and ENVID parameters is required by
-          RFC-DSN-EXT].
-
-    (6)   No SMTP verbs are defined by this extension.
-
-
-
-
-
-
-Allman & Hansen                                               [Page 2]
-
-Internet Draft     Message Tracking ESMTP Extension  December 14, 2000
-
-
-4.  The Extended MAIL FROM Command
-
-        The extended MAIL FROM command is issued  by  an  SMTP  client
-   when  it  wishes  to  inform  an  SMTP server that message tracking
-   information should be retained for future querying.   The  extended
-   MAIL  FROM command is identical to the MAIL FROM command as defined
-   in [RFC-SMTP], except that MTRK, ORCPT, and ENVID parameters appear
-   after the address.
-
-   4.1.  The MTRK parameter to the ESMTP MAIL command
-
-           Any  sender  wishing to track a message must first tag that
-      message as trackable by creating two values A and B:
-
-          A = some-large-random-number
-          B = SHA1(A)
-
-      The large random number A  is  calculated  on  a  host-dependent
-      basis as described in [DRAFT-MTRK-MODEL].  See also [RFC-RANDOM]
-      for a discussion of choosing good random numbers.   This  random
-      number  MUST be at least 128 bits but MUST NOT be more than 1024
-      bits.
-
-           The 128-bit hash B of A is then computed  using  the  SHA-1
-      algorithm as described in [NIST-SHA1].
-
-           The  sender  then  base64  encodes  value B and passes that
-      value as the mtrk-certifier on the MAIL FROM command:
-
-          mtrk-parameter  = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
-          mtrk-certifier  = base64  ; authenticator
-          mtrk-timeout    = 1*9digit; seconds until timeout
-
-
-           A is stored in the originator's tracking database to  vali-
-      date future tracking requests as described in [DRAFT-MTRK-MTQP].
-      B is stored in tracking tracking databases of compliant MTAs and
-      used to authenticate future tracking requests.
-
-           The mtrk-timeout field indicates the number of seconds that
-      the client requests that this tracking information  be  retained
-      on intermediate servers, as measured from the initial receipt of
-      the message at that server.  Servers MAY ignore this value if it
-      violates  local  policy.   In  particular,  servers MAY silently
-      enforce an upper limit to how long  they  will  retain  tracking
-      data; this limit MUST be at least one day.
-
-           If  no  mtrk-timeout  field  is  specified  then the server
-      should use a local default.  This default SHOULD  be  8-10  days
-      and  MUST be at least one day.  Notwithstanding this clause, the
-      information MUST NOT be expired while the message remains in the
-      queue  for  this  server:  that is, an MTQP server MUST NOT deny
-      knowledge of a message while that same message sits in  the  MTA
-      queue.
-
-
-
-
-Allman & Hansen                                               [Page 3]
-
-Internet Draft     Message Tracking ESMTP Extension  December 14, 2000
-
-
-           If the message is relayed to another compliant SMTP server,
-      the MTA acting as the client SHOULD pass an  mtrk-timeout  field
-      equal  to  the  remaining life of that message tracking informa-
-      tion.  Specifically, the tracking timeout is decremented by  the
-      number  of seconds the message has lingered at this MTA and then
-      passed to the next MTA.  If the decremented tracking timeout  is
-      less  than  or equal to zero, the entire MTRK parameter MUST NOT
-      be passed to the next MTA; essentially, the entire tracking path
-      is considered to be lost at that point.
-
-           See  [RFC-DELIVERYBY] section 4 for an explanation of why a
-      timeout is used instead of an absolute time.
-
-   4.2.  Use of ENVID
-
-           To function properly, Message Tracking requires  that  each
-      message  have  a  unique  identifier that is never reused by any
-      other message.  For that  purpose,  if  the  MTRK  parameter  is
-      given,  an  ENVID  parameter MUST be included, and the syntax of
-      ENVID from RFC 1891 section 5.4 is extended as follows:
-
-          envid-parameter = "ENVID=" unique-envid
-          unique-envid    = xtext "@" fqhn
-          fqhn            = xtext
-
-      Any retransmissions of this message MUST assign a new ENVID.  In
-      this  context, "retransmission" includes forwarding or resending
-      a message.
-
-   4.3.  Forwarding Tracking Certifiers
-
-           MTAs SHOULD forward unexpired tracking certifiers  to  com-
-      pliant mailers as the mail is transferred during regular hop-to-
-      hop transfers.  If the "downstream" MTA is  not  MTRK-compliant,
-      then the MTRK= parameter MUST be deleted.  If the downstream MTA
-      is DSN-compliant, then the ENVID and ORCPT parameters  MUST  NOT
-      be deleted.
-
-           If  aliasing,  forwarding, or other redirection of messages
-      to a single recipient occurs, then the MTA SHOULD treat this  as
-      an  ordinary  hop-to-hop transfer and forward the MTRK=, ENVID=,
-      and ORCPT= values; these values MUST NOT be modified.
-
-           MTAs MUST NOT copy MTRK certifiers when relaying a  message
-      to multiple recipients.  An MTA MAY designate one recipient in a
-      multi-recipient alias as the "primary" recipient to which track-
-      ing  requests  shall  be  forwarded;  other  addresses SHALL NOT
-      receive tracking certifiers.  MTAs MUST NOT forward MTRK  certi-
-      fiers when doing mailing list expansion.
-
-
-5.  Security Issues
-
-
-
-
-
-
-Allman & Hansen                                               [Page 4]
-
-Internet Draft     Message Tracking ESMTP Extension  December 14, 2000
-
-
-   5.1.  Denial of service
-
-           An attacker could attempt to flood the database of a server
-      by submitting large numbers of small, tracked messages.  In this
-      case,  a  site  may  elect to lower its maximum retention period
-      retroactively.
-
-   5.2.  Confidentiality
-
-           The mtrk-authenticator value (``A'') must be hard  to  pre-
-      dict and not reused.
-
-           The  originating client must take reasonable precautions to
-      protect the secret.  For example, if the secret is stored  in  a
-      message store (e.g., a "Sent" folder), the client must make sure
-      the secret isn't accessible  by  attackers,  particularly  on  a
-      shared store.
-
-           MTAs  SHOULD  take precautions to make certain that message
-      tracking cannot be used to explore internal topologies  of  net-
-      works.
-
-6.  References
-
-   [DRAFT-MTRK-MODEL]
-        T.   Hansen,  ``Message  Tracking  Model  and  Requirements.''
-        draft-ietf-msgtrk-model-03.txt.  November 2000.
-
-   [DRAFT-MTRK-MTQP]
-        T. Hansen, ``Message Tracking Query  Protocol.''   draft-ietf-
-        msgtrk-mtqp-01.txt.  November 2000.
-
-   [RFC-ABNF]
-        Crocker,  D., Editor, and P. Overell, ``Augmented BNF for Syn-
-        tax Specifications: ABNF'', RFC 2234, November 1997.
-
-   [RFC-DELIVERYBY]
-        D. Newman, ``Deliver By SMTP Service Extension.''   RFC  2852.
-        June 2000.
-
-   [RFC-DSN-REPT]
-        G.  Vaudreuil,  ``The  Multipart/Report  Content  Type for the
-        Reporting of Mail System Administrative Messages.''  RFC 1892.
-        January 1996.
-
-   [RFC-DSN-SMTP]
-        K. Moore, ``SMTP Service Extension for Delivery Status Notifi-
-        cations.''  RFC 1891.  January 1996.
-
-   [RFC-DSN-STAT]
-        K. Moore and G. Vaudreuil, ``An Extensible Message Format  for
-        Delivery Status Notifications.''  RFC 1894.  January 1996.
-
-   [RFC-EMSSC]
-        G.  Vaudreuil,  ``Enhanced  Mail  System  Status Codes.''  RFC
-        1893.  January 1996.
-
-
-Allman & Hansen                                               [Page 5]
-
-Internet Draft     Message Tracking ESMTP Extension  December 14, 2000
-
-
-   [RFC-ESMTP]
-        Rose, M., Stefferud, E.,  Crocker,  D.,  Klensin,  J.  and  N.
-        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.  Novem-
-        ber 1995.
-
-   [RFC-KEYWORDS]
-        S. Bradner, ``Key words for use in RFCs to  Indicate  Require-
-        ment Levels.''  RFC 2119.  March 1997.
-
-   [RFC-MDN]
-        R. Fajman, ``An Extensible Message Format for Message Disposi-
-        tion Notifications.''  RFC 2298.  March 1998.
-
-   [RFC-MIME]
-        N. Freed  and  N.  Borenstein,  ``Multipurpose  Internet  Mail
-        Extensions  (MIME)  Part  One: Format of Internet Message Bod-
-        ies.''  RFC 2045.  November 1996.
-
-   [RFC-MSGFMT]
-        D. Crocker, ``Standard for the Format of  ARPA  Internet  Text
-        Messages.''  RFC 822.  August 1982.
-
-   [RFC-RANDOM]
-
-   [RFC-RELATED]
-        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
-        2387.  August 1998.
-
-   [NIST-SHA1]
-        NIST FIPS  PUB  180-1,  ``Secure  Hash  Standard.''   National
-        Institute of Standards and Technology, U.S. Department of Com-
-        merce.  May 1994.  DRAFT.
-
-   [RFC-SMTP]
-        J. Postel,  ``Simple  Mail  Transport  Protocol.''   RFC  821.
-        August 1982.
-
-7.  Authors' Addresses
-
-       Eric Allman
-       Sendmail, Inc.
-       6603 Shellmound
-       Emeryville, CA  94608
-       U.S.A.
-
-       E-Mail: eric@Sendmail.COM
-       Phone: +1 510 594 5501
-       Fax: +1 510 594 5411
-
-
-
-
-
-
-
-
-
-
-Allman & Hansen                                               [Page 6]
-
-Internet Draft     Message Tracking ESMTP Extension  December 14, 2000
-
-
-       Tony Hansen
-       AT&T Laboratories
-       Lincroft, NJ 07738
-       U.S.A.
-
-       Phone: +1 732 576 3207
-       E-Mail: tony@att.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman & Hansen                                               [Page 7]
-
diff --git a/doc/devel/I-D/draft-ietf-msgtrk-trkstat-00.txt b/doc/devel/I-D/draft-ietf-msgtrk-trkstat-00.txt
deleted file mode 100644
index dc8e5758..00000000
--- a/doc/devel/I-D/draft-ietf-msgtrk-trkstat-00.txt
+++ /dev/null
@@ -1,498 +0,0 @@
-Internet Draft                                               E. Allman
-draft-ietf-msgtrk-trkstat-00.txt                        Sendmail, Inc.
-Valid for six months                                 December 14, 2000
-Updates: RFC 1893
-
-
-
-
-              The Message/Tracking-Status MIME Extension
-
-                  <draft-ietf-msgtrk-trkstat-00.txt>
-
-Status of This Memo
-
-     This  document  is  an  Internet-Draft and is in full conformance
-with all provisions of Section 10  of  RFC2026.   Internet-Drafts  are
-working  documents  of the Internet Engineering Task Force (IETF), its
-areas, and its working groups.  Note that other groups may  also  dis-
-tribute working documents as Internet-Drafts.
-
-     Internet-Drafts  are  draft  documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by  other  documents
-at  any time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-     The list of current Internet-Drafts can be accessed at:
-
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at:
-
-    http://www.ietf.org/shadow.html
-
-
-     This document is a submission by the MSGTRK Working Group of  the
-Internet  Engineering Task Force (IETF).  Comments should be submitted
-to the msgtrk@imc.org mailing list.  An archive of  the  mailing  list
-may be found at
-
-    http://www.ietf.org/archive/msgtrk
-
-
-     Distribution of this memo is unlimited.
-
-1.  Abstract
-
-        Message  Tracking is expected to be used to determine the sta-
-   tus of undelivered e-mail upon request.  Tracking is used  in  con-
-   junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes-
-   sage Disposition  Notifications  [RFC-MDN];  generally,  a  message
-   tracking request will be issued only when a DSN or MDN has not been
-   received within a reasonable timeout period.
-
-        This memo defines a MIME [RFC-MIME] content-type  for  message
-   tracking  status  in  the  same spirit as RFC 1894, ``An Extensible
-   Message Format for Delivery Status Notifications''  [RFC-DSN-STAT].
-
-Internet Draft          Message/Tracking-Status      December 14, 2000
-
-
-   It  is to be issued upon a request as described in ``Message Track-
-   ing Query Protocol'' [DRAFT-MTRK-MTQP].  This memo defines only the
-   format of the status information.  An extension to SMTP [RFC-ESMTP]
-   to label messages for further tracking and request tracking  status
-   is defined in a separate memo [DRAFT-MTRK-SMTPEXT].
-
-2.  Other Documents and Conformance
-
-        The  model  used  for Message Tracking is described in [DRAFT-
-   MTRK-MODEL].
-
-        Message tracking is intended for use as a "last resort" mecha-
-   nism.   Normally,  Delivery  Status  Notifications (DSNs) [RFC-DSN-
-   SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]  would
-   provide  the  primary  delivery  status.   Only if no response from
-   either of these mechanisms would Message Tracking be used.
-
-        This document is based on [RFC-DSN-STAT].  Sections 1.3  (Ter-
-   minology),  2.1.1  (General  conventions  for  DSN  fields),  2.1.2
-   ("*-type" subfields), and 2.1.3 (Lexical tokens imported  from  RFC
-   822)  of  [RFC-DSN-STAT]  are included into this document by refer-
-   ence.  Other sections are further incorporated as described herein.
-
-        Syntax notation in this document conforms to [RFC-ABNF].
-
-        The  following  lexical  tokens,  defined in [RFC-MSGFMT], are
-   used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR,  CRLF,
-   DIGIT,  LF, linear-white-space, SPACE, text.  The date-time lexical
-   token is defined in [RFC-HOSTREQ].
-
-        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",  "SHALL
-   NOT",  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
-   in this document are to be interpreted as  described  in  RFC  2119
-   [RFC-KEYWORDS].
-
-
-3.  Format of a Message Tracking Status Notification
-
-        A  Message  Tracking Status Notification (MTSN) is intended to
-   be returned as the body of a Message Tracking request  [DRAFT-MTRK-
-   MTQP].   The  actual body MUST be a multipart/related [RFC-RELATED]
-   with type of "tracking-status"; each subpart  MUST  be  type  "mes-
-   sage/tracking-status" as described herein.
-
-   3.1.  The message/tracking-status content-type
-
-           The message/tracking-status content-type is defined as fol-
-      lows:
-
-          MIME type name:           message
-          MIME subtype name:        tracking-status
-          Optional parameters:      none
-          Encoding considerations:  "7bit" encoding is sufficient and
-                                    MUST be used to maintain readability
-                                    when viewed by non-MIME mail readers.
-          Security considerations:  discussed in section 4 of this memo.
-
-
-Allman                                                        [Page 2]
-
-Internet Draft          Message/Tracking-Status      December 14, 2000
-
-
-           The body of  a  message/tracking-status  is  modeled  after
-      [RFC-DSN-STAT].  That body consists of one or more "fields" for-
-      matted to according to the ABNF of RFC 822 headers "fields" (see
-      [RFC-MSGFMT]).  The per-message fields appear first, followed by
-      a blank line.  Following the per-message fields are one or  more
-      groups  of  per-recipient  fields.   Each group of per-recipient
-      fields is preceded by a blank line.  Formally, the syntax of the
-      message/tracking-status content is as follows:
-
-          tracking-status-content =
-                    per-message-fields 1*( CRLF per-recipient-fields )
-
-      The  per-message  fields are described in section 3.2.  The per-
-      recipient fields are described in section 3.3.
-
-      3.1.1.  General conventions for MTSN fields
-
-              Section 2.1.1 (General conventions for  DSN  fields)  of
-         [RFC-DSN-STAT] is included herein by reference.  Notably, the
-         definition of xtext is identical to that of that document.
-
-      3.1.2.  *-type subfields
-
-              Section 2.1.2 (*-type subfields)  of  [RFC-DSN-STAT]  is
-         included  herein  by  reference.  Notably, the definitions of
-         address-type, diagnostic-type, and MTA-name type are  identi-
-         cal to that of RFC 1894.
-
-
-   3.2.  Per-Message MTSN Fields
-
-           Some  fields  of an MTSN apply to all of the addresses in a
-      single envelope.  These fields may appear at most  once  in  any
-      MTSN.   These  fields  are  used  to correlate the MTSN with the
-      original message transaction and to provide additional  informa-
-      tion which may be useful to gateways.
-
-          per-message-fields =
-                    original-envelope-id-field CRLF
-                    reporting-mta-field CRLF
-                    arrival-date CRLF
-                    *( extension-field CRLF )
-
-
-      3.2.1.  The Original-Envelope-Id field
-
-              The optional Original-Envelope-Id field is defined as in
-         section 2.2.1 of [RFC-DSN-STAT].  This field is REQUIRED.
-
-      3.2.2.  The Reporting-MTA field
-
-              The Reporting-MTA field is defined as in  section  2.2.2
-         of [RFC-DSN-STAT].  This field is REQUIRED.
-
-
-
-
-
-Allman                                                        [Page 3]
-
-Internet Draft          Message/Tracking-Status      December 14, 2000
-
-
-      3.2.3.  The Arrival-Date field
-
-              The Arrival-Date field is defined as in section 2.2.5 of
-         [RFC-DSN-STAT].  This field is REQUIRED.
-
-
-   3.3.  Per-Recipient MTSN fields
-
-           An MTSN contains information about attempts  to  deliver  a
-      message to one or more recipients.  The delivery information for
-      any particular recipient is contained in a group  of  contiguous
-      per-recipient  fields.   Each  group  of per-recipient fields is
-      preceded by a blank line.
-
-           The syntax for the group of per-recipient fields is as fol-
-      lows:
-
-          per-recipient-fields =
-                    original-recipient-field CRLF
-                    final-recipient-field CRLF
-                    action-field CRLF
-                    status-field CRLF
-                    [ remote-mta-field CRLF ]
-                    [ last-attempt-date-field CRLF ]
-                    [ will-retry-until-field CRLF ]
-                    *( extension-field CRLF )
-
-
-      3.3.1.  Original-Recipient field
-
-              The  optional  Original-Recipient field is defined as in
-         section 2.3.1 of [RFC-DSN-STAT].  This field is REQUIRED.
-
-      3.3.2.  Final-Recipient field
-
-              The required Final-Recipient field is defined as in sec-
-         tion 2.3.2 of [RFC-DSN-STAT].  This field is REQUIRED.
-
-      3.3.3.  Action field
-
-              The required Action field indicates the action performed
-         by the Reporting-MTA as a result of its attempt  to  delivery
-         the  message  to  this recipient address.  This field MUST be
-         present for each recipient named in the MTSN.  The syntax  is
-         as  defined  in  section  2.3.3  of  RFC 1894.  This field is
-         REQUIRED.
-
-              Valid actions are:
-
-         failed       The message could not  be  delivered.   If  DSNs
-                      have been enabled, a "failed" DSN should already
-                      have been returned.
-
-         delayed      The message is  currently  waiting  in  the  MTA
-                      queue  for  future  delivery.  Essentially, this
-                      action means "the message is located, and it  is
-
-
-Allman                                                        [Page 4]
-
-Internet Draft          Message/Tracking-Status      December 14, 2000
-
-
-                      here."
-
-         delivered    The  message  has been successfully delivered to
-                      the final recipient.  This  includes  "delivery"
-                      to a mailing list exploder.  No further informa-
-                      tion is available; in particular,  the  tracking
-                      agent  SHOULD  NOT  attempt further "downstream"
-                      tracking requests.
-
-         relayed      The message has been delivered into an  environ-
-                      ment that does not support message tracking.  No
-                      further information is available; in particular,
-                      the  tracking  agent  SHOULD NOT attempt further
-                      "downstream" tracking requests.
-
-         transferred  The message  has  been  transferred  to  another
-                      MTRK-compliant  MTA.   The tracking agent SHOULD
-                      attempt further "downstream" tracking  requests.
-
-         opaque       The  message  may  or  may not have been seen by
-                      this system.  No further information  is  avail-
-                      able or forthcoming.
-
-      3.3.4.  Status field
-
-              The  Status  field  is  defined  as  in RFC 1894 section
-         2.3.4.   A  new  code  is  added  to  RFC  1893  [RFC-EMSSC],
-         "Enhanced Mail System Status Codes",
-
-             X.1.9   Message relayed to non-compliant mailer"
-
-                 The mailbox address specified was valid, but the mes-
-                 sage has been relayed to a system that does not speak
-                 this  protocol;  no  further  information can be pro-
-                 vided.
-         A  2.1.9  Status  field  MUST  be  used  exclusively  with  a
-         "relayed" Action field.  This field is REQUIRED.
-
-      3.3.5.  Remote-MTA field
-
-              The  Remote-MTA field is defined as in section Reference
-         2.3.5 of [RFC-DSN-STAT].  This field MUST NOT be included  if
-         no  delivery  attempts  have been made or if the Action field
-         has value "opaque".  If delivery to some agent other than  an
-         MTA (for example, a Local Delivery Agent) then this field MAY
-         be included, giving the name of the host on which that  agent
-         was contacted.
-
-      3.3.6.  Last-Attempt-Date field
-
-              The  Last-Attempt-Date  field  is  defined as in section
-         Reference 2.3.7 of [RFC-DSN-STAT].  This field is REQUIRED if
-         any  delivery  attempt  has  been made, in which case it will
-         specify when it last attempted to  deliver  this  message  to
-         another  MTA or other Delivery Agent.  This field MUST NOT be
-         included if no delivery attempts have been made.
-
-
-Allman                                                        [Page 5]
-
-Internet Draft          Message/Tracking-Status      December 14, 2000
-
-
-      3.3.7.  Will-Retry-Until field
-
-              The Will-Retry-Until field is defined as in section Ref-
-         erence  2.3.8  of  [RFC-DSN-STAT].  This field is REQUIRED if
-         the message is still in the MTA queue.  This field  MUST  NOT
-         be included if the message is not in the local queue.
-
-   3.4.  Extension fields
-
-           Future  extension  fields may be defined as defined in sec-
-      tion 2.4 of [RFC-DSN-STAT].
-
-   3.5.  Interaction Between MTAs and LDAs
-
-           A message that has been delivered to  an  LDA  that  under-
-      stands  message  tracking  (in  particular, an LDA speaking LMTP
-      [RFC-LMTP] that supports the MTRK  extension)  SHOULD  pass  the
-      tracking request to the LDA.  In this case, the Action field for
-      the MTA->LDA exchange will look the same as a transfer to a com-
-      pliant  MTA;  that  is,  a "transferred" tracking status will be
-      issued.
-
-
-4.  Security Issues
-
-   4.1.  Forgery
-
-           Malicious servers may attempt to subvert  message  tracking
-      and return false information.  This could result in misdirection
-      or misinterpretation of results.
-
-   4.2.  Confidentiality
-
-           Another dimension of security  is  confidentiality.   There
-      may be cases in which a message recipient is autoforwarding mes-
-      sages but does not wish to divulge the address to which the mes-
-      sages  are  autoforwarded.   The desire for such confidentiality
-      will probably be heightened as  "wireless  mailboxes",  such  as
-      pagers, become more widely used as autoforward addresses.
-
-           MTA  authors  are  encouraged  to provide a mechanism which
-      enables the end user to preserve the confidentiality of  a  for-
-      warding  address.   Depending  on  the degree of confidentiality
-      required, and the nature of the environment to which  a  message
-      were  being forwarded, this might be accomplished by one or more
-      of:
-
-      (a)  respond with a "relayed" tracking status when a message  is
-           forwarded  to  a  confidential forwarding address, and dis-
-           abling further message tracking requests.
-
-      (b)  declaring the message to be delivered,  issuing  a  "deliv-
-           ered" tracking status, re-sending the message to the confi-
-           dential forwarding address, and disabling  further  message
-           tracking requests.
-
-
-
-Allman                                                        [Page 6]
-
-Internet Draft          Message/Tracking-Status      December 14, 2000
-
-
-           The  tracking  algorithms  MUST  NOT allow tracking through
-      list expansions.  When a message  is  delivered  to  a  list,  a
-      tracking request MUST respond with an "expanded" tracking status
-      and MUST NOT display the contents of the list.
-
-5.  References
-
-   [DRAFT-MTRK-MODEL]
-        T.  Hansen,  ``Message  Tracking  Model  and   Requirements.''
-        draft-ietf-msgtrk-model-03.txt.  November 2000.
-
-   [DRAFT-MTRK-MTQP]
-        T.  Hansen,  ``Message Tracking Query Protocol.''  draft-ietf-
-        msgtrk-mtqp-01.txt.  November 2000.
-
-   [DRAFT-MTRK-SMTPEXT]
-        E. Allman, ``SMTP Service Extension  for  Message  Tracking.''
-        draft-ietf-msgtrk-smtpext-00.txt.  December 2000.
-
-   [RFC-ABNF]
-        Crocker,  D., Editor, and P. Overell, ``Augmented BNF for Syn-
-        tax Specifications: ABNF'', RFC 2234, November 1997.
-
-   [RFC-DSN-REPT]
-        G. Vaudreuil, ``The  Multipart/Report  Content  Type  for  the
-        Reporting of Mail System Administrative Messages.''  RFC 1892.
-        January 1996.
-
-   [RFC-DSN-SMTP]
-        K. Moore, ``SMTP Service Extension for Delivery Status Notifi-
-        cations.''  RFC 1891.  January 1996.
-
-   [RFC-DSN-STAT]
-        K.  Moore and G. Vaudreuil, ``An Extensible Message Format for
-        Delivery Status Notifications.''  RFC 1894.  January 1996.
-
-   [RFC-EMSSC]
-        G. Vaudreuil, ``Enhanced  Mail  System  Status  Codes.''   RFC
-        1893.  January 1996.
-
-   [RFC-ESMTP]
-        Rose,  M.,  Stefferud,  E.,  Crocker,  D.,  Klensin, J. and N.
-        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.  Novem-
-        ber 1995.
-
-   [RFC-HOSTREQ]
-        R. Braden (ed.), ``Requirements for Internet Hosts -- Applica-
-        tion and Support.''  STD 3, RFC 1123.  October 1989.
-
-   [RFC-KEYWORDS]
-        S. Bradner, ``Key words for use in RFCs to  Indicate  Require-
-        ment Levels.''  RFC 2119.  March 1997.
-
-   [RFC-LMTP]
-        J.  Myers, ``Local Mail Transfer Protocol.''  RFC 2033.  Octo-
-        ber 1996.
-
-
-Allman                                                        [Page 7]
-
-Internet Draft          Message/Tracking-Status      December 14, 2000
-
-
-   [RFC-MDN]
-        R. Fajman, ``An Extensible Message Format for Message Disposi-
-        tion Notifications.''  RFC 2298.  March 1998.
-
-   [RFC-MIME]
-        N.  Freed  and  N.  Borenstein,  ``Multipurpose  Internet Mail
-        Extensions (MIME) Part One: Format of  Internet  Message  Bod-
-        ies.''  RFC 2045.  November 1996.
-
-   [RFC-MSGFMT]
-        D.  Crocker,  ``Standard  for the Format of ARPA Internet Text
-        Messages.''  RFC 822.  August 1982.
-
-   [RFC-RELATED]
-        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
-        2387.  August 1998.
-
-6.  Author's Address
-
-       Eric Allman
-       Sendmail, Inc.
-       6603 Shellmound
-       Emeryville, CA  94608
-       U.S.A.
-
-       E-Mail: eric@Sendmail.COM
-       Phone: +1 510 594 5501
-       Fax: +1 510 594 5411
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman                                                        [Page 8]
-
diff --git a/doc/devel/I-D/draft-jones-msgtrk-def-00.txt b/doc/devel/I-D/draft-jones-msgtrk-def-00.txt
deleted file mode 100644
index adf5910a..00000000
--- a/doc/devel/I-D/draft-jones-msgtrk-def-00.txt
+++ /dev/null
@@ -1,222 +0,0 @@
-MSGTRK BOF                             G. Jones [gbjones@mitre.org]
-INTERNET-DRAFT                         B. Ernst [bruce_ernst@lotus.ssw.com]
-draft-ietf-jones-msgtrk-def-00.txt     G. Vaudreuil [gregv@ons.octel.com]
-Expires: February 1999
-
-
-
-
-
-                 Basic Definition of Message Tracking
-
-
-Status of this Memo
-
-This document is an  Internet  Draft.  Internet  Drafts  are working
-documents  of  the Internet Engineering Task Force (IETF), its Areas,   
-and its Working Groups. Note that other groups  may  also  distribute   
-working documents as Internet Drafts. 
-
-Internet Drafts are draft  documents  valid  for  a  maximum  of  six   
-months.  Internet  Drafts  may  be updated, replaced, or obsoleted by   
-other documents at any time.  It is not appropriate to  use  Internet   
-Drafts as reference material or to cite them other than as a "working
-draft" or "work in progress."
-
-To view the entire list of current Internet-Drafts, please check
-the "1id-abstracts.txt" listing contained in the Internet-Drafts     
-Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 
-Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
-ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast).
-
-
-Abstract
-
-This document defines message tracking as a prelude to the creation of 
-a message tracking model. Message tracking is a messaging  management 
-function; it provides the ability to find out, after the fact, the path 
-that a particular message took through the messaging  system, the current 
-status of that message, and its characteristics.
-
-
-Definition
-
-Message tracking refers, in its simplest form, to determining the path an 
-RFC822 message has taken, its current location, and its characteristics. 
-Message tracking allows the originator of a message to issue a request 
-about a previously sent message, the answer to which contains the delivery
-status, delivery time, delivered recipients, and other information about 
-the message. This is different from the delivery status notification (DSN) 
-function in use today, because DSNs are requested at the time of submission
-and are generated automatically; alternatively a tracking request is 
-generated independently of the previously submitted message's status and is
-done so on demand. 
-
-This capability is  analogous to the service provided by carriers of 
-conventional paper mail - the  ability to quickly locate where a package is, 
-and to determine whether or not  the package has been delivered to its
-destination. An Internet-standard approach will allow development of  
-message tracking applications that can operate in a multi-vendor messaging
-environment, and will encourage operation of the function across 
-administrative boundaries.
-
-One might ask: why should there be a standard for message tracking when 
-Internet domains will be unwilling to open themselves up to outside 
-tracking requests ?  This is one reason why we design and implement 
-Internet standards. So that there is a reliable, secure, agreed upon 
-mechanism for message tracking that people will be willing to use. 
-
-Companies have implemented and are implementing message tracking today. 
-Standardization of this technique will aid the Internet user community, 
-make Internet messaging more profitable, and fulfill a key messaging 
-management need.
-
-
-Reasons for Message Tracking
-
-Message tracking is useful for determining the whereabouts and status of 
-"lost" messages, and for several other purposes:
-
-o When there is a lack of trust in the messaging system, such as when an 
-originator claims a message failed to be delivered, the point of failure 
-may be isolated. This includes messages that were never delivered or 
-messages that were delivered incorrectly. Message tracking thus adds to the 
-overall reliability of the mail system;
-
-o Per-message information can be used for accounting, billing, and 
-performance purposes. Traffic can be itemized on a per-origin or per-
-destination basis by system or originator. This typically involves two
-steps - collection of message traffic data, followed by the gehe time they 
-are submitted to an MTA up until the time a network of MTAs discharges the 
-message onward to another entity (e.g. a proprietary mail server, IMAP 
-server, and so on).
-
-o Message tracking information adds security in that the origins of  
-potential security threats can be more precisely determined. If a system 
-were flooded with traffic, for instance, the origin of this traffic would
-become known. Message tracking information is suitable for routine security 
-audits containing the details of messaging traffic over specific time 
-intervals;
-
-o End-to-end delivery time could be measured;
-
-o Message tracking would aid in message loop detection, since unique 
-message identifiers of looping messages, when these exist, would be 
-recorded multiple times;
-
-o Performance characteristics about the type of messaging traffic could be 
-determined, such as when an inbound message causes the creation of multiple 
-outbound messages, and the percentage of messages that were actually 
-delivery reports or receipts.  This is valuable for performance 
-measurement, among other reasons;
-
-o Standardized message tracking information acts as a bridge between 
-dissimilar messaging systems and dissimilar messaging communities;
-
-
-Tracking Messages on the Public Internet
-
-One might ask: why bother to track messages if a majority of public 
-Internet traffic is point to point; messages don't live long enough to be 
-trackable, and are not an interesting event to track since you always 
-know the next point ? Just because you know where a message went that 
-doesn't mean you know what happened to it, how fast it got there, or what 
-was in it. As the Internet is used more and more for commercial/official 
-purposes a logging function is commonly embedded in the messaging system 
-internally. Even if most of the message traffic is point to point, this 
-point-to-point traffic is inter-domain, across firewalls, and thus it is 
-even more important to have a reliable tracking mechanism that 
-organizations can agree on. It is something that intra-domain messaging 
-users want. Even if 95% of transactions are point to point, the 5% that is 
-non point-to-point is still a huge amount of traffic, and this is exactly 
-the traffic that users will want to track. Once messaging traffic enters an 
-intranet or domain of any size it invariably encounters a more hierarchical 
-routing structure. 
-
-
-Who is Allowed to Track Messages
-
-Only the originators of messages are allowed to track their messages. 
-Optionally, an originator may delegate this responsibility to a third 
-party, but this is left for future study.
-
-
-How Tracking is Done: Requests and Responses
-
-The originator will issue a message tracking request using the Unique 
-Message Identifier plus security information. The originator (of both 
-the message and the query at this point) will receive optional response 
-criteria such as the message disposition, delivered recipients, delivery 
-time, and the names of MTAs that handled the message.
-
-
-Security for Message Originators
-
-One option for message security is that the originator calculates a hash A 
-to be equal to the hash of the message ID + time stamp + a per-user secret.
-The user then calculates hash B to be the hash of A. The user includes B in
-the submitted message, and retains A. Later, when the user makes a message 
-tracking request to the messaging system or tracking entity, it submits A 
-in the racking request. The entity receiving the tracking request then uses 
-A to calculate B, since it was already provided B, verifying that the 
-requestor is authentic. Summarily
-
-A = H(message ID + time stamp + secret)
-B = H(A)
-
-If the originator of a message were to delegate his or her tracking request
-to a third party by sending them A, this would be vulnerable to snooping 
-over unencrypted sessions, but the user can decide on a message-by-message
-basis if this risk is acceptable.
-
-
-Three Possible Architectures
-
-There are ways of accomplishing message tracking without mandating the 
-addition of large amounts of new infrastructure on the participants. 
-Optionally, if more infrastructure is proven to be a good and necessary 
-thing, it should be considered. 
-
-In all cases, messages are only tracked from the time they are submitted 
-to an MTA up until the time a network of MTAs discharges the message 
-onward to another entity (e.g. a proprietary mail server, IMAP server, and 
-so on).
-
-The three architectural alternatives offered by the start-up working group 
-to date might be called "ask later", "ask now", and "ask someone else." 
-
-Under "ask later", a user requests tracking as a service when submitting a 
-message, and then at a later time issues a separate tracking request to the
-mail system. The user receives a response to the request from the tracking
-entity. This has the advantage of being deployable within the existing SMTP 
-infrastructure.
-
-Under "ask now", a user requests tracking as a service while submitting a 
-message, and receives a step-by-step report contemporaneously from each MTA
-that handles the message. This provides the user with a high level of 
-service, but also causes extra overhead: an additional message generated 
-for each hop the original message takes.
-
-Under "ask someone else", the user issues a separate message tracking 
-request to an entity other than the messaging system at a later time. 
-The user receives a response to the request from this same third-party 
-tracking entity. This has the advantage of allowing tracking to occur when
-the messaging process has failed but the platform is still working. It also 
-off-loads the tracking function from the messaging system itself. It may, 
-however, require new infrastructure in order to support it.
-
-One possibility would be to implement "ask now" and "ask later" as SMTP 
-extensions. One could implement "ask someone else" as a UDP- or TCP-based
-protocol, among other options.
-
-
-Acknowledgments
-
-Thanks to all those who participated in the message tracking meetings.
-Many thanks to Ned Freed and Harald Alvesrand for the hashing material.
-
-
-Internet Draft              Expires February 1999           Internet Draft
-
-
-
diff --git a/doc/devel/I-D/draft-jones-msgtrk-def-01.txt b/doc/devel/I-D/draft-jones-msgtrk-def-01.txt
deleted file mode 100644
index 61c405bf..00000000
--- a/doc/devel/I-D/draft-jones-msgtrk-def-01.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-
-MSGTRK BOF                             G. Jones [TomorrowSys@yahoo.com]
-INTERNET-DRAFT                         B. Ernst [bruce_ernst@lotus.ssw.com]
-draft-jones-msgtrk-def-01.txt	       G. Vaudreuil [gregv@ons.octel.com]
-Expires: September 1999
-
-
-
-
-
-                 Basic Definition of Message Tracking
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with 
-all provisions of Section 10 of RFC2026.
-
-This document is an  Internet  Draft.  Internet  Drafts  are working
-documents  of  the Internet Engineering Task Force (IETF), its Areas,   
-and its Working Groups. Note that other groups  may  also  distribute   
-working documents as Internet Drafts. 
-
-Internet Drafts are draft  documents  valid  for  a  maximum  of  six   
-months.  Internet  Drafts  may  be updated, replaced, or obsoleted by   
-other documents at any time.  It is not appropriate to  use  Internet   
-Drafts as reference material or to cite them other than as a "working
-draft" or "work in progress."
-
-To view the entire list of current Internet-Drafts, please check
-the "1id-abstracts.txt" listing contained in the Internet-Drafts     
-Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 
-Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
-ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast).
-
-
-Abstract
-
-This document defines message tracking as a prelude to the creation of 
-a message tracking model. Message tracking is a messaging  management 
-function; it provides the ability to find out, after the fact, the path 
-that a particular message took through the messaging  system, the current 
-status of that message, and its characteristics.
-
-
-Definition
-
-Message tracking refers, in its simplest form, to determining the path an 
-RFC822 message has taken, its current location, and its characteristics. 
-Message tracking allows the originator of a message to issue a request 
-about a previously sent message, the answer to which contains the delivery
-status, delivery time, delivered recipients, and other information about 
-the message. This is different from the delivery status notification (DSN) 
-function in use today, because DSNs are requested at the time of submission
-and are generated automatically; alternatively a tracking request is 
-generated independently of the previously submitted message's status and is
-done so on demand. 
-
-This capability is  analogous to the service provided by carriers of 
-conventional paper mail - the  ability to quickly locate where a package is, 
-and to determine whether or not  the package has been delivered to its
-destination. An Internet-standard approach will allow development of  
-message tracking applications that can operate in a multi-vendor messaging
-environment, and will encourage operation of the function across 
-administrative boundaries.
-
-One might ask: why should there be a standard for message tracking when 
-Internet domains will be unwilling to open themselves up to outside 
-tracking requests ?  This is one reason why we design and implement 
-Internet standards. So that there is a reliable, secure, agreed upon 
-mechanism for message tracking that people will be willing to use. 
-
-Companies have implemented and are implementing message tracking today. 
-Standardization of this technique will aid the Internet user community, 
-make Internet messaging more profitable, and fulfill a key messaging 
-management need.
-
-
-Reasons for Message Tracking
-
-Message tracking is useful for determining the whereabouts and status of 
-"lost" messages, and for several other purposes:
-
-o When there is a lack of trust in the messaging system, such as when an 
-originator claims a message failed to be delivered, the point of failure 
-may be isolated. This includes messages that were never delivered or 
-messages that were delivered incorrectly. Message tracking thus adds to the 
-overall reliability of the mail system;
-
-o Per-message information can be used for accounting, billing, and 
-performance purposes. Traffic can be itemized on a per-origin or per-
-destination basis by system or originator. This typically involves two
-steps - collection of message traffic data, followed by the gehe time they 
-are submitted to an MTA up until the time a network of MTAs discharges the 
-message onward to another entity (e.g. a proprietary mail server, IMAP 
-server, and so on).
-
-o Message tracking information adds security in that the origins of  
-potential security threats can be more precisely determined. If a system 
-were flooded with traffic, for instance, the origin of this traffic would
-become known. Message tracking information is suitable for routine security 
-audits containing the details of messaging traffic over specific time 
-intervals;
-
-o End-to-end delivery time could be measured;
-
-o Message tracking would aid in message loop detection, since unique 
-message identifiers of looping messages, when these exist, would be 
-recorded multiple times;
-
-o Performance characteristics about the type of messaging traffic could be 
-determined, such as when an inbound message causes the creation of multiple 
-outbound messages, and the percentage of messages that were actually 
-delivery reports or receipts.  This is valuable for performance 
-measurement, among other reasons;
-
-o Standardized message tracking information acts as a bridge between 
-dissimilar messaging systems and dissimilar messaging communities;
-
-
-Tracking Messages on the Public Internet
-
-One might ask: why bother to track messages if a majority of public 
-Internet traffic is point to point; messages don't live long enough to be 
-trackable, and are not an interesting event to track since you always 
-know the next point ? Just because you know where a message went that 
-doesn't mean you know what happened to it, how fast it got there, or what 
-was in it. As the Internet is used more and more for commercial/official 
-purposes a logging function is commonly embedded in the messaging system 
-internally. Even if most of the message traffic is point to point, this 
-point-to-point traffic is inter-domain, across firewalls, and thus it is 
-even more important to have a reliable tracking mechanism that 
-organizations can agree on. It is something that intra-domain messaging 
-users want. Even if 95% of transactions are point to point, the 5% that is 
-non point-to-point is still a huge amount of traffic, and this is exactly 
-the traffic that users will want to track. Once messaging traffic enters an 
-intranet or domain of any size it invariably encounters a more hierarchical 
-routing structure. 
-
-
-Who is Allowed to Track Messages
-
-Only the originators of messages are allowed to track their messages. 
-Optionally, an originator may delegate this responsibility to a third 
-party, but this is left for future study.
-
-
-How Tracking is Done: Requests and Responses
-
-The originator will issue a message tracking request using the Unique 
-Message Identifier plus security information. The originator (of both 
-the message and the query at this point) will receive optional response 
-criteria such as the message disposition, delivered recipients, delivery 
-time, and the names of MTAs that handled the message.
-
-
-Security for Message Originators
-
-One option for message security is that the originator calculates a hash A 
-to be equal to the hash of the message ID + time stamp + a per-user secret.
-The user then calculates hash B to be the hash of A. The user includes B in
-the submitted message, and retains A. Later, when the user makes a message 
-tracking request to the messaging system or tracking entity, it submits A 
-in the racking request. The entity receiving the tracking request then uses 
-A to calculate B, since it was already provided B, verifying that the 
-requestor is authentic. Summarily
-
-A = H(message ID + time stamp + secret)
-B = H(A)
-
-If the originator of a message were to delegate his or her tracking request
-to a third party by sending them A, this would be vulnerable to snooping 
-over unencrypted sessions, but the user can decide on a message-by-message
-basis if this risk is acceptable.
-
-
-Three Possible Architectures
-
-There are ways of accomplishing message tracking without mandating the 
-addition of large amounts of new infrastructure on the participants. 
-Optionally, if more infrastructure is proven to be a good and necessary 
-thing, it should be considered. 
-
-In all cases, messages are only tracked from the time they are submitted 
-to an MTA up until the time a network of MTAs discharges the message 
-onward to another entity (e.g. a proprietary mail server, IMAP server, and 
-so on).
-
-The three architectural alternatives offered by the start-up working group 
-to date might be called "ask later", "ask now", and "ask someone else." 
-
-Under "ask later", a user requests tracking as a service when submitting a 
-message, and then at a later time issues a separate tracking request to the
-mail system. The user receives a response to the request from the tracking
-entity. This has the advantage of being deployable within the existing SMTP 
-infrastructure.
-
-Under "ask now", a user requests tracking as a service while submitting a 
-message, and receives a step-by-step report contemporaneously from each MTA
-that handles the message. This provides the user with a high level of 
-service, but also causes extra overhead: an additional message generated 
-for each hop the original message takes.
-
-Under "ask someone else", the user issues a separate message tracking 
-request to an entity other than the messaging system at a later time. 
-The user receives a response to the request from this same third-party 
-tracking entity. This has the advantage of allowing tracking to occur when
-the messaging process has failed but the platform is still working. It also 
-off-loads the tracking function from the messaging system itself. It may, 
-however, require new infrastructure in order to support it.
-
-One possibility would be to implement "ask now" and "ask later" as SMTP 
-extensions. One could implement "ask someone else" as a UDP- or TCP-based
-protocol, among other options.
-
-
-Acknowledgments
-
-Thanks to all those who participated in the message tracking meetings.
-Many thanks to Ned Freed and Harald Alvesrand for the hashing material.
-
-
-Internet Draft              Expires September 1999           Internet Draft
-
-
-
-
-