Subject: Re: MSGTRK pre-drafts

From: [email-masked]
Date: Fri, 28 Jul 2000 19:33:11 +0100

Keith Moore wrote:

>[email-masked] 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

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jul 2000 15:05:29 -0400

> Ok - maybe not designed - but they _are_ used.

people do all kinds of silly things.  people attempt to use knife tips to 
remove Philips head screws.  that doesn't mean that we should try to
cater to such things.  it's usually hard enough to get the normal cases
to work right.

if you want to say that msgtrk should work over X.400 transports
in addition to SMTP, that's worth considering... but probably not
worthwhile considering that X.400 is mostly dead.  but trying to
define how to make msgtrk work over http, pop, imap, snail mail,
or avian carriers - things that don't transfer messages reliably
in the first place - doesn't seem worth the trouble.

> for SMTP therefore it is silly to define it for anything other than SMTP -

no I'm saying that it's silly to insist that it be usable for any
random protocol that people use to transfer messages.

> SMTP is unnecessarily restrictive.

my contention is that you often have to restrict the probem space in 
order to solve a useful subset of the general problem

recently I sent off a radio to be repaired.  I would love to have been
able to track the movement of radio not only to its initial shipping
destination, but also through its repair, and through its return 
shipment back to me.  

but I claim that the purpose of this group is to define how to track 
Internet mail, and the only standard protocol for transfer of Internet
mail is SMTP.  if you can find a way to make the protocol track 
messages (or parcels, whatever) over arbitrary transports, without 
modifying those transports, or making the protocol too complex,
(don't forget to consider security requirements) and in such a way
that the protocol is attractive to deploy , and which is not much
more difficult than tracking SMTP messages, more power to you.

what I don't accept is that it is necessary to widen the scope of
this group to try to solve that problem.

> delivery)  I don't agree that the http server will always be an end-point.

folks can use http as a user agent if they want to.  but trying to use
it as an intermediary for message transfer is something close to insane.  
HTTP doesn't (in practice) have the kind of status reporting necessary
to say things like "I've accepted responsibility for delivery of this
message".

I really do not want this group to rathole on trying to define how to 
make HTTP work sanely enough so that you can track messages through it,
when people shouldn't be relaying messages through it any way.
 
> user that needs to track messages must be doing so through a purely SMTP

no, that's not the question.  the question is whether this group can 
make more useful progress if it tries to solve the general message
tracking problem, than if it tries only to solve the tracking problem
for standard internet mail protocols.

note that this is really a separate question from whether to do the queries
through SMTP or some other protocol.

Keith