SMPTE ST 343M-2002 Television - Declarative Data Essence - Local Identifier (Lid ) URI Scheme.pdf

1、SMPTE 343M-2002 SMPTE STANDARD Table of contents Scope Normative references Introduction Definition of local identifier (lid:) URI scheme Resolution rules Normalization and equivalence Local identifier syntax BNF Security considerations Annex A Converting other URI schemes to lid: Annex B Bibliograp

2、hy 1 Scope This standard defines the lid: uniform resource iden- tifier (URI), and describes how it is used to identify instances of resources, such as web pages and graphics files, that are transmitted through unidirec- tional means, such as a television broadcast. 2 Normative references The follow

3、ing Standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the pos

4、sibility of applying the most recent edition of the standards indicated below. IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax ISOAEC 11578:1996, Information Technology - Open Systems Interconnection - Remote Procedure Call (RPC), Annex A, Universal Unique Identifier Page 1 of 4 pa

5、ges 3 Introduction Content resources delivered by a one-way broadcast must be identified, stored in a storage system used by the receiver as they are received, and referenced by a uniform scheme for access by applications and systems. Broadcast receivers may use different types of storage devices; t

6、herefore, content broadcasters and application developers need a standard syntax for resource storage and reference that does not depend on the specific device or directory syntax, such as the file: URI scheme. A lid: can be bound to a resource entity during authoring and distribution, and may be us

7、ed to name a device-independent storage location for the entity. The lid: scheme is syntactically similar to the http: scheme, but it is not intended to resoive lid: identifiers to locations outside the broadcast stream or local storage system, as is the case for http: DNS and resource resolution. T

8、he lid: URI scheme enables content creators to assign an author value that is globally unique. The lid: scheme supports relative paths for resource re- trieval, so the authority component can be separately identified in applications to allow relative path refer- ences similar to http: and other URI

9、references. A single lid: can be used to identify different resource instances over time, and will resolve in a receiver to the last instance received with an equivalent lid:. Appropriate lid: identifiers can reduce the storage of redundant instances of resources for better memory efficiency. Storag

10、e management for lid: entities is implementation specific and beyond the scope of this specification, but it can be assumed that memory will be finite, and so will the period of persistence of any lid: entity. Applications using lid: should be designed to handle the case where resources have been de

11、 leted over time due to storage limitations. CopyigM O 2o(n by ME SOCIEIY OF MOTION PICNFlE ANDTELEVISION ENGINEERS 595 W. I.brtSdaleAve., Whb Plains, NY 10607 (914)761-1100 Approved January 3,2002 SMPTE 343M-2002 4 Definition of local identifier (lid:) URI scheme The lid: URI scheme describes URI

12、references con- sisting of a sequence of characters which are inde- pendent of their coding in octets in any particular character set. The lid: URI fully complies with IETF RFC 2396 except for the overloading of the authority field in the deprecated form. The layout of the lid: URI follows the gener

13、ic URI syntax: Userinfo is an optional string that enables message ID syntax forms of the authoriifield and, in combina- tion with the host field, complies with the mid: scheme syntax defined in IETF RFC 2392. Host is a string whose root is a registered domain name or a uuid (ISO/IEC 11578) in strin

14、g form. Note that the uuid form is deprecated and is intended to support past common practice. Port is a string to allow syntactic compatibility with IETF RFC 2616 and has no semantic meaning. Path is a slash-separated string of components iden- tical to the http: scheme syntax as defined in IETF RF

15、C 261 6. Query and fragment are content-type dependent strings compliant with IETF RFC 2396. Relative path syntax, as described in section 3 of IETF RFC 2396 is also permitted syntactically, but must only be used in cases where there is a guaranteed mechanism to resolve the absolute path (Le., the B

16、ASE URI is well defined). Practical delivery consid- erations may require that lid: identified resources be delivered on broadcast channels using absolute paths to enable real-time storage in sequence of resource arrival, but relative path resolution must be supported for lid: resource retrieval, as

17、suming an application specifies the base of the URI by other means. The following are examples of lid:s: lidi/4F4182671 C1 FDD4BAO937A7EB7B8B4Cl O mail A deprecated form of usage is to permit host to be an encoded UUID (ISOAEC 11578). While technically the UUID name space overlaps the domain name s

18、pace, in practice a collision is entirely improbable. Examples of this deprecated form using UUID are: lid:/4F4182C71 C1 FDD4BA0937A7EB7B8B4CV images/logo.gif lidi/4F4182C7-1 C1 F-DD4B-A093-7A7EB7B8B4Cl/ images/logo.gif The UUID is represented as an ASCII hex coding resulting in 32 characters. Note

19、that two syntaxes are permitted - one with some specifically placed sepa- rating hyphens and one without (see the BNF defini- tion below). When different resources are received with matching lids, the most recently received resource should be referenced using that lid:. Thus a lid: may refer to diff

20、erent resources over time. One lid: URI can be assigned for all instances of a resource, or multiple unique URls can be assigned, one for each instance of the resource. 5 Resolution rules A lid: URI is used to label a resource. Certain parts of the URI are ignored for the purposes of comparison, whe

21、n the lid: is used for retrieval, or to replace a previously transmitted resource with an equivalent URI. When testing for equivalence, the query and fragment identifiers (.e., characters in the lid: includ- ing and following the first ? or # character) in a lid: URI are ignored. Notwithstanding, re

22、ferences using frag- ment and query identifiers may function in ways de- fined by the content type being referenced. When comparing two URls to decide i they match or not, a receiver should use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is emp

23、ty or not given is equivalent to the default port for http:, which is 80; - Comparisons of host names shall be case insen- sitive: - Comparisons of scheme names shall be case insenslive; - An empty absgadh is equivalent to an abspth of /. Page 2 of 4 pages SMPTE 343M-2002 Characters other than those

24、 in the reserved and un- safe sets (see IETF RFC 2396) are equivalent to their % HEX HEX encoding. For example, the following three URls are equivalent: lidY/:80/-smith/home. html lidY/ABC.com:/%7esmith/home. html Unlike http:, a lid: URI is not locatable without more information and is thus URN-lik

25、e in the generic defini- tion in that a URN is associated to a resource and independent of the resources location. Therefore, the details of resolution of the location of a lid: is applica- tion dependent. 6 Normalization and equivalence In many cases, different URI strings may actually identify the

26、 same resource. For example, the host names used in the URL are case insensitive, so the URL is equivalent to . In general, the rules for equiva- lence and definition of a normal form, if any, are scheme dependent. When a scheme uses elements of the common syntax, it will also use the common syntax

27、equivalence rules; namely, that the scheme and hostname are case insensitive and a URL with an explicit :port, where the port is the default for the scheme, is equivalent to one where the port is elided. 7 Local identifier syntax BNF The collected BNF for lid: URls is as follows: lid = “lid“ “:“ “Y

28、authority abs-pah I?“ query “#Y fragment authority = server I uuid server = as defined in RFC 2396 absgath = as defined in RFC 2396 query = as defined in RFC 2396 fragment = as defined in RFC 2396 uuid = uuid-simple I uuid-id1 uuid-simple = 32hex uuid-id1 = 8hex “-“ 4hex “-“ 4hex 4hex “-“ l2hex hex

29、 as defined in RFC 2396 NOTE - The notation en (element) means exactiy en occurrences of (element): e.g 32hex means exactiy 32 hex digits. Use of the uuid authority element is deprecated. 8 Security considerations The local identifier URI scheme is subject to the same secum implications as in gener

30、al URI schemes, so the usual precautions apply. This means that some local identifier URls may refer to resources that are not available (because they have not been received, for example), or to resources that have been received but were intentionally misidentified. The security is- sues associated

31、with this mislabeling, as weil as the secur issues associated with the use of HTML content which is broadcast, are the same as those identified in section 11.1 of IETF RFC 2387. Appropriate secur mechanisms should be used in the delivery of content identified by lid: URls. These include protection o

32、f the broadcast signal by data encryption and conditional access methods, and pro- tection of content prior to broadcast so that invalid lid:s are not created, and valid lid:s are not modified. Page 3 of 4 pages SMPTE 343M-2002 Annex A (informative) Converting other URI schemes to lid: URL reference

33、s using schemes such as http:, ftp:, and file: can be converted to valid lids by changing the scheme component and using the original name, host, path, frag- ment, and query components. This is useful, for instance, to deliver resources stored on Internet servers over a broad- cast channel. Note tha

34、t the original URL port and password fields have no semantic definition in lid:. Example: An Internet resident resource at the location http:/ Annex B (informative) Bibliography IETF RFC 2387, The MIME MultiparRelated Content-Type IETF RFC 2392, Content-ID and Message-ID Uniform Resource Locators IE

35、TF RFC 2616, Hypertext Transfer Protocol - HTTPI1.1 could be packaged in a broadcast stream with a header containing the resource identifier lid:/ and that resource identifier could be used to store the text.txt entity in memory with a denved directory entry, which would be matched by the following lid: reference in an HTML document href=lid:/ y Program IETF RFC 2717, Registration Procedures for URL Scheme Names IETF RFC 2718, Guidelines for New URL Schemes Page 4 of 4 pages