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.

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.

> > 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 -

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

> 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.

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.

> >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.

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.
 
> >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 ?"

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