LISTSERV mailing list manager LISTSERV 16.0

Help for ISOJAC Archives


ISOJAC Archives

ISOJAC Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ISOJAC Home

ISOJAC Home

ISOJAC  March 2000

ISOJAC March 2000

Subject:

Re: Resolutions

From:

Håvard Hjulstad <[log in to unmask]>

Reply-To:

ISO 639 Joint Advisory Committee <[log in to unmask]>

Date:

Thu, 2 Mar 2000 13:38:16 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (497 lines)

Dear fellow JAC members,

The "resolutions" from the JAC meeting in Washington are very good indeed. I
have just a few comments. Most of them are minor clarifications.

I have copied in the text of the resolutions document below. It may lose
even more of its formatting going through various conversion processes, but
you all have the original document to compare with.

Please see below. The first comment is under item 2.5.1.3, so just skip down
quite a bit.

Best regards
Håvard

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Håvard Hjulstad           mailto:[log in to unmask]
  Rådet for teknisk terminologi
  (Norwegian Council for Technical Terminology)
  Postboks 41 Blindern
  NO-0313  Oslo, Norway
  (besøksadresse/visiting address: Forskningsveien 3 B)
  tel: +47-23198040   faks: +47-23198041
  http://www.rtt.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> -----Original Message-----
> From: Rebecca S. Guenther [SMTP:[log in to unmask]]
> Sent: Tuesday, February 29, 2000 9:07 PM
> To:   [log in to unmask]
> Subject:      Resolutions
> 
> Attached to this message is a file containing the resolutions from our ISO
> 639 JAC meeting on 17-18 Feb. 2000.
> 
> I do plan to edit documents N2 and N3 as well as all the work we agreed
> upon on the Web site. I just haven't yet had time.
> 
> Thank you all for your hard work. It is clear from this document how much
> we accomplished!
> 
> Rebecca
> 
> 
> 
> ===== TEXT COPIED IN =====>
> 
> 
> ISO 639/JAC Resolutions
> February 17-February 18, 2000
> 
> 1.    JAC N2: Rules of Procedure for Conducting Business
>               1.      Composition of the Joint Advisory Committee
>                       1.      3.2. Voting
>                       1.      Because Mr. Vervoorn was not present and
> because the group wanted to accomplish its goals, Ms. Guenther recommended
> to take two votes where at least five positive votes would be required in
> the second vote to pass a resolution.
>                       2.      3.3 Role of Observers
>                       1.      It was agreed that each TC could appoint no
> more than 3 observers each, making a total of six, not five observers.
>                       2.      Observers / Technical Advisors are experts
> on specific points.  They should serve on an Ad Hoc basis based on the
> needs of the community.
>                       3.      Members can request additional consultants
> to the Chair as technical experts.
>               2.      Procedures for conducting business by electronic
> mail
>                       1.      Electronic communications
>                       1.      There will be two discussion lists
>                       (1)     The JAC list will include appointed members
> and observers.
>                       (2)     [log in to unmask] is the general discussion
> list.  Directions about how to subscribe will be added to the webpage in
> the future.  (It does not use list software, but there is an address for
> requests).
>                       (3)     The technical experts may wish to summarize
> the discussion of the general list to the JAC list in some cases.
>                       (4)     Official JAC documents shall be distributed
> to the general public only after consultation with the chair.
>                       2.      Electronic voting procedures
>                       1.      Voting will take place on the list.  
>                       2.      A paper-based record for this must be kept.
>                       3.      Votes will be generally submitted within two
> weeks of the e-distribution.  However, any extensions of this
> period/deadlines, when necessary, should be stated in the
> request-for-a-vote document.
>                       4.      If a JAC member does not vote after two
> consecutive times, the JAC chair will inform the appropriate ISO
> sub-committee (TC37/SC2 or TC46/SC4) and request a replacement.
>                       5.      Members are replaced as necessary.
>                       3.      Deadlines for response
>                       1.      Two weeks for voting.
>                       1.      2.      The RA should give the requester
> notification of receipt no later than two weeks after the request has been
> received.
>                       3.      One month for the JAC deliberations allows
> time for a second vote and additional information.
>                       4.      The requester should be informed of the
> result in six weeks to two months from the time the request is submitted
> to the RA, if possible.
>                       5.      ISO 639/JAC is consulted after the RA
> determines that the request meets the relevant criteria.  This should be
> within four weeks of the request=s receipt.
>                       6.      A flow chart that outlines the time frame
> may be developed and  placed on the website.  Mr. Galinski agreed to work
> on this.
>                       7.      Results of JAC actions will be publicized.
> 
> 2.    JAC N3:  Working Principles for ISO 639 Maintenance
>               1.      Terminology
>                       1.      The two standards should attempt to use the
> same terminology to help the users in regards to the terms, ACode,@
> ACodes,@ ACode Elements,@ and AIdentifiers.@
>                       2.      However, no consensus was agreed upon.  A
> decision will be made after the balloting of ISO 639-1/DIS.
>                       3.      The document will be generalized to include
> information about both parts of the standard.
>               2.      Definition of new language codes
>                       1.      Procedures
>                       1.      Some wording changes will be incorporated as
> suggested in N13 by Mr. Everson.
>                       2.      Criteria
>                       1.      Number of documents.  Documents include all
> forms of material and thus, not only text.
>                       2.      Collective codes.  ISO 639-1 does not have
> collective codes.  When the need arises to code for a group of languages,
> the Alpha-3 codes will be used.
>                       3.      Scripts.  The following should be added to
> the statement on scripts:
>                       (1)     If a language uses more than one script or
> orthography, it is not normally given a new symbol.
>                       (2)     The ISO standard script name should be: Code
> for the representation of names of scripts.
>                       4.      Dialects.  The difference between dialects
> and languages will be decided on a case to case situation.
>               3.      Choice of new language codes
>                       1.      The first bullet point will be reworded
> similar to that in 639-1 and the phrase ALatin-alphabet@ should further
> specify which Latin letters are used.
>                       1.      2.      The JAC will try to base the code on
> the vernacular as much as possible.  ARequests by the countries or country
> or sponsor submitting the requestA is possible language for the editing of
> this document.
>                       3.      In regards to prefixes, the  example of
> Swahili and KiSwahili should be used in the documentation instead of the
> Aotshiherero@ example.  This will state that Athe prefix is not regarded
> as part of the language name for purposes of assigning a code.@
>               4.      Changes of existing language codes
>                       1.      It was decided that codes shall not be
> changed.  This will be stated more firmly in the documentation.
>                       1.      Second bullet should read: AIn the rare case
> that a code is changed, the old code shall not be reassigned and the
> request goes through the same process as new codes.@
>                       2.      Requesters will be directed to look at the
> MARC Code List for Languages when they are in the need of variant names
> for languages.  Variant names may be included in the language name
> separated by a semicolon in the future.  No effort will be made by the
> Standard to collect these.
>                       3.      The standard will be amended to take out the
> footnote concerning the possible change of the ISO 639-2/T code for
> Spanish.
>               5.      Relationship between ISO 639-1 and ISO 639-2
>                       1.      ISO 639-1 shall remain a subset of ISO 639-2
>                       1.      No new 2 letter codes can be added without
> also adding a corresponding 3-letter code.
>                       2.      In the future, the two standards will be
> presented as one.
>                       3.      At a certain point in time (probably after
> approval of the ISO 639-1 DIS), the alpha-2 code list will be frozen.
> Then only alpha-3 codes will be added.
                                [H.Hjulstad:]  This needs to be modified!
Any item that is already in 639-2 at the point of "freezing" 639-1, may not
be added in 639-1. However, for items that are new to both parts, may be
considered for inclusion in both parts, or in 639-2 only. New items that
have been accepted in 639-2, may not AT A LATER DATE be accepted also in
639-1. The point in time of this "freezing" should NOT be at the approval of
the DIS, but at the approval of the IS (in practise FDIS), since we don't
know now how many DISes we might need and how many changes there will be. I
am not quite certain that the whole issue of "freezing" 639-1 is finalized!
>                       4.      If possible, new codes introduced into ISO
> 639-1 will agree with those in ISO 639-2 if already defined (i.e. have two
> letters in common).
> 
> 3.    JAC N10:  Website
>               1.      There will be one central ISO 639 page with both the
> ISO 639-1 and ISO 639-2 pages linked from it.
>                       1.      The ISO 639-1 introductory page will be
> modeled after the ISO 639-2 one.
>                       2.      The same form for requesting changes will be
> used (it will state whether the request is for ISO 639-1, ISO 639-2, or
> both).
>                       3.      The criteria for requesting changes for each
> part will be available on the page.  Mr. Galinski has prepared the ISO
> 639-1 criteria.  See N20
>               2.      Form for registration of new codes
>                       1.      A section will be added for additional names
> in indigenous languages.  (The choice of the word Aindigenous@ is used
> instead of Aoriginal.@)
                                [H.Hjulstad:]  There is a misunderstanding
(or bad wording) here. The phrase "additional names in indigenous languages"
hardly makes sense. May be the following wording: "A section will be added
to submit information on the indigenous name of the language".
>                       1.      2.      A section for additional information
> will be added on the form
>                       3.      A section for code suggestions will be added
> with a parenthetical note that there is no guarantee that a requester will
> receive the suggested code.
>                       4.      The title is: ISO 639 Registration Form
>               3.      The e-mail generated by the form is sent to the JAC
> chair.
>                       1.      If there is a two character code request, it
> must be referred then to the appropriate ISO 639-1/RA chair.
>               A.      ISO members need to request approval to have the
> standard on its website; this has already been done for ISO 639-2.
>               4.      The AFunctions of the ISO authority@ link will state
> the purpose found in the introduction of the standard.
>               5.      The ADevelopment@ link will contain historical
> information about each standard and the JAC.
>               6.      Links will be made between the ISO secretariat
> homepage and the ISO 639 page.
>               7.      There will be a AUseful Links@ page added to the
> website
>               8.      For the dissemination of changes to the standard,
> Mr. Everson will draft a web-based newsletter for review.
>               9.      When the chair rotates, LC will continue to host the
> page.  The current chair will maintain it and send files to the host as
> appropriate.
>               10.     For security purposes, some documents will be
> available, but not linked from the JAC page (or password protection will
> be available).
> 
> 4.    JAC N4: Changes to be considered at JAC meeting.
>               1.      Voting occurred on each proposal.
>               2.      Principles previously agreed upon were followed.
>               3.      Votes
>                       1.      Serbian: change scc to srb : Rejected
>                       2.      Serbian: change scc to srp: Rejected
>                       3.      Croatian: change scr to hrv: Rejected
>                       4.      Croatian: change scr to cro/hrv: Rejected
>                       5.      Serbo-Croatian: add scc and scr for
> Serbo-Croatian (1892-1990):  Rejected
>                       6.      Discontinue sh in ISO 639-1 and never reuse:
> Approved.
                                [H.Hjulstad:]  Yes, but I am not sure that
"discontinued" is the best word. Should we say "deprecated"? Would we also
regard the old symbols "iw" (= he), "in" (= id), and "ji" (= yi) as
"deprecated" in more or less the same way, and threat them in a table note?
>                       1.      A table note must be in the table at sh to
> show the historical status of it.
>                       2.      A hyphen before the code could indicate that
> discontinued codes could be used.
>                       7.      Bosnian: Approved with codes bos and bs.
>                       8.      Low German: request for a two letter and a
> three letter
>                       (1)     Need more research/further study
>                       (1)     Sufficient number of documents needs to be
> indicated.
>                       (1)     (2)     Is this a code for low Germanic
> languages as a collective? 
>                       (3)     Mr. Everson will forward these questions to
> the Germans and then report back to the group for a e-mail vote.
>                       9.      Japanese (T code) change based on
> vernacular: Rejected.
>                       10.     Chichewa:  This is the same as Nyanja, which
> is already in ISO 639-2 as nya.
>                       11.     Norwegian Bokmål:  Add nb and nob:
> Approved.
>                       12.     Norwegian Nynorsk:  Add nn and nno:
> Approved.
>                       13.     Sami Languages/Northern Sami
>                       1.      Alpha-3 codes: change the definition of smi
> to Sami (other) and add sme for Northern Sami
>                       2.      Alpha-2 codes:  change se (already in ISO
> 639-1) to be Northern Sami : Approved without the accent on Sami.
>                       14.     Montagnais:  Deferred for more research.
>                       15.     Naskapi:  Deferred for more research.
                                [H.Hjulstad:]  = Neskapi (both names should
be included)
>                       16.     Balki:  Ms. Guenther will contact the
> requesting body (Iran) and request more information
>                       17.     Parti:  Ms. Guenther will contact the
> requesting body (Iran) and request more information
>                       18.     Kharazmi:  Ms. Guenther will contact the
> requesting body (Iran) and request more information
>                       19.     Manchu: Add mnc:  Approved.  No alpha-2 code
> is approved unless requested.
                                [H.Hjulstad:]  In my notes: approved 639-2;
rejected 639-1 (not "deferred", as I guess must be the meaning of the text
here.
>                       20.     Sandawe:  For stability of the codes, the
> code for Sandawe will remain as is.
>                       21.     Sign Languages
>                       1.      Add sgn:  Approved.
>                       2.      Further thought will be given on development
> of guidelines or links to other resources on the World Wide Web.
>                       22.     Alsatian:  Deferred for more research.  Mr.
> Galinski will further investigate Alsatian=s properties and similarities
> to other languages/dialects, and Mr. Everson will ask some of the Germanic
> listservs about it.
>                       23.     Aromanian:  Deferred.  Further evidence of
> the documents is needed.  These will be circulated through the e-mail
> lists.
>               4.      Ancient languages:  The policy of the standard
> stands.  Any problem situations, etc. will be decided on a case-by-case
> basis
>               5.      Conflicting codes between the two standards
>                       1.      Cornish:  Already published and thus, will
> not be changed in either standard.
>                       2.      Herero:  Not published or approved and thus,
> action will be taken by the ISO 639-1 editor to propose other codes.
                                [H.Hjulstad:]  The identifier hz has been
proposed.
>                       1.      3.      Kuanyama/Kwanyama:  Not published or
> approved and thus, action will be taken by the ISO 639-1 editor to propose
> other codes.
                                [H.Hjulstad:]  The identifier kj has been
proposed.
>                       4.      Kdonga:  Not published or approved and thus,
> action will be taken by the ISO 639-1 editor to propose other codes.
                                [H.Hjulstad:]  Error in the name. Correct:
Ndonga. The identifier ng has been proposed.
>                       5.      Ndebele:  In ISO 639-1,   the code ND will
> correspond with North and the editor of ISO 639-1 will propose a new code
> for the South.
                                [H.Hjulstad:]  The identifier nr has been
proposed for South Ndebele.
>               6.      An electronic distribution list should be set up to
> publicize code changes, deletions, etc.
> 
> V.  JAC N5: An Aannotated version@ of Annex C of ISO/DIS 639-1
>       A.  The term ADefer@ means consider the request after it has been
> formally requested.  Those introduced into ISO 639-1 are already in ISO
> 639-2, unless otherwise indicated.
> *     Abaza: defer
> *     Adyge: defer
> *     Aragonese: defer
> *     Aromanian; Arumanian: defer
> *     Arvanite: defer
> *     Asturian: defer
> *     Avestan: Accept into ISO 639-1; the code is being reconsidered
                                [H.Hjulstad:]  The identifier ae has been
proposed.
> *     Balkar: defer
> *     Bosnian:  Accept into ISO 639-1; the code: Abs@/ Abos@ for ISO 639-2
> *     Chamorro: Accept into ISO 639-1; the code: Ach@
> *     Chechen: Accept into ISO 639-1; the code: Ace@
> *     Cherokee: defer
> *     Chichewa;Chewa:  Accept into ISO 639-1; the code: ny.  Already
> accepted into ISO 639-2 as Nyanga (nya).
                                [H.Hjulstad:]  Error in the name. Correct:
Nyanja. This item was already in both parts (as ny and nya respectively).
The English name of the item with identifier ny/nya should be: Chichewa;
Chewa; Nyanja.
> *     Church Slavonic; Church Slavic; Old Slavonic; Old Church Slavonic:
> Accept into ISO 639-1; the code: Acu@
> *     Chuvash: Accept into ISO 639-1; the code: Acv@
> *     Dargwa: defer
> *     East Frisian; Frisian, East; Sater Frisian; Frisian, Sater: reject
> *     Efik: reject
                                [H.Hjulstad:]  Rejected in 639-1; is already
accepted in 639-2 as efi (this should be made clear in the report, to avoid
confusion.
> *     Erzya Mordvin: defer	
> *     Franco-Provençal: defer
> *     Friulian: reject
                                [H.Hjulstad:]  Rejected in 639-1; is already
accepted in 639-2 as fur
> *     Frisian, North; North Frisian: reject
> *     Gagauz: defer
> *     German, Low; Low German: defer (Already discussed for ISO 639-2)
> *     Gikuyu; Kikuyu: Accept into ISO 639-1; the code: Aki@	
> *     Hiri Motu: Accept into ISO 639-1; the code: Aho@
                                [H.Hjulstad:]  Something like the following
should be added: The name should be Hiri Motu only, not Motu.
> *     Inari Sami; Sami, Inari: defer
> *     Ingush: defer
> *     Istro-Romanian: reject
> *     Kabardian: defer
> *     Kalmyk: defer
> *     Karachay : defer (same as Balkar)
> *     Karaim: defer
> *     Karelian, North; North Karelian: defer
> *     Kashubian: defer for ISO 639-2 / Reject for ISO 639-1
> *     Kikuyu; Gikuyu: Accept into ISO 639-1; the code: Aki@
> *     Kildin Sami; Sami, Kildin: defer
> *     Komi: Accept into ISO 639-1; the code: Akv@
> *     Kumyk: defer
> *     Ladin: reject
> *     Ladino: reject
                                [H.Hjulstad:]  Rejected in 639-1; is already
accepted in 639-2 as lad
> *     Lak: defer
> *     Lallans; Lowlands Scots:  reject
                                [H.Hjulstad:]  Rejected in 639-1; is already
accepted in 639-2 as sco, English name "Scots"
> *     Lezghian: defer
> *     Livonian: defer for ISO 639-2 / Reject for ISO 639-1
> *     Lower Sorbian; Sorbian, Lower: reject
> *     Lule Sami; Sami, Lule: defer
> *     Mandingo: reject 
                                [H.Hjulstad:]  Rejected in 639-1; is already
accepted in 639-2 as man
> *     Mari, Meadow; Meadow Mari; Mountain Mari: defer
> *     Marshall; Marshallese: Accept into ISO 639-1; the code: Amh@
> *     Middle Persian; Persian, Middle: defer
> *     Mingrelian: reject
> *     Moksha Mordvin: defer
> *     Nama: defer
> *     Navajo; Navaho: Accept into ISO 639-1; the code: Anv@
> *     Nenets: defer
> *     Nogai; Noghay: defer
> *     Northern Sami; Sami, Northern:  Accept into ISO 639-1; the code:
> Ase@
> *     Norwegian Bokmål:  Accept into ISO 639-1; the code: Anb@ / Accept
> into ISO 639-2; the code: Anob@
> *     Norwegian Nynorsk:  Accept into ISO 639-1; the code: Ann@ / Accept
> into ISO 639-2; the code: Anno@
> *     Nyanja; Chechewa: Accept into ISO 639-1; the code: Any@
                                [H.Hjulstad:]  It is "Chichewa". Cf comment
to "Chichewa; Chewa; Nyanja" above.
> *     Old Persian; Persian, Old: reject 
> *     Ossetian: Accept into ISO 639-1; the code: Aos@
> *     Pali: Accept into ISO 639-1; the code: Api@
> *     Provençal: Same as Occitan (post 1500); already in ISO 639-1 as Aoc@
> *     Romany; Romani:  reject
                                [H.Hjulstad:]  Rejected in 639-1; is already
accepted in 639-2 as rom
> *     Ruthenian; Rusyn: defer for ISO 639-2 / reject for ISO 639-1
                                [H.Hjulstad:]  My notes differ from this. In
my notes it is "deferred" for both parts of the standard. It may not make
that much difference, but it should be clarified. New vote?
> *     Sardinian: Accept into ISO 639-1; the code: Asc@
> *     Skolt Sami; Sami, Skolt: defer
> *     Southern Sami; Sami, Southern: defer
> *     Tabasaran: defer
> *     Tahitian: Accept into ISO 639-1; the code: Aty@ 
> *     Udmurt: defer
> *     Upper Sorbian, Sorbian, Upper: reject
> *     Valencian: defer
> *     Veps: reject
> *     Walloon: defer
> *     Yi: defer
> 
>                       B.  Norway, Finland, and Sweden will consult on Sami
> languages
> 
> 5.    JAC N20:  Criteria for ISO 639-1
>               1.      This information will be published on the webpage.
>               2.      The criteria will be tested on a case-by-case basis.
>               3.      The criteria will emphasize the need for sufficient
> number of existing terminologies in various subject fields.
>               4.      The code chosen will be as mnemonically similar to
> the alpha-3 code as possible and ISO 639-1 will remain a subset.
> 
> 6.    Other Business
>               1.      Mr. Everson and Mr. Galinski will develop a
> flowchart to illustrate the procedural time line of the code process that
> will be on the webpage.
>               2.      More forms to facilitate the process for requesting
> codes should be made available on the website:
>                       1.      Registration (revised)
>                       2.      Information that goes back to the requester
> explaining the time frame for requests and procedures followed by both the
> RA and JAC to determine codes.
>                       3.      Voting forms.  Negative votes must be
> explained with ISO justification or comment.
>                       4.      Final decision of JAC to go back to the
> requester.
>                       5.      Mechanism for disseminating results (i.e.
> the newsletter).
>                       6.      The forms above will be used both for ISO
> 639-1 and ISO 639-2
>               3.      Name of JAC:  AISO 639/JAC@ (This has also been
> referred to as ISO 639/RA JAC).
>               4.      Adoption of resolutions will be disseminated through
> the e-mail list
>               5.      Next Meeting: This will be just after the chair
> rotates in the beginning of 2002 or when the ISO 639-2 is up for review in
> 2003.  It will be decided during an electronic discussion in the future.
>               6.      Renewal of ISO 639-2 in 2003: a joint working group
> may be needed.  This may be the time to combine ISO 639-1 and ISO 639-2
> into one published standard.
> 
> 7.    Miscellaneous
>               1.      The Joint Working Group for ISO 639 1988
>                       1.      1.      There still exists a registration
> authority for this, but activities are given to the JAC for now.
>                       2.      Resolution: the JAC will replace the working
> group when ISO 639-1 is published.  Approval may be needed from TC37 and
> TC46.
                                [H.Hjulstad:]  Is there something wrong
here? What is "Joint Working Group for ISO 639 1988"??? ISO/TC37/SC2/WG1 is
not a JWG as far as I know, and it produced ISO/DIS 639-1. However, the
issue may be that there "in theory" still exists a Advisory Committee to
639:1988.

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

April 2021
January 2021
November 2020
June 2020
May 2019
February 2019
September 2018
April 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
May 2016
April 2016
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
October 2013
September 2013
August 2013
July 2013
May 2013
April 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager