Authors ' Addresses

Network Working Group R. Bush Request for Comments: 3681 IIJ BCP: 80 R. Fink Category: Best Current Practice January 2004 Delegation of E.F.F.3.IP6.ARPAStatus of this MemoThis document specifies an Internet Best Current Practices for theInternet Community, and requests discussion and suggestions forimprovements. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004). All Rights Reserved. AbstractThis document discusses the need for delegation of theE.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for6bone addresses, and makes specific recommendations for the processneeded to accomplish this.1. 6bone and DNSThe 6bone, whose address space was allocated by [RFC2471], hasprovided a network for IPv6 experimentation for numerous purposes for seven years. Up to the present time, reverse lookups for 6boneaddresses have been accomplished through IP6.INT. It is nowimportant that the thousands of 6bone users be able to update theirIPv6 software to use IP6.ARPA [RFC3152].Although the 6bone has a limited life, as a phaseout plan is beingdiscussed at the IETF at this time [I-D.fink-6bone-phaseout], thereis likely to be 2.5 to 3.5 more years of operation. During thisremaining 6bone lifetime IP6.ARPA reverse lookup services for the3ffe::/16 address space are required.Discussions have been underway between the 6bone and RIR communities, about having the RIRs perform this service. It was agreed at the San Francisco IETF meeting in March 2003 that it was more practical forthe 6bone to provide this service for itself. This would relieve the RIRs of the costs of providing this service, yet still provide theIP6.ARPA authority the ability to terminate the service when theplanned 6bone termination date is reached (currently anticipated tobe June 6, 2006).Bush & Fink Best Current Practice [Page 1]The current planning within the 6bone operational community is toprovide new inet6num attributes in the 6bone registry database fortop level 6bone address space holders to request delegation to their reverse path servers.2. IANA ConsiderationsThis memo requests that the IANA delegate the E.F.F.3.IP6.ARPA domain to the 6bone, as will be described in instructions to be provided by the IAB. Names within this zone are to be further delegated withinthe top level 6bone ISPs (known as pTLAs) in accordance with thedelegation of 6bone 3FFE::/16 address space.3. Security ConsiderationsWhile DNS spoofing of address to name mapping has been exploited inIPv4, delegation of the E.F.F.3.IP6.ARPA zone creates no new threats to the security of the internet.4. References4.1. Normative References[RFC2471] Hinden, R., Fink, R. and J. Postel, "IPv6Testing Address Allocation", RFC 2471,December 1998.4.2. Informative References[I-D.fink-6bone-phaseout] Fink, R. and R. Hinden, "6bone (IPv6Testing Address Allocation) Phaseout", Work in Progress.[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.Bush & Fink Best Current Practice [Page 2]5. Intellectual Property StatementThe IETF takes no position regarding the validity or scope of anyintellectual property or other rights that might be claimed topertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; neither does it represent that ithas made any effort to identify any such rights. Information on the IETF’s procedures with respect to rights in standards-track andstandards-related documentation can be found in BCP-11. Copies ofclaims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made toobtain a general license or permission for the use of suchproprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights which may cover technology that may be required to practicethis standard. Please address the information to the IETF Executive Director.6. Authors’ AddressesRandy BushIIJ5147 Crystal SpringsBainbrisge Island, WA 98110USPhone: +1 206 780 0431EMail: randy@URI: /˜randy/Robert FinkTruckee, CAUSEMail: bob@Bush & Fink Best Current Practice [Page 3]7. Full Copyright StatementCopyright (C) The Internet Society (2004). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assignees.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Bush & Fink Best Current Practice [Page 4]。

A Simple Min-Cut AlgorithmMECHTHILD STOERTeleverkets Forskningsinstitutt,Kjeller,NorwayANDFRANK WAGNERFreie Universita¨t Berlin,Berlin-Dahlem,GermanyAbstract.We present an algorithm for finding the minimum cut of an undirected edge-weighted graph.It is simple in every respect.It has a short and compact description,is easy to implement,and has a surprisingly simple proof of correctness.Its runtime matches that of the fastest algorithm known.The runtime analysis is straightforward.In contrast to nearly all approaches so far,the algorithm uses no flow techniques.Roughly speaking,the algorithm consists of about͉V͉nearly identical phases each of which is a maximum adjacency search.Categories and Subject Descriptors:G.L.2[Discrete Mathematics]:Graph Theory—graph algorithms General Terms:AlgorithmsAdditional Key Words and Phrases:Min-Cut1.IntroductionGraph connectivity is one of the classical subjects in graph theory,and has many practical applications,for example,in chip and circuit design,reliability of communication networks,transportation planning,and cluster analysis.Finding the minimum cut of an undirected edge-weighted graph is a fundamental algorithmical problem.Precisely,it consists in finding a nontrivial partition of the graphs vertex set V into two parts such that the cut weight,the sum of the weights of the edges connecting the two parts,is minimum.A preliminary version of this paper appeared in Proceedings of the2nd Annual European Symposium on Algorithms.Lecture Notes in Computer Science,vol.855,1994,pp.141–147.This work was supported by the ESPRIT BRA Project ALCOM II.Authors’addresses:M.Stoer,Televerkets Forskningsinstitutt,Postboks83,2007Kjeller,Norway; e-mail:mechthild.stoer@nta.no.;F.Wagner,Institut fu¨r Informatik,Fachbereich Mathematik und Informatik,Freie Universita¨t Berlin,Takustraße9,Berlin-Dahlem,Germany;e-mail:wagner@inf.fu-berlin.de.Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage,the copyright notice,the title of the publication,and its date appear,and notice is given that copying is by permission of the Association for Computing Machinery(ACM),Inc.To copy otherwise,to republish,to post on servers,or to redistribute to lists,requires prior specific permission and/or a fee.᭧1997ACM0004-5411/97/0700-0585$03.50Journal of the ACM,Vol.44,No.4,July1997,pp.585–591.586M.STOER AND F.WAGNER The usual approach to solve this problem is to use its close relationship to the maximum flow problem.The famous Max-Flow-Min-Cut-Theorem by Ford and Fulkerson[1956]showed the duality of the maximum flow and the so-called minimum s-t-cut.There,s and t are two vertices that are the source and the sink in the flow problem and have to be separated by the cut,that is,they have to lie in different parts of the partition.Until recently all cut algorithms were essentially flow algorithms using this duality.Finding a minimum cut without specified vertices to be separated can be done by finding minimum s-t-cuts for a fixed vertex s and all͉V͉Ϫ1possible choices of tʦVگ{s}and then selecting the lightest one.Recently Hao and Orlin[1992]showed how to use the maximum flow algorithm by Goldberg and Tarjan[1988]in order to solve the minimum cut problem in timeᏻ(͉VʈE͉log(͉V͉2/͉E͉),which is nearly as fast as the fastest maximum flow algorithms so far[Alon1990;Ahuja et al.1989;Cheriyan et al. 1990].Nagamochi and Ibaraki[1992a]published the first deterministic minimum cut algorithm that is not based on a flow algorithm,has the slightly better running time ofᏻ(͉VʈE͉ϩ͉V͉2log͉V͉),but is still rather complicated.In the unweighted case,they use a fast-search technique to decompose a graph’s edge set E into subsets E1,...,E␭such that the union of the first k E i’s is a k-edge-connected spanning subgraph of the given graph and has at most k͉V͉edges.They simulate this approach in the weighted case.Their work is one of a small number of papers treating questions of graph connectivity by non-flow-based methods [Nishizeki and Poljak1989;Nagamochi and Ibaraki1992a;Matula1992].Karger and Stein[1993]suggest a randomized algorithm that with high probability finds a minimum cut in timeᏻ(͉V͉2log͉V͉).In this context,we present in this paper a remarkably simple deterministic minimum cut algorithm with the fastest running time so far,established in Nagamochi and Ibaraki[1992b].We reduce the complexity of the algorithm of Nagamochi and Ibaraki by avoiding the unnecessary simulated decomposition of the edge set.This enables us to give a comparably straightforward proof of correctness avoiding,for example,the distinction between the unweighted, integer-,rational-,and real-weighted case.This algorithm was found independently by Frank[1994].Queyranne[1995]generalizes our simple approach to the minimization of submodular functions.The algorithm described in this paper was implemented by Kurt Mehlhorn from the Max-Planck-Institut,Saarbru¨cken and is part of the algorithms library LEDA[Mehlhorn and Na¨her1995].2.The AlgorithmThroughout the paper,we deal with an ordinary undirected graph G with vertex set V and edge set E.Every edge e has nonnegative real weight w(e).The simple key observation is that,if we know how to find two vertices s and t, and the weight of a minimum s-t-cut,we are nearly done:T HEOREM2.1.Let s and t be two vertices of a graph G.Let G/{s,t}be the graph obtained by merging s and t.Then a minimum cut of G can be obtained by taking the smaller of a minimum s-t-cut of G and a minimum cut of G/{s,t}.The theorem holds since either there is a minimum cut of G that separates s and t ,then a minimum s -t -cut of G is a minimum cut of G ;or there is none,then a minimum cut of G /{s ,t }does the job.So a procedure finding an arbitrary minimum s -t -cut can be used to construct a recursive algorithm to find a minimum cut of a graph.The following algorithm,known in the literature as maximum adjacency search or maximum cardinality search ,yields the desired s -t -cut.M INIMUM C UT P HASE (G ,w ,a )A 4{a }while A Vadd to A the most tightly connected vertexstore the cut-of-the-phase and shrink G by merging the two vertices added lastA subset A of the graphs vertices grows starting with an arbitrary single vertex until A is equal to V .In each step,the vertex outside of A most tightly connected with A is added.Formally,we add a vertexz ʦ͞A such that w ͑A ,z ͒ϭmax ͕w ͑A ,y ͉͒y ʦ͞A ͖,where w (A ,y )is the sum of the weights of all the edges between A and y .At the end of each such phase,the two vertices added last are merged ,that is,the two vertices are replaced by a new vertex,and any edges from the two vertices to a remaining vertex are replaced by an edge weighted by the sum of the weights of the previous two edges.Edges joining the merged nodes are removed.The cut of V that separates the vertex added last from the rest of the graph is called the cut-of-the-phase .The lightest of these cuts-of-the-phase is the result of the algorithm,the desired minimum cut:M INIMUM C UT (G ,w ,a )while ͉V ͉Ͼ1M INIMUM C UT P HASE (G ,w ,a )if the cut-of-the-phase is lighter than the current minimum cutthen store the cut-of-the-phase as the current minimum cutNotice that the starting vertex a stays the same throughout the whole algorithm.It can be selected arbitrarily in each phase instead.3.CorrectnessIn order to proof the correctness of our algorithms,we need to show the following somewhat surprising lemma.L EMMA 3.1.Each cut -of -the -phase is a minimum s -t -cut in the current graph ,where s and t are the two vertices added last in the phase .P ROOF .The run of a M INIMUM C UT P HASE orders the vertices of the current graph linearly,starting with a and ending with s and t ,according to their order of addition to A .Now we look at an arbitrary s -t -cut C of the current graph and show,that it is at least as heavy as the cut-of-the-phase.587A Simple Min-Cut Algorithm588M.STOER AND F.WAGNER We call a vertex v a active(with respect to C)when v and the vertex added just before v are in the two different parts of C.Let w(C)be the weight of C,A v the set of all vertices added before v(excluding v),C v the cut of A vഫ{v} induced by C,and w(C v)the weight of the induced cut.We show that for every active vertex vw͑A v,v͒Յw͑C v͒by induction on the set of active vertices:For the first active vertex,the inequality is satisfied with equality.Let the inequality be true for all active vertices added up to the active vertex v,and let u be the next active vertex that is added.Then we havew͑A u,u͒ϭw͑A v,u͒ϩw͑A uگA v,u͒ϭ:␣Now,w(A v,u)Յw(A v,v)as v was chosen as the vertex most tightly connected with A v.By induction w(A v,v)Յw(C v).All edges between A uگA v and u connect the different parts of C.Thus they contribute to w(C u)but not to w(C v).So␣Յw͑C v͒ϩw͑A uگA v,u͒Յw͑C u͒As t is always an active vertex with respect to C we can conclude that w(A t,t)Յw(C t)which says exactly that the cut-of-the-phase is at most as heavy as C.4.Running TimeAs the running time of the algorithm M INIMUM C UT is essentially equal to the added running time of the͉V͉Ϫ1runs of M INIMUM C UT P HASE,which is called on graphs with decreasing number of vertices and edges,it suffices to show that a single M INIMUM C UT P HASE needs at mostᏻ(͉E͉ϩ͉V͉log͉V͉)time yielding an overall running time ofᏻ(͉VʈE͉ϩ͉V͉2log͉V͉).The key to implementing a phase efficiently is to make it easy to select the next vertex to be added to the set A,the most tightly connected vertex.During execution of a phase,all vertices that are not in A reside in a priority queue based on a key field.The key of a vertex v is the sum of the weights of the edges connecting it to the current A,that is,w(A,v).Whenever a vertex v is added to A we have to perform an update of the queue.v has to be deleted from the queue,and the key of every vertex w not in A,connected to v has to be increased by the weight of the edge v w,if it exists.As this is done exactly once for every edge,overall we have to perform͉V͉E XTRACT M AX and͉E͉I NCREASE K EY ing Fibonacci heaps[Fredman and Tarjun1987],we can perform an E XTRACT M AX operation inᏻ(log͉V͉)amortized time and an I NCREASE K EY operation inᏻ(1)amortized time.Thus,the time we need for this key step that dominates the rest of the phase, isᏻ(͉E͉ϩ͉V͉log͉V͉).5.AnExample F IG .1.A graph G ϭ(V ,E )withedge-weights.F IG .2.The graph after the first M INIMUM C UT P HASE (G ,w ,a ),a ϭ2,and the induced ordering a ,b ,c ,d ,e ,f ,s ,t of the vertices.The first cut-of-the-phase corresponds to the partition {1},{2,3,4,5,6,7,8}of V with weight w ϭ5.F IG .3.The graph after the second M INIMUM C UT P HASE (G ,w ,a ),and the induced ordering a ,b ,c ,d ,e ,s ,t of the vertices.The second cut-of-the-phase corresponds to the partition {8},{1,2,3,4,5,6,7}of V with weight w ϭ5.F IG .4.After the third M INIMUM C UT P HASE (G ,w ,a ).The third cut-of-the-phase corresponds to the partition {7,8},{1,2,3,4,5,6}of V with weight w ϭ7.589A Simple Min-Cut AlgorithmACKNOWLEDGMENT .The authors thank Dorothea Wagner for her helpful re-marks.REFERENCESA HUJA ,R.K.,O RLIN ,J.B.,AND T ARJAN ,R.E.1989.Improved time bounds for the maximum flow problem.SIAM put.18,939–954.A LON ,N.1990.Generating pseudo-random permutations and maximum flow algorithms.Inf.Proc.Lett.35,201–204.C HERIYAN ,J.,H AGERUP ,T.,AND M EHLHORN ,K.1990.Can a maximum flow be computed in o (nm )time?In Proceedings of the 17th International Colloquium on Automata,Languages and Programming .pp.235–248.F ORD ,L.R.,AND F ULKERSON ,D.R.1956.Maximal flow through a network.Can.J.Math.8,399–404.F RANK , A.1994.On the Edge-Connectivity Algorithm of Nagamochi and Ibaraki .Laboratoire Artemis,IMAG,Universite ´J.Fourier,Grenoble,Switzerland.F REDMAN ,M.L.,AND T ARJAN ,R.E.1987.Fibonacci heaps and their uses in improved network optimization algorithms.J.ACM 34,3(July),596–615.G OLDBERG ,A.V.,AND T ARJAN ,R.E.1988.A new approach to the maximum-flow problem.J.ACM 35,4(Oct.),921–940.H AO ,J.,AND O RLIN ,J.B.1992.A faster algorithm for finding the minimum cut in a graph.In Proceedings of the 3rd ACM-SIAM Symposium on Discrete Algorithms (Orlando,Fla.,Jan.27–29).ACM,New York,pp.165–174.K ARGER ,D.,AND S TEIN ,C.1993.An O˜(n 2)algorithm for minimum cuts.In Proceedings of the 25th ACM Symposium on the Theory of Computing (San Diego,Calif.,May 16–18).ACM,New York,pp.757–765.F IG .5.After the fourth and fifth M INIMUM C UT P HASE (G ,w ,a ),respectively.The fourth cut-of-the-phase corresponds to the partition {4,7,8},{1,2,3,5,6}.The fifth cut-of-the-phase corresponds to the partition {3,4,7,8},{1,2,5,6}with weight w ϭ4.F IG .6.After the sixth and seventh M INIMUM C UT P HASE (G ,w ,a ),respectively.The sixth cut-of-the-phase corresponds to the partition {1,5},{2,3,4,6,7,8}with weight w ϭ7.The last cut-of-the-phase corresponds to the partition {2},V گ{2};its weight is w ϭ9.The minimum cut of the graph G is the fifth cut-of-the-phase and the weight is w ϭ4.590M.STOER AND F.WAGNERM ATULA ,D.W.1993.A linear time 2ϩ⑀approximation algorithm for edge connectivity.In Proceedings of the 4th ACM–SIAM Symposium on Discrete Mathematics ACM,New York,pp.500–504.M EHLHORN ,K.,AND N ¨AHER ,S.1995.LEDA:a platform for combinatorial and geometric mun.ACM 38,96–102.N AGAMOCHI ,H.,AND I BARAKI ,T.1992a.Linear time algorithms for finding a sparse k -connected spanning subgraph of a k -connected graph.Algorithmica 7,583–596.N AGAMOCHI ,H.,AND I BARAKI ,puting edge-connectivity in multigraphs and capaci-tated graphs.SIAM J.Disc.Math.5,54–66.N ISHIZEKI ,T.,AND P OLJAK ,S.1989.Highly connected factors with a small number of edges.Preprint.Q UEYRANNE ,M.1995.A combinatorial algorithm for minimizing symmetric submodular functions.In Proceedings of the 6th ACM–SIAM Symposium on Discrete Mathematics ACM,New York,pp.98–101.RECEIVED APRIL 1995;REVISED FEBRUARY 1997;ACCEPTED JUNE 1997Journal of the ACM,Vol.44,No.4,July 1997.591A Simple Min-Cut Algorithm。

Sample manuscript for Applied Physics Letters a)A. Author,1,2,b)B. Author,2,b,c)C. Author, Jr.,3,d) and XYZ Collaboration1Department, University, City, Postal code, Country2Corporation or Laboratory, Street address, Postal code, City, Country3 Department, University, City, State (spell out full name) Zip code, USAThis is an abstract. It gives the reader an overview of the manuscript. In this sample article weprovide instructions on how to prepare and submit your paper to Applied Physics Letters, a journalpublished by the American Institute of Physics (AIP). Authors must follow the instructions given inthis document. The AIP staff appreciates your effort to follow our style when preparing yourmanuscript.I. THE MANUSCRIPTU se this “sample manuscript” as a guide for preparing your article. This will ensure that your submission will be in the required format for Peer Review. Please read all of the following manuscript preparation instructions carefully and in their entirety. The manuscript must be in good scientific American English; this is the author's responsibility. All files MUST be submitted through our online electronic submission system at .A. Manuscript preparationArticles must be prepared as either a Microsoft Word .doc/.docx file or a REVTeX/LaTeX file. The entire manuscript, should be set up for 21.6 × 28 cm (8-1/2 × 11 in. or A4) pages with 2.54 cm (1 in.) margins all the way around. The font and the point size will be reset according to the journal’s spec ifications, but authors most commonly use the Times Roman font and point size 12. The manuscript must begin with a title, names of all authors and their affiliations, and an abstract, followed by the body of the paper, tables and figures, if any, included, and the reference section. Consecutively number all tables (I, II, III, etc.) and figures (1, 2, 3, etc.), including those in an Appendix. Figures may be embedded in the text or not (author’s choice). Figure captions must be included in the manuscript. Number all pages consecutively, beginning with 1._____________________________a) This is an example of a footnote to the title if the paper was part of a conference: Contributed paper, published as part of the Proceedings of the 17th International Conference on Physics, Anytown, State, May 2010.b) A. Author and B. Author contributed equally to this work.c) This is an example of a footnote to an autho r’s name: Author to whom correspondence should be addressed. Electronic mail: author@.d) This research was performed while C. Author was at Anywhere National Laboratory, City, State, Postal code, Country.B. Manuscript submissionAll files MUST be submitted through the online system . Each version of the manuscript (the original and subsequent revisions) should be submitted with its own complete set of files: a cover letter (indicating the title, authors, and contact information), a complete article file, and separate figure files (see Sec. VIII―FIGURES). When uploading a revised manuscript, also include a response/rebuttal letter (indicating the changes made to address the Ed itor’s and Reviewers’ comments).II. MANUSCRIPT LENGTHManuscripts should not exceed 3500 words (approximately four printed journal pages). Abstract, title, author list, references and acknowledgements are all excluded from the length limit of 3500 words. Figures, tables and equations however are included and must be accounted for. Circumvention of the length limitation by division of a long article into small parts is considered to be contrary to the purpose of this journal. Please use the guidelines for Estimating Length included in the Information for Contributors.III. TITLEMake the title as concise as possible but informative enough to facilitate information retrieval. Only the most common acronyms and abbreviations are allowed in the title. Use acronyms with considerable moderation and always define at first use.IV. ABSTRACTLimit the abstract to less than 100 words. It must be self-contained (contain no footnotes or citations to references), adequate as an index (giving all subjects, major and minor, about which new information is given), and a concise summary (giving the conclusions and all results of general interest in the article). The abstract must be one paragraph and should not contain displayed mathematical equations or tabular material. AIP journals do not require PACs numbers.V. AUTHORS’ NAMES AND ADDRESSESAuthors’ names s hould preferably be written in a standard form for all publications to facilitate indexing and to avoid ambiguities. Include the names and postal addresses of all institutions, followed by city, state, zip code, and USA if in the United States or by postal code, city, and country if not in the U.S. Please provide complete addresses. See the byline for this sample article for examples.Authors with Chinese, Japanese, or Korean names may choose to have their names published in their own language alongside the English versions of their names in the author list of their publications. For Chinese, authors may use eitherSimplified or Traditional characters. Chinese, Japanese, or Korean characters must be included within the author list of the manuscript when submitting or resubmitting. The manuscript must be prepared using Microsoft Word or using the CJK LaTeX package. Specific guidelines for each authoring tool are given at /pubservs/cjk_instructions.html . VI. FOOTNOTESFootnotes are generally unacceptable in AIP journals, with the exception of footnotes to the title or authors. All other information should be included in the reference section. Use a), b), c), etc., for footnotes to the title or authors. The following list shows some examples:a) Contributed paper, published as part of the Proceedings of the 17th International Conference on Physics, Anytown, State, May, 2010. (footnote to title) b) A. Author and B. Author contributed equally to this work. c) Author to whom correspondence should be addressed. Electronic mail: author@.d)This research was performed while C. Author was at Anywhere National Laboratory, City, State, Postal code, Country. VII. EQUATIONSEquations should be punctuated and aligned to bring out their structure, and numbered on the right. Mathematical operation signs indicating continuity of the expression should be placed at the left of the second and succeeding lines. Use (×) rather than a centered dot for multiplication, except for scalar products of vectors. Use a solidus (/) instead of built-up fractions in running text, and in display wherever clarity would not be jeopardized. Use “exp” for complicated exponents. 1212i i i i N B B B B N , (1)21cos 2sin 2.2D n a I nn (2)Please note that you must use MathType or the Microsoft ® Equation Editor 3.0. Use of Microsoft ® Math Editor is not recommended.VIII. ACRONYMS AND NOTATIONAcronyms, except for the most common (such as 2D, rms, or ac) must be spelled out when they first appear both in the abstract and again in the text. Spell out machine names, except for those not considered acronyms (such as ITER or DIII-D). Try to avoid the excessive use of acronyms or specialized jargon.FIG. 1. (Color) This figure will appear in color in print and online. Figures should be created at 300 dpi and submitted at 300 dpi for the best presentation. Choose CMYK (cyan, magenta, yellow, black) for any figure that will appear in color in the print version.FIG. 2. (Color online) This figure will appear in color only in the online version only, not in the printed version. Figures should be created at 300 dpi and submitted at 300 dpi for the best presentation. Choose RGB (red, green, blue) for any figure that will appear in color only online.FIG. 3. This is a good example of information that was presented clearly. When this figure appeared in the printed journal it was in black and white print, but the reader was able to discern the “red” triangles, the closed “green” circles, and the open “black” circles. A description as well as the color is needed. If the caption had simply discussed “the red and green symbols,” the reader of the print version would not understand because he/she would be seeing the figure without the color.FIG. 4. This is an example of line art. Figures should be created at 600 dpi and submitted at 600 dpi for the best presentation. Save line art as black/white bitmap, not grayscale..FIG. 5. This is an example of a halftone. Figures should be created at 300 dpi and submitted at 300 dpi for the best presentation.FIG. 6.This is an example of a combination figure (line art and halftone). Figures should be created at 600 dpi and submitted at 600 dpi for the best presentation.TABLE I.This table provides instructions on how to prepare figures.(a) General guidelines for preparing illustrationsNumber figures in the order in which they appear in the text.Label all figure parts with (a), (b), etc. Each figure file should contain all parts of the figure. For example, if Fig.1 contains three parts [(a), (b), and (c)], then all parts should be combined in a single file for Fig. 1.Avoid any large disparity in size of lettering and labels used within one illustration.Prepare illustrations in the final published size, not oversized. The maximum published width for a one-column illustration is 8.5 cm (3-3/8 in.). The maximum width for a two-column figure is 17 cm (7.0 in.).In cases where reduction is required, avoid small open symbols that tend to fill in and avoid small lettering; ensure that, in the final published illustration, there is a minimum of 8-point type size (2.8 mm high; 1/8 in. high) for lettering and 0.5-point width for lines.Ensure that lettering and lines are dark enough, and thick enough, to reproduce clearly. Remember that fine lines tend to disappear upon reduction.It is preferred that authors embed figures and captions in the manuscript file. Embed the figures in the approximate position and size you think is appropriate. In addition, separate figure files must be provided (see below for accepted file formats) along with the manuscript.(b) Guidelines for preparation of electronic graphics filesAcceptable formats for figures: Portable Document Files (PDF), Encapsulated PostScript Files (EPS), PostScript, or Tagged Image File format (TIF). EPS (using Arial or Times Roman fonts) is preferred graphic format when preparing illustrations. Microsoft Word (.doc or .docx) or JPEG (.jpg) files are NOT acceptable.More detailed information is given about figure preparation on the RSI website in the Information for Contributors tab.Settings: Set the graphic for 600 dpi resolution for line art, 300 dpi for halftones, and 600 dpi for combinations (line art + halftone).Save line art as black/white bitmap, not grayscale.Save halftones and combinations as grayscale, not black/white bitmap.Click here for publication charge information.Submit color files at 300 dpi in one of the accepted file formats: PDF, EPS, PS, or TIF. EPS (using Arial or Times Roman fonts) is preferred graphic format when preparing illustrations. No other type of color illustration is acceptable. When selecting a file mode, for print choose CMYK (cyan, magenta, yellow, black) and for color online choose RGB (red, green, blue).PDF files should be vector files.In the PDF illustration, resolution of any shaded or photographic images must be 600 pixels per inch (PPI).Within the PDF illustration, resolution of line art with no shading should be 1200 pixels per inch (PPI).All fonts must be embedded in the PDF.Select "High Quality Print" when creating a PDF through the application’s print command.If usable color graphics files are received in time for the production process, authors will see color versions of those illustrations when viewing their author proofs. (The Corresponding Author will receive e-mail notification from AIP when the proof, as a PDF file, is available for downloading.)The author is responsible for obtaining permissions to reuse previously published material. Full credit lines are needed for figures that are used with permission. An example of the recommended format for crediting material from a journal article is: “Reprinted with permission from [FULL CITATION]. Copyright [PUBLICATION YEAR], American Institute of Ph ysics.” Full citation format is as follows: Author names, journal title, Vol. #, Issue #, Page # (or CID#), Year of publication. For example, the credit line would appear as: “Reprinted with permission from J. Chem. Phys. 128, 024365 (2008). Copyright 2008American Institute of Physics. If you need help acquiring permissions from another publisher, use this form [CLICK HERE].XI. TABLESSeparate tables (numbered with Roman numerals in the order of their appearance in the text) should be used for all tabular material. Tables must be embedded in the article file, not uploaded like figure files. The structure should be clear. Use simple column headings and include units of measure. Table captions are positioned above the table and should be styled as “TABLE I. This is a table caption.” A caption should make its table intelligible without reference to the text. Capitalize th e first word in the table headings and subheadings. References within tables are designated by lowercase Roman letter superscripts and given at the end of the table. Unaltered computer output and notation should be uploaded as supplemental files. See Table II for an example of correct table styling.TABLE II. Bond distances for alkene molecules (atomic units).No. C a RI,I+1b SRI,I+1c RI−1,I+RI,I+1SRI−1,I+RI,I+12 2.5255 ………4 2.6175 0.123 5.306 …6 2.6314 0.0999 5.3025 0.01128 2.6368 0.0876 5.3009 0.011110 2.6396 0.0795 5.2999 0.010614 2.6424 0.0689 5.2989 0.009618 2.6437 0.0623 5.2982 0.008822 2.6443 0.0573 5.2973 0.00826 2.6448 0.0536 5.2968 0.0074ab RI,I+1 is the distance between two neighboring carbon atoms, while ‹RI,I+1› is the averageof RI,I+1 for a given molecule.c SRI,I+1 is the standard deviation of RI,I+1 within the given molecule.XII. MULTIMEDIA SUBMISSIONSMultimedia files can be included in the online version of published papers. All such files are peer reviewed. When published, these files can be viewed by clicking on a link from the figure caption, provided that the reader has a video player installed, such as Windows Media PlayerTM, Quick Time PlayerTM, or RealOne PlayerTM. Please see Information for Contributors on our website. Click on Multimedia. Please note the following important information when preparing your manuscript:Treat all multimedia files as figures, numbered in sequence as they are referred to in text. (Multimedia files will not have a numbering scheme separate from the figures.) For each multimedia file, provide a figure, which is a staticrepresentation of the multimedia file. Also provide an accompanying caption. At the end of the caption, include the phrase "(enhanced online)."All multimedia files must be cited in the text, referred to by their figure number.XIII. SUPPLEMENTAL MATERIALText material that may not be of interest to all readers, long data tables, multimedia, and computer programs may be deposited as supplementary materials. Information about depositing supplemental material may be found at the journal’s Information for Contributors section on the website.ACKNOWLEDGMENTSTypically, standard acknowledgments include financial support and technical assistance, and may include dedications, memorials, and awards. Check with the Editorial Office for suitability of an acknowledgment if there is any question. To indicate the author, use initials. For example, “B.A. wishes to thank A. Loudon for technical assistance. C.A. wishes to thank Anytown University for use of th eir equipment.” Note: the Acknowledgment section is not a numbered section. APPENDIXAppendices are placed after the acknowledgments section and before the listing of references. Appendices must have a Level One heading as illustrated below. They do not follow the sequential heading numbering given in the rest of the paper. If there is only one appendix, then the heading is set as follows:APPENDIXIf there is more than one appendix, the headings are set as:APPENDIX A: DESCRIPTIONAPPENDIX B: DESCRIPTIONSubheadings in an Appendix are labeled 1, 2, etc.REFERENCESReferences must be numbered consecutively in order of first appearance in the text and should be listed at the end of the text material. Reference citations in text are rendered in several ways. For example:Voitsenya et al.4Kawa and Lin8MOLPRO (Ref. 10)The citation in the reference list must include the full list of authors. Do not list the first author followed by an abbreviation such as et al. See Table III for acceptable reference formats.TABLE III.This table provides instructions on how to prepare references.Articles “submitted to” or “accepted for publication” (but not yet published) in a journal: When possible, these references should be updated in the galley proof.1K. Park, A. Marchenkov, Z. M. M. Zhang, and W. P. King, J. Appl. Phys. 101, 094504 (2007). Books: List authors and editors. Must include publisher, city and year of publication, and the page numbers (unless the entire book is being cited).2R. J. Hunter, Zeta Potential in Colloid Science (Academic, New York, 1981), p.120.AIAA Papers:The usual format is: Authors’ names, Paper Title, AIAA Paper No. (usual formats are 99-1111 or 2004-2222), year (corresponds to numbers on left side of paper number).3M.S. Narayan and A. Banaszuk, “Experimental study of a novel active separation control approach,” AIAA Paper No. 2003-0060, 2003.Conference proceedings: Include the list of authors, the title of the proceedings, the city and year of the conference, the name of the publisher (cannot be a laboratory or institution), city and year of publication (or the words “to be published”), and the page numbers. Inclu de the full list of editors, if they are given.4R. K. Ahrenkiel, in Gallium Arsenide and Related Compounds 1993: Proceedings of the 20th International Symposium on Gallium Arsenide and Related Compounds, Freiburg, Germany, 29 August–2 September 1993, edited by H. S. Rupprecht and G. Weimann (Institute of Physics, London, 1994), pp. 685–690.Government publications:Format as for a book citation. Each must include the author(s), title of the publication, name of the publisher, city and year of publication, and page numbers (unless the entire publication is being cited).5D. Nunes, The Brillouin Effect (U.S. Department of Energy, Washington, DC, 1992).Journal citations: Include authors (see author rule above), volume number, beginning page number, and publication year:6J. D. Kiely and J. E. Houston, Phys. Rev. B 57, 12588 (1998).Laboratory report: May only be used if first deposited with a national depository such as the National Technical Information Service. (Check with the NTIS librarian at 703-605-6000.) Materials or reports in electronic form—codes, data tables,etc.—may be uploaded as supplemental material files (see Sec. XIII). If the paper is on deposit with NTIS, use the following format:7See National Technical Information Service Document No. DE132450 L. (R. Newchuck, SESAME Tables, LANL Rep. 23453, 1983). Copies may be ordered from the National Technical Information Service, Springfield, VA 22161.Multiple citations are acceptable:8D.-Y. Choi, S. Madden, A. Rode, R. Wang, and B. Luther-Davies, J. Non-Cryst. Solids 354, 3179 (2008); J. Appl. Phys. 104, 113305 (2008).(same authors, different journals)or9J.Scaroni and T. Mckee, Solid State Technol. 40, 245 (1997); M. G. Lawrence, Bull. Am.Meteorol. Soc. 86, 225 (2005).(two completely different references)or10Y. de Carlan, A. Alamo, M. H. Mathon, G. Geoffroy, and A. Castaing, J. Nucl. Mater. 283–287, 762 (2000); M. H. Mathon, Y. de Carlan, G. Geoffroy, X. Averty, A. Alamo, and C. H. de Novion, ibid. 312, 236 (2003).(different authors, same journal and volume number)MOLPRO:11H.-J. Werner, P. J. Knowles, R. Lindh, F. R. Manby, M. Schütz, et al., Molpro, version2006.1, a package of ab initio programs, 2006, see .Preprints and electronic postings:Preprints or eprints that have not been submitted to a journal for publication (i.e., are only posted on a preprint server) cannot be used as references.Private communication:May not be one of the authors of the article. Must include the year in which the communication took place.12A. Einstein (private communication, 1954).References as footnotes: Footnotes are not permitted within the main text. Each should be numbered and described in the reference list.Software manuals: If published, use the book format; if not published, give the entire address for the software maker.Thesis/dissertation: Include the author, school and year, but not the title.13S. L. Goldschmidt, Ph.D. thesis, University of California, Los Angeles, 1985.Web sites: Due to their perishable nature, web sites are not generally acceptable as references unless the site is maintained as an archival site. It is permissible to include web sites as adjuncts to acceptable references.11。

Virology Division NewsArch Virol 143/8 (1998)A revised version of the international code of virus classificationand nomenclatureM. A. Mayo and M. C. HorzinekOn behalf of the Executive Committee of the International Committee on Taxonomy of VirusesForewordThe classification of viruses and the assignment of names to taxa are the responsibility of the International Committee on Taxonomy of Viruses (ICTV). The activities of ICTV are governed by Statutes agreed by the Virology Division of the International Union of Microbiological Societies and are guided by an International Code [2]. This Code is revised occasionally to conform with accepted virological practice and to make the Rules as readily comprehensible as possible (e.g. [1]).Recently some changes to the Rules were proposed by the Executive Committee of the ICTV and subsequently ratified by the full membership of the ICTV. This article records these changes and also presents a new format for the Code, based in part on the International Code of Nomenclature of Bacteria [3].The new Rules in the Code are the following:(1) A replacement of old rule 24 (new Rule 3.24) that does not explicitly ban the use ofhigher taxon names in a species name, while at the same time avoiding encouraging this practice.(2)New Rules (3.35 to 3.36) to regulate the activities of the ICTV in classifying sub-viralagents, as has in fact been done for several years.(3)Changes to the Rules regarding orthography, so that the new Rule 3.40 replaces the oldRules 36 and 37. This Rule extends italicization of taxa to apply to species names that were previously exempted from the Rule as applied to other taxa.The changes to the format of the Code are the introduction of brief sections that describe the statutory basis for the ICTV (Section 1), the principles of nomenclature (Section 2) and the Rules (Section 3). These are laid out such that explanatory comments now follow the Rule to which they refer, and contain more examples. The new Code is presented on the following page.References1.Mayo MA (1996) Recent revisions of the rules of virus classification and nomenclature. Arch Virol 141:2479–24842.Murphy FA, Fauquet CM, Bishop DHL, Ghabrial SA, Jarvis AW, Martelli GP, Mayo MA, Summers MD(1995) Virus Taxonomy. Classification and Nomenclature of Viruses. Sixth Report of the International Committee on Taxonomy of Viruses. Springer, Wien New York (Arch Virol [Suppl] 10)3.Sneath PHA (1992) International Code of Nomenclature of Bacteria: BACTERIOLOGICAL CODE. Amer-ican Society for Microbiology, Washington DCAuthors’ addresses: M. A. Mayo, Scottish Crop Research Institute, Invergowrie, Dundee DD2 5DA, UK, and M. C. Horzinek, Department of Infectious Diseases and Immunology, Utrecht University, Yalelaan 1, 3508 TD Utrecht, The Netherlands.The international code of virus classification and nomenclature1.Statutory basis for the International Committee on Taxonomy of Viruses (ICTV)1.1The International Committee on Taxonomy of Viruses (ICTV) is a committee ofthe Virology Division of the International Union of Microbiological Societies.ICTV activities are governed by Statutes agreed with the Virology Division.1.2The Statutes define the objectives of the ICTV. These are:(i)To develop an internationally agreed taxonomy for viruses(ii)To develop internationally agreed names for virus taxa, including species and sub-viral agents.(iii)To communicate taxonomic decisions to the international community of virologists.(iv)To maintain an index of virus names.1.3The Statutes also state that classification and nomenclature will be subject to Rulesset out in an International Code.2.Principles of nomenclature2.1The essential principles of virus nomenclature are:(i)To aim for stability.(ii)To avoid or reject the use of names which might cause error or confusion.(iii)To avoid the unnecessary creation of names.2.2Nomenclature of viruses and sub-viral agents is independent of other biologicalnomenclature. Virus and virus taxon nomenclature are recognized to have the status of exceptions in the proposed International Code of Bionomenclature (BioCode).2.3The primary purpose of naming a taxon is to supply a means of referring to thetaxon, rather than to indicate the characters or the history of the taxon.2.4The application of names of taxa is determined, explicitly or implicitly, by meansof nomenclatural types.2.5The name of a taxon has no status until it has been approved by the ICTV.3.Rules of classification and nomenclatureI. General rulesThe universal scheme3.1Virus classification and nomenclature shall be international and shall be universallyapplied to all viruses.3.2The universal virus classification system shall employ the hierarchical levels ofOrder, Family, Subfamily, Genus, and Species.CommentsIt is not obligatory to use all levels of the taxonomic hierarchy. The primary classification is of viruses into species. Most species are classified into genera and most genera are classified into families. Species not assigned to a genus will be “unassigned” in a family (see Rule 3.6) and genera not classified in families have the status of “unassigned” (sometimes referred to as “floating”). Some families are classified together into Orders, but for many, the family is the highest level taxon in use. Also, families are not necessarily divided into subfamilies. This taxon is to be used only when it is needed to solve a complex hierarchical problem (see Rule3.29).Contrasting examples of full classifications of some negative strand RNA viruses are:(1) species Mumps virus; genus Rubulavirus; subfamily Paramyxovirinae; fam-ily Paramyxoviridae; order Mononegavirales, and (2) species Rice stripe virus; genus Tenuivirus (see also Rule 3.41).Scope of the classification3.3The ICTV is not responsible for classification and nomenclature of virus taxa belowthe rank of species. The classification and naming of serotypes, genotypes, strains, variants and isolates of virus species is the responsibility of acknowledged interna-tional specialist groups.CommentsParticular virus isolates may be regarded as strains, variants, clusters or other sub-specific entities that, together with other entities, constitute a species. Classification of such isolates is not the responsibility of the ICTV but is the responsibility of international speciality groups. It is the responsibility of ICTV Study Groups to decide if an isolate or a group of isolates should constitute a species.Deciding the names of serotypes, genotypes, strains, variants or isolates of virus species is not the responsibility of the ICTV. However, it is recommended that new names not be the same as, or closely similar to, names already in use (Rule 3.14 for taxa). When a particular virus isolate is designated to represent a species, the decision as to which name will be adopted for the species for formal taxonomic purposes will be the responsibility of the ICTV, initially of a particular Study Group working on behalf of the ICTV. The Study Group will be expected to consult widely so as to ensure the acceptability of names, subject to the Rules in the Code. The policy of the ICTV is that as far as is possible, taxonomic and nomenclatural decisions should reflect the majority view of the appropriate virological constituency.3.4Artificially created viruses and laboratory hybrid viruses will not be given taxonomicconsideration. Their classification will be the responsibility of acknowledged interna-tional specialist groups.CommentsNaturally occurring isolates that have genomes formed from parts of the genomes of different strains of a virus, either by recombination between the genome nucleic acids or by re-assortment of separate genome parts, will be classified either as species or sub-specific entities in the same way that other isolates are classified. Neitherartificial variants made by recombination or re-assortment, nor mutant viruses, are subject to the Rules in the Code.Limitations3.5Taxa will be established only when representative member viruses are sufficientlywell characterized and described in the published literature so as to allow them to be identified unambiguously and the taxon to be distinguished from other similar taxa.3.6When it is uncertain how to classify a species into a genus but its classification in afamily is clear, it will be classified as an unassigned species of that family.CommentsA species can be classified as an unassigned member of a family when no genus hasbeen devised. For example, Bimbo virus is a rhabdovirus of vertebrates but is not a member of any of the currently recognized genera in the family Rhabdoviridae.Likewise, Groundnut rosette assistor virus resembles viruses in the family Luteoviri-dae but is not classified in any of the genera in that family. These viruses are each classified as an unassigned member of their respective families.3.7Names will only be accepted if they are linked to taxa at the hierarchical levelsdescribed in Rule 2 and which have been approved by the ICTV.CommentsTaxa above the rank of species must be approved before a name is assigned to them.Proposals for the creation of taxa shall be accompanied by proposals for names. A decision to create a taxon can thus be followed immediately by a decision about the name for the taxon. Species will be approved together with their names as a single taxonomic act.The following example is of a proposal concerning an imaginary virus with the vernac-ular name of “beta gamma virus” that is related to another virus, “alpha beta virus”.Proposal 1.Approve Beta gamma virus as a species containing strains known as “beta gamma virus” and “alpha beta virus”.Proposal 2.Create a genus to contain species resembling Beta gamma virus.Proposal the genus created by Proposal 2, Betavirus.Proposal 4.Nominate Beta gamma virus as the type species of the genus Betavirus.Proposal 5.Create a family to contain genus Betavirus and similar genera.Proposal the family created by Proposal 5, Betaviridae.Proposal 7.Assign species X, Y and Z to genus Betavirus (such a proposal should include a listing of the parameters for discriminating between species inthe genus Betavirus).II. Rules about naming taxaStatus of names3.8Names proposed for taxa are “valid names” if they conform to the Rules set out in theCode and they pertain to established taxa. Valid names are “accepted names” if they are recorded as approved International Names in the 6th Report of the ICTV (Springer-Verlag, 1995) or become “accepted names” by an ICTV vote of approval for a taxo-nomic proposal.CommentsA valid name is one that has been published, one that is associated with descriptivematerial, and one that is acceptable in that it conforms to the Rules in the Code.Accepted names will be kept in an “Index” by the ICTV.3.9Existing names of taxa and viruses shall be retained whenever feasible.CommentA stable nomenclature is one of the principal aims of taxonomy and therefore changesto names that have been accepted will only be considered in exceptional circumstanc-es, and then only because of serious conflict with the Rules.3.10The rule of priority in naming taxa and viruses shall not be observed.CommentsThe earlier of candidate names for a taxon may be chosen as a convenience to virologists, but the Rule ensures that it is not possible to invalidate a name in current use by claiming priority for an older name that has been superseded.3.11No person’s name shall be used when devising names for new taxa.CommentsNew taxon names shall not be made by adopting a person’s name, by adding a formal ending to a person’s name or by using part of a person’s name to create a stem for a name. When existing names of species incorporate a person’s name (for example, Shope papilloma virus) continued usage of this name, in agreement with Rule 2.3 and3.9, is in general preferable to the creation of a new name.3.12Names for taxa shall be easy to use and easy to remember. Euphonious names arepreferred.CommentsIn general, short names are desirable and the number of syllables should be kept to a minimum.3.13Subscripts, superscripts, hyphens, oblique bars and Greek letters may not be used indevising new names.CommentsThe Rule is intended to make text unambiguous and easy to manipulate and its application should often make names more pronouncable, in agreement with Rule3.12. Existing names of some species violate this Rule (e.g. coliphage λ), butinternational names of genera and families do not.3.14New names shall not duplicate approved names. New names shall be chosen such thatthey are not closely similar to names that are in use currently or have been in use in the recent past.CommentsThe name selected for a new taxon should not sound indistinguishable from the name of another taxon at any rank or from any taxon. For example, the existence of the genus Iridovirus means that forms of new name such as “irodovirus” or “iridivirus”are unacceptable as they are too easily confused with an approved name. Confusion can also be between species and genus names as both end in “virus”. Thus, for example, the name selected for a genus typified by a species “Omega virus” would not be named “Omegavirus” because species and genus would then be too readily confused.3.15Sigla may be accepted as names of taxa, provided that they are meaningful tovirologists in the field, normally as represented by Study Groups.CommentsSigla are names comprising letters and/or letter combinations taken from words in a compound term. The name of the genus Comovirus has the sigla stem “Co-” from cowpea and “-mo-” from mosaic; the name of the genus Reovirus has the sigla stem “R” from “Respiratory, “e” from “enteric” and “o” from “orphan”.Decision making3.16In the event of more than one candidate name being proposed, the relevant Subcom-mittee will make a recommendation to the Executive Committee of the ICTV, which will then decide among the candidates as to which to recommend to ICTV for acceptance.CommentsWhen there is more than one candidate name for the same taxon, the decision as to which will be accepted shall be made on the basis of the Code and, if necessary, thereafter on the basis of likely acceptability to the majority of virologists.3.17If no suitable name is proposed for a taxon, the taxon may be approved and the namewill be left undecided until the adoption of an acceptable international name when one is proposed to and accepted by the ICTV.CommentsWhen genera have not been named this is indicated by quotation marks. For example, Soybean chlorotic mottle virus is a species in an as yet un-named genus in the family Caulimoviridae. Until the genus is named, it is designated as “soybean chlorotic mottle-like viruses”. This designation is regarded as temporary as it is an inconven-ience to most virologists.3.18New names shall be selected such that they, or parts of them, do not convey a meaningfor the taxon which would either (1) seem to exclude viruses which lack the character described by the name but which are members of the taxon being named, or (2) seem to exclude viruses which are as yet undescribed but which might belong to the taxon being named, or (3) appear to include within the taxon viruses which are members of different taxa.3.19New names shall be chosen with due regard to national and/or local sensitivities.When names are universally used by virologists in published work, these or derivatives shall be the preferred basis for creating names, irrespective of national origin.Procedures for naming taxa3.20Proposals for new names, name changes, establishment of taxa and taxonomicplacement of taxa shall be submitted to the Executive Committee of the ICTV in the form of taxonomic proposals. All relevant subcommittees and study groups of the ICTV will be consulted prior to a decision being taken.CommentsFor example, taxonomic proposals concerned with the family Partitiviridae would be considered by the Fungal Virus Subcommittee and one of its Study Groups but because some genera in the family contain viruses of plants, proposals affecting the family would also be considered by the Plant Virus Subcommittee.III. Rules about speciesDefinition of a virus species3.21 A virus species is defined as a polythetic class of viruses that constitutes a replicatinglineage and occupies a particular ecological niche.Definition of “tentative” status3.22When an ICTV Subcommittee is uncertain about the taxonomic status of a new speciesor about the assignment of the new species to an established genus, the new species will be listed as a tentative species in the appropriate genus or family. Names of tentative species, as of taxa generally (Rule 14), shall not duplicate approved names and shall be chosen such that they are not closely similar to names that are in use currently, names that have been in use in the recent past, or names of definitive species.CommentsSpecies classified as tentative are candidates for taxonomic decision by the appropri-ate Study Groups to resolve their tentative status.Construction of a name3.23 A species name shall consist of as few words as practicable but shall not consist onlyof a host name and the word “virus”.CommentsThe styles used when virus names are devised differ according to the traditions of the particular fields of virology. For example, plant virus names are usually constructed as host + symptom + “virus” (e.g. tobacco necrosis virus) whereas, in contrast, viruses in the family Bunyaviridae are usually named after the location at which the virus was found + “virus” (e.g. Bunyamwera virus).3.24 A species name must provide an appropriately unambiguous identification of thespecies.3.25Numbers, letters, or combinations thereof may be used as species epithets where suchnumbers and letters are already widely used. However, newly designated serial numbers, letters or combinations thereof are not acceptable alone as species epithets.If a number or letter series is in existence it may be continued.IV. Rules about genera3.26 A genus is a group of species sharing certain common characters.3.27 A genus name shall be a single word ending in “… virus.”3.28Approval of a new genus must be accompanied by the approval of a type species.V. Rules about subfamilies3.29 A subfamily is a group of genera sharing certain common characters. The taxon shallbe used only when it is needed to solve a complex hierarchical problem.3.30 A subfamily name shall be a single word ending in “… virinae.”VI. Rules about families3.31 A family is a group of genera (whether or not these are organized into subfamilies)sharing certain common characters.3.32 A family name shall be a single word ending in “… viridae.”VII. Rules about orders3.33An order is a group of families sharing certain common characters.3.34An order name shall be a single word ending in “… virales.”VIII. Rules about sub-viral agentsViroids3.35Rules concerned with the classification of viruses shall also apply to the classificationof viroids.3.36The formal endings for taxa of viroids are the word “viroid” for species, the suffix“-viroid” for genera, the suffix “-viroinae” for sub-families (should this taxon be needed) and “-viroidae” for families.CommentsFor example, the species Potato spindle tuber viroid is classified in genus Pospivi-roid, and the family Pospiviroidae.Other sub-viral agents3.37Retrotransposons are considered to be viruses in classification and nomenclature 3.38Satellites and prions are not classified as viruses but are assigned an arbitraryclassification as seems useful to workers in the particular fields.IX. Rules for orthography3.39In formal taxonomic usage, the accepted names of virus Orders, Families, Sub-families, and Genera are printed in italics and the first letters of the names are capitalized.CommentsSee Rule 3.8 for the definition of an “accepted” name.3.40Species names are printed in italics and have the first letter of the first wordcapitalized. Other words are not capitalized unless they are proper nouns, or parts of proper nouns.CommentsWhen used formally, as labels for taxonomic entities, the names Tobacco mosaic virus and Murray River encephalitis virus are in the correct form and typographical style. Examples of incorrect forms are Aspergillus niger virus S (not italic), Murray river encephalitis virus (River is a proper noun) or tobacco mosaic virus (not capitalized or italic).Taxa are abstractions and thus when their names are used formally, these are written distinctively using italicization and capitalization. In other senses, such as an adjecti-val form (e.g. the tobacco mosaic virus polymerase) italics and capital initial letters are not needed. Equally, these are not needed when referring to physical entities such as virions (e.g. a preparation or a micrograph of tobacco mosaic virus).This Rule was introduced in 1998 and is in contradistinction to Rules in the Code published in the 6th Report of the ICTV (Springer-Verlag, 1995).3.41In formal usage, the name of the taxon shall precede the term for the taxonomic unit.CommentsFor example, the correct formal descriptions of various taxa are … the family Herpesviridae … the genus Morbillivirus, … the genus Rhinovirus, … the species Tobacco necrosis virus, and so on.Verleger: Springer-Verlag KG, Sachsenplatz 4–6, A-1201 Wien. – Herausgeber: Dr. F. A. Murphy, School of Veterinary Medicine, University of California Davis, Davis, CA 95616, U.S.A. – Redaktion: Sachsenplatz 4–6, A-1201 Wien. – Satz und Umbruch: Thomson Press (India) Ltd., New Delhi. – Offsetdruck: Adolf Holzhausens Nachfolger, Kandlgasse 19–21, A-1070 Wien. – Umschlagentwurf: Ecke Bonk. – Herstellungsort: Wien. – Printed in Austria.。

RFC 3550 中文文档翻译说明译者注：本文档提供给那些有一定英语基础的读者，所以文中涉及到的专有词汇均以英文原词给出，给读者带来的不便请凉解。

本文档知识产权声明部分仅供参考，如有涉及到与知识产权有关的地方请参看原文或询问相关法律人式。

由于工作量太大，附录部分没有列入译者翻译之列，请谅解。

感谢罗总及工程师gale 给予的支持和帮助。

由于译者水平有限和时间冲忙，文中一定有错译的地方，译者尽量将这种情况降到最小，但不排除译者本身就理解错误的情况，欢迎任何对本书有兴趣的读者提出任何质疑，邮箱：xingkongft@，QQ：601211088。

Network Working Group H。

Schulzrinne Request for Comments：3550 Columbia UniversityObsoletes：1889 S。

Casner Category： Standards Track Packet DesignR。

Frederick Blue Coat Systems Inc 。

V。

JacobsonPacket DesignJuly 2003 RTP ：应用于实时应用的传输协议备忘录的状态：本文档讲述了一种Internet 社区的Internet 标准跟踪协议，它需要进一步进行讨论和建议以得到改进。

请参考最新版的“Internet 正式协议标准”(STD1)来获得本协议的标准化程度和状态。

本备忘录的发布不受任何限制。

版权声明：版权为The Internet Society （2003）所有。

所有权利保留。

摘要：本文档阐述了实时传输协议（RTP)，RTP 提供了端到端的网络传输功能，适合于通过多播或单播网络服务的实时数据传输应用，例如：音频，视频等，RTP 不强调资源保留(does not address resource reservation) 而且并不保证实时服务QOS(quality-of-service)，实时控制协议(RTCP)对数据进行监控和提供最小的控制和鉴别功能。

Network Working Group J. Case Request for Comments: 1157 SNMP Research Obsoletes: RFC 1098 M. Fedor Performance Systems International M. Schoffstall Performance Systems International J. Davin MIT Laboratory for Computer Science May 1990 A Simple Network Management Protocol (SNMP)Table of Contents1. Status of this Memo (2)2. Introduction (2)3. The SNMP Architecture (5)3.1 Goals of the Architecture (5)3.2 Elements of the Architecture (5)3.2.1 Scope of Management Information (6)3.2.2 Representation of Management Information (6)3.2.3 Operations Supported on Management Information (7)3.2.4 Form and Meaning of Protocol Exchanges (8)3.2.5 Definition of Administrative Relationships (8)3.2.6 Form and Meaning of References to Managed Objects .. 123.2.6.1 Resolution of Ambiguous MIB References (12)3.2.6.2 Resolution of References across MIB Versions (12)3.2.6.3 Identification of Object Instances (12)3.2.6.3.1 ifTable Object Type Names (13)3.2.6.3.2 atTable Object Type Names (13)3.2.6.3.3 ipAddrTable Object Type Names (14)3.2.6.3.4 ipRoutingTable Object Type Names (14)3.2.6.3.5 tcpConnTable Object Type Names (14)3.2.6.3.6 egpNeighTable Object Type Names (15)4. Protocol Specification (16)4.1 Elements of Procedure (17)4.1.1 Common Constructs (19)4.1.2 The GetRequest-PDU (20)4.1.3 The GetNextRequest-PDU (21)4.1.3.1 Example of Table Traversal (23)4.1.4 The GetResponse-PDU (24)4.1.5 The SetRequest-PDU (25)4.1.6 The Trap-PDU (27)4.1.6.1 The coldStart Trap (28)4.1.6.2 The warmStart Trap (28)4.1.6.3 The linkDown Trap (28)4.1.6.4 The linkUp Trap (28)Case, Fedor, Schoffstall, & Davin [Page 1]RFC 1157 SNMP May 1990 4.1.6.5 The authenticationFailure Trap (28)4.1.6.6 The egpNeighborLoss Trap (28)4.1.6.7 The enterpriseSpecific Trap (29)5. Definitions (30)6. Acknowledgements (33)7. References (34)8. Security Considerations (35)9. Authors' Addresses (35)1. Status of this MemoThis RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for anetwork element may be inspected or altered by logically remoteusers. In particular, together with its companion memos whichdescribe the structure of management information along with themanagement information base, these documents provide a simple,workable architecture and system for managing TCP/IP-based internets and in particular the Internet.The Internet Activities Board recommends that all IP and TCPimplementations be network manageable. This implies implementation of the Internet MIB (RFC-1156) and at least one of the tworecommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095). It should be noted that, at this time, SNMP is a full Internetstandard and CMOT is a draft standard. See also the Host and Gateway Requirements RFCs for more specific information on the applicability of this standard.Please refer to the latest edition of the "IAB Official ProtocolStandards" RFC for current information on the state and status ofstandard Internet protocols.Distribution of this memo is unlimited.2. IntroductionAs reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP) was to be used to manage nodes in the Internet community. In the long-term,the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI)[2], and RFC 1066, which defined the Management Information Base(MIB) [3]. Both of these documents were designed so as to beCase, Fedor, Schoffstall, & Davin [Page 2]RFC 1157 SNMP May 1990 compatible with both the SNMP and the OSI network managementframework.This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this,portions of the Internet community became network manageable in atimely fashion.As reported in RFC 1109, Report of the Second Ad Hoc NetworkManagement Review Group [4], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated.As such, the requirement for compatibility between the SMI/MIB andboth frameworks was suspended. This action permitted the operational network management framework, the SNMP, to respond to new operational needs in the Internet community by producing documents defining new MIB items.The IAB has designated the SNMP, SMI, and the initial Internet MIB to be full "Standard Protocols" with "Recommended" status. By thisaction, the IAB recommends that all IP and TCP implementations benetwork manageable and that the implementations that are networkmanageable are expected to adopt and implement the SMI, MIB, andSNMP.As such, the current network management framework for TCP/IP- based internets consists of: Structure and Identification of ManagementInformation for TCP/IP-based Internets, which describes how managed objects contained in the MIB are defined as set forth in RFC 1155[5]; Management Information Base for Network Management of TCP/IP-based Internets, which describes the managed objects contained in the MIB as set forth in RFC 1156 [6]; and, the Simple Network Management Protocol, which defines the protocol used to manage these objects, as set forth in this memo.As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], the Internet ActivitiesBoard has directed the Internet Engineering Task Force (IETF) tocreate two new working groups in the area of network management. One group was charged with the further specification and definition ofelements to be included in the Management Information Base (MIB).The other was charged with defining the modifications to the Simple Network Management Protocol (SNMP) to accommodate the short-termneeds of the network vendor and operations communities, and to align with the output of the MIB working group.The MIB working group produced two memos, one which defines aStructure for Management Information (SMI) [2] for use by the managed Case, Fedor, Schoffstall, & Davin [Page 3]RFC 1157 SNMP May 1990 objects contained in the MIB. A second memo [3] defines the list of managed objects.The output of the SNMP Extensions working group is this memo, which incorporates changes to the initial SNMP definition [7] required to attain alignment with the output of the MIB working group. Thechanges should be minimal in order to be consistent with the IAB'sdirective that the working groups be "extremely sensitive to the need to keep the SNMP simple." Although considerable care and debate has gone into the changes to the SNMP which are reflected in this memo, the resulting protocol is not backwardly-compatible with itspredecessor, the Simple Gateway Monitoring Protocol (SGMP) [8].Although the syntax of the protocol has been altered, the originalphilosophy, design decisions, and architecture remain intact. Inorder to avoid confusion, new UDP ports have been allocated for use by the protocol described in this memo.Case, Fedor, Schoffstall, & Davin [Page 4]RFC 1157 SNMP May 1990 3. The SNMP ArchitectureImplicit in the SNMP architectural model is a collection of network management stations and network elements. Network managementstations execute management applications which monitor and controlnetwork elements. Network elements are devices such as hosts,gateways, terminal servers, and the like, which have managementagents responsible for performing the network management functionsrequested by the network management stations. The Simple NetworkManagement Protocol (SNMP) is used to communicate managementinformation between the network management stations and the agents in the network elements.3.1. Goals of the ArchitectureThe SNMP explicitly minimizes the number and complexity of management functions realized by the management agent itself. This goal isattractive in at least four respects:(1) The development cost for management agent softwarenecessary to support the protocol is accordingly reduced.(2) The degree of management function that is remotelysupported is accordingly increased, thereby admittingfullest use of internet resources in the management task.(3) The degree of management function that is remotelysupported is accordingly increased, thereby imposing thefewest possible restrictions on the form andsophistication of management tools.(4) Simplified sets of management functions are easilyunderstood and used by developers of network managementtools.A second goal of the protocol is that the functional paradigm formonitoring and control be sufficiently extensible to accommodateadditional, possibly unanticipated aspects of network operation and management.A third goal is that the architecture be, as much as possible,independent of the architecture and mechanisms of particular hosts or particular gateways.3.2. Elements of the ArchitectureThe SNMP architecture articulates a solution to the networkmanagement problem in terms of:Case, Fedor, Schoffstall, & Davin [Page 5]RFC 1157 SNMP May 1990 (1) the scope of the management information communicated bythe protocol,(2) the representation of the management informationcommunicated by the protocol,(3) operations on management information supported by theprotocol,(4) the form and meaning of exchanges among managemententities,(5) the definition of administrative relationships amongmanagement entities, and(6) the form and meaning of references to managementinformation.3.2.1. Scope of Management InformationThe scope of the management information communicated by operation of the SNMP is exactly that represented by instances of all non-aggregate object types either defined in Internet-standard MIB ordefined elsewhere according to the conventions set forth inInternet-standard SMI [5].Support for aggregate object types in the MIB is neither required for conformance with the SMI nor realized by the SNMP.3.2.2. Representation of Management InformationManagement information communicated by operation of the SNMP isrepresented according to the subset of the ASN.1 language [9] that is specified for the definition of non-aggregate types in the SMI.The SGMP adopted the convention of using a well-defined subset of theASN.1 language [9]. The SNMP continues and extends this tradition by utilizing a moderately more complex subset of ASN.1 for describingmanaged objects and for describing the protocol data units used for managing those objects. In addition, the desire to ease eventualtransition to OSI-based network management protocols led to thedefinition in the ASN.1 language of an Internet-standard Structure of Management Information (SMI) [5] and Management Information Base(MIB) [6]. The use of the ASN.1 language, was, in part, encouraged by the successful use of ASN.1 in earlier efforts, in particular, the SGMP. The restrictions on the use of ASN.1 that are part of the SMI contribute to the simplicity espoused and validated by experiencewith the SGMP.Case, Fedor, Schoffstall, & Davin [Page 6]RFC 1157 SNMP May 1990 Also for the sake of simplicity, the SNMP uses only a subset of the basic encoding rules of ASN.1 [10]. Namely, all encodings use thedefinite-length form. Further, whenever permissible, non-constructor encodings are used rather than constructor encodings. Thisrestriction applies to all aspects of ASN.1 encoding, both for thetop-level protocol data units and the data objects they contain.3.2.3. Operations Supported on Management InformationThe SNMP models all management agent functions as alterations orinspections of variables. Thus, a protocol entity on a logicallyremote host (possibly the network element itself) interacts with the management agent resident on the network element in order to retrieve (get) or alter (set) variables. This strategy has at least twopositive consequences:(1) It has the effect of limiting the number of essentialmanagement functions realized by the management agent totwo: one operation to assign a value to a specifiedconfiguration or other parameter and another to retrievesuch a value.(2) A second effect of this decision is to avoid introducinginto the protocol definition support for imperativemanagement commands: the number of such commands is inpractice ever-increasing, and the semantics of suchcommands are in general arbitrarily complex.The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoringcenter(s). A limited number of unsolicited messages (traps) guidethe timing and focus of the polling. Limiting the number ofunsolicited messages is consistent with the goal of simplicity andminimizing the amount of traffic generated by the network management function.The exclusion of imperative commands from the set of explicitlysupported management functions is unlikely to preclude any desirable management agent operation. Currently, most commands are requestseither to set the value of some parameter or to retrieve such avalue, and the function of the few imperative commands currentlysupported is easily accommodated in an asynchronous mode by thismanagement model. In this scheme, an imperative command might berealized as the setting of a parameter value that subsequentlytriggers the desired action. For example, rather than implementing a "reboot command," this action might be invoked by simply setting aparameter indicating the number of seconds until system reboot. Case, Fedor, Schoffstall, & Davin [Page 7]RFC 1157 SNMP May 1990 3.2.4. Form and Meaning of Protocol ExchangesThe communication of management information among management entities is realized in the SNMP through the exchange of protocol messages.The form and meaning of those messages is defined below in Section 4. Consistent with the goal of minimizing complexity of the management agent, the exchange of SNMP messages requires only an unreliabledatagram service, and every message is entirely and independentlyrepresented by a single transport datagram. While this documentspecifies the exchange of messages via the UDP protocol [11], themechanisms of the SNMP are generally suitable for use with a widevariety of transport services.3.2.5. Definition of Administrative RelationshipsThe SNMP architecture admits a variety of administrativerelationships among entities that participate in the protocol. The entities residing at management stations and network elements which communicate with one another using the SNMP are termed SNMPapplication entities. The peer processes which implement the SNMP, and thus support the SNMP application entities, are termed protocol entities.A pairing of an SNMP agent with some arbitrary set of SNMPapplication entities is called an SNMP community. Each SNMPcommunity is named by a string of octets, that is called thecommunity name for said community.An SNMP message originated by an SNMP application entity that in fact belongs to the SNMP community named by the community component ofsaid message is called an authentic SNMP message. The set of rules by which an SNMP message is identified as an authentic SNMP message for a particular SNMP community is called an authentication scheme. An implementation of a function that identifies authentic SNMPmessages according to one or more authentication schemes is called an authentication service.Clearly, effective management of administrative relationships among SNMP application entities requires authentication services that (by the use of encryption or other techniques) are able to identifyauthentic SNMP messages with a high degree of certainty. Some SNMP implementations may wish to support only a trivial authenticationservice that identifies all SNMP messages as authentic SNMP messages. For any network element, a subset of objects in the MIB that pertain to that element is called a SNMP MIB view. Note that the names ofthe object types represented in a SNMP MIB view need not belong to a Case, Fedor, Schoffstall, & Davin [Page 8]RFC 1157 SNMP May 1990 single sub-tree of the object type name space.An element of the set { READ-ONLY, READ-WRITE } is called an SNMPaccess mode.A pairing of a SNMP access mode with a SNMP MIB view is called anSNMP community profile. A SNMP community profile representsspecified access privileges to variables in a specified MIB view. For every variable in the MIB view in a given SNMP community profile,access to that variable is represented by the profile according tothe following conventions:(1) if said variable is defined in the MIB with "Access:" of"none," it is unavailable as an operand for any operator;(2) if said variable is defined in the MIB with "Access:" of"read-write" or "write-only" and the access mode of thegiven profile is READ-WRITE, that variable is availableas an operand for the get, set, and trap operations;(3) otherwise, the variable is available as an operand forthe get and trap operations.(4) In those cases where a "write-only" variable is anoperand used for the get or trap operations, the valuegiven for the variable is implementation-specific.A pairing of a SNMP community with a SNMP community profile is called a SNMP access policy. An access policy represents a specifiedcommunity profile afforded by the SNMP agent of a specified SNMPcommunity to other members of that community. All administrativerelationships among SNMP application entities are architecturallydefined in terms of SNMP access policies.For every SNMP access policy, if the network element on which theSNMP agent for the specified SNMP community resides is not that towhich the MIB view for the specified profile pertains, then thatpolicy is called a SNMP proxy access policy. The SNMP agentassociated with a proxy access policy is called a SNMP proxy agent. While careless definition of proxy access policies can result inmanagement loops, prudent definition of proxy policies is useful in at least two ways:(1) It permits the monitoring and control of network elementswhich are otherwise not addressable using the managementprotocol and the transport protocol. That is, a proxyagent may provide a protocol conversion function allowinga management station to apply a consistent managementCase, Fedor, Schoffstall, & Davin [Page 9]RFC 1157 SNMP May 1990 framework to all network elements, including devices suchas modems, multiplexors, and other devices which supportdifferent management frameworks.(2) It potentially shields network elements from elaborateaccess control policies. For example, a proxy agent mayimplement sophisticated access control whereby diversesubsets of variables within the MIB are made accessibleto different management stations without increasing thecomplexity of the network element.By way of example, Figure 1 illustrates the relationship betweenmanagement stations, proxy agents, and management agents. In thisexample, the proxy agent is envisioned to be a normal InternetNetwork Operations Center (INOC) of some administrative domain which has a standard managerial relationship with a set of managementagents.Case, Fedor, Schoffstall, & Davin [Page 10]RFC 1157 SNMP May 1990 +------------------+ +----------------+ +----------------+ | Region #1 INOC | |Region #2 INOC | |PC in Region #3 | | | | | | | |Domain=Region #1 | |Domain=Region #2| |Domain=Region #3| |CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 | |PCommunity=pub | |PCommunity=pub | |PCommunity=slate| | | | | | | +------------------+ +----------------+ +----------------+ /|\ /|\ /|\| | || | || \|/ || +-----------------+ |+-------------->| Region #3 INOC |<-------------+| ||Domain=Region #3 ||CPU=super-mini-2 ||PCommunity=pub, || slate ||DCommunity=secret|+-------------->| |<-------------+| +-----------------+ || /|\ || | || | |\|/ \|/ \|/+-----------------+ +-----------------+ +-----------------+ |Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 | |CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 | |DCommunity=secret| |DCommunity=secret| |DCommunity=secret| +-----------------+ +-----------------+ +-----------------+ Domain: the administrative domain of the elementPCommunity: the name of a community utilizing a proxy agentDCommunity: the name of a direct communityFigure 1Example Network Management ConfigurationCase, Fedor, Schoffstall, & Davin [Page 11]RFC 1157 SNMP May 1990 3.2.6. Form and Meaning of References to Managed ObjectsThe SMI requires that the definition of a conformant managementprotocol address:(1) the resolution of ambiguous MIB references,(2) the resolution of MIB references in the presence multipleMIB versions, and(3) the identification of particular instances of objecttypes defined in the MIB.3.2.6.1. Resolution of Ambiguous MIB ReferencesBecause the scope of any SNMP operation is conceptually confined to objects relevant to a single network element, and because all SNMPreferences to MIB objects are (implicitly or explicitly) by uniquevariable names, there is no possibility that any SNMP reference toany object type defined in the MIB could resolve to multipleinstances of that type.3.2.6.2. Resolution of References across MIB VersionsThe object instance referred to by any SNMP operation is exactly that specified as part of the operation request or (in the case of a get- next operation) its immediate successor in the MIB as a whole. Inparticular, a reference to an object as part of some version of the Internet-standard MIB does not resolve to any object that is not part of said version of the Internet-standard MIB, except in the case that the requested operation is get-next and the specified object name is lexicographically last among the names of all objects presented aspart of said version of the Internet-Standard MIB.3.2.6.3. Identification of Object InstancesThe names for all object types in the MIB are defined explicitlyeither in the Internet-standard MIB or in other documents whichconform to the naming conventions of the SMI. The SMI requires that conformant management protocols define mechanisms for identifyingindividual instances of those object types for a particular network element.Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its "variable name." Ingeneral, the name of an SNMP variable is an OBJECT IDENTIFIER of the form x.y, where x is the name of a non-aggregate object type defined in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way Case, Fedor, Schoffstall, & Davin [Page 12]RFC 1157 SNMP May 1990 specific to the named object type, identifies the desired instance. This naming strategy admits the fullest exploitation of the semantics of the GetNextRequest-PDU (see Section 4), because it assigns names for related variables so as to be contiguous in the lexicographical ordering of all variable names known in the MIB.The type-specific naming of object instances is defined below for a number of classes of object types. Instances of an object type towhich none of the following naming conventions are applicable arenamed by OBJECT IDENTIFIERs of the form x.0, where x is the name of said object type in the MIB definition.For example, suppose one wanted to identify an instance of thevariable sysDescr The object class for sysDescr is:iso org dod internet mgmt mib system sysDescr1 3 6 12 1 1 1Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which isappended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0 identifies the one and only instance of sysDescr.3.2.6.3.1. ifTable Object Type NamesThe name of a subnet interface, s, is the OBJECT IDENTIFIER value of the form i, where i has the value of that instance of the ifIndexobject type associated with s.For each object type, t, for which the defined name, n, has a prefix of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.s, where s is the name of the subnet interface about which i represents information.For example, suppose one wanted to identify the instance of thevariable ifType associated with interface 2. Accordingly, ifType.2 would identify the desired instance.3.2.6.3.2. atTable Object Type NamesThe name of an AT-cached network address, x, is an OBJECT IDENTIFIER of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar"dot" notation) of the atNetAddress object type associated with x.The name of an address translation equivalence e is an OBJECTIDENTIFIER value of the form s.w, such that s is the value of thatinstance of the atIndex object type associated with e and such that w is the name of the AT-cached network address associated with e. Case, Fedor, Schoffstall, & Davin [Page 13]RFC 1157 SNMP May 1990 For each object type, t, for which the defined name, n, has a prefix of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the address translationequivalence about which i represents information.For example, suppose one wanted to find the physical address of anentry in the address translation table (ARP cache) associated with an IP address of 89.1.1.42 and interface 3. Accordingly,atPhysAddress.3.1.89.1.1.42 would identify the desired instance.3.2.6.3.3. ipAddrTable Object Type NamesThe name of an IP-addressable network element, x, is the OBJECTIDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the familiar "dot" notation) of that instance of the ipAdEntAddr object type associated with x.For each object type, t, for which the defined name, n, has a prefix of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the IP-addressable networkelement about which i represents information.For example, suppose one wanted to find the network mask of an entry in the IP interface table associated with an IP address of 89.1.1.42. Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desiredinstance.3.2.6.3.4. ipRoutingTable Object Type NamesThe name of an IP route, x, is the OBJECT IDENTIFIER of the forma.b.c.d such that a.b.c.d is the value (in the familiar "dot"notation) of that instance of the ipRouteDest object type associated with x.For each object type, t, for which the defined name, n, has a prefix of ipRoutingEntry, an instance, i, of t is named by an OBJECT。

组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：********************译者：黄晓东（黄晓东****************）译文发布时间：2001-7-14版权：本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

Network Working Group T. Berners-Lee Request for Comments: 1945 MIT/LCS Category: Informational R. Fielding UC IrvineH. FrystykMIT/LCSMay 1996超文本传输协议 -- HTTP/1.0（Hyptertext Transfer Protocol – HTTP/1.0）关于下段备忘（Status of This Memo）本段文字为Internet团体提供信息，并没有以任何方式指定Internet标准。

本段文字没有分发限制。

IESG提示（IESG Note）：IESG已在关注此协议，并期待该文档能尽快被标准跟踪文档所替代。

摘要（Abstract）HTTP（Hypertext Transfer Protocol）是应用级协议，它适应了分布式超媒体协作系统对灵活性及速度的要求。

它是一个一般的、无状态的、基于对象的协议，通过对其请求方法（request methods）进行扩展，可以被用于多种用途，比如命名服务器（name server）及分布式对象管理系统。

HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。

HTTP自从1990年就在WWW上被广泛使用。

该规范反映了“HTTP/1.0”的普通用法。

目录（Table of Contents）1. 介绍（Introduction） 61.1 目的（Purpose） 61.2 术语（Terminology） 61.3 概述（Overall Operation）81.4 HTTP and MIME 92. 标志转换及通用语法（Notational Conventions and Generic Grammar）9 2.1 补充反馈方式（Augmented BNF）92.2 基本规则（Basic Rules）103. 协议参数（Protocol Parameters） 123.1 HTTP版本（HTTP Version）123.2 统一资源标识（Uniform Resource Identifiers）133.2.1 一般语法（General Syntax）133.2.2 http URL 143.3 Date/Time 格式（Date/Time Formats）153.4 字符集（Character Sets）163.5 内容译码（Content Codings）163.6 介质类型（Media Types）173.6.1标准及文本缺省（Canonicalization and Text Defaults）183.6.2 多部分类型（Multipart Types） 183.7 产品标识（Product Tokens） 194. HTTP 消息（HTTP Message）194.1 消息类型（Message Types）194.2 消息标题（Message Headers）204.3 普通标题域（General Header Fields）205. 请求（Request）215.1 请求队列（Request-Line）215.1.1 方法（Method）225.1.2 请求URI（Request-URI）225.2 请求标题域（Request Header Fields）236. 回应（Response）236.1 状态行（Status-Line）246.1.1 状态代码和原因分析（Status Code and Reason Phrase）246.2 回应标题域（Response Header Fields）257. 实体（Entity）267.1 实体标题域（Entity Header Fields） 267.2 实体主体（Entity Body）267.2.1 类型（Type）277.2.2 长度（Length）278. 方法定义（Method Definitions）278.1 GET 288.2 HEAD 288.3 POST 289. 状态代码定义（Status Code Definitions） 299.1 消息1xx（Informational 1xx）299.2 成功2xx（Successful 2xx）299.3 重定向（Redirection 3xx）309.4 客户端错误（Client Error ）4xx 319.5 服务器错误（Server Error ）5xx 3210. 标题域定义（Header Field Definitions） 3310.1 允许（Allow） 3310.2 授权（Authorization） 3410.3 内容编码（Content-Encoding）3410.4 内容长度（Content-Length）3410.5 内容类型（Content-Type）3510.6 日期（Date）3510.7 过期（Expires）3610.8 来自（From）3710.9 从何时更改（If-Modified-Since）3710.10 最近更改（Last-Modified）3810.11 位置（Location） 3810.12 注解（Pragma）3910.13 提交方（Referer） 3910.14 服务器（Server） 4010.15 用户代理（User-Agent）4010.16 WWW-授权（WWW-Authenticate） 4011. 访问鉴别（Access Authentication）4111.1 基本授权方案（Basic Authentication Scheme）4212. 安全考虑（Security Considerations）4312.1 客户授权（Authentication of Clients） 4312.2 安全方法（Safe Methods）4312.3 服务器日志信息的弊端（Abuse of Server Log Information）4312.4 敏感信息传输（Transfer of Sensitive Information） 4412.5 基于文件及路径名的攻击（Attacks Based On File and Path Names）4413. 感谢（Acknowledgments）4514. 参考书目（References）4515. 作者地址（Authors' Addresses） 47附录（Appendices）48A. Internet介质类型消息/http（Internet Media Type message/http）48B. 容错应用（Tolerant Applications）48C. 与MIME的关系（Relationship to MIME）49C.1 转换为规范形式（Conversion to Canonical Form） 49C.2 日期格式转换（Conversion of Date Formats） 49C.3 内容编码介绍（Introduction of Content-Encoding）50C.4 无内容传输编码（No Content-Transfer-Encoding） 50C.5 多个主体的HTTP标题域（HTTP Header Fields in Multipart Body-Parts）50D. 附加特性（Additional Features） 50D.1 附加请求方法（Additional Request Methods） 51D.2 附加标题域定义（Additional Header Field Definitions）511. 介绍（Introduction）1.1 目的（Purpose）HTTP（Hypertext Transfer Protocol）是应用级协议，它适应了分布式超媒体协作系统对灵活性及速度的要求。

Network Working Group A. NiemiRequest for Comments: 3310 NokiaCategory: Informational J. Arkko V. Torvinen Ericsson September 2002

Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)

Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.Abstract This memo specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography.