Re: MSGTRK pre-drafts

Cutting to the bones ...

msgtrk seems to have 2 thrusts (in addition to the framework)

1) a mechanism to provide and preserve a tracking id.
2) a mechanism to query the status.

1) Is defined only for SMTP.  This I understand.  If other transports need
to provide or preserve  this information then they will have to do so in an
SMTP-friendly style.  This limits the scope to a managable proportion.  I
agree that there is no value in turning the Tracking ID into some kind of
monster that contains a "tracking id type", "originating system" or any
other form of qualifier.  If a message originates in a non-SMTP
environment, but might need tracking through an SMTP one - then the ID
should conform to the proposal, which is something that SMTP knows and
loves.

2) Is what this discussion is all about.  Do we have a new protocol or do
we augment SMTP ?

My belief is that, by choosing to augment the SMTP protocol to provide
tracking information, we will end up with the situation where non-SMTP
systems will put up an interface that will sit on the SMTP well-known port
and behave in part like an SMTP server, but will, in fact, not be capable
of Transfering Mail.  They will simply be stubs for the msgtrk information
that they need to provide.

My contention is that, if we accept that such non-SMTP mail transfer
systems are going to exist and they will wish to provide tracking
information in a standard way - then this means we need to define a
separate tracking protocol that can be implemented without pretending to be
an impotent SMTP server.



My question remains "do we accept that such non-SMTP mail transfer systems
are going to exist and they will wish to provide tracking information in a
standard way"

All the stuff about screwdrivers and pocket-knives was trying to say that
they do and they will.

Paul