> {at}DOMAIN fidonet 3:635/727.4 fidonet 3:635/727.4

This is superfluous. Like ^aINTL, it is only necessary when the source and
target domains differ.

 > Hey now.  It's been around 5 years since jim nutt released
 > the FSC-0038, the proposal for the ^aDOMAIN control line.

 > Why do only a handful of FTN developers support this
 > proposal?  In my opinion it could by many developers as a
 > method of determining the full origin and destination 5D
 > addresses of a netmail (and perhaps echomail) messages, yet I
 > can't see anyone using it. :-(

I use it here as a matter of course. However, as with ^aINTL where there is
effectively no specific destination, the proposal does not apply to
echomail.

Also, it isn't necessary to /support/ ^aDOMAIN explicitly for it to be
useful. It is transparent to anyone else and can quite happily remain so.

 > For those who don't have FSC-0038 handy (or are too lazy to
 > find it :-)), here it is.
[copy of FSC-0038 elided]

This is a little over the top, Andrew. These files are available in
compressed form the world over without costing an international link
(multiple of them) to ship it out again. The feed of this conference is
erratic enough as it is without giving someone incentive to remove it from
their import list. The feed for this conference has already been lost at
least once for excess traffic generated by inconsiderate posters.

The spec is a little short on examples, imho. Some folks (you included,
apparently) don't seem to understand it as a result. The only people who
need to worry about ^aDOMAIN lines are the source (usually in a user editor
or similar) and the domain gateway who does the header/INTL/??PT
translation. I'm not sure how many editors do truely support multiple
domains via ^aDOMAIN; the only one I'm sure about is my own.


david

---