Re: Keywords for "SMTP Service Extension for Content Negotiation"

> At 01:39 -0700 on 07/15/2002, [email protected] wrote about Re:
> Keywords for "SMTP Service Extension for Content Ne:

> >  > Frankly the method of returning capabilities in a bounce
> >>  message seems more effective and more reliable because it doesn't rely on
> >>  intermedaries.
> >
> >The problem I see with depending on notifications is another one of those
> >"looks good on paper" things: For whatever reason, support for sophisticated
> >handling of notifications has been slow to materialize in user agents.

> Agreed. OTOH, since the client is going to have to handle CONNEG in
> any case, adding a notification parser to the mix as part of the
> CONNEG implementation is a different issue since it is not adding the
> notification parser to existent support but adding new support that
> INCLUDES a notification parser as part of its implementation
> requirements. Note that I am not advocating or rejecting a
> notification parser solution but only pointing out what I perceive as
> a fallacy in your analysis of the issue.

I'm not entirely clear on what you're driving at here, but regardless: My point
was and is that resistance against doing certain things in certain ways can be
a lot higher than you'd ever expect it to be, to the point where things just
don't get implemented or deployed.

There are all sorts of good reasons to parse DSNs. But despite the multiple
advantages this capability provides it hasn't materialized in a lot of places
where you'd expect it to. Indeed, what has happened in some of those cases is
that some quite extraordinary kludges have been adopted instead.

I'm guilty of this myself to some extent, I guess: MIXER-compliant X.400
gateways require DSN parsing, but back when I coded such things this capability
was the absolute last thing I added.

I still cannot explain the reluctance. This just isn't rocket science.

				Ned