rfc3937.A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Counc
rfc4122.A Universally Unique IDentifier (UUID) URN Namespace
Network Working Group P. Leach Request for Comments: 4122 Microsoft Category: Standards Track M. Mealling Refactored Networks, LLC R. Salz DataPower Technology, Inc. July 2005 A Universally Unique IDentifier (UUID) URN NamespaceStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis specification defines a Uniform Resource Name namespace forUUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guaranteeuniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open SoftwareFoundation’s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.This specification is derived from the DCE specification with thekind permission of the OSF (now known as The Open Group).Information from earlier versions of the DCE specification have been incorporated into this document.Leach, et al. Standards Track [Page 1]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 33. Namespace Registration Template . . . . . . . . . . . . . . . 34. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Format. . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Variant. . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Layout and Byte Order. . . . . . . . . . . . . . . 6 4.1.3. Version. . . . . . . . . . . . . . . . . . . . . . 7 4.1.4. Timestamp. . . . . . . . . . . . . . . . . . . . . 8 4.1.5. Clock Sequence . . . . . . . . . . . . . . . . . . 8 4.1.6. Node . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.7. Nil UUID . . . . . . . . . . . . . . . . . . . . . 9 4.2. Algorithms for Creating a Time-Based UUID . . . . . . . . 9 4.2.1. Basic Algorithm. . . . . . . . . . . . . . . . . . 10 4.2.2. Generation Details . . . . . . . . . . . . . . . . 12 4.3. Algorithm for Creating a Name-Based UUID. . . . . . . . . 13 4.4. Algorithms for Creating a UUID from Truly Random orPseudo-Random Numbers . . . . . . . . . . . . . . . . . . 144.5. Node IDs that Do Not Identify the Host. . . . . . . . . . 155. Community Considerations . . . . . . . . . . . . . . . . . . . 156. Security Considerations . . . . . . . . . . . . . . . . . . . 167. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 168. Normative References . . . . . . . . . . . . . . . . . . . . . 16A. Appendix A - Sample Implementation . . . . . . . . . . . . . . 18B. Appendix B - Sample Output of utest . . . . . . . . . . . . . 29C. Appendix C - Some Name Space IDs . . . . . . . . . . . . . . . 301. IntroductionThis specification defines a Uniform Resource Name namespace forUUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and requires no central registration process.The information here is meant to be a concise guide for those wishing to implement services using UUIDs as URNs. Nothing in this document should be construed to override the DCE standards that defined UUIDs. There is an ITU-T Recommendation and ISO/IEC Standard [3] that arederived from earlier versions of this document. Both sets ofspecifications have been aligned, and are fully technicallycompatible. In addition, a global registration function is beingprovided by the Telecommunications Standardisation Bureau of ITU-T;for details see <http://www.itu.int/ITU-T/asn1/uuid.html>.Leach, et al. Standards Track [Page 2]2. MotivationOne of the main reasons for using UUIDs is that no centralizedauthority is required to administer them (although one format usesIEEE 802 node identifiers, others do not). As a result, generationon demand can be completely automated, and used for a variety ofpurposes. The UUID generation algorithm described here supports very high allocation rates of up to 10 million per second per machine ifnecessary, so that they could even be used as transaction IDs.UUIDs are of a fixed size (128 bits) which is reasonably smallcompared to other alternatives. This lends itself well to sorting,ordering, and hashing of all sorts, storing in databases, simpleallocation, and ease of programming in general.Since UUIDs are unique and persistent, they make excellent UniformResource Names. The unique ability to generate a new UUID without a registration process allows for UUIDs to be one of the URNs with the lowest minting cost.3. Namespace Registration TemplateNamespace ID: UUIDRegistration Information:Registration date: 2003-10-01Declared registrant of the namespace:JTC 1/SC6 (ASN.1 Rapporteur Group)Declaration of syntactic structure:A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs. Since a UUID is a fixedsize and contains a time field, it is possible for values torollover (around A.D. 3400, depending on the specific algorithmused). A UUID can be used for multiple purposes, from taggingobjects with an extremely short lifetime, to reliably identifying very persistent objects across a network.The internal representation of a UUID is a specific sequence ofbits in memory, as described in Section 4. To accuratelyrepresent a UUID as a URN, it is necessary to convert the bitsequence to a string representation.Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significantdigit first. The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.Leach, et al. Standards Track [Page 3]The formal definition of the UUID string representation isprovided by the following ABNF [7]:UUID = time-low "-" time-mid "-"time-high-and-version "-"clock-seq-and-reservedclock-seq-low "-" nodetime-low = 4hexOctettime-mid = 2hexOctettime-high-and-version = 2hexOctetclock-seq-and-reserved = hexOctetclock-seq-low = hexOctetnode = 6hexOctethexOctet = hexDigit hexDigithexDigit ="0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" /"A" / "B" / "C" / "D" / "E" / "F"The following is an example of the string representation of a UUID as a URN:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6Relevant ancillary documentation:[1][2]Identifier uniqueness considerations:This document specifies three algorithms to generate UUIDs: thefirst leverages the unique values of 802 MAC addresses toguarantee uniqueness, the second uses pseudo-random numbergenerators, and the third uses cryptographic hashing andapplication-provided text strings. As a result, the UUIDsgenerated according to the mechanisms here will be unique from all other UUIDs that have been or will be assigned.Identifier persistence considerations:UUIDs are inherently very difficult to resolve in a global sense. This, coupled with the fact that UUIDs are temporally uniquewithin their spatial context, ensures that UUIDs will remain aspersistent as possible.Process of identifier assignment:Generating a UUID does not require that a registration authoritybe contacted. One algorithm requires a unique value over spacefor each generator. This value is typically an IEEE 802 MACaddress, usually already available on network-connected hosts.The address can be assigned from an address block obtained fromthe IEEE registration authority. If no such address is available, Leach, et al. Standards Track [Page 4]or privacy concerns make its use undesirable, Section 4.5specifies two alternatives. Another approach is to use version 3 or version 4 UUIDs as defined below.Process for identifier resolution:Since UUIDs are not globally resolvable, this is not applicable.Rules for Lexical Equivalence:Consider each field of the UUID to be an unsigned integer as shown in the table in section Section 4.1.2. Then, to compare a pair of UUIDs, arithmetically compare the corresponding fields from eachUUID in order of significance and according to their data type.Two UUIDs are equal if and only if all the corresponding fieldsare equal.As an implementation note, equality comparison can be performed on many systems by doing the appropriate byte-order canonicalization, and then treating the two UUIDs as 128-bit unsigned integers.UUIDs, as defined in this document, can also be orderedlexicographically. For a pair of UUIDs, the first one follows the second if the most significant field in which the UUIDs differ is greater for the first UUID. The second precedes the first if the most significant field in which the UUIDs differ is greater forthe second UUID.Conformance with URN Syntax:The string representation of a UUID is fully compatible with theURN syntax. When converting from a bit-oriented, in-memoryrepresentation of a UUID into a URN, care must be taken tostrictly adhere to the byte order issues mentioned in the stringrepresentation section.Validation mechanism:Apart from determining whether the timestamp portion of the UUIDis in the future and therefore not yet assignable, there is nomechanism for determining whether a UUID is ’valid’.Scope:UUIDs are global in scope.4. Specification4.1. FormatThe UUID format is 16 octets; some bits of the eight octet variantfield specified below determine finer structure.Leach, et al. Standards Track [Page 5]4.1.1. VariantThe variant field determines the layout of the UUID. That is, theinterpretation of all other bits in the UUID depends on the settingof the bits in the variant field. As such, it could more accurately be called a type field; we retain the original term forcompatibility. The variant field consists of a variable number ofthe most significant bits of octet 8 of the UUID.The following table lists the contents of the variant field, wherethe letter "x" indicates a "don’t-care" value.Msb0 Msb1 Msb2 Description0 x x Reserved, NCS backward compatibility.1 0 x The variant specified in this document.1 1 0 Reserved, Microsoft Corporation backwardcompatibility1 1 1 Reserved for future definition.Interoperability, in any form, with variants other than the onedefined here is not guaranteed, and is not likely to be an issue inpractice.4.1.2. Layout and Byte OrderTo minimize confusion about bit assignments within octets, the UUIDrecord definition is defined only in terms of fields that areintegral numbers of octets. The fields are presented with the mostsignificant one first.Field Data Type Octet Note#time_low unsigned 32 0-3 The low field of thebit integer timestamptime_mid unsigned 16 4-5 The middle field of thebit integer timestamptime_hi_and_version unsigned 16 6-7 The high field of thebit integer timestamp multiplexedwith the version number Leach, et al. Standards Track [Page 6]clock_seq_hi_and_rese unsigned 8 8 The high field of therved bit integer clock sequencemultiplexed with thevariantclock_seq_low unsigned 8 9 The low field of thebit integer clock sequencenode unsigned 48 10-15 The spatially uniquebit integer node identifierIn the absence of explicit application or presentation protocolspecification to the contrary, a UUID is encoded as a 128-bit object, as follows:The fields are encoded as 16 octets, with the sizes and order of the fields defined above, and with each field encoded with the MostSignificant Byte first (known as network byte order). Note that the field names, particularly for multiplexed fields, follow historicalpractice.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| time_low |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| time_mid | time_hi_and_version |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|clk_seq_hi_res | clk_seq_low | node (0-1) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| node (2-5) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.1.3. VersionThe version number is in the most significant 4 bits of the timestamp (bits 4 through 7 of the time_hi_and_version field).The following table lists the currently-defined versions for thisUUID variant.Msb0 Msb1 Msb2 Msb3 Version Description0 0 0 1 1 The time-based versionspecified in this document.0 0 1 0 2 DCE Security version, withembedded POSIX UIDs.Leach, et al. Standards Track [Page 7]0 0 1 1 3 The name-based versionspecified in this documentthat uses MD5 hashing.0 1 0 0 4 The randomly or pseudo-randomly generated versionspecified in this document.0 1 0 1 5 The name-based versionspecified in this documentthat uses SHA-1 hashing.The version is more accurately a sub-type; again, we retain the term for compatibility.4.1.4. TimestampThe timestamp is a 60-bit value. For UUID version 1, this isrepresented by Coordinated Universal Time (UTC) as a count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian reform to the Christian calendar).For systems that do not have UTC available, but do have the localtime, they may use that instead of UTC, as long as they do soconsistently throughout the system. However, this is not recommended since generating the UTC from local time only needs a time zoneoffset.For UUID version 3 or 5, the timestamp is a 60-bit value constructed from a name as described in Section 4.3.For UUID version 4, the timestamp is a randomly or pseudo-randomlygenerated 60-bit value, as described in Section 4.4.4.1.5. Clock SequenceFor UUID version 1, the clock sequence is used to help avoidduplicates that could arise when the clock is set backwards in timeor if the node ID changes.If the clock is set backwards, or might have been set backwards(e.g., while the system was powered off), and the UUID generator can not be sure that no UUIDs were generated with timestamps larger than the value to which the clock was set, then the clock sequence has to be changed. If the previous value of the clock sequence is known, it can just be incremented; otherwise it should be set to a random orhigh-quality pseudo-random value.Leach, et al. Standards Track [Page 8]Similarly, if the node ID changes (e.g., because a network card hasbeen moved between machines), setting the clock sequence to a random number minimizes the probability of a duplicate due to slightdifferences in the clock settings of the machines. If the value ofclock sequence associated with the changed node ID were known, thenthe clock sequence could just be incremented, but that is unlikely.The clock sequence MUST be originally (i.e., once in the lifetime of a system) initialized to a random number to minimize the correlation across systems. This provides maximum protection against nodeidentifiers that may move or switch from system to system rapidly.The initial value MUST NOT be correlated to the node identifier.For UUID version 3 or 5, the clock sequence is a 14-bit valueconstructed from a name as described in Section 4.3.For UUID version 4, clock sequence is a randomly or pseudo-randomlygenerated 14-bit value as described in Section 4.4.4.1.6. NodeFor UUID version 1, the node field consists of an IEEE 802 MACaddress, usually the host address. For systems with multiple IEEE802 addresses, any available one can be used. The lowest addressedoctet (octet number 10) contains the global/local bit and theunicast/multicast bit, and is the first octet of the addresstransmitted on an 802.3 LAN.For systems with no IEEE address, a randomly or pseudo-randomlygenerated value may be used; see Section 4.5. The multicast bit must be set in such addresses, in order that they will never conflict with addresses obtained from network cards.For UUID version 3 or 5, the node field is a 48-bit value constructed from a name as described in Section 4.3.For UUID version 4, the node field is a randomly or pseudo-randomlygenerated 48-bit value as described in Section 4.4.4.1.7. Nil UUIDThe nil UUID is special form of UUID that is specified to have all128 bits set to zero.4.2. Algorithms for Creating a Time-Based UUIDVarious aspects of the algorithm for creating a version 1 UUID arediscussed in the following sections.Leach, et al. Standards Track [Page 9]4.2.1. Basic AlgorithmThe following algorithm is simple, correct, and inefficient:o Obtain a system-wide global locko From a system-wide shared stable store (e.g., a file), read theUUID generator state: the values of the timestamp, clock sequence, and node ID used to generate the last UUID.o Get the current time as a 60-bit count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582.o Get the current node ID.o If the state was unavailable (e.g., non-existent or corrupted), or the saved node ID is different than the current node ID, generate a random clock sequence value.o If the state was available, but the saved timestamp is later than the current timestamp, increment the clock sequence value.o Save the state (current timestamp, clock sequence, and node ID)back to the stable store.o Release the global lock.o Format a UUID from the current timestamp, clock sequence, and node ID values according to the steps in Section 4.2.2.If UUIDs do not need to be frequently generated, the above algorithm may be perfectly adequate. For higher performance requirements,however, issues with the basic algorithm include:o Reading the state from stable storage each time is inefficient.o The resolution of the system clock may not be 100-nanoseconds.o Writing the state to stable storage each time is inefficient.o Sharing the state across process boundaries may be inefficient.Each of these issues can be addressed in a modular fashion by localimprovements in the functions that read and write the state and read the clock. We address each of them in turn in the followingsections.Leach, et al. Standards Track [Page 10]4.2.1.1. Reading Stable StorageThe state only needs to be read from stable storage once at boottime, if it is read into a system-wide shared volatile store (andupdated whenever the stable store is updated).If an implementation does not have any stable store available, thenit can always say that the values were unavailable. This is theleast desirable implementation because it will increase the frequency of creation of new clock sequence numbers, which increases theprobability of duplicates.If the node ID can never change (e.g., the net card is inseparablefrom the system), or if any change also reinitializes the clocksequence to a random value, then instead of keeping it in stablestore, the current node ID may be returned.4.2.1.2. System Clock ResolutionThe timestamp is generated from the system time, whose resolution may be less than the resolution of the UUID timestamp.If UUIDs do not need to be frequently generated, the timestamp cansimply be the system time multiplied by the number of 100-nanosecond intervals per system time interval.If a system overruns the generator by requesting too many UUIDswithin a single system time interval, the UUID service MUST eitherreturn an error, or stall the UUID generator until the system clockcatches up.A high resolution timestamp can be simulated by keeping a count ofthe number of UUIDs that have been generated with the same value ofthe system time, and using it to construct the low order bits of the timestamp. The count will range between zero and the number of100-nanosecond intervals per system time interval.Note: If the processors overrun the UUID generation frequently,additional node identifiers can be allocated to the system, whichwill permit higher speed allocation by making multiple UUIDspotentially available for each time stamp value.4.2.1.3. Writing Stable StorageThe state does not always need to be written to stable store everytime a UUID is generated. The timestamp in the stable store can beperiodically set to a value larger than any yet used in a UUID. Aslong as the generated UUIDs have timestamps less than that value, and Leach, et al. Standards Track [Page 11]the clock sequence and node ID remain unchanged, only the sharedvolatile copy of the state needs to be updated. Furthermore, if the timestamp value in stable store is in the future by less than thetypical time it takes the system to reboot, a crash will not cause a reinitialization of the clock sequence.4.2.1.4. Sharing State Across ProcessesIf it is too expensive to access shared state each time a UUID isgenerated, then the system-wide generator can be implemented toallocate a block of time stamps each time it is called; a per-process generator can allocate from that block until it is exhausted.4.2.2. Generation DetailsVersion 1 UUIDs are generated according to the following algorithm:o Determine the values for the UTC-based timestamp and clocksequence to be used in the UUID, as described in Section 4.2.1.o For the purposes of this algorithm, consider the timestamp to be a 60-bit unsigned integer and the clock sequence to be a 14-bitunsigned integer. Sequentially number the bits in a field,starting with zero for the least significant bit.o Set the time_low field equal to the least significant 32 bits(bits zero through 31) of the timestamp in the same order ofsignificance.o Set the time_mid field equal to bits 32 through 47 from thetimestamp in the same order of significance.o Set the 12 least significant bits (bits zero through 11) of thetime_hi_and_version field equal to bits 48 through 59 from thetimestamp in the same order of significance.o Set the four most significant bits (bits 12 through 15) of thetime_hi_and_version field to the 4-bit version numbercorresponding to the UUID version being created, as shown in thetable above.o Set the clock_seq_low field to the eight least significant bits(bits zero through 7) of the clock sequence in the same order ofsignificance.Leach, et al. Standards Track [Page 12]o Set the 6 least significant bits (bits zero through 5) of theclock_seq_hi_and_reserved field to the 6 most significant bits(bits 8 through 13) of the clock sequence in the same order ofsignificance.o Set the two most significant bits (bits 6 and 7) of theclock_seq_hi_and_reserved to zero and one, respectively.o Set the node field to the 48-bit IEEE address in the same order of significance as the address.4.3. Algorithm for Creating a Name-Based UUIDThe version 3 or 5 UUID is meant for generating UUIDs from "names"that are drawn from, and unique within, some "name space". Theconcept of name and name space should be broadly construed, and notlimited to textual names. For example, some name spaces are thedomain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished Names (DNs), and reserved words in a programming language. Themechanisms or conventions used for allocating names and ensuringtheir uniqueness within their name spaces are beyond the scope ofthis specification.The requirements for these types of UUIDs are as follows:o The UUIDs generated at different times from the same name in thesame namespace MUST be equal.o The UUIDs generated from two different names in the same namespace should be different (with very high probability).o The UUIDs generated from the same name in two different namespaces should be different with (very high probability).o If two UUIDs that were generated from names are equal, then theywere generated from the same name in the same namespace (with very high probability).The algorithm for generating a UUID from a name and a name space are as follows:o Allocate a UUID to use as a "name space ID" for all UUIDsgenerated from names in that name space; see Appendix C for somepre-defined values.o Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; Ifbackward compatibility is not an issue, SHA-1 is preferred.Leach, et al. Standards Track [Page 13]o Convert the name to a canonical sequence of octets (as defined by the standards or conventions of its name space); put the namespace ID in network byte order.o Compute the hash of the name space ID concatenated with the name. o Set octets zero through 3 of the time_low field to octets zerothrough 3 of the hash.o Set octets zero and one of the time_mid field to octets 4 and 5 of the hash.o Set octets zero and one of the time_hi_and_version field to octets 6 and 7 of the hash.o Set the four most significant bits (bits 12 through 15) of thetime_hi_and_version field to the appropriate 4-bit version number from Section 4.1.3.o Set the clock_seq_hi_and_reserved field to octet 8 of the hash.o Set the two most significant bits (bits 6 and 7) of theclock_seq_hi_and_reserved to zero and one, respectively.o Set the clock_seq_low field to octet 9 of the hash.o Set octets zero through five of the node field to octets 10through 15 of the hash.o Convert the resulting UUID to local byte order.4.4. Algorithms for Creating a UUID from Truly Random orPseudo-Random NumbersThe version 4 UUID is meant for generating UUIDs from truly-random or pseudo-random numbers.The algorithm is as follows:o Set the two most significant bits (bits 6 and 7) of theclock_seq_hi_and_reserved to zero and one, respectively.o Set the four most significant bits (bits 12 through 15) of thetime_hi_and_version field to the 4-bit version number fromSection 4.1.3.o Set all the other bits to randomly (or pseudo-randomly) chosenvalues.Leach, et al. Standards Track [Page 14]See Section 4.5 for a discussion on random numbers.4.5. Node IDs that Do Not Identify the HostThis section describes how to generate a version 1 UUID if an IEEE802 address is not available, or its use is not desired.One approach is to contact the IEEE and get a separate block ofaddresses. At the time of writing, the application could be found at </regauth/oui/pilot-ind.html>, and the cost was US$550.A better solution is to obtain a 47-bit cryptographic quality random number and use it as the low 47 bits of the node ID, with the leastsignificant bit of the first octet of the node ID set to one. Thisbit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards. Hence, there can never be aconflict between UUIDs generated by machines with and without network cards. (Recall that the IEEE 802 spec talks about transmissionorder, which is the opposite of the in-memory representation that is discussed in this document.)For compatibility with earlier specifications, note that thisdocument uses the unicast/multicast bit, instead of the arguably more correct local/global bit.Advice on generating cryptographic-quality random numbers can befound in RFC1750 [5].In addition, items such as the computer’s name and the name of theoperating system, while not strictly speaking random, will helpdifferentiate the results from those obtained by other systems.The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. A generic approach, however, is to accumulate as many sources as possible into a buffer, use amessage digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6bytes from the hash value, and set the multicast bit as describedabove.5. Community ConsiderationsThe use of UUIDs is extremely pervasive in computing. They comprise the core identifier infrastructure for many operating systems(Microsoft Windows) and applications (the Mozilla browser) and inmany cases, become exposed to the Web in many non-standard ways. Leach, et al. Standards Track [Page 15]。
httpstaus汇总
httpstaus汇总常见HTTP状态码1.2.3.4.5.6.7.8.9.10.11.12.100 Continue初始的请求已经接受，客户应当继续发送请求的其余部分101 Switching Protocols服务器将遵从客户的请求转换到另外⼀种协议200 OK⼀切正常，对GET和POST请求的应答⽂档跟在后⾯201 Created服务器已经创建了⽂档，Location头给出了它的URL。
202 Accepted已经接受请求，但处理尚未完成。
203 Non-Authoritative Information⽂档已经正常地返回，但⼀些应答头可能不正确，因为使⽤的是⽂档的拷贝204 No Content没有新⽂档，浏览器应该继续显⽰原来的⽂档。
如果⽤户定期地刷新页⾯，⽽Servlet可以确定⽤户⽂档⾜够新，这个状态代码是很有⽤的205 Reset Content没有新的内容，但浏览器应该重置它所显⽰的内容。
⽤来强制浏览器清除表单输⼊内容206 Partial Content客户发送了⼀个带有Range头的GET请求，服务器完成了它300 Multiple Choices客户请求的⽂档可以在多个位置找到，这些位置已经在返回的⽂档内列出。
如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently客户请求的⽂档在其他地⽅，新的URL在Location头中给出，浏览器应该⾃动地访问新的URL。
302 Found类似于301，但新的URL应该被视为临时性的替代，⽽不是永久性的。
303 See Other类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向⽬标⽂档应该通过GET提取304 Not Modified客户端有缓冲的⽂档并发出了⼀个条件性的请求（⼀般是提供If-Modified-Since头表⽰客户只想⽐指定⽇期更新的⽂档）。
URI的基本格式以及与URL的区别
URI的基本格式以及与URL的区别当没有URI时：站长欲分享⼀部电影给Forrest Gump给B时，需要告诉：请使⽤FTP协议访问,端⼝是8502登陆⽤户名是user，密码是pass进⼊到/shared/movie/⽬录下转换为⼆进制格式下载名字为Forrest Gump.mkv格式的⽂件有了URI：ftp://user:pass@:8502/shared/movie/Forrest Gump.mkv（我们管这种⽅式也可以叫URL）URL：RFC1738(1994.12),Uniform Resource Locator ,表⽰资源的位置，期望找到提供查找资源的⽅法。
URN: RFC2141(1997.5),Uniform Resource Name ,期望为资源提供持久的的，与位置⽆关的的表⽰⽅式，并允许简单的将多个命名空间映射到单个URN命名空间。
例如磁⼒链接：magnet:?xt=urn:sha1:YNCKHTQC5CURI:RFC1630(1994.6)、RFC3986(2005.1,取代RFC2396和RFC2732),Uniform Resource Identifier,⽤以区分资源，是URL和URN的超集，⽤以取代URL和URN概念Uniform Resource Identifier 统⼀资源标识符Resource资源可以是图⽚、⽂档、今天上海的天⽓温度，也可以是不能通过互联⽹访问的实体⼀个资源可以有多个URIIdentifier 标识符将当前资源与其他资源区分开的名称Uniform 统⼀允许不同种类的资源在同⼀上下⽂中出现对不同种类资源标识符可以使⽤同⼀语义进⾏解读引⼊新标识符时，不会对已有标识符产⽣影响允许同⼀资源标识符在不同的、Internet规模下的上下⽂中出现合法的URI：ftp://ftp.is.co.za/rfc/rfc1808.txt/rfc/rfc2396.txtldap://[2001:db8::7]/c=GB?objectClass?onemailto:John.Doe@news:systems.www.servers.unixtelnet://192.0.2.16:80/urn:oasis:names:specification:docbook:dtd:xml:4.1.2URI格式URI = scheme ":" hire-part ["?" query] [ "#" fragment ]scheme = ALPHA * (ALPHA / DIGIT / "+" / "-" / "." )例如 http,https,ftp,mailto,rtsp,file,telnetquery = *( pchar / "/" / "?" )fragment = * ( pchar / "/" / "?" ) ⽰例： https:///html/rfc/7231?test=1#page-7hire-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty authority = [ userinfo "@" ] host [ ":" port]userinfo = *( unreserved / pct-encoded / sub-delims / ":" )host = IP-literal / IPv4adress / reg-nameport = *DIGIT实例：https://tom:pass@localhost:8080/index.html path = path-abempty / path-absolute / path-noscheme / path-rootless / path-empty path-abempty = *( "/" segment) 以/开头的路径或者空路径path-absolute = "/" [ segment-nz *( "/" segment )] 以/开头的路径，但是不能以//开头path-noscheme = segment-nz-nc *( "/" segment )以⾮：开头的路径path-rootless = segment-nz *( "/" segment )相对path-noscheme,增加允许以：开头的路径path-empty = 0 < pchar > 空路径向正向代理发出的请求中，传递的绝对URI。
rfc相关设置及使用
rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。
RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。
在本文中，我们将介绍RFC相关的设置和使用。
1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。
RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。
RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。
2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。
这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。
通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。
阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。
3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。
它们提供了协议规范、算法实现、安全性和隐私等方面的建议。
网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。
此外，RFC文档还常用于进行互联网协议的实现、编程和配置。
4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。
任何人都可以参与到RFC的制定过程中。
要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。
通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。
5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。
这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。
遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。
总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。
开源项目rfc流程
开源项目rfc流程开源项目RFC流程1. 什么是RFC？•RFC是”Request for Comments”的缩写，意为”征求意见”或”意见征集”。
•在开源项目中，RFC是一种协作流程，用于提出新的功能或更改现有功能的建议，并征求项目群体的意见。
2. RFC的目的与重要性•RFC流程为开源项目提供了一个包容性的环境，让所有人都有机会参与决策过程。
•通过RFC流程，项目团队可以更好地理解社区成员的需求，减少冲突和误解，并确保变更是基于共识和讨论的结果。
3. RFC流程的具体步骤•提出RFC：在项目的RFC存储库中创建一个新的RFC文件，并使用Markdown格式编写提案。
•反馈与讨论：项目群体和有兴趣的社区成员将参与讨论，提出问题、建议和其他反馈。
•修改与改进：根据收到的反馈，作者可以对RFC进行修改和改进，以更好地满足需求和解决问题。
•状态更新：在RFC的生命周期中，通过更新RFC文件的状态，作者可以向社区反馈进展情况。
•最终评审：项目核心团队将对RFC进行最终评审，并确认是否接受或拒绝提案。
•实施与跟踪：一旦RFC被接受并实施，作者需要跟踪变更的进展，并确保及时更新相关文档。
4. RFC文章的Markdown格式要求•使用Markdown格式可以更好地展示RFC的内容和结构。
•下面提供一些常用的Markdown格式要求：–标题：使用井号（#）表示不同级别的标题，以突出重点和组织结构。
–列表：使用横杠（-）或星号（*）创建无序列表，使用数字创建有序列表。
–引用：使用大于号（>）创建引用段落，用于引用他人意见或讨论。
–代码块：使用反引号（`）创建代码块，用于展示代码示例或命令。
–链接：使用方括号（[]）和圆括号（()）创建链接，以便在RFC中引用其他文件或资源。
5. 一些建议与注意事项•清晰明了地描述问题或需求，以便社区成员更好地理解和提供反馈。
•避免使用复杂的排版和格式，以保持RFC的易读性。
使用jenkins进行前端项目自动部署
使⽤jenkins进⾏前端项⽬⾃动部署前⾯的话 后端的nodeJS项⽬可以使⽤pm2进⾏⾃动部署，由于前端项⽬打包后是静态资源，不需要进程守护。
⼀般地，前端项⽬使⽤jenkins来进⾏⾃动部署，包括打包、测试等⼀系列流程。
本⽂将详细介绍jenkins的使⽤安装 Jenkins 是⼀款业界流⾏的开源持续集成⼯具，⼴泛⽤于项⽬开发，具有⾃动化构建、测试和部署等功能。
由于 jenkins是基于java环境运⾏的，所以⾸先需要安装java环境 1、安装依赖包，使得add-apt-repository命令可以进⾏apt-get install software-properties-common 2、通过add-apt-repository加载第三⽅的开源软件源sudo add-apt-repository ppa:webupd8team/java 3、更新软件包列表，并安装jdksudo apt-get updatesudo apt-get install oracle-java8-installer 安装器会提⽰同意 oracle 的服务条款，选择 ok，然后选择yes 即可 4、通过查看java版本，来测试java环境是否安装成功xiaohuochai@iZbp13p7zpoi6363d01pugZ:~$ java -versionjava version "1.8.0_171"Java(TM) SE Runtime Environment (build 1.8.0_171-b11)Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode) 5、接下来，按照官⽹的操作要求，安装jenkinswget -q -O - https://pkg.jenkins.io/debian/.key | sudo apt-key add -sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'sudo apt-get updatesudo apt-get install jenkins 6、安装完成后，jenkins的⽂件⽬录如下所⽰安装⽬录：/var/lib/jenkins⽇志⽬录：/var/log/jenkins/jenkins.log 7、接下来，就可以启动jenkins了service jenkins start 在jenkins启动过程中，可能会遇到如下问题Job for jenkins.service failed 这是因为java环境，没有安装成功，按照上⾯的步骤重新安装java即可 还可能会出现如下警告.UnknownHostException: yonghu: yonghu: 未知的名称或服务 直接修改hosts⽂件(vi /etc/hosts)，将原127.0.0.1替换成127.0.0.1 localhost centos-a即可127.0.0.1 localhost yonghu 因为jenkins默认使⽤8080端⼝，如果使⽤阿⾥云，还需要在安全组中开放8080端⼝初始化 启动jenkins服务后，可以在8080端⼝访问到jenkins 然后在服务器的指定⽬录找到密码登录/var/lib/jenkins/secrets/initialAdminPassword 按照默认配置安装插件 等待插件安装完成 创建⼀个管理员账户，完成配置后，就可以登录 Jenkins 了安装插件 下⾯来安装nodejs插件 可以看到，Jenkins提供了丰富的插件供开发者使⽤，找到需要的[NodeJS Plugin]，勾选后点击安装即可 3、安装完毕后，选择系统管理->全局⼯具配置，配置node下载及安装git钩⼦ 为了能够与 GitHub 配合，需要进⼊对 GitHub 进⾏⼀些设置 在github中进⼊博客所在的repo，并点击settings。
http状态码大全（404、505、502，500）
http状态码⼤全（404、505、502，500）HTTP 400 – 请求⽆效HTTP 401.1 – 未授权：登录失败HTTP 401.2 – 未授权：服务器配置问题导致登录失败HTTP 401.3 – ACL 禁⽌访问资源HTTP 401.4 – 未授权：授权被筛选器拒绝HTTP 401.5 – 未授权：ISAPI 或 CGI 授权失败HTTP 403 – 禁⽌访问HTTP 403 – 对 Internet 服务管理器的访问仅限于 LocalhostHTTP 403.1 禁⽌访问：禁⽌可执⾏访问HTTP 403.2 – 禁⽌访问：禁⽌读访问HTTP 403.3 – 禁⽌访问：禁⽌写访问HTTP 403.4 – 禁⽌访问：要求 SSLHTTP 403.5 – 禁⽌访问：要求 SSL 128HTTP 403.6 – 禁⽌访问：IP 地址被拒绝HTTP 403.7 – 禁⽌访问：要求客户证书HTTP 403.8 – 禁⽌访问：禁⽌站点访问HTTP 403.9 – 禁⽌访问：连接的⽤户过多HTTP 403.10 – 禁⽌访问：配置⽆效HTTP 403.11 – 禁⽌访问：密码更改HTTP 403.12 – 禁⽌访问：映射器拒绝访问HTTP 403.13 – 禁⽌访问：客户证书已被吊销HTTP 403.15 – 禁⽌访问：客户访问许可过多HTTP 403.16 – 禁⽌访问：客户证书不可信或者⽆效HTTP 403.17 – 禁⽌访问：客户证书已经到期或者尚未⽣效 HTTP 404.1 -⽆法找到 Web 站点HTTP 404- ⽆法找到⽂件HTTP 405 – 资源被禁⽌HTTP 406 – ⽆法接受HTTP 407 – 要求代理⾝份验证HTTP 410 – 永远不可⽤HTTP 412 – 先决条件失败HTTP 414 – 请求 – URI 太长HTTP 500 – 内部服务器错误HTTP 500.100 – 内部服务器错误 – ASP 错误HTTP 500-11 服务器关闭HTTP 500-12 应⽤程序重新启动HTTP 500-13 – 服务器太忙HTTP 500-14 – 应⽤程序⽆效HTTP 500-15 – 不允许请求 global.asaError 501 – 未实现HTTP 502 – ⽹关错误⽤户试图通过 HTTP 或⽂件传输协议 (FTP) 访问⼀台正在运⾏ Internet 信息服务 (IIS) 的服务器上的内容时，IIS 返回⼀个表⽰该请求的状态的数字代码。
url的组成格式为
url的组成格式为：“URL的一般语法格式为：(带方括号[]的为可选项)protocol://hostname[:port]/path/[;parameters][?query]#fra gment。
”统一资源定位系统：统一资源定位系统（uniform resource locator;URL）是因特网的万维网服务程序上用于指定信息位置的表示方法。
它最初是由蒂姆·伯纳斯·李发明用来作为万维网的地址。
现在它已经被万维网联盟编制为互联网标准RFC1738。
因特网上的可用资源可以用简单字符串来表示，该文档就是描述了这种字符串的语法和语义。
而这些字符串则被称为：“统一资源定位器”（URL）。
这篇说明源于万维网全球信息主动组织（World Wide Web global informationinitiative）介绍的概念。
RFC1630《通用资源标志符》描述了一些对象数据，他们自1990年起就开始使用这些对象数据。
这篇URL说明符合《因特网资源定位符的功能需求（Functional Requirements for Internet Resource Locators）》中说明的需求。
这篇文档是由工程任务组织（IETF）的URI工作小组写的。
Url的语法：正如访问资源的方法有很多种一样，对资源进行定位的方案也有好几种。
URL的一般语法只是为使用协议来建立新方案提供了一个框架，当然除了已经在这篇文档中定义过的。
URL通过提供资源位置的一种抽象标志符来对资源进行定位。
系统定位了一个资源后，可能会对它进行各种各样的操作，这些操作可以抽象为下面的几个词：访问，更新，替换，发现属性。
一般来说，只有访问方法这一项在任何URL 方案中都需要进行描述。
主要部分第五部分给出了URL语法的完整BNF描述。
URL通常被写成如下形式：<方案>:<方案描述部分>一个URL包含了它使用的方案名称（<方案>）,其后紧跟一个冒号，然后是一个字符串（<方案描述部分>），这部分的解释由所使用的方案来决定。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group M. Steidl Request for Comments: 3937 IPTC Category: Informational October 2004 A Uniform Resource Name (URN) Namespace forthe International Press Telecommunications Council (IPTC)Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004).AbstractThis document describes a URN (Uniform Resource Name) namespace foridentifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSLstylesheets, other XML based document and documents of other dataformats like PDF documents, Microsoft Office documents and others. Steidl Informational [Page 1]Table of Contents1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 22. IANA URN Specification Template . . . . . . . . . . . . . . . 3 2.1. Namespace ID. . . . . . . . . . . . . . . . . . . . . . 3 2.2. Registration Information. . . . . . . . . . . . . . . . 3 2.3. Declaration of syntactic structure. . . . . . . . . . . 3 2.4. Relevant ancillary documentation. . . . . . . . . . . . 5 2.5. Identifier uniqueness considerations. . . . . . . . . . 5 2.6. Identifier persistence considerations . . . . . . . . . 5 2.7. Process of identifier assignment. . . . . . . . . . . . 5 2.8. Process for identifier resolution . . . . . . . . . . . 5 2.9. Rules for Lexical Equivalence . . . . . . . . . . . . . 5 2.10. Conformance with URN Syntax . . . . . . . . . . . . . . 5 2.11. Validation mechanism. . . . . . . . . . . . . . . . . . 52.12. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 53. Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . 64. Namespace Considerations and Community Considerations . . . . 65. Security Considerations . . . . . . . . . . . . . . . . . . . 76. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77. References. . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References. . . . . . . . . . . . . . . . . . 7 7.2. Informative References. . . . . . . . . . . . . . . . . 7 Author’s Address. . . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 91. IntroductionThe International Press Telecommunications Council (IPTC) is a non-profit consortium of the world’s major news agencies and newsindustry vendors. It develops and maintains technical standards for the news business that are used by virtually every major newsorganization in the world. IPTC was established in 1965.Since the 1990’s IPTC’s standardization work is based on openstandards like first SGML, then the XML [W3CXML] family of standards, MIME, Unicode, and so on.As some of these standards require identification of resources IPTCwas looking for a technology for globally unique, persistent andlocation-independent identifiers and decided to implement URNs asdescribed in "URN Syntax" [RFC2141] for this reason.This namespace specification is for a formal namespace.Steidl Informational [Page 2]2. IANA URN Specification Template2.1. Namespace ID"iptc" requested.2.2. Registration InformationRegistration Version Number: 1Registration Date: 2003-11-11Declared registrant of the namespace:Registering organization:International Press Telecommunications Council IPTCRoyal Albert HouseSheet StreetWindsor, Berkshire SL4 1BEDesignated contact person:Michael SteidlManaging Directormdirector@2.3. Declaration of syntactic structureAll URNs assigned by IPTC will have a Namespace Specific String (NSS) of the following hierarchical structure:At the top of the hierarchy are three branches:- "std"- "std-draft"- "workdoc"The "std" branch hierarchy:The "std" branch URNs will be assigned to IPTC resourcesused for specifying and explaining any aspect of an IPTCstandard.The NSS in the "std" branch will have this general structure:urn:iptc:std:{std-name}:{std-version}:{res-group}{:res-name}?{:res-version}?Steidl Informational [Page 3]where"std-name" is a unique identifier for an IPTC standard."std-version" reflects the version of this standard. The value’current’ will be assigned to point at resources of thecurrent version of a standard."res-group": this field will take only three values:"spec" for all resources specifying a standard,"doc" for all resources used for additional documentation ofand to support the use of a standard."xmlns" for defining an XML namespace [W3CXMLNS]."res-name" is an identifier for a tangible resource; the nameshould describe the content or the use of the resource. Since not all resources are tangible this value is optional."res-version" reflects the version of this resource as long as it takes a physical format - like e.g., a file. Since not allresources are of a physical kind this value is optional.The "std-draft" branch hierarchy:The "std-draft" branch URNs will be assigned to IPTC resourcesused for specifying and explaining any aspect of an IPTC standard while being in draft status, that is at a time when the resourceis not formally approved by the IPTC Standards body.The NSS in the "std" branch will have this general structure:urn:iptc:std-draft:{std-name}:{std-version}:{res-group}{:res-name}?{:res-version}?The substructure of "urn:iptc:std-draft" is identical to that of"urn:iptc:std", find all explanations there.The "workdoc" branch hierarchy:The "workdoc" branch URNs will be assigned to IPTC resources notdirectly related to IPTC standards but to the work of IPTC.The NSS in the "doc" branch will have this general structure:urn:iptc:workdoc:{group-id}:{doc-id}:{doc-version}{:doc-descr}?where"group-id" is a unique identifier for working groups and workingareas of IPTC and constitutes a document group."doc-id" is a unique identifier for a document within a documentgroup.Steidl Informational [Page 4]"doc-version" reflects the version of this work document."doc-descr" is an optional concise description of the documentcontent.2.4. Relevant ancillary documentationNone2.5. Identifier uniqueness considerationsIdentifier uniqueness will be enforced by the Managing Director ofIPTC who will assign unique identifiers to all resources identifiedby a URN.2.6. Identifier persistence considerationsIPTC is committed to maintaining the accessibility and persistence of all resources that are identified by an IPTC URN.2.7. Process of identifier assignmentAssignment is limited to the owner of this namespace and itsauthorities.2.8. Process for identifier resolutionIPTC will develop an appropriate mechanism that maps all assignedURNs to Uniform Resource Locators (URL), specifically to enable webbased resolution of URNs.2.9. Rules for Lexical EquivalenceNo special considerations, the rules for lexical equivalence of RFC2141 apply.2.10. Conformance with URN SyntaxNo special considerations.2.11. Validation mechanismNone specified. IPTC will develop a mechanism for resolving URNs to URLs (see 2.8), this mechanism will also show whether a URN is valid.2.12. ScopeGlobal.Steidl Informational [Page 5]3. ExamplesThe following examples are representative for IPTC URNs, but may not refer to actual resources.urn:iptc:std:NewsML:1.1:spec:DTD:1DTD version 1 to specify the IPTC standard "NewsML", version 1.1urn:iptc:std-draft:NITF:3.5:spec:xml-schema:2Second draft XML Schema for the IPTC standard "NITF", version 3.5 urn:iptc:std:SportsML:1.0:xmlnsURN to identify an XML namespace for the IPTC standard "SportsML", version 1.0. No "res-name" and "res-version" since an XMLnamespace is of no physical format.urn:iptc:std:NewsML:1.1:doc:news-agency-guidelines:1.2Supporting document named "news-agency-guidelines", version 1,revision 2, based on the IPTC standard "NewsML" version 1.1.urn:iptc:workdoc:NMA:0315:1:srs-termsWork document of IPTC’s News Metadata Working Party (NMA), version 1, holding terms of the Subject Reference System4. Namespace Considerations and Community ConsiderationsThe IPTC acknowledged already the use of URNs during the development of its XML based standard "NewsML". This standard implements the use of URNs as unique identifiers for news items as described in "URNNamespace for NewsML resources" [RFC3085].While developing additional XML based standards as siblings toNewsML, IPTC soon got aware that URNs have to be assigned toresources that fall beyond the scope of the NewsML namespace. Forthis reason IPTC developed a new and very general hierarchicalnamespace structure to cover the needs of the currently developedstandards as well as future standards and to be able to assign URNsto resources emanating from them.In addition to resources relating directly to its standards, IPTCalso produces and publishes other documents relevant to the newsbusiness. As those resources are used by many organizations outside the IPTC membership and therefore could not be considered as internal documents IPTC decided to add a branch to the URN hierarchy to beassigned to these resources.Steidl Informational [Page 6]IPTC maintains global activities and its standards as well asresources based on them are used world wide. Since one focus of the activities of IPTC is on global exchange of news any system forunique identification of resources has to be considered under global aspects.For this reason IPTC considers the introduction of a URN namespacefor its resources as proper action to maintain globally unique,persistent and location-independent identifiers based on openstandards.5. Security ConsiderationsThere are no additional security considerations other than thosenormally associated with the use and resolution of URNs in general. 6. IANA ConsiderationsThis document includes a URN Namespace registration that conforms to the "Uniform Resources Names (URN) Namespace Definition Mechanism"[RFC3406] and has been entered into the IANA registry for URN NIDs. 7. References7.1. Normative References[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.[RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace DefinitionMechanisms", BCP 66, RFC 3406, October 2002.7.2. Informative References[W3CXML] W3C, XML WG, "Extensible Markup Language (XML) 1.0" (Third Edition), February 2004, </TR/REC-xml>.[W3CXMLNS] W3C, Namespaces WG, "Namespaces in XML", January 1999,</TR/REC-xml-names>.[RFC3085] Coates, A., Allen, D. and D. Rivers-Moore, "URN Namespace for NewsML Resources", RFC 3085, March 2001.Steidl Informational [Page 7]Author’s AddressMichael SteidlIPTC (International Press Telecommunications Council)Royal Albert HouseSheet StreetWindsor SL4 1BEUnited KingdomPhone: +44 (1753) 705 051EMail: mdirector@Steidl Informational [Page 8]Full Copyright StatementCopyright (C) The Internet Society (2004).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THEINFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain 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; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Steidl Informational [Page 9]。