Patrik,
The relevant MTA is the point of access into the mail
distribution service. That's equivalent to a telephone handset.
PF> The handset (MUA) is connecting to an MTA which in turn passes the mail
PF> to the receiving MTA.
We can have a fine-grained debate about whether it is the handset or
the local central office, or something in between, that should be
equated to the MTA. (I actually think it would be useful to develop a
common, clear frame of comparison for related services; it will help
us to understand likely implications of design choices.)
However, either one serves the purpose I am citing, namely that users
need to be able to use different ones, in different, independent
places and that pre-registering the set is a serious barrier to
practical and legitimate use.
PF> I further claim the MUA is what moves around and
PF> changes IP address, not the sending MTA. I hear you say the sending MTA
PF> is moving around. If this is not what you are saying Dave, I am sorry
PF> for have misunderstood you.
I am saying that there are lots of initial MTAs around the net and
that users must not be required to use their 'home' MTA. There are
quite a few legitimate scenarios that break if this requirement is
imposed.
There are some users that carry their MTA around with them, but no
that's not the particular case I've been worried about all that much.
Eliminating that case is bad, but not the critical problem.
PF> The problem for this wg is when the sending MTA is moving around, and
PF> what I say is that the number of MTA's which have to be managed
PF> separately is significantly fewer than if the MUA moving around was
PF> part of the problem space.
There are MUAs that are mobile and there are _different_ MUAs, ie, the
users employs multiple independent MUAs. The integrated web mail
service, like greeting cards, and third-party kiosk services are two
popular examples.
I use the telephone handset analogy to describe a style of usage...
from the user's perspective.
PF> And one kind of "more work" is by use of DDNS as I explained in a
PF> separate mail.
perhaps, but it introduces a critical dependency on use of a separate,
substantial mechanism that is not yet deployed and popular. This is
problematic for near-term adoption.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>