Re: MSGTRK pre-drafts

Keith Moore wrote:

>[email protected] wrote:
>>
>> Given that SMTP is a subset of message transfer protocols, 2) would mean
>> adding verbs and extensions to the rest of them too.

>uh, no.  yes there are other message transfer protocols, but SMTP is
>the only message transfer protocol of interest.  none of the other
>examples you cited are message transfer protocols.  they can be
>employed to read messages or sometimes to submit messages, but
>they are not designed for this purpose.

Ok - maybe not designed - but they _are_ used.

>it's silly to say that
>every protocol that can possibly be used to transfer mail has to
>be extended to support message tracking,

No - but it would be nice to allow those that are being used to do so.

> or even to say that an
>external message tracking protocol has to support the ability to
>track messages through arbitrary other protocols.

Umm - I'm confused by this.  It seems that you are saying that msgtrk is
for SMTP therefore it is silly to define it for anything other than SMTP -
my contention is that SMTP is not the only way that people and systems
interact with messages that require tracking and therefore tying msgtrk to
SMTP is unnecessarily restrictive.

>> Whilst some of them might need extending to provide or understand the
>> tracking ID hand-off, it seems that incorporating the querying mechanism
>> only into SMTP wouldn't be terribly flexible.

>insisting that a protocol be too flexible is a good way to kill it.

I didn't say the _protocol_ had to be flexible, just that the mechanism of
implementation could make less assumptions about its environment i.e.
didn't assume an existing SMTP session.

>> A particular example might be extending the EDI-INT AS2 spec (EDI,
S/MIME
>> and HTTP).  Not an SMTP server in sight - but a definite need for a
>> trackable message.

>SMTP has explicit support for relaying.  HTTP does not.  I have a
>hard time understanding the need for message tracking when you only
>have two parties handling the message.

Often the http server involved is the front end to a whole system (and may
indeed dump it to SMTP or some other message transfer mechanism for onward
delivery)  I don't agree that the http server will always be an end-point.

>yes, HTTP has proxies, but in the case of a transferring an EDI message
>you want to defeat them.

I'm not 100% sure what this means here.

>there are probably good reasons to consider using an external protocol,
>but IMHO this  isn't one of them.

I suppose it comes down to the question - "Do you assume that any system or
user that needs to track messages must be doing so through a purely SMTP
environment ?"

I guess the alternative is that, for those non-SMTP transfer protocols,
they need to put up an SMTP-a-like on port 25 that only uses the msgtrk
query commands - now that would be confusing.

Paul