[6] [DFN[[CODE(URI)@en[[[opaquelocktoken:]]]]]] は、[[ロック]]を表す [[URL]] に使うことができる [[URL scheme]] です。 * 仕様書 [REFS[ - [5] '''[CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) ''' - [16] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) ]REFS] * 意味 [7] [CODE(URI)@en[[[opaquelocktoken:]]]] [[URL scheme]] は、 [[UUID]] から構文的に正しく生成しやすい [[URL]] を作り、 すべての[[資源]]にわたってすべての[[時間]]に関して固有である[[ロックトークン]]として使うために定義されたものです [SRC[>>5]]。 [8] [[RFC 2518]] で標準的な方法として規定されていましたが、 [[RFC 4918]] では [CODE(URI)@en[[[urn:uuid:]]]] が[RUBYB[推奨]@en[encourage]] [SRC[>>16]] されているようで、 [CODE(URI)@en[[[opaquelocktoken:]]]] は代替として定義されているに過ぎません。 * 構文 [9] [CODE(URI)@en[[[opaquelocktoken:]]]] [[URL]] は、 [[URL scheme]]、[[UUID]]、省略可能な[RUBYB[拡張]@en[extension]]により構成されます [SRC[>>5]]。 [FIG(railroad)[ = [CODE(URI)@en[[[opaquelocktoken:]]]] = [[UUID]] = ? == [[パス]] ]FIG] [10] [[UUID]] は、 [[RFC 4122]] 第3章の定義が参照されています [SRC[>>5]]。 [12] [[鯖]]は[[ロックトークン]]それぞれに新しい [[UUID]] を作ることができます [SRC[>>5]]。 [11] 拡張は、 [[RFC 3986]] [[パス]]です [SRC[>>5]]。 [13] [[鯖]]は [[UUID]] を再利用する場合には、拡張を追加しなければ[['''なりません''']]。 同じ拡張をもう一度使うことがないよう保証する方法を使わなければ[['''なりません''']]。 [SRC[>>5]] * 処理 [14] [[ロックトークン]]は[[不透明]]な文字列として処理されることになっていて、 [[クライアント]]その他の受信者が [CODE(URI)@en[[[opaquelocktoken:]]]] [[URL]] を構文解析して処理することは想定されていません。 [15] [[鯖]]は、自身が発行した[[ロックトークン]]を何らかの方法で解釈して[[ロック]]を識別するよう実装することもできますが、 だとしても特定の[[鯖]]の内部の実装に限られた話であり、その方法は規定されていませんし、 他の[[鯖]]で発行した[[ロックトークン]]をその方法で解釈できる保証はまったくありません。 * 歴史 [FIG(quote)[ [FIGCAPTION[ [4] RFC 2518 (WebDAV) 6.4 opaquelocktoken Lock Token URI Scheme ]FIGCAPTION] > The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it. [CODE(URI)[opaquelocktoken]] URI scheme は、全ての資源が全ての時刻に渡って固有であるように設計されています。 この固有性の品質のために、 クライアントは [CODE(HTTP)[If]] 頭中の不透明固定字句をそれが返された資源以外の資源に送信してもかまいません。 > All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource. 全ての資源は [CODE(URI)[opaquelocktoken]] scheme を認識し、少なくてもその固定字句がその資源についての未解決固定を参照していないことを認識しなければ'''なりません'''。 > In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578]. 全ての資源の全ての時刻についての固有性を保証するために、 [CODE(URI)[opaquelocktoken]] は ISO 11578 で説明されている普遍固有識別子 ([[UUID]]) の使用を必要とします。 > Opaquelocktoken generators, however, have a choice of how they create these tokens. They can either generate a new UUID for every lock token they create or they can create a single UUID and then add extension characters. If the second method is selected then the program generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID. しかし、 [CODE(URI)[opaquelocktoken]] の生成者はこれらの字句をどう生成するかを選択できます。 生成者はその生成する各固定字句毎に UUID を生成しても構いませんし、単一の UUID を生成して拡張文字を加えても構いません。 二番目の方法を選択するときは、 拡張を生成する応用は関連付けられた UUID に対して同じ拡張が二度と使われないことを保証しなければ'''なりません'''。 > - OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID, as defined in [ISO-11578]. Note that white space (LWS) is not allowed between elements of this production. - Extension = path ; path is defined in section 3.2.1 of RFC 2068 [RFC2068] * 6.4.1 Node Field Generation Without the IEEE 802 Address > UUIDs, as defined in [ISO-11578], contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in section 17.8, there are several security risks associated with exposing a machine's IEEE 802 address. This section provides an alternate mechanism for generating the "node" field of a UUID which does not employ an IEEE 802 address. WebDAV servers MAY use this algorithm for creating the node field when generating UUIDs. The text in this section is originally from an Internet-Draft by Paul Leach and Rich Salz, who are noted here to properly attribute their work. (要約) [[IEEE802]] address を使いたくないなら、この代案を使え。 > The ideal 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 most significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards. (要約) 乱数の最上位ビットを 1 にすれば 802 アドレスから生成した UUID と絶対衝突しない。 > If a system does not have a primitive to generate cryptographic quality random numbers, then in most systems there are usually a fairly large number of sources of randomness available from which one can be generated. Such sources are system specific, but often include: (要約) 乱数源の例: [PRE[ - the percent of memory in use - the size of main memory in bytes - the amount of free main memory in bytes - the size of the paging or swap file in bytes - free bytes of paging or swap file - the total size of user virtual address space in bytes - the total available user address space bytes - the size of boot disk drive in bytes - the free disk space on boot drive in bytes - the current time - the amount of time since the system booted - the individual sizes of files in various system directories - the creation, last read, and modification times of files in various system directories - the utilization factors of various system resources (heap, etc.) - current mouse cursor position - current caret position - current number of running processes, threads - handles or IDs of the desktop window and the active window - the value of stack pointer of the caller - the process and thread ID of caller - various processor architecture specific performance counters (instructions executed, cache misses, TLB misses) ]PRE] > (Note that it is precisely the above kinds of sources of randomness that are used to seed cryptographic quality random number generators on systems without special hardware for their construction.) > In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate 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. However, assuming that one can concatenate all the values from the randomness sources into a buffer, and that a cryptographic hash function such as MD5 is available, then any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the high bit of the first byte) set will be an appropriately random node ID. > Other hash functions, such as SHA-1, can also be used. The only requirement is that the result be suitably random _ in the sense that the outputs from a set uniformly distributed inputs are themselves uniformly distributed, and that a single bit change in the input can be expected to cause half of the output bits to change. ]FIG] * メモ - [1] 例: [SAMP(URI)[]] - [2] [SAMP(URI)[opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4]] - [3] [SAMP(URI)[opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77]]