The Canadian UUCP Map Coordinator's FAQ Original: Sun Jan 01 02:38:23 EST 1995 Updated: Sun Jun 01 14:00:55 EDT 1997 Version: 1.08f I've accumulated this set of Q&A over the years with the intention of providing a quick reference for those with common questions about the Canadian UUCP maps and how they're handled. The goal is to minimize the volume of repetitious queries which sometimes number hundreds per week. There are always new questions, so if it's not covered below, then please do inquire by sending email to: path@cs.utoronto.ca. Your question (and the answer) will likely be included in the next update. Please ensure you're always reading a current copy, obtainable from: ftp://ftp.cs.utoronto.ca/pub/path/path.faq or http://www.xenitec.on.ca/path-reg.html ------------------------ Q: Please put me in the maps! -or- Please update my map entry for me... A: The Canadian UUCP Map Coordinator is responsible for checking and compiling the UUCP maps for thousands of Canadian organizations and individuals into a rational map set. It's up to the connectivity administrators of those sites to generate, submit and update their individual map entries with the information that they know and the map coordinator typically doesn't until the map entry is produced. Please don't ask the map coordinator to try and do your work for you - it's simply not feasible to do this for everyone within the historical and current framework of a volunteer position. You will however generally find the map coordinator to be fairly responsive if you're stuck and ask for help, as time permits. If you do need help, ensure that the Subject line in your email is commensurate with the urgency of your query. Remember that the map coordinator receives a daily *minimum* of several hundred pieces of email. Q: Please can you call me ... A: It is impossible for the map coordinator to call everyone that might want to correspond by voice. There simply aren't enough volunteer hours in the year and there is no budget to support long- distance calls to folks all over the country. The alternative would be to charge a fee for registrations, and we wish to continue to offer this service at no charge. If it is imperative that voice contact be made, then email the "path" address with a phone number that will facilitate reaching you evenings or weekends as well as during the day. If possible, an exception will be made and the call will be returned "collect" as soon as time to do so becomes available. Q: Why don't you answer your email? A: More properly put, that question might be: "Why didn't you answer the email you didn't get?" Depending on the nature of your correspondence, you will either receive an automated reply almost immediately, or a fairly timely response where human intervention is appropriate. If you have sent email and have no response, please check your routing, check your system mailboxes as well as your personal mailbox a non-delivery notice. Please check any aliases that you may have that might affect mail delivery. Check your routing. Check with your service provider to ensure that they are properly handling your outgoing *and* incoming email and that you indeed have ability to receive incoming email. Try a recursive email test - does it work? Lastly, try to resend, using the "Return-Receipt-To:" header so that you are notified that your email has indeed been delivered to the intended recipient. Did you embed your correspondence in with a map entry submission? If so, the robot processed it, as it should, discarding anything other than the map entry itself. Send seperate email if you want me to see it - don't try to include it with a map entry. (see: "May I combine correspondence with my map entry?") Q: I need an emergency update! A: While discouraged, if link data needs to be urgently corrected to address major mis-routing problems, contact the map coordinator and request an emergency update. Timely response *may* be possible, but can't be promised or guaranteed. In practice, this should and does happen *rarely*. Let's keep it that way. A good way to avoid having any need for an emergency update is to run pathalias on your new map entry with the global map set on your machine. Once you know that you're not about to cause a problem, it's pretty safe to submit it. If you know you're about to cause a problem, don't! Fix your map entry, test it, and then send it in. Q: I deal with a commercial connectivity service provider. Do they do any of this for me? A: Many do, but you should definitely check with yours to see if they submit and properly maintain a map entry for you. Even if they offer this service, you still have the choice of maintaining it yourself. Whichever you choose, please ensure your service provider knows of that choice, so that you don't clobber each others efforts, or worse yet, neither of you does anything. Q: I just received notice that my map entry will be automatically deleted if no one updates it. I thought my service provider takes care of these things for me! A: Often service providers will submit an initial UUCP map entry for a customer. In practice, sometimes they maintain them, sometimes they don't. Contact your service provider and determine whether they are to maintain your map entry or if you prefer to do so yourself. Whoever is chosen should follow the instructions in the notice to update and submit. The information in this FAQ should help you with the rest of your questions, but if you have a new one, holler for help. ** If neither of you do anything, your stale-dated map entry goes away. Q: Where do I send my UUCP map entry? A: path@cs.utoronto.ca If you're sending in map entries for others at their request, please do ensure that you include link data for them in your own map entry if you connect to them. Failure to do this produces an overabundance of backlinks, causing some versions of pathalias to upchuk and die. Q: Are there any Web-accessible docs, tools, and forms? A: You'll find the documentation, interfaces to various search engines and other useful anchors available via URL: http://www.xenitec.on.ca/path-reg.html The new Web "Pathalias Map Entry Generation Tool" is located at URL: http://www.xenitec.on.ca/path-mapgen.html Note that the Web form is in beta test, so please report any problems or suggestions to the undersigned. Q: What happens if I send my map entry to the "pathadmin@cs.utoronto.ca" address I see on ACKs? A: You bypass the map processing robot. It will be forwarded directly to the Map Coordinator, which is ok for correspondence but not very productive if you're trying to get a map entry published. You could easily miss the map compilation if the coordinator hasn't the time to work through the constant email backlog before compiling the maps, as often happens. Q: Please explain the u.can.* files, what do they consist of? A: The Canadian uucp maps consist of two segments: u.can.? and u.can.?? files contain automatically generated entries based on the CA Domain Registrations as is briefly explained towards the top of u.can.1 . In the absence of any additional link data elsewhere, this is what (hopefully) provides the glue necessary to ensure that pathalias knows how to generate a bang-path to you that traverses the listed forwarders for those sending email to (and potentially through) your FQDN (Fully Qualified Domain Name - eg: cs.utoronto.ca). u.can.??.* files contain the uucp map entries submitted by Canadian site admins providing the link data that pathalias uses (vrs DNS) to determine routing to any upstream/downstream sites you may talk to and most importantly pathalias link data indicating your primary connectivity link(s) irrespective of connectivity method. While the entries therein have separate origins, they do work together when both are present. It is normally best that both be present to provide full routing information for those who use pathalias to determine the paths email should take. Q: Please update the forwarders in my CA Registration, so that my automatic entries show correct info. A: Ooops! Wrong number. You want to send this to the liason to CA Registry appropriate to your network. See the CA Registry documentation for the current list of CA Domain Committee members. If you're a customer of a major service provider, they will often be your liason and offer this additional service to you for the fees you pay them. Ask them. Members of the UUCP community and unaffiliated sites may contact the UUCP Liason to CA Registry: registry@cs.utoronto.ca for updates to their CA subdomain registration, forms and documentation. Registration of a new CA subdomain is subject to a fee. Currently there is no charge for updates and assistance. At this time, this is actually the same volunteer human as maintains the Canadian UUCP maps, but it has been separate people in the past and may again be so in future. Best to send requests to the correct address if you want to get things done with minimal delays. Q: I don't use UUCP anymore, all my traffic is routed on the 'NET using DNS now. Do I still need my map entry? A: Your UUCP map entry isn't there for your use, it's there so that those who do route via UUCP and/or use pathalias link data to determine their routing can find a route to you. Q: I have DNS, so why do I need a UUCP map entry? A: Do not assume that the entire world uses DNS. DNS records are fine for those hosts who have access to them or which route email via those with access to DNS. The remainder of the hosts on the planet typically rely on "pathalias" routing, thus are only able to route mail for those sites with UUCP map entries. Mail destined for anyone on a site without a UUCP map entry (irrespective of connectivity method), originating on or requiring re-routing at a site using pathalias for routing, is typically either bounced or hits the bit bucket. "You can't get there from here." We had hoped that eventually the need for UUCP maps would go away. Instead, they continue to grow, as does their use. Consider this as you decide whether you want your site to be reachable from most of the hosts on the planet including those using pathalias based routing, or only from those with access to Domain Name Service records. Today, the UUCP maps may no longer be adequately named. Perhaps they should be called the "Connectivity Maps", as that's exactly what they indicate. If you have a good look through the Canadian UUCP maps, you'll see lots of IP connectivity listed in the map entries of those who enjoy it, to ensure that everyone is aware of their connectivity, not just those with access to Domain Name Service. What we're trying to do is to provide pathalias with lowest-cost routing info, and we're not at all picky about what that route may physically be. Q: I'm registered under .CA. Don't I automatically get a UUCP map entry? A: Actually, you do, but the only information that it will contain is that which can be derived from your CA registration form. It *won't* have any link data in there for other hosts (UUCP or otherwise connected) that you talk to regularly. I would highly recommend that you supplement the automatic entry with your own specific entry, and keep it updated. Q: Now that I have a .CA subdomain registered, should I ask you to delete my map entry? A: No, not unless you have only and precisely the connectivity indicated in your CA subdomain registration "Forwarder" fields. The entry automatically generated from your CA registration form will only show link data for your specified forwarders. It won't have any link data for any other sites you talk to, so you typically will want a separate entry under u.can..* providing that information. Also, remember that deletion of your UUCP map entry returns that site name to the pool of available names, for re-registration by others. Q: What action is required to delete our map entry entirely? A: Map deletion is handled manually. Simply send email to the coordinator (path@cs.utoronto.ca) providing the reason, your authority, and request deletion. Don't forget to tell me which map entry we're deleting! The information you provide will be reported in can.uucp with the next compilation and issue. Remember to advise your neighbours listing link data to your site to update their map entries removing that link data. Q: I'm registered under .com, .org, (or somesuch). Where's my automatic u.can.* entry? A: You're under .COM, .ORG, .NET or anything other than .CA? Sorry, your non-Canadian subdomain registration is outside of our jurisdiction, so any mapping is something you must initiate yourself by submitting a map entry. Only .CA subdomains are known to be automatically and fully mapped at this time. Send in a map entry for your site listing link data to a mapped site. Q: My only connection is with an unmapped site. Help! A: Ideally, you would encourage and ensure that your upstream site is mapped, especially if you are paying them money for connectivity services! Contact them and ensure that they have submitted a map entry for their site, and have listed your site as connecting to them. Q: No matter what I do, I can't get a connection to a mapped site, but I am on the Internet. - or - Q: What is: internet-ca-gws(DEDICATED) A: Ok, you've contacted your Internet Service Provider, and they won't do the right thing (send in a proper map entry), and you aren't in a position to switch to a competent provider? ... Since you are in this case on the directly-connected Internet, specifically there are either MX or NS records in place for your subdomain and thus the sites under it, you may include the following line in your link data, replacing "your_site_name" with the name of your site: your_site_name internet-ca-gws(DEDICATED) By doing so, you are effectively declaring to pathalias that you or your provider can and will receive email for you via smtp using DNS based routing. Note that this doesn't provide pathalias based routes directly to you based on declared costs in your and your neighbours map entries, but simply advises pathalias to generate a route to you via the lowest cost directly-connected Internet site available. This is NOT really the best solution in most cases, but at least your site won't be deemed unreacheable. Please see u.can.1 for details. Do *NOT* do this if a DNS query doesn't return the necessary records for your subdomain! Q: How long is my map entry good for? A: Currently, a Canadian UUCP map entry is valid for 12 months from date of submission. Historically, I've notified holders of stale-dated map entries once or twice annually, and removed those not updated shortly thereafter. I've now automated the procedure somewhat, resulting in automatic bi-weekly notifications and monthly deletions of those entries still not updated. Q: Why do map entries go "stale-dated" at all? A: Map entries that aren't maintained are most often indicative of a permanently dysfunctional site, which *should* be removed from the maps. Your regularly updated map entry (and the thousand+ others for Canada) is the only way we have of knowing that your info *is* current, which in turn allows us to produce UUCP maps for routing purposes where the routes will actually work. Q: How often should I update my map entry? A: Any time there is a change in any of the important information, particularly in your link data, please update your map entry! You may do this as often as you feel necessary. A valid newer map entry simply overwrites the older one. The map processing robot will send you an ACK so that you know your map entry was received and processed, or if there's anything wrong with it, will send you an appropriately descriptive error message. In the event of an error, you want to correct it and resubmit. Don't forget to update your date and time stamp in the #W line. If someone else previously maintained your map entry for you, remember to change the #W line to reflect your address and name - it should always reflect the person who submitted that particular map entry. Do yourself and them a favour and let them know you've assumed responsibility for your own map entry. Q: Can I maintain my map entry as a placeholder until we restore connectivity? A: Yes. Submit a map entry including no link data, thus indicating that your site is not reacheable. Update your map entry, including your new link data when you restore your connectivity. Remember that a "placeholder" map entry, like any other, will become stale-dated once it ages 12 months. Notifications can't reach you if you have no connectivity. The onus is completely on you to remember to update your map entry every 12 months lest it be automatically removed as stale-dated. Please notify "path@cs.utoronto.ca" if it should be removed earlier. Q: Should I use an alias in my #W field? A: The #W line should optimally contain a generic organizational address aliased to the mailboxes of those in charge of connectivity - usually "postmaster", your local equivalent, or perhaps "root". Whichever you specify, please ensure that the alias exists and that it always points to the correct users who should receive notifications and correspondence in future. Q: May I supply multiple #W fields with different addresses? A: Only a single #W line is supported. Consider establishing a local alias to distribute notifications and correspondence as suggested in the answer to "Should I use an alias in my #W field?". Q: How can I include other information? A: Folks commonly include other information as comments between their #W field and their link data. Simply ensure that each comment line starts with a "#" symbol. Don't put comments anywhere else though! Q: I'm moving to another organization, need I do anything? A: Yes, please educate your replacement at your old organization about the existence and maintenance requirements of their map entry. Ensure that an updated map entry is submitted reflecting the new contact information in both the #E line and #W lines. If you neglect this responsibility, you will likely receive notices and such, years after you've moved. You don't need to see them after you move on, but they will often be crucial to the people left behind. When you arrive at your new organization, please ensure that all their registrations, including a map entry, are correct and in place. If your new organization is in another jurisdiction (ie, outside of Canada), consult the comp.mail.maps README file for the map submissions address for that jurisdiction. Q: What's wrong with #N foobar.com ? A: We file Canadian map entries by simple sitename. It's perfectly acceptable (and advisable) to include iterations of your sitename and your FQDN in your #N line, as long as you start it off with your simple sitename - that's what the UUCP Mapping Project knows you as. In this example, you might use: #N foobar, foobar.com, .foobar.com This also preserves your sitename priority registration with the UUCP Mapping Project. If you didn't, then anyone else could come along and register your simple sitename ("foobar" in the example) out from under you, and you would have essentially no recourse, as you effectively and voluntarily surrendered it by not having it appear in your #N line. Submitting a new map entry with an incorrect #N line will of course not supersede your old one, as it is filed by the sitename appearing first in the #N line. Thus, in this example, your old "foobar" map entry would still be present, now conflicting with your new "foobar.com" map entry, requiring the map coordinators manual intervention to fix. In the interim, conflicts in link data often causes misrouting of mail. Q: How do I equivalence my simple sitename to my FQDN? You've now got a Fully Qualified Domain Name (ie, you've registered your subdomain)? Good! Equivalencing it in your link data is a really good way to ensure that any pathalias routed email still winds up at your site. Let's assume you registered foobar.on.ca. You would (plus your other links) want your pathalias link data in your map entry to read: foobar = foobar.on.ca foobar foobar.on.ca(LOCAL), .foobar.on.ca(LOCAL) In combination, you're stating that one address is the same as the other in delivery and that your network and the potential hosts thereunder can be reached using either addressing method. Ensure that you don't neglect to include your link to your Internet Service Provider (or your "upstream" feeds whatever they may be), eg: foobar net-provider.ca(DIRECT) Q: Why does the path@cs.utoronto.ca robot keep sending my my map entry to you personally instead of processing it? A: > #N sitename See that leading "> ", in front of your #N line? So does the map processing robot. When it sees no valid "#N" line, it says to itself: "Hmmmm, this isn't a valid map entry! It must be correspondence for the human. Ah! I'll forward it to his personal mailbox. :-)" You really don't want it to do that. Dropping it into my mailbox instead of having it hit the automated processing routines will at very best delay your map entry until I stumble over it and re-forward it for you. Ensure that your map entry has no leading chars where they should not be. Refer to the comp.mail.maps README file for format details. Q: What's wrong with #Nfoobar ?? Q: What's wrong with #N foobar ?? A: You've omitted the required tab between "#N" and your site name. It needs to be there, or the map processing sfw will not recognize what it thinks is text as actually being a map entry and will simply forward it to the human as correspondence. All the # lines must have a tab between the "label" and the information. Put those tabs back in: #N foobar Q: What does the #F field do? A: At this time the #F field is strictly informational, and optional. It is intended to specify your Internet Forwarder, ie, that host on the Internet which maintains a DNS (Domain Name Service) MX (Mail eXchange) record for your site. If you are on the directly connected Internet, this would typically be the FQDN (Fully Qualfied Domain Name) of your ISP (Internet Service Provider) who holds an A (address) record for you. [What a wonderful excuse for expanding some YAA's (Yet Another Acronym).] Q: Which fields are mandatory, which are optional? A: Mandatory: #N, #S, #O, #C, #E, #T, #P, #L, #U, #W Optional: #F #R The #U line should be left empty if you have no news neighbours. The #R line is optional and may contain information about your site or organization. The rest of the fields need to be there for various reasons, and the map processing script will offer various forms of complaint until you provide the correct information in the mandatory fields. Q: Where do I find the junk for the #L line? -or- What's a (fairly) sure-fire way to get the latitude and longitude for the #L field in map entries for new sites? A: Sources for geographic information include: 1/ URL: http://ellesmere.ccm.emr.ca/cgndb/english/cgndb_lookup.html Querying Canadian Geographical Names - search for your community. 2/ Your local public library usually has a drawer full of detailed local maps. Ask the library reference staff for access. 3/ Check with the local municipal building dept. They have this stuff, and if you get the right person, they'll gladly give it to you. 4/ Look it up in an atlas, and then apply the fudge factors detailed in the comp.mail.maps README file. 5/ Find a map entry in the same city and use those as "city" coordinates (and hope they're right). 6/ Consult URL: http://pubweb.parc.xerox.com/map/ (not as specific as the Canadian server, but still very useful if none of the above work for you) One map submitter advised: "I got mine from the national geodetic survey maps, available from the federal government and from various wilderness camping suppliers. The most detailed of these actually show city blocks and buildings! Mind you, they are often out of date, so a lot of new suburbs are incomplete." Q: Must I submit my map entry as plain ascii text? A: Yes. Only plain ascii text is supported. Various non-ascii character sets, MIME attachment, or proprietary encoding will almost always cause your map entry submission to fail. Q: When will the Mapping Project support 8 bit character sets, for example ISO 8601? A: Much as this may be a very good idea, any implimentation must first rely on someone convincing the author of pathalias to code support for the various 8 bit character sets that some might desire. Check a public archive site near you for the pathalias source code. You can either write to the pathalias author with your suggestion, or submit your own implimentation to the Mapping Project and the 'NET at large. The next thing that would need to happen is for the authors of the various MTAs (Mail Transport Agents) to bring all their code into compliancy and subsequently for operating system vendors to embrace the new standards and incorporate them into their future technology levels. If there is general agreement, various regional map coordinators may eventually find the time to bring their map processing software to compliancy. This would be a non-trivial undertaking for all of the many people that would need to be involved, so would literally take years to accomplish due to lack of the massive amounts of additional volunteer time that would be required. It's certainly not something that one can expect to happen overnight or in the near future. Q: What's the approximate turn-around? Does the processing robot work 'round the clock? A: Yes, the robot works 24 hrs/day, as long as the host it lives on is up, which is virtually always. The map processing robot checks map and pathalias syntax, and either issues stderr or an ACK to the submitter immediately. This of course can and often is subject to connectivity outages, usually on the side of the submitting site. Quite often I receive STDERR bounces or ACKs that simply couldn't find their way back to the submitter. Q: Does the robot do one large batch every month? A: Now we're talking about the human dealing with what's in the spool. Valid map entries are processed as they are received at the "path" address. Once or twice a month, time permitting, I compile all the new valid entries dropped into the spool by the map processing robot, resolve problems, and initiate the process whereby a new u.can.* map set is ultimately posted to comp.mail.maps and reposted to can.uucp.maps. Q: I sent in 4 map entries and heard nothing. Why? A: Either we didn't receive your submission, or we couldn't get back to you. This is especially import when we need to tell you how to fix your map entry and to resubmit. Is the address in your "From:" line reachable? If not, then the auto-reply went nowhere. Watch for the next u.can.* compilation posting report. If you're not listed, bring it to the attention of the human, who can always be found at the Canadian UUCP Map Coordinator's correspondence address: pathadmin@cs.utoronto.ca. Yes, that *is* a different address than were you sent map entries for auto-processing. Q: Will the robot return mail to the person that's listed on the #W line, or to the person who's on the From: (or Reply-To:) line? A: Yes, assuming that we can get it to you. Most hosts upstream of you will try for some varied period (usually somewhere between 8 hours and 8 days), and then bounce it or toss it into their bit bucket. (I suspect that "Reply-To:", if present, takes precedence over "From:") At this time, I only use the #W line address for manual correspondence, and auto-notification of stale-dated map entries. Q: Just how responsive is the human to questions and cries for help? A: That depends on just how overworked the human is at any given time. Seriously. The Canadian UUCP Map Coordinator's position is strictly volunteer, and while that currently consumes somewhere between 10 and 40 hours monthly, it's unpaid and thus does have to be juggled with little details like paying for the resources needed to access the master files and do this job and many others. You may receive an answer to your query within minutes. Other times you may wait quite a while. It all depends on time availability, connectivity when traveling, and severity of the problem being queried. If you're not sure if your query was received, send another a few days later. Q: Must my sitename be unique. If so, unique with what? A: The global UUCP Mapping Project, originally formed to map UUCP site names for pathalias routing purposes, considers a new site to be registered when it appears in the pathalias link data by way of the maps. That sitename must be unique within the first 6 characters, as that's all that pathalias resolves. It is irrelevant that the name may be in use and/or registered in other jurisdictions, although consistency is a nice advantage for the administrator of that site. Q: How can I find out if the sitename I want is already registered by someone else? A: Look it up in the global UUCP map set. If you don't already receive comp.mail.maps and can.uucp.maps, you may want to arrange a newsfeed for these newsgroups. Alternatively, you can use your WWW (World Wide Web) client to access the Global UUCP Map search anchor using URL: http://www.xenitec.on.ca/htbin/uuwhere If all else fails, ask the Canadian UUCP Map Coordinator. Suggest several possibilities. The few seconds it takes to check and reply is a whole lot less work than having to hunt it down and manually yanking it out of the spool at compilation time. NEVER use a UUCP sitename that is already registered with the UUCP Mapping project under any jurisdiction. It's sensible to stay away from using the names of ghost sites as well. While ghost sites only appear in other link data and don't have their own map entry (and hence priority of registration), trying to use them will cause some folks and yourself more aggravation than it's usually worth. If you don't want to handle all the traffic intended for a machine in some place like Argentina whose name you're trying to grab, let it go. Q: Someone in Argentina is trying to steal my name, and I've been using it, registered, since 1988! A: The first organization to submit and see their UUCP map entry published for a given sitename gets registration priority from the UUCP mapping project (not the same as subdomain registration, remember!). Sometimes it's even enforceable, though in reality it's rarely quick, easy or permanent. Priority registration records are maintained only by the global UUCP Mapping Coordinator, who's word is final. Write to the admin at that site and explain the problem. If you get nowhere, write to me, providing all the details and evidence you can. Explicitly state the problem you want me to try and solve. Be patient. Q: Where are the UUCP maps archived? A: There are innumerable archives of comp.mail.maps out there. You're best advised to check with your service provider - they often have public archives, or else "ask archie". Newest copies of the full Canadian UUCP map set always live at ftp://ftp.cs.toronto.edu/pub/path/, as does u.can.tar.Z This directory now also contains copies of the current versions of the comp.mail.maps README file, the Canadian Map Tutorial, and this FAQ. Q: My map entry for "foo_bar" didn't get published! A: Please do avoid the use of the underscore "_" character in sitenames, both in yours and in any in the link data you supply. The map processing robot is not yet smart enough to complain about such and toss the map entry back at the submitter. Unfortunately, pathalias doesn't seem to like underscore characters in link data all, and it's always a chore for the map coordinator to manually hunt them down, yank the map entry from the spool and notify the sender. This often causes delays of up to a few months in publication of a new map entry, as such problems don't show up until compilation time. Q: Why is the robot trying to use my .signature as link data? A: By convention, your .signature should be appended *following* a pair of leading dashes by themselves on the preceding line, like so: -- This is a .signature file ... Anything that appears after that pair of dashes is your .signature. It's the only way the map checker can differentiate between the link data at the end of your map entry and something else, so when you omit them, it looks at this stuff you've appended and thinks "hmmm, more link data - WAIT - wrong format - pathalias SYNTAX ERROR!", and thus spits it back at you instead of processing your intended map entry. Depending on what you put in there, it may slide by the map checker, requiring manual intervention at map compilation time. Either remove your .signature or use it properly. You will be rewarded. Q: May I combine correspondence with my map entry? A: This is unwise. Better to avoid this pitfall and send map entries as distinct unadorned messages to: path@cs.utoronto.ca Use the "pathadmin" address for correspondence, although sending it to "path" will cause it to be forwarded to me *if* and only if there is no valid map entry contained. If you embed correspondence with a valid map entry, the map checking software may find that map entry, (it looks for a valid #N field to start) and in the absence of a problem will simply do its job, thus not bother the human at all. The result is that your correspondence will never be seen by a human, other than by sheer and very unlikely chance. Alternatively, depending on just where you place portions of your text, the entire works might be forwarded to the human rather than being processed. You *might* receive error messages. If you're really excessively creative, your entire submission may even be tossed in the bit bucket. Q: Why do some entries have no link data? A: Occasionally sites may loose connectivity, so may request a map entry with commented or no link data, to ensure that pathalias does NOT try to route any mail via or to this site. Once connectivity is restored, the admin there will wisely remember to submit an updated map entry reflecting their restored (or new) connectivity. The only other reason you may see a map entry with no link data is where the administrator negligently stripped it off their update when they submitted it, thus unknowingly made their site appear unreachable. They should correct this with a new map entry ASAP. Q: Why did you manually change my link data to all lower case when your robot said it was ok? A: The robot needs a better education, just as soon as I (or perhaps my replacement sometime down the road) has time to clue it in. Sorry, you can't use upper case sitenames in your link data. Please don't. Using uppercase sitenames is yet another good way to waste the Map Coordinator's time and delay publication of the Canadian UUCP maps. Speaking of wasting time ... UNPRINTABLE CHARACTERS - *don't* embed them in your link data! Not by accident; not ever! Nothing traps them, so I must occasionally spend hours or days manually doing binary searches only to eventually find those characters and correct that link data. I rarely think kind thoughts about folks who cause this. Q: Ok so now why does the robot complain about my cost weighting in lower case? What's wrong with (direct)? A: You can't have: FOOBAR(DIRECT) FOOBAR(direct) foobar(direct) FoObAr(DiReCt) What will work is: foobar(DIRECT), The sitename must be lower case. The cost weighting must be uppercase. You can't use white space within that data segment, but must use a comma "," separator between different segments of link data. For example: mysite eenie(DIRECT), meenie(WEEKLY), mynie(DAILY/4), moe(LOCAL-1) -or- mysite eenie(DIRECT), meenie(WEEKLY), mynie(DAILY/4), moe(LOCAL-1) Q: Why doesn't it like: uunet(NEVER) in my link data? A: There is no such link cost as (NEVER). The valid costs are described in the comp.mail.maps README file. Perhaps instead you want (DEAD)? Do be advised that even (DEAD) doesn't mean "NOT", it instead means "If you can't find a better route, use this one!". If you "NEVER" want it used, then overwrite your map entry with a newer one completely removing any link data that you don't want at all. Q: What's wrong with: foobar (DAILY) A: See that space between the sitename and the cost? mysite foobar (DAILY) ^ Pathalias won't like that space. Loose it! This example should read: mysite foobar(DAILY) Q: Ooops! I accidently submitted a map with no link data. A: A map without link data is permissible, but pathalias will of course have no way to build an address path to you, so you certainly won't receive any pathalias-route email. Depending on your connectivity, that may totally orphan your site. You likely want to submit a corrected map entry immediately, including your current link data to rectify this problem. If you don't, remember to keep your "place-holder" map entry updated, as you won't be able to receive notifications reminding you when updates are due. Q: How frequently are the Canadian UUCP and Connectivity maps (u.can.*) compiled and published? A: Canadian UUCP maps (u.can.*) are compiled and uploaded to rutgers for posting to comp.mail.maps monthly, as soon as possible following the 5th of each month, time permitting. They incorporate all Canadian UUCP map entry submissions received by "path@cs.utoronto.ca" to the end of the previous month and generally all those at hand at compilation time. Combined connectivity, machine, and human factors occasionally force other variances from the normal schedule. Emergency compilations may be issued at any time, should they be necessary. Q: How do I know when you publish u.can.* A: I religiously post a compilation summary, currently titled: "Maps uploaded to rutgers (for posting to comp.mail.maps and can.uucp.maps); available via ftp." to can.uucp shortly after receiving an acknowledgment from rutgers that they have received the new maps. It will also advise of events of interest to Canadian UUCP map entry maintainers and users as well as tell you of any patching I've had to do to get the maps compiled and out yet again. Make a habit of checking it. Q: Your can.uucp posting 4 weeks ago said you'd uploaded u.can.* to rutgers for posting. Where are they? (translation: What's a rutgers logjam?) A: There may be delays between compilation/uploading and actually posting to comp.mail.maps. Any broken UUCP map submissions by regional UUCP map coordinators anywhere on the planet will cause a logjam at rutgers until such broken map file(s) are overwritten with ones resolving the problem. This has been known to take between a few days and several weeks in the past and is beyond the control of the Canadian UUCP Map Coordinator (although we do prod the global folks). Q: Ed, how long have you been doing the Canadian maps? A: Since March 1992. Most of the automated and processing software that I use was written by the first Canadian UUCP Map Coordinator, Rayan Zachariassen and greatly enhanced and supplemented by Mark Moraes, my immediate predecessor in this hot seat. I've added a few goodies and a lot of patches. As the Canadian UUCP maps grow at a substantial rate, hardly a quarter goes by without something breaking from sheer volume. Let me know if you'd like to wear this hat; I just might take you up on it it you're the right person and hit me at just the right time. Seriously, please do indicate your interest to me. There will come a time when I will pass this hat, and it'd be nice to have some candidates. Q: As a regional UUCP map coordinator, can I use your sfw? A: Rayan has given me verbal release permission and Mark said ok in some email a while back. If I wrote it for "path", then you're welcome to it as well. Therefore, the answer is yes, the software in use at "path.cs.utoronto.ca" is available to map coordinators. Write to me. The entire "path@cs.utoronto.ca" footprint (excluding public archives) is 33.4 megs (Jan 1/94). The core sfw is obviously a lot less, so I could likely strip it substantially for a needy coordinator with lots of patience. Q: What's the largest UUCP map jurisdiction on the planet? A: Arguably, Canada. When last I checked, "California and Arizona" (together) came in as the runner-up; occasionally other jurisdictions hold the largest map set title for a short time. Q: Help! Don't remove me! I got this stale-dated warning, tried to update ... A: Here's some real, live, correspondence, disguised to protect identities. Hi Samuel, You sent me: #N foobar, foobar.bc.ca #F net-provider.ca #S Pentium;SCO UNIX 3.2v4.2 #O My Company or Organization #C Samuel Mapsubmitter #E samuel@foobar #T +1 613 555 1212 #P Unit 1, 123 Mystreet, Vancouver, BC, V5A 4N3 #L 49 18 N / 122 50 W city #R #U net-provider.ca #W postmaster@net-provider.ca (Postmaster); Mon Feb 10 15:29:37 EST 1992 # foobar = foobar.bc.ca foobar foobar.bc.ca(LOCAL), .foobar.bc.ca(LOCAL) foobar net-provider.ca(DIRECT) First, let's strip off all the leading chars so that our info field lines all start with #something, particularly the #N line which identifies this as a map entry, otherwise the map processing script will determine that it's not a map entry, instead interpreting it as is simple text, correspondence, to be tossed at the human. You don't want it forwarded to my personal mailbox, you want it processed! #N foobar, foobar.bc.ca #F net-provider.ca #S Pentium;SCO UNIX 3.2v4.2 #O My Company or Organization #C Samuel Mapsubmitter #E samuel@foobar #T +1 613 555 1212 #P Unit 1, 123 Mystreet, Vancouver, BC, V5A 4N3 #L 49 18 N / 122 50 W city #R #U net-provider.ca #W postmaster@net-provider.ca (Postmaster); Mon Feb 10 15:29:37 EST 1992 # foobar = foobar.bc.ca foobar foobar.bc.ca(LOCAL), .foobar.bc.ca(LOCAL) foobar net-provider.ca(DIRECT) Further to my previous comment ... } >} If you're now maintaining your map entry, you wish to amend your } >} #W line to reflect this fact. It would best if you would establish } >} an alias that always points to your connectivity admin personnel. } >} Remember to change the date on your #W line to that current, lest } >} your map entry update fail the automated processing checks. Ok, your submitted #W line says: #W postmaster@net-provider.ca (Postmaster); Mon Feb 10 15:29:37 EST 1992 Now, that's not you. That's who sent in your previous map entry. If you are now going to maintain it, you want to substitute your address and name. You also want to update the date on that line, or it will be rejected as stale. So, you get: #W samuel@foobar.bc.ca (Samuel Mapsubmitter); Wed Dec 22 00:19:33 EST 1993 ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ how to reach you who you are date/time updated (a working alias that points to you or your admins is even better!) } We also have foobar.com Let's reflect that in the #N line .... #N foobar, foobar.bc.ca, foobar.com ....and equivalence it in your link data (in addition to what's already there), and advise that you talk to that network. foobar = foobar.com foobar foobar.com(LOCAL), .foobar.com(LOCAL) BTW, we didn't talk about this yet, but it would be nice if your #E line contained either a simple bangpath (foobar!samuel) or an address using your FQDN, that's "Fully Qualified Domain Name" (samuel@foobar.bc.ca). Now, let's put all that together: #N foobar, foobar.bc.ca, foobar.com #F net-provider.ca #S Pentium;SCO UNIX 3.2v4.2 #O My Company or Organization #C Samuel Mapsubmitter #E samuel@foobar.bc.ca #T +1 416 462 4606 #P Unit 1, 123 Mystreet, Vancouver, BC, V5A 4N3 #L 49 18 N / 122 50 W city #R #U net-provider.ca #W samuel@foobar.bc.ca (Samuel Mapsubmitter); Wed Dec 22 00:19:33 EST 1993 # # reflect our subdomains foobar =foobar.bc.ca foobar foobar.bc.ca(LOCAL), .foobar.bc.ca(LOCAL) foobar =foobar.com foobar foobar.com(LOCAL), .foobar.com(LOCAL) # foobar net-provider.ca(DIRECT) # reflect our external connectivity That should do it; I've included a couple of comments (ok to do) to give you a better idea of what you're trying to accomplish with your link data (ie, reflecting the links that exist and their costs). Now, based on your earlier comment, everything else is the same, yes? If not, amend the rest of the info as needed. If you talk to any other sites, add them (with the appropriate cost) to your link data. For example, does "foobar" talk to "netxxx" directly? Lastly, you submit it to the map checking/processing robot by emailing it to: path@cs.utoronto.ca ...or, if you don't have a "smart mailer", use, in your case: ...!utcsri!path You will get stderr if you goof, or an ACK if you did things right. It will then go into my spool for inclusion in the next u.can.* compilation (and a copy is forwarded to me on this host for monitoring purposes). Once it's in the next set of maps, the dunning dire warnings will cease - until another year rolls around again. } and netxxx, CA registered as netxxx.on.ca. "netxxx" appears to be a separate map entry. Deal with it in a similar manner. I've checked, and DNS tells me that both the netxxx.com and netxxx.on.ca subdomain registrations that you also own can be handled just as above. If you didn't, you'd ask them to follow the procedure so that they would also be properly mapped instead of being apparently unreachable. } Since I haven't done this } before, any help would be appreciated. I hope this quick demonstration of the changes I know you need help you. } A reference on format or an explanation of each line and it's } exact structure would be helpful. You want to read the "README" file, periodically posted to the comp.mail.maps newsgroup. You do received USENET news? If not, check your local friendly public archive site, or ask me for a copy. The other item of help (aside from this FAQ), is the Canadian UUCP Map Tutorial. It's badly in need of a major overhaul, but it still provides some solid information. Feel free to use your Web browser to get it, ftp it, or if all else fails ask me to mail it to you. Feel free to ask for any additional assistance you may require. --ed (Ed Hew) -- ==> Canadian UUCP Map Coordinator UUCP liason to .CA Domain Registry XeniTec Consulting Services