📄 rfc2938.txt
字号:
Network Working Group G. Klyne
Request for Comments: 2938 Content Technologies
Updates: 2533 L. Masinter
Category: Standards Track AT&T
September 2000
Identifying Composite Media Features
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
In RFC 2533, an expression format is presented for describing media
feature capabilities as a combination of simple media feature tags.
This document describes an abbreviated format for a composite media
feature set, based upon a hash of the feature expression describing
that composite.
Table of Contents
1. Introduction ................................................2
1.1 Organization of this document ...............................2
1.2 Terminology and document conventions ........................2
2. Motivation and goals ........................................3
3. Composite feature representation ............................4
3.1 Feature set hashed reference format .........................5
3.1.1 Hash value calculation ......................................6
3.1.2 Base-32 value representation ................................7
3.2 Resolving feature set identifiers ...........................8
3.2.1 Query protocol ..............................................8
3.2.2 Inline feature set details ..................................9
4. Examples ...................................................10
5. Internationalization Considerations ........................12
6. Security Considerations ....................................13
7. Acknowledgements ...........................................13
8. References .................................................13
Klyne & Masinter Standards Track [Page 1]
RFC 2938 Identifying Composite Media Features September 2000
9. Authors' Addresses .........................................15
10. Appendix A: The birthday paradox ...........................16
11. Full Copyright Statement ...................................18
1. Introduction
In "A Syntax for Describing Media Feature Sets" [1], an expression
format is presented for describing media feature capabilities as a
combination of simple media feature tags [2].
This document proposes an abbreviated format for a composite media
feature set, based upon a hash of the feature expression describing
that composite.
This memo extends and builds upon the expression syntax described in
RFC 2533 [1], and it is assumed that the reader is familiar with the
interpretation of feature set expressions described there.
1.1 Organization of this document
Section 2 sets out some of the background and goals for feature set
references.
Section 3 presents a syntax for feature set references, and describes
how they are related to feature set expressions.
1.2 Terminology and document conventions
This section defines a number of terms and other document
conventions, which are used with specific meaning in this memo. The
terms are listed in alphabetical order.
dereference
the act of replacing a feature set reference with its
corresponding feature set expression. Also called
"resolution".
feature set
some set of media features described by a media feature
assertion, as described in "A Syntax for Describing Media
Feature Sets" [1]. (See that memo for a more formal
definition of this term.)
feature set expression
a string that describes some feature set, formulated
according to the rules in "A Syntax for Describing Media
feature sets" [1] (and possibly extended by other
specifications).
Klyne & Masinter Standards Track [Page 2]
RFC 2938 Identifying Composite Media Features September 2000
feature set reference
a brief construct that references some feature set. (See
also: "dereference".)
feature set tag
a name that conforms to the syntax of a feature tag [2] that
is used to denote a feature set rather than a single
feature.
resolution
(See "dereference").
This specification uses syntax notation and conventions described
in RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3].
NOTE: Comments like this provide additional nonessential
information about the rationale behind this document. Such
information is not needed for building a conformant
implementation, but may help those who wish to understand the
design in greater depth.
2. Motivation and goals
The range of media feature capabilities of a message handling system
can be quite extensive, and the corresponding feature set expression
[1] can reach a significant size.
A requirement has been identified to allow recurring feature sets to
be identified by a single reference value, which can be combined with
other elements in a feature set expression. It is anticipated that
mechanisms will be provided that allow the recipient of such a
feature set reference to discover the corresponding feature set
expression, but any such mechanism is beyond the scope of this
specification.
Thus, the goals for this proposal are:
o to provide an abbreviated form for referencing an arbitrary
feature set expression.
o the meaning of (i.e., the corresponding feature set expression) a
feature set reference should be independent of any particular
mechanism that may be used to dereference it.
o to be able to verify whether a given feature set expression
corresponds to some feature set reference without having to
perform an explicit dereferencing operation (i.e., without
incurring additional network traffic).
Klyne & Masinter Standards Track [Page 3]
RFC 2938 Identifying Composite Media Features September 2000
o for protocol processors that conform to RFC 2533 [1] to be able to
sensibly handle a feature set reference without explicit knowledge
of its meaning (i.e., the introduction of feature set references
should not break existing feature expression processors). That
is, the applicable interpretation and processing rules of RFC 2533
[1] apply equally to expressions containing feature set
references.
NOTE: This proposal does not attempt to address the "override"
or "default" problem. (Where a feature set may be referenced and
selectively modified.)
Some circumstances in which such an abbreviated form might be used
include:
o A media feature expression that contains a repeated sub-
expression. If the sub-expression is quite large, space can be
saved by writing it out once, then using the abbreviated form to
reference it.
o A capability that is common to a range of devices, such as a given
class of fax machine where are large number of feature tags are
involved, but only a small number of common feature sets. If the
recipient understands, or can discover, that some abbreviation
stands for a given feature set then feature expression size can be
reduced by using the abbreviation.
If feature set abbreviations are used in this way, it may be that
they can be interpreted by a simple table lookup rather than full
feature expression parsing. (Making this useful in practice will
depend on crafting the feature subsets appropriately.)
Examples of such usage are given in section 4 of this memo.
This memo does not specify how a program that receives a feature set
abbreviation should discover the corresponding feature set
expression: see section 3.2.
3. Composite feature representation
This specification hinges on two central ideas:
o the use of auxiliary predicates (introduced in RFC 2533 [1]) to
form the basis of a feature set identifier, and
o the use of a token based on a hash function computed over the
referenced feature set expression.
Klyne & Masinter Standards Track [Page 4]
RFC 2938 Identifying Composite Media Features September 2000
A key reason to use a hash function to generate an identifier is to
define a global name space without requiring a central naming
authority. New feature set tags can be introduced by any party
following the appropriate rules of formulation, without reference to
any centralized authority.
Local resolution services may be needed to map feature set tags to
their corresponding feature set expressions, but these are not able
to vary the meaning of any given tag. Failure of a resolution
service to return the correct expression is detectable by a calling
application, which should reject any incorrect value supplied.
NOTE: where a feature set reference is used, its meaning is
defined by substitution of the referenced feature expression into
the referencing expression. When all references have been thus
replaced, the result is interpreted as a normal feature
expression.
In particular, if a referenced feature expression contains some
feature tag that is also constrained by the referencing
expression, the constraints are interpreted per RFC 2533 [1],
without regard for their origin. E.g., (using some notation
introduced below):
(& (pix-x=100) (pix-y<=300)
(h.SBB5REAOMHC09CP2GM4V07PQP0) )
where (h.SBB5REAOMHC09CP2GM4V07PQP0) resolves to:
(& (pix-x<=200) (pix-y<=150) )
yields a result equivalent to:
(& (pix-x=100) (pix-y<=150) )
3.1 Feature set hashed reference format
This specification introduces a special form of auxiliary predicate
name with the following syntax:
fname = "h." 1*BASE32DIGIT
BASE32DIGIT = DIGIT
/ "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H"
/ "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P"
/ "Q" / "R" / "S" / "T" / "U" / "V"
The sequence of base-32 digits represents the value of a hash
function calculated over the corresponding feature set expression
(see following sections). Note that the above syntax allows upper-
or lower-case letters for base-32 digits (per RFC 2234 [3]).
Klyne & Masinter Standards Track [Page 5]
RFC 2938 Identifying Composite Media Features September 2000
Thus, within a feature set expression, a hashed feature set reference
would have the following form:
(h.123456789abcdefghijklmnopq)
3.1.1 Hash value calculation
The hash value is calculated using the MD5 algorithm [6] over the
text of the referenced feature set expression subjected to certain
normalizations. The feature expression must conform to the syntax
given for 'filter' in RFC 2533 [1]:
filter = "(" filtercomp ")" *( ";" parameter )
The steps for calculating a hash value are:
1. Whitespace normalization: all spaces, CR, LF, TAB and any other
layout control characters that may be embedded in the feature
expression string, other than those contained within quoted
strings, are removed (or ignored for the purpose of hash value
computation).
2. Case normalization: all lower case letters in the feature
expression, other than those contained within quoted strings, are
converted to upper case. That is, unquoted characters with US-
ASCII values 97 to 122 (decimal) are changed to corresponding
characters in the range 65 to 90.
3. Hash computation: the MD5 algorithm, described in RFC 1321 [6], is
applied to the normalized feature expression string (represented
as a sequence of octets containing US-ASCII character codes; see
also section 5).
The result obtained in step 3 is a 128-bit (16 octet) value that
is converted to a base-32 representation to form the feature set
reference.
NOTE: under some circumstances, removal of ALL whitespace may
result in an invalid feature expression string. This should not
be a problem as this is done only for the purpose of calculating
a hash value, and significantly different feature expressions are
expected to differ in ways other than their whitespace.
NOTE: case normalization is deemed appropriate since feature tag
and token matching is case insensitive.
Klyne & Masinter Standards Track [Page 6]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -