randyo@microsoft.UUCP (Randy Orrison) (05/24/89)
In article <KARL.89May22100322@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >Ann Westine <westine@venera.isi.edu> is the domain contact for the .us >top-level domain, which is where random, organizationally-disconnected >machines can become registered. The .us domain is subdivided into >state and city subdomains, and machines are thereby registered >geographically. E.g., there is a machine here for which my machines >perform MX service called sydney.columbus.oh.us. But, unfortunately, they (the .us domain people) seem to be unwilling to delegate control of lower level domains. In the two cases I've been involved in, this has resulted in the formation of non-.us domains so that we could have local control. (The two examples are .mn.org and .wa.com) These serve the purpose that .us intends to serve, but allows bottom level people to deal with local contacts for setup and assistance, instead of having to deal with some remote person they will probably never even meet. I suggest to anyone interested in getting a domain registration that they look into setting up a comparable domain for their state (or city or whatever local unit makes sense). (Specifically, if you're in MN or WA, get in touch with .mn.org or .wa.com) Perhaps a ".usa" domain could be formed for organizations like these? :-) (but :-( that it's necessary) (Note: I wouldn't be bashing these people, but... In Minnesota the .mn.org domain is pretty tightly linked to an active users group, and it is ludicrous to expect each of the 44 sites in the .mn.org domain to have to individually go through a coordinator out of state in order to be registered in .mn.us when we all get together twice a month anyway. Most simply wouldn't do it, which defeats the idea of the .us domain.) I really don't understand the goals of the people administering the .us domain. Is this a money making venture for them, or are they really trying to benefit the national community by bringing domain names to the people? If it's the former, I don't understand why they're allowed control of .us, if it's the latter, their policies are counter-productive. -randyo -- Randy C. Orrison -- Just an employee of Microsoft Corp, not a spokesman uunet!microsoft!randyo microsoft!cctb!randy randy@cctb.mn.org "Gravity really brings me down."
john@jetson.UPMA.MD.US (John Owens) (05/25/89)
In article <5794@microsoft.UUCP>, randyo@microsoft.UUCP (Randy Orrison) writes: > I really don't understand the goals of the people administering the .us > domain. Is this a money making venture for them, or are they really > trying to benefit the national community by bringing domain names to the > people? How could it be a money-making venture? They don't get any money for it! Since they're doing all this as a volunteer effort, as far as I know, they decided to keep it simple and have no wildcard MXs and no delegations of authority. The concept is that if you have an organization big enough to have its own nameserver and a lot of names, that you can be a .ORG; they've developed .US for individual sites. If anyone on the Internet has any problems with "one of those weird .US domains", the NIC can ask Ann or Jon and they'll know everything there is to know about the domain. With NS delegations (or wildcard MXs), they won't be able to say with certainty what is and isn't legal and who's responsible for it. These are just my interpretations of their motives, of course.... -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
chris (Fubar Guru) (05/26/89)
Ok, then, can we do this ONE MORE TIME? :-) I have a machine running fsuucp, and my feeder has agreed to forward mail for me. I suppose i would be fubarsys.slo.ca.us. How? Thanks, --- Christopher J. Ambler Fubar Systems BBS 1525 Mill #6 San Luis Obispo, ----------------------------------------------\ California, 93401-2543 USA n@m_atl(s)a@spa->a@n_af(via-conv)n@w_med | (805) 546-0820 Voice -> Diplomacy, it's not just a game, it's WAR! | (805) 544-9234 Data/BBS
gore@eecs.nwu.edu (Jacob Gore) (05/28/89)
/ comp.mail.uucp / les@chinet.chi.il.us (Leslie Mikesell) / May 26, 1989 / >Smail passing off >to a smart host works fine for sending, but how does a recipient, perhaps >on BITNET, get a response back to you if you aren't in the maps? >... an address like: > a!x.y.z!b!you (replace ! with your favorite character) (That's not an address, it's the end of a path. Your correspondent would still need to figure out how to get to 'a'.) >would mean for the local machine to send to machine a (which it must >know about). Machine a forwards to x.y.z by its choice of methods. >Machine x.y.z forwards to the machine b that it knows about, HOLD IT -- how does 'x.y.z' "know about" 'b' if 'b' is not in the maps? >This approach would avoid the necessity to track the transient connections >of every PC running uupc in the world yet allow the stable machines >to optimize routing to each other. On the contrary. If 'b' is my (God forbid :-) PC, and I move its connection to a place where it's no longer forwarded to by x.y.z, but by l.m.n, then I have to tell everybody who writes to me to stop using you-figure-out-what-goes-here!x.y.x!b!me and start using you-figure-out-what-goes-here-instead!l.m.n!b!me If I call it 'b.c' instead and register it with the domain name service, I just need to tell whatever nameserver on the net is handling the '.c' domain the new information. 'me@b.c' before the move, 'me@b.c' after the move. >A FROM: line line x.y.z!a!me >could then be replied to from anywhere. Unless 'a' itself moves to where 'x.y.z' no longer forwards to it, and 'q.r.s' is doing it instead. >I suspect that it is intentionally not done this way because the domain >nameserver would automatically get stuck with providing name service and/or >forwarding for anything that connects downstream without having the >control process of putting the machine in the domain. "THE domain nameserver"? The Internet nameservers (that's plural, very plural) form a distributed database. Their only purpose is to store this "knowledge" that you seem to expect some "smart hosts" to acquire out of nowhere (about sites that are not listed in any registry, such as the name service database or the UUCP maps). Name servers don't forward mail. They only provide answers about how to deliver mail to a given address. They don't "get stuck" with providing name service -- they exist for that purpose. They have nothing to do with the actual transfer of mail -- they just provide information about which host will accept (and, if necessary, forward) mail for a specific address. The domain naming scheme is there to make it possible to have a distributed (as opposed to simply duplicated) database. You say that 'x.y.z' knows about 'b'? Fine. Then you have two options: give 'b' a domain name so that 'x.y.z' can share that knowledge with other sites, or you go and share it with every one of your correspondents. Personally, I prefer giving people an address that they can send to, without having to figure out the route for the message to take. All I ask of mail systems is to deliver it faithfully to me, and not muck with my return address when the message is from me to somebody else. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
les@chinet.chi.il.us (Leslie Mikesell) (05/29/89)
In article <3400012@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: >> a!x.y.z!b!you (replace ! with your favorite character) >(That's not an address, it's the end of a path. Your correspondent would >still need to figure out how to get to 'a'.) Yes, that's what I meant -- I'd like to see a standard for tacking paths onto both ends of a domain address. >>would mean for the local machine to send to machine a (which it must >>know about). Machine a forwards to x.y.z by its choice of methods. >>Machine x.y.z forwards to the machine b that it knows about, >HOLD IT -- how does 'x.y.z' "know about" 'b' if 'b' is not in the maps? B might be a direct neighbor, but no one but x.y.z needs to know *how*, and only the person who says his address is x.y.z!b!person needs to know that x.y.z is a forwarder. I can't see this as being any more difficult than becoming b.x.y.z!person or person@b.x.y.z which depends on your relationship with x.y.z and generates extra work for thousands of machines that will probably never send mail to b. >If I call it 'b.c' instead and register it with the domain name service, I >just need to tell whatever nameserver on the net is handling the '.c' >domain the new information. 'me@b.c' before the move, 'me@b.c' after the >move. Are you really going to get a 2nd level domain for your single-user machine? How long will it take before an average uucp site will generate the new path to you? I'd prefer to notify people of the change if I cared about getting their mail. >The domain naming scheme is there to make it possible to have a distributed >(as opposed to simply duplicated) database. You say that 'x.y.z' knows >about 'b'? Fine. Then you have two options: give 'b' a domain name so >that 'x.y.z' can share that knowledge with other sites, or you go and >share it with every one of your correspondents. But off the Internet the database is simply duplicated (if we are lucky). I don't mind sharing the knowledge that x.y.z forwards to b with every one of my correspondents. That is, I don't see an address like x.y.z!b!me as being any more difficult to use (or any more ambiguous) than me@b.x.y.z, and I don't think anyone is going to give me a 2nd level domain to simplify it. The problem is that it doesn't work if the sender wants to resolve the end point instead of accepting the senders indication that x.y.z will forward. Les Mikesell
bill@twwells.uucp (T. William Wells) (05/29/89)
In article <8577@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
: >If I call it 'b.c' instead and register it with the domain name service, I
: >just need to tell whatever nameserver on the net is handling the '.c'
: >domain the new information. 'me@b.c' before the move, 'me@b.c' after the
: >move.
:
: Are you really going to get a 2nd level domain for your single-user machine?
: How long will it take before an average uucp site will generate the new
: path to you? I'd prefer to notify people of the change if I cared about
: getting their mail.
Twwells.com is a single-user machine. And if I were to change my map
entry, the procedure would be as follows: move the machine, change
the map entry, poll the *old* neighbors (or have them forward) till
no more mail comes in.
---
Bill { uunet | novavax } !twwells!billwisner@mica.Berkeley.EDU (Bill Wisner) (05/30/89)
>: Are you really going to get a 2nd level domain for your single-user machine? >Twwells.com is a single-user machine. Right. And see also scum.com, conmicro.com, and sigma.com, all of which (when last I checked) contain but one machine.
clutx.clarkson.edu (Drew Derbyshire,,,9143397425) (05/30/89)
From article <8577@chinet.chi.il.us>, by les@chinet.chi.il.us (Leslie Mikesell): > In article <3400012@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: > >>> a!x.y.z!b!you (replace ! with your favorite character) > >>(That's not an address, it's the end of a path. Your correspondent would >>still need to figure out how to get to 'a'.) > > Yes, that's what I meant -- I'd like to see a standard for tacking paths > onto both ends of a domain address. > If you are dealing with RFC-822 mail, the RFC does support explicit routing in the form of the prefix "@host:", such as: @a:@x.y.z:you@b Note that unlike bang (!) routing, this should work with any real RFC-822 mailer, such as the Columbia mailer used by most (read: almost all) Bitnet VM sites. > B might be a direct neighbor, but no one but x.y.z needs to know *how*, > and only the person who says his address is x.y.z!b!person needs to > know that x.y.z is a forwarder. I can't see this as being any more > difficult than becoming b.x.y.z!person or person@b.x.y.z which depends > on your relationship with x.y.z and generates extra work for thousands > of machines that will probably never send mail to b. The basic failure of this argument is that you _must_ know everyone you will ever send mail to, and that you will personally send mail to update them to boot. I have 98 (count 'em, 98) addresses in my regularly pruned alias file, and do you want me to notify all of them just because I added a new poll to my PC's server list? Many of those people will kill the address by mistake or on purpose, and will never have the new address. Drew Derbyshire Clarkson University Class of 1989 (7 years late) Internet: ahd@clutx.clarkson.edu U.S. Mail: 578 Broadway, Apt 6 Voice: 914-339-7425 Kingston, NY 12401
wisner@mica.Berkeley.EDU (Bill Wisner) (05/30/89)
(Someone, anyone, please, please tell me, what kind of a stoopid return address is ahd@sun.soe!clutx.clarkson.edu?) >If you are dealing with RFC-822 mail, the RFC does support explicit >routing in the form of the prefix "@host:", such as: > > @a:@x.y.z:you@b Close, but not quite. Every host beyond the first must be followed by a comma rather than a colon. In other words, @x.y.z:you@a.b.c (this is valid) @p.q.r,@x.y.z:you@a.b.c (this is also valid) @p.q.r:@x.y.z:you@a.b.c (this isn't) w
" Maynard) (05/30/89)
In article <25008@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes: >>: Are you really going to get a 2nd level domain for your single-user machine? >>Twwells.com is a single-user machine. >Right. And see also scum.com, conmicro.com, and sigma.com, all of which (when >last I checked) contain but one machine. The only reason conmicro.com is a single-machine domain is because I can't afford another one... The uunet $35 registration deal is a steal. It's well worth the money. Don't ask me about it; e-mail uunet!domain-request for info. (No, you don't have to be a direct uunet customer; I'm not.) -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. {killer,bellcore}!texbell!splut!jay +---------------------------------------- internet: jay@splut.conmicro.com | "Less great!" "Tastes filling!"
blarson@skat.usc.edu (Bob Larson) (05/30/89)
In article <3135@sun.soe.clarkson.edu> ahd@sun.soe!clutx.clarkson.edu writes: > @a:@x.y.z:you@b Why can't the self-proclaimed rfc822 experts read and remember rfc822 style routing? The correct route is: foobar <@a,@x.y.z:you@b> foobar may be any legal comment, and if you want to follow the host requirments draft (ietf-hosts.rfc on venera.isi.edu) rather than rfc822, it may be omited. (I don't know of any mailer that actually requires it.) The angle brackets are definitly required. Some hosts require that all hosts listed (a, x.y.z, and b) be known domains, but I consider this a rather pedantic enforcement of rfc822 rules. -- Bob Larson Arpa: blarson@skat.usc.edu Uucp: {uunet,cit-vax}!usc!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu usc!ais1!info-prime-request
mju@mudos.ann-arbor.mi.us (Marc Unangst) (05/31/89)
In article <2674@splut.conmicro.com>, jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >The uunet $35 registration deal is a steal. It's well worth the money. >Don't ask me about it; e-mail uunet!domain-request for info. (No, you >don't have to be a direct uunet customer; I'm not.) That's funny; I got my .ANN-ARBOR.MI.US domain registration for free. All you need is a friendly Internet host to forward mail for you, and you're all set. (No, I don't remember the address to request applications from, but I'm sure that they're on SRI-NIC.ARPA. Look around.) -- Marc Unangst UUCP smart : mju@mudos.ann-arbor.mi.us UUCP dumb : ...!uunet!sharkey!mudos!mju UUCP dumb alt.: ...!{ames,rutgers}!mailrus!clip!mudos!mju Internet : mju@mudos.ann-arbor.mi.us
honey@mailrus.cc.umich.edu (peter honeyman) (05/31/89)
Bob Larson asks: >In article <3135@sun.soe.clarkson.edu> ahd@sun.soe!clutx.clarkson.edu writes: >> @a:@x.y.z:you@b > >Why can't the self-proclaimed rfc822 experts read and remember rfc822 >style routing? > >The correct route is: pike and weinberger give some insights of a different nature in "the hideous name" (summer usenix, 1985, portland). peter
clutx.clarkson.edu (Drew Derbyshire,,,9143397425) (05/31/89)
From article <25019@agate.BERKELEY.EDU>, by wisner@mica.Berkeley.EDU (Bill Wisner): > (Someone, anyone, please, please tell me, what kind of a stoopid return > address is ahd@sun.soe!clutx.clarkson.edu?) It's wrong. Next question? My REAL address is simply ahd@clutx.clarkson.edu, but the interaction of "vn" and the news server on sun.soe.clarkson.edu yields the funky address. I'm just visiting this system, so I don't complain (much). > Close, but not quite. Every host beyond the first must be followed by > a comma rather than a colon. In other words, > > @x.y.z:you@a.b.c (this is valid) > @p.q.r,@x.y.z:you@a.b.c (this is also valid) > @p.q.r:@x.y.z:you@a.b.c (this isn't) ooops. Excuse me, I have to go fix a piece of code that assumes the former. Drew Derbyshire Clarkson University Class of 1989 (7 years late) Internet: ahd@clutx.clarkson.edu U.S. Mail: 578 Broadway, Apt 6 Voice: 914-339-7425 Kingston, NY 12401
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (05/31/89)
honey@mailrus.cc.umich.edu (peter honeyman) writes:
pike and weinberger give some insights of a different nature in
"the hideous name" (summer usenix, 1985, portland).
I've seen this paper referenced two other times in the recent past, so
I dug around in my files, pulled it out, and re-read it. My memory of
it wasn't as bad as I feared (but not as good as I hoped, either).
I am alternately impressed and irritated by this paper. On the one
hand, a lot of excellent guidelines are (re-)introduced for naming
schemes. However, a lot of trees were killed for the space in which
to do what seems to me to be gratuitous mudslinging.
There's a lot of discussion on filename representation, the evilness
of VMS' use of no less than 6 punctuation characters and the problems
of late-evaluated dynamic macros, as well as the problems in
interpretation of Berkeley (actually, IBIS and [later?] berknet)
conventions to use host:filename.
When it jumps into the area of mail addressing, I think the bulk of
the gratuitous bashing begins. In particular, the example addresses
(These are given on the cover page and on page 4, and are
research!ucbvax!@cmu-cs-pt.arpa:@CMU-ITC-LINUS:dave%CMU-ITC-LINUS@CMU-CS-PT
and
IJQ3SRA%UCLAMVS.BITNET%SU-LINDY@SU-CSLI.ARPA
and yes, the first does include !@ and :@)
are nothing more than pathological cases of something that was clearly
broken from the outset. Not that the standard in question was broken,
but that the mailers which generated these addresses did not (then)
implement that standard. The moaning about the use of % as a
pseudorouting punctuation character is nothing but moaning; it is not
and has never been a part of anyone's standard, and I don't know of
anyone who advertises it as advisable - I tell my users about it from
time to time to get around temporary, transient difficulties
regarding, e.g., nameserver blackouts and dead links. The same cannot
be said for UUCP !-paths which are absolute until and unless one
implements aggressive rerouting. I think we all know how well that
goes over with The General Populace.
There is also the general complaint that naming requires registration
with a central authority. I consider this complaint vacuous. You can
register with hostmaster@sri-nic.arpa, or you can register with
uunet!uucpmap, take your pick. If you don't register with *someone*,
mail is not going to get back to you, even if you can get mail sent
out properly. Not many people are willing to put up with the need for
manual tracking of UUCP connectivity to any serious extent, especially
if one is prone to receiving mail from a wide variety of sources
through gateways which do not even necessarily use bidirectional
links[*].
In general, the domain naming system gets around the problem by hiding
the issue of transport from the mail-writing user entirely, so that he
no longer needs to worry about it in the least. I have to write a
heck of a lot of mail, and without domains, it would border on the
impossible. I don't care how it gets there, just so long as it does.
There is further complaint that, "the gateway service between BITNET
and ARPANET was made explicit," in the second example. Give me a
break - tell it to the BITNET, OK? If they'd ever get their
collective butts into gear, they would settle down to the task of
registering hosts in the domain system properly somewhere (whether
they do it at UUNET or the NIC, I don't care). Then I would be able
to take out the morbid special case in my mailer where I detect
.BITNET addresses and foist such mail onto a gateway system of which I
know little. With proper use of the domain system, I don't have to
know what network Joe Random is using, and I'm tired of complaints
that .BITNET is abusing the network naming schemes. *When the
standard is properly implemented,* it works well. Those who don't
implement it have no one but themselves to blame for their inability
to get between Here and There.
All things considered, the closing complaint, "despite the words in
the standard about hierarchy, the domain space is completely flat," is
just a lot of nonsense. Consider, for one thing, that this paper was
written when the standard which it so heavily abuses was really rather
new, and there wasn't a whole lot done in the way of implementation
yet. Now, 4 years later, there is considerable support available,
ready-made and off-the-shelf. Plug it in and it goes - and the result
is that now it's not flat.
AT&Ters, the paper in question can be requested from the library as
11271-850508-05TM.
--Karl
[*] I run the archive machine osu-cis, which provides UUCP-accessible
source archives to anyone who cares to call it, using an anonymous
account. Execution of rmail is permitted in this area. We have had
incidents where sites Out There Somewhere (I know not where,
physically) have used osu-cis as their mail gateway to the Known
Universe, with ensuing complaints directed at me from the recipients
of such mail, wondering why mail can't get *back* the way it came.
The answer is obvious, since we don't know about (in a UUCP Systems
file sense) 99+% of the systems which use osu-cis.dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (06/01/89)
In article <KARL.89May31103452@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >Then I would be able >to take out the morbid special case in my mailer where I detect >.BITNET addresses and foist such mail onto a gateway system of which I >know little. To send mail to a host on BITNET, no system outside BITNET should be required to know any other than "hand this to the nearest BITNET gateway and let it handle delivery". The domain scheme violates this basic modularity principle by wanting hosts on BITNET conform to a non-BITNET naming scheme. You can have "France" as the last line of the address on paper mail, and it will get to France, where the French postal service will be 100% responsible for figuring out where it goes. This is simple, efficient, and requires no country to know anything about internal addresses in any other country, or for addressees to register in some world-wide database scheme. Yes, the postal services could have come up with a scheme in which addresses were entirely unrelated to location, but they are smart enough not to try to maintain and update a world-wide database system of domains when there *already* exists a well-defined set of names (names of countries) that will do just fine. When you are talking about connectivity between two networks such that each network is internally well-connected, and there are gateways between the networks, it seems wrong to me to insist that an address not contain information that will tell you which network it belongs to. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume
wisner@mica.Berkeley.EDU (Bill Wisner) (06/01/89)
> (No, I don't remember the address to request applications from, >but I'm sure that they're on SRI-NIC.ARPA. Look around.) US domain requests to westine@isi.edu.
rick@uunet.UU.NET (Rick Adams) (06/02/89)
> The moaning about the use of % as a > pseudorouting punctuation character is nothing but moaning; it is not > and has never been a part of anyone's standard, and I don't know of > anyone who advertises it as advisable - I tell my users about it from > time to time to get around temporary, transient difficulties > regarding, e.g., nameserver blackouts and dead links. This is documented (but discouraged) in section 5.1.2.15 [page 111] of the current hosts requirement rfc. ---rick
kamat@uceng.UC.EDU (Govind N. Kamat) (06/02/89)
In article <7518@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >In article <KARL.89May31103452@triceratops.cis.ohio-state.edu> >karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >>Then I would be able >>to take out the morbid special case in my mailer where I detect >>.BITNET addresses and foist such mail onto a gateway system of which I >>know little. >To send mail to a host on BITNET, no system outside BITNET should be >required to know any other than "hand this to the nearest BITNET >gateway and let it handle delivery". The domain scheme violates this >basic modularity principle by wanting hosts on BITNET conform to a >non-BITNET naming scheme. No one is forcing BITNET hosts to change their names within their net. However, if they wish Internet hosts to recognize who they are and what they are, evidently they have to conform to the domain naming system. The DNS violates no modularity principle; on the contrary, its zones encourage modularity and delegation of authority. >When you are talking about connectivity between two networks such that >each network is internally well-connected, and there are gateways >between the networks, it seems wrong to me to insist that an address >not contain information that will tell you which network it belongs to. Let's assume that tomorrow an "internally well-connected" network, XNET comes along with its own naming scheme. The only sane way to recognize an XNET address externally is to append an uncouth .XNET to it. And create yet another special case in the cf file to push such stuff on to a hardcoded XNET gateway -- one that I have to know all about before I can "let it handle delivery". If some day that gateway disappears, I can just see irate users: "How come my XNET mail is bouncing on this machine, and not on the one down the hall?" I completely agree with Karl's view on this point -- I don't wish to be at the mercy of XNET. >You can have "France" as the last line of the address on paper mail, >and it will get to France, where the French postal service will be 100% >responsible for figuring out where it goes. This is simple, efficient, >and requires no country to know anything about internal addresses in >any other country, or for addressees to register in some world-wide >database scheme. Your analogy is misleading. The name of the country has to be in a language the postal authorities in any country can understand, i.e., similar to the .XNET appendage above. Sure, no one needs to know about your internal addresses. To achieve that (I can't imagine why), just register the network as "XNET.NET." in the DNS, and broadcast a MX for *.XNET.NET pointing to your gateways. This is akin to telling the world how to get to the Central Post Office of France. That institution is not likely to move overnight but a hardcoded gateway very well might. With the domain system, all that needs to be done is update XNET's records, and everyone can see the change. The "*" represents your internal XNET addresses, which have thus not been registered in any world-wide database. Also, as per your desire, everyone everywhere can see that this is a XNET address. The idea of the DNS *is* to steer clear of a world-wide centralized database -- each zone decides what information it wants others to see. In the XNET you wish, seems to me that there is nothing much that others *can* see in any case, even if you wanted them to. That is, unless you get your hosts to change their over to the domain naming convention, at least for their transactions with the outside world. >Yes, the postal services could have come up with a scheme in which >addresses were entirely unrelated to location, but they are smart >enough not to try to maintain and update a world-wide database system >of domains when there *already* exists a well-defined set of names >(names of countries) that will do just fine. Domains are administrative, not topological. But that does not in any way preclude setting up a domain for XNET, using your own set of names as I mentioned above. >Rahul Dhesi <dhesi@bsu-cs.bsu.edu> >UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi >Career change search is on -- ask me for my resume -- Govind N. Kamat College of Engineering kamat@uceng.UC.EDU University of Cincinnati Cincinnati, OH 45221, USA
plocher%sally@Sun.COM (John Plocher) (06/03/89)
In article <1120@uceng.UC.EDU> kamat@uceng.UC.EDU (Govind N. Kamat) writes: >>gateway and let it handle delivery". The domain scheme violates this >>basic modularity principle by wanting hosts on BITNET conform to a >>non-BITNET naming scheme. > >Domains are administrative, not topological. But that does not in any >way preclude setting up a domain for XNET, using your own set of names >as I mentioned above. Which of these are legal? 121.45.33/123.XNET.NET <Secret service>@Washington_D.C.XNET.NET Following your reasoning, Both. Because as you say, they are in the XNET domain. In reality, Neither. The first (121.45.33/123) is the "name" of a fidonet node. This is the name by which other Fidonet nodes identify each other. But, the syntax [0-9]*.[0-9]* is explicitly dissallowed by the domain naming RFCs. The second case is made up, simply to show that you can not use arbitrary "names" for your machines, even if you "hide" them behind a domain name. This "name" uses "@" and "<",">" and "." in ways which are not consistant with the RFCs. I have to agree, in a general way, with the person you quoted. It is not just Bitnet which must change the naming scheme to match. Others have had to also. -John Plocher
kamat@uceng.UC.EDU (Govind N. Kamat) (06/05/89)
In article <107917@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes: >In article <1120@uceng.UC.EDU> kamat@uceng.UC.EDU (Govind N. Kamat) writes: >>Domains are administrative, not topological. But that does not in any >>way preclude setting up a domain for XNET, using your own set of names >>as I mentioned above. > > Which of these are legal? > > 121.45.33/123.XNET.NET > <Secret service>@Washington_D.C.XNET.NET > >Following your reasoning, Both. ... In reality, Neither. > > The first (121.45.33/123) is the "name" of a fidonet node. > This is the name by which other Fidonet nodes identify each > other. But, the syntax [0-9]*.[0-9]* is explicitly dissallowed > by the domain naming RFCs. Not true. For instance, IP addresses are used in the IN-ADDR.ARPA domain. The domain system (DNS) places no restrictions on the content of domain names; in fact, even 8-bit characters may be used. However, the various protocols in use on the Internet -- telnet, SMTP, etc. do have restrictions. Therefore, it is *recommended* that only alphabets, digits and hyphens be used in host names, so that such software won't break. > The second case is made up, simply to show that you can not use > arbitrary "names" for your machines, even if you "hide" them > behind a domain name. This "name" uses "@" and "<",">" and "." > in ways which are not consistant with the RFCs. Our domain server seems to be perfectly happy with "@ < >" in domain names. These characters are specified as special in the mail RFC, #822, which predates the domain RFCs. If they occur in the so-called "local-part", they have to be placed inside a quoted string. Even while processing XNET mail as a special case, as would be done today, this cannot be avoided. In other words, XNET participating in the domain system does not introduce any additional complexities. >I have to agree, in a general way, with the person you quoted. It is >not just Bitnet which must change the naming scheme to match. Others >have had to also. Don't get me wrong: I am not trying to belittle the problems in converting to a different naming convention. That is necessarily a painful process. However, it is not reasonable to expect the world at large to continue to provide special treatment for various "internally well-connected" networks like the hypothetical XNET. Which is what Rahul Dhesi was suggesting. > -John Plocher -- Govind N. Kamat College of Engineering kamat@uceng.UC.EDU University of Cincinnati Cincinnati, OH 45221, USA
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (06/05/89)
In article <1137@uceng.UC.EDU> kamat@uceng.UC.EDU (Govind N. Kamat) writes: >The domain system (DNS) places no restrictions on the content >of domain names; ... That's not the problem. The problem is that the domain naming system, while claiming to allow a "local part" to be interpreted by the host, in fact wants that local part to have a specific syntax. More importantly, in a multi-network system there will be many local parts, one for each network, and the domain naming system makes it nearly impossible to have this. >However, it is not reasonable to expect the world at >large to continue to provide special treatment for various "internally >well-connected" networks like the hypothetical XNET. Which is what >Rahul Dhesi was suggesting. I was suggesting nothing of the sort. (The Internet is not "the world", by the way.) I was essentially saying, "if you want to get mail to a BITNET host, just give it to a gateway and let BITNET be 100% responsible for delivering it." The ONLY part of a bitnet address that another network should look at should be a trailing .BITNET string, which identifies the network. Therefore <jklsjdf><<<Jkldf>>!%%%!x@b#&*()$jsdfkjljsd;fadf&*7987904klj;l;.BITNET should be a valid address. It isn't, and that's half the problem. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume
wisner@mica.Berkeley.EDU (Bill Wisner) (06/06/89)
(Rahul Dhesi) > <jklsjdf><<<Jkldf>>!%%%!x@b#&*()$jsdfkjljsd;fadf&*7987904klj;l;.BITNET > >should be a valid address. It isn't, and that's half the problem. Pfthhht. If that address is strictly limited to within BITNET, fine. But if BITNET wants to communicate with the rest of the world, it must respect the rest of the world's conventions.
clutx.clarkson.edu (Drew Derbyshire,,,9143397425) (06/06/89)
From article <25270@agate.BERKELEY.EDU>, by wisner@mica.Berkeley.EDU (Bill Wisner): > (Rahul Dhesi) >> <jklsjdf><<<Jkldf>>!%%%!x@b#&*()$jsdfkjljsd;fadf&*7987904klj;l;.BITNET >> >>should be a valid address. It isn't, and that's half the problem. > > Pfthhht. If that address is strictly limited to within BITNET, fine. But I've got ten bucks if Rahul can give me the name of *one* host acting on the Bitnet side as a gateway that can handle that address (ignoring the gateway, UUCP, internet, etc.) Any internal Bitnet address has to have an 1-8 character host name for starters, and his example does not clarify the issue. Nor does this... oh well.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (06/07/89)
dhesi@bsu-cs.bsu.edu writes:
I was essentially saying, "if you want to get
mail to a BITNET host, just give it to a gateway and let BITNET be 100%
responsible for delivering it."
That is exactly what is wrong: Asking mail users to know the network
connectivity underlying their correspondence.
I expect a mailer to hand a BITNET-bound piece of mail to some BITNET
gateway, and for that gateway to be 100% responsible for safe
delivery. But I, as a mail user, don't expect to have to know that
such a gateway was needed.
If you send mail to me, you address it in geographic hierarchy. You
don't know how the planes, trucks, and humans push it around, and you
don't care. The system knows its own internal connectivity, and does
the work for you without intervention by either the sending or
receiving human.
If you send email to me, you address it in organizational hierarchy.
You don't know how the networks, routing gateways, and phone lines
push it around, and you don't care. The system knows its own internal
connectivity, and does the work for you without intervention by either
the sending or receiving human.
I don't have to know the name of the mail delivery person who goes
down your street every day. But for some reason, you expect me to
know the name of the mail delivery network which connects your system
to the rest of the world. The two are exactly analogous.
--Karldhesi@bsu-cs.bsu.edu (Rahul Dhesi) (06/07/89)
In article <KARL.89Jun6155004@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) quotes me as saying "If you want to get mail to a BITNET host, just give it to a gateway and let BITNET be 100% responsible for delivering it." and responds: >That is exactly what is wrong: Asking mail users to know the network >connectivity underlying their correspondence. There is a misunderstanding here. The "you" in the quote refers to the software responsible for correctly routing mail, not to the user. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume
amanda@mermaid.intercon.com (Amanda Walker) (06/30/90)
About uunet's $35 'domain registration fee' -- this fee includes not only dealing with the NIC for you but also setting up MX forwarding for you on uunet.uu.net and seismo.gss.gov (as a secondary). As I understood it, the fee was set up to cover the operator's time in taking care of all of this. Karl may be cheaper, but as he said, you may get bumped way down on his priority list, which can get mind-bogglingly long sometimes :-)... -- Amanda Walker InterCon Systems Corporation --
wengland@stephsf.stephsf.com (Bill England) (07/01/90)
In article <268BDD16.4F4B@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >About uunet's $35 'domain registration fee' -- this fee includes not only >dealing with the NIC for you but also setting up MX forwarding for you on If someone has not pointed this out yet as a uunet subscriber, where you pay $35 per month anyway, domain registration is _free_. +-------- | Bill England | Stephen Software Systems, Inc., Tacoma Wa. | wengland@stephsf.com +1 206 564 2122 | * * H -> He +24Mev * * * ... Oooo, we're having so much fun making itty bitty suns * * *
tp@mccall.com (07/02/90)
In article <268BDD16.4F4B@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > About uunet's $35 'domain registration fee' -- this fee includes not only > dealing with the NIC for you but also setting up MX forwarding for you on > uunet.uu.net and seismo.gss.gov (as a secondary). As I understood it, the > fee was set up to cover the operator's time in taking care of all of this. As I read the documentation they sent me (email and paper), the MX forwarding is ONLY available to their subscribers. If you are a subscriber, there is no charge to register your domain. On the other hand you pay $35 per month. This is fine if you otherwise make use of their services, but incredibly steep if all you wanted was an MX forwarder! -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
les@chinet.chi.il.us (Leslie Mikesell) (07/26/90)
In article <961@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >>What we need is a ".phone" domain. Mail to someone at "+17135551212.phone" is >>accomplished by making a call to +17135551212, logging in as anonymous, and >>sending mail. >Interesting idea... > user@+number.phone for dialup mail > user@+number.fax for fax What we really need is a single machine that understands both. The originator should put a tone on the line so that the answering machine can automatically roll over to a voice phone or modem when something else calls, thus avoiding the need for separate lines. It should interoperate with existing fax machines, converting text to fax image when it detects that it is sending a mail message to a fax-only device. When 2 similar machines connect, they would use something resembling SMTP to exchange either text messages or encoded images with encapsulating headers that would allow forwarding over typical mail connections. The simplest versions would probably be PC cards with software to view, print and manipulate using the normal PC devices. Standalone units might have serial ports, network connections, hard disk (of course), fax-style scanner and printer, etc. A single machine could thus give you fax-over-internet and mail to anywhere you can dial. >Are we going to allow them in routes? > > site_a!site_b!+18005551234.phone!site_c!site_d!user Normally you would just dial up the one you want. Do people forward faxes? There should be a way to include an inbound address, but it would be up to the installation to decide what to do with it. Handling at least one hop of routing would make sense where a local phone connection exists between one endpoint and a forwarding machine which has network or dedicated conections to the other endpoint. I don't see why such a device should cost much more than existing fax equipment other than the HD storage and with 200M 3 1/2" drives available for around $1,000, that would only double the cost. Hmmm... maybe it should do voice mail as well. Les Mikesell les@chinet.chi.il.us
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (07/27/90)
In article <1990Jul26.025310.4158@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <961@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: } }> user@+number.phone for dialup mail }> user@+number.fax for fax } }What we really need is a single machine that understands both. The originator }should put a tone on the line so that the answering machine can automatically }roll over to a voice phone or modem when something else calls, thus avoiding }the need for separate lines. It should interoperate with existing fax }machines, converting text to fax image when it detects that it is sending }a mail message to a fax-only device. When 2 similar machines connect, they }would use something resembling SMTP to exchange either text messages or }encoded images with encapsulating headers that would allow forwarding over }typical mail connections. The simplest versions would probably be PC cards }with software to view, print and manipulate using the normal PC devices. }Standalone units might have serial ports, network connections, hard disk }(of course), fax-style scanner and printer, etc. A single machine could }thus give you fax-over-internet and mail to anywhere you can dial. Actually what I had in mind was using the existing fax protocols. Specifically there is proposal to standardize a file transfer protocol (BFTP) using fax modems. So if you are sending mail you fire up your T.30 protocol engine, connect to the remote end and check if they support BFTP. If they don't you deliver the message by converting to a bitmap and sending the image. If the remote end supports BFTP you forward a (for example) BSMTP file containing the mail message and information on how to forward. With some of the new modems coming out you will be able to get Fax, 1200/2400 and MNP all in one box. So the above becomes feasible. It will probably take another year or so before the modems are able to provide mechanisms to allow incoming calls to be either fax or data. Rest assured that the modem manufacturers know that we want that. They just havn't figured out how to do it reliably. }>Are we going to allow them in routes? }> }> site_a!site_b!+18005551234.phone!site_c!site_d!user }Normally you would just dial up the one you want. Do people forward faxes? Yes, they do. And with BFTP sending a BSMTP file the above would work. We probably do want two protocols though. user@+number.phone for dialup mail Would allow mail to be forwarded to a remote site, assuming a 1200/2400 Hayes compatible modem at the far end. Perhaps a BSMTP file transferred using ZModem or Kermit. user@+number.fax for fax Would allow mail to be forwarded to a remote site by sending a bit image if the remote machine is note capable of BFTP (i.e. a real fax machine) or using BSMTP via BFTP if the remote machine is capable. We can make the assumption that the contents of the mail message is RFC822 compatible. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
les@chinet.chi.il.us (Leslie Mikesell) (07/27/90)
In article <1075@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >With some of the new modems coming out you will be able to get Fax, >1200/2400 and MNP all in one box. So the above becomes feasible. I'm not particularly interested in 1200/2400 compatibility. 9600 baud V.29 would work just fine for data transfers. What I'd like to see is a store & forward "appliance" that could send and receive between similar machines over the phone lines with a compatibility mode for existing fax machines. Connections to computers would be done through a serial or network port (or PC buss), so there would be no need for this machine to have direct compatibility with any existing non-fax modems. A prime requirement would be the ability to detect calls from non-compatible equipment and roll over automatically to another built-in phone port which could go to your choice of voice phone or modem (depending on the current use of the existing phone line). Thus if you want modem compatibility you would just roll over to your choice of modems. >It will probably take another year or so before the modems are able to >provide mechanisms to allow incoming calls to be either fax or data. Rest >assured that the modem manufacturers know that we want that. They just >havn't figured out how to do it reliably. The way to do it reliably is to forget backwords compatibility and compromises with interactive operation. Go for high-speed bulk transfers to a hard disk in the same device and your call will be finished in the time it takes for 47 flavors of modem handshakes to even start. Hard disks are cheap these days and many offices could justify such a device for fax-only use based on the time savings in scanning onto a local disk with the image transfer (compressed if the remote is compatible) happening when the phone lines and remote system are available. Put the backwards compatibility on the serial port or network link to the local computer, with perhaps a new standard or two. >We probably do want two protocols though. > user@+number.phone for dialup mail >Would allow mail to be forwarded to a remote site, assuming a 1200/2400 >Hayes compatible modem at the far end. Perhaps a BSMTP file transferred >using ZModem or Kermit. This would be on the serial port/normal modem side. One standard should look very much like SMTP layered under Kermit. The additions needed to the protocols would be better initial handshaking for kermit to establish the optimum modes and a BSMTP variation when the sender isn't especially interested in the responses or is using an existing version of kermit to transfer files. For backwards compatibility, uucp transfers could be built in as well. >We can make the assumption that the contents of the mail message is RFC822 >compatible. The other standard needed is a format for encapsulating fax images inside of mail messages. Optimal compression would be very important so uuencoding should be avoided unless the next hop is known to have arbitrary restrictions on the message content. This may already be addressed by X.400 standards for multi-part messages and is, in fact the most important part of making the scheme work since it will provide the ability to store and retrieve images in a standard format. "Nifty" features (perhaps optional) would be the ability to detect and log inbound caller-id with the messages, and to use DTMF for control functions. For example, you might want to set up a machine to hold your mail until you call up, punch in your access code and the fax number where you want it printed out. Les Mikesell les@chinet.chi.il.us
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (08/02/90)
In <1990Jul26.025310.4158@chinet.chi.il.us> les@chinet.chi.il.us
(Leslie Mikesell) writes:
What we really need is a single machine that understands both
[email and fax]. I don't see why such a device should cost much
more than existing fax equipment [with some caveats].
I think that asking anybody who already has a computer and a modem to
invest more money in a new machine for email is not a good idea. We
need a dial-up email standard that anybody who already has PC and modem
can use by simply loading some software.
It's good if the fax machine makers become compatible with this
standard; it's not good for this standard to be incompatible with
existing PCs and modems.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesisl@van-bc.wimsey.bc.ca (Stuart Lynne) (08/03/90)
In article <2118@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In <1990Jul26.025310.4158@chinet.chi.il.us> les@chinet.chi.il.us >(Leslie Mikesell) writes: > > What we really need is a single machine that understands both > [email and fax]. I don't see why such a device should cost much > more than existing fax equipment [with some caveats]. > >I think that asking anybody who already has a computer and a modem to >invest more money in a new machine for email is not a good idea. We >need a dial-up email standard that anybody who already has PC and modem >can use by simply loading some software. > >It's good if the fax machine makers become compatible with this >standard; it's not good for this standard to be incompatible with >existing PCs and modems. That would be nice but... One of the problems is that data modems are connected to many types of computers, each of which has different ideas on how they want you to initiate a connection. I.e. baud rates, parity, login sequences, etc. And you will be very hard pressed to come up with a method to use data modems that can get into *any* existing system to deposit mail. Unless you can replace the front ends on a lot of different systems. (Like getty on unix, who knows what on VMS..) The advantage Fax has is a very specific sequence of events to establish a connection to a given phone number. Once connected a very specific sequence of negotiations to establish what each side is willing to do. This already exists and is useable. With some extensions (ECM, BFTP) it quite reasonable to assume that an EMail message can be sent to a "phone number" with the decision about delivery being made as a bitmap, or the original ASCII text being deferred until you have connected and discovered whether the machine on the other side supports file transfer. Also remember that there are more real fax machine's available as destinations for you email than pc's with data modems. So hoisting this all on fax gives you a larger number of potential targets than doing so with data modems. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
peter@ficc.ferranti.com (Peter da Silva) (08/05/90)
In article <1193@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: > In article <2118@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > >In <1990Jul26.025310.4158@chinet.chi.il.us> les@chinet.chi.il.us > >(Leslie Mikesell) writes: > > What we really need is a single machine that understands both > > [email and fax]. ... > >I think that asking anybody who already has a computer and a modem to > >invest more money in a new machine for email is not a good idea. We > >need a dial-up email standard that anybody who already has PC and modem > >can use by simply loading some software. > That would be nice but... One of the problems is that data modems are > connected to many types of computers, each of which has different ideas on > how they want you to initiate a connection. So standardise on a string to send to indicate you want to exchange mail, and an authorisation string (login and password). Call at higher baud rates, and if that fails hang up and call back at a lower baud rate. It's a SMOP. The simplest algorithm would be: send CR, wait until the other end stops sending data, send "email<CR>", wait until the other end stops sending data, send a password, and wait for a start packet. > Also remember that there are more real fax machine's available as > destinations for you email than pc's with data modems. But none of them have the email support, so they will have to be replaced anyway if you want anything more than the existing capability. I can already send a FAX via Email, anywhere in the world... why should I spend $1000 on extra hardware if it doesn't buy me anything? And a terminal and 2400 baud modem is less than half the price of just your smart FAX peripheral. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
les@chinet.chi.il.us (Leslie Mikesell) (08/10/90)
In article <2118@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >I think that asking anybody who already has a computer and a modem to >invest more money in a new machine for email is not a good idea. We >need a dial-up email standard that anybody who already has PC and modem >can use by simply loading some software. Yes, you can use a refigerator as a paperweight but not everyone likes to do it just because the referigerator was expensive. There already is a dial-up email standard in the form of uucp mail, and there is software available to emulate it on a variety of machines. There are also several reasons why it it not widely used. >It's good if the fax machine makers become compatible with this >standard; it's not good for this standard to be incompatible with >existing PCs and modems. There have to be orders of magnitudes more fax machines around than PC's that are continuously available for email reception, so I would make this argument the other way around. Anyway, all you need is a forwarding machine to gateway between a new optimal method and existing equipment. If you don't have enough traffic to justify a gateway, well, then it doen't matter much anyway - you might as well just have an account with mcimail, attmail, CIS, or the like. Attmail (and probably some of the others) provides PC software to hide the details of the connection. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (08/10/90)
In article <B2=4HM6@ggpc2.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> That would be nice but... One of the problems is that data modems are >> connected to many types of computers, each of which has different ideas on >> how they want you to initiate a connection. >So standardise on a string to send to indicate you want to exchange mail, >and an authorisation string (login and password). Call at higher baud rates, >and if that fails hang up and call back at a lower baud rate. It's a SMOP. Hmmm, doesn't sound optimal to me. >The simplest algorithm would be: send CR, wait until the other end stops >sending data, send "email<CR>", wait until the other end stops sending >data, send a password, and wait for a start packet. I'd like to get away from the "simplest" methods and go directly to the fastest possible. Also, it should be possible to detect calls from similar devices so other calls can be passed to another device. An algorithm where the sender starts sending as soon as the connection is established using a standard speed and protocol would be nice. If the receiver doesn't want it, wants to go faster or misses something, it can mention it in the return packets. >> Also remember that there are more real fax machine's available as >> destinations for you email than pc's with data modems. > >But none of them have the email support, so they will have to be replaced >anyway if you want anything more than the existing capability. I can already >send a FAX via Email, anywhere in the world... why should I spend $1000 on >extra hardware if it doesn't buy me anything? I agree that munging email capability into existing pc-fax modems is a bandaid solution (cheap 9600 baud, but not much else). What I want to see is an integrated and optimized modem, CPU and hard disk with a simple set of commands to store messages and deliver to a specified phone-number destination. The only real option would be to deliver to standard fax machines if that is what answers, and to store a fax image if called by a fax machine. Everything else would be controled by the host software, and to that end it should be possible to retrieve the message "envelope" without the body so forwarding would be possible without copying the data to the host and back. Les Mikesell les@chinet.chi.il.us