Subject: Re: MSGTRK pre-drafts

From: [email-masked]
Date: Fri, 28 Jul 2000 18:27:42 +0100

I thought so.

Given that SMTP is a subset of message transfer protocols, 2) would mean
adding verbs and extensions to the rest of them too.

http, ftp, pop3 and imap spring to mind.

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.

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.

1) seems much more flexible in a heterogenous environment

Paul

--
Paul Ford-Hutchinson : EMEA eCommerce application security :
[email-masked]
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005

Tony Hansen wrote:

The two choices on the table are:

1) Provide a separate protocol (the Message Tracking Query Protocol, or
MTQP) that lets you query a message's tracking status.

2) As part of the MTRK SMTP extension, add a verb that lets you query a
message's tracking status. It would be similar in a way to HELP, NOOP,
EXPN and VRFY in that it's not used in the sending of mail messages.

The original proposal was to do the second one. At Adelaide it was
proposed that we do the first one. The support for a separate protocol
was overwhelming among the people who were there.

     Tony Hansen
     [email-masked]

[email-masked] wrote:
>
> Keith Moore wrote:
> >
> > I'd be curious as to the justification for creating a separate
> > protocol for message tracking.  to me it doesn't make any sense.
>
> It is unclear to me what the alternative would be.  Can you elaborate ?

---

From: Tony Hansen <[email-masked]>
Date: Fri, 28 Jul 2000 13:46:57 -0400

No, because the problem space was purposely limited to that of tracking
a message until it has delivered to a user's mailbox or passed on to a
network element for which tracking information cannot be provided. That
is, pop3 and imap would not need additions. I can't say I've ever heard
of ftp being used for message transfer, and http's use has typically
been for message access (ala imap and pop) and not message transmission.

	Tony Hansen
	[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jul 2000 14:04:08 -0400

> 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.  it's silly to say that
every protocol that can possibly be used to transfer mail has to
be extended to support message tracking, or even to say that an 
external message tracking protocol has to support the ability to 
track messages through arbitrary other protocols.

> only into SMTP wouldn't be terribly flexible.

insisting that a protocol be too flexible is a good way to kill it.
 
> and HTTP).  Not an SMTP server in sight - but a definite need for a

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.  

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

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

Keith