分享
 
 
 

RFC2506 - Media Feature Tag Registration Procedure

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group K. Holtman

Request for Comments: 2506 TUE

BCP: 31 A. Mutz

Category: Best Current Practice Hewlett-Packard

T. Hardie

Equinix

March 1999

Media Feature Tag Registration Procedure

Status of this Memo

This document specifies an Internet Best Current Practices for the

Internet Community, and requests discussion and suggestions for

improvements. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

ABSTRACT

Recent Internet applications, sUCh as the World Wide Web, tie

together a great diversity in data formats, client and server

platforms, and communities. This has created a need for media

feature descriptions and negotiation mechanisms in order to identify

and reconcile the form of information to the capabilities and

preferences of the parties involved.

Extensible media feature identification and negotiation mechanisms

require a common vocabulary in order to positively identify media

features. A registration process and authority for media features is

defined with the intent of sharing this vocabulary between

communicating parties. In addition, a URI tree is defined to enable

sharing of media feature definitions without registration.

This document defines a registration procedure which uses the

Internet Assigned Numbers Authority (IANA) as a central registry for

the media feature vocabulary.

Please send comments to the CONNEG working group at <ietf-

medfree@imc.org>. Discussions of the working group are archived at

<URL: http://www.imc.org/ietf-medfree/>.

TABLE OF CONTENTS

1 Introduction ................................................. 2

2 Media feature tag definitions ................................ 3

2.1 Media feature tag purpose ................................. 3

2.2 Media feature tag syntax .................................. 4

2.3 Media feature tag values .................................. 4

2.4 ASN.1 identifiers for media feature tags ................. 5

3 Media feature tag registration ............................... 5

3.1 Registration trees ........................................ 6

3.1.1 IETF tree ............................................... 6

3.1.2 Global tree ............................................. 6

3.1.3 URL tree ................................................ 6

3.1.4 Additional registration trees ........................... 7

3.2 Location of registered media feature tag list ............. 7

3.3 IANA procedures for registering media feature tags ........ 7

3.4 Registration template ..................................... 7

4 Security Considerations ...................................... 10

5 Acknowledgments .............................................. 10

6 References ................................................... 10

7 Authors' Addresses ........................................... 11

8 Full Copyright Statement ..................................... 12

1 Introduction

Recent Internet applications, such as the World Wide Web, tie

together a great diversity in data formats, client and server

platforms, and communities. This has created a need for media

feature descriptions and negotiation mechanisms in order to identify

and reconcile the form of information to the capabilities and

preferences of the parties involved.

Extensible media feature identification and negotiation mechanisms

require a common vocabulary in order to positively identify media

features. A registration process and authority for media features is

defined with the intent of sharing this vocabulary between

communicating parties. In addition, a URI tree is defined to enable

sharing of media feature definitions without registration.

This document defines a registration procedure which uses the

Internet Assigned Numbers Authority (IANA) as a central registry for

the media feature vocabulary.

This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and

MAY according to usage described in [8].

2 Media feature tag definitions

2.1 Media feature tag purpose

Media feature tags represent individual and simple characteristics

related to media capabilities or properties associated with the

resource to which they are applied. Examples of such features are:

* the color depth of the screen on which something is to be displayed

* the type of paper available in a printer

* the support of the `floating 5 dimensional tables' feature

* the fonts which are available to the recipient

* the capability to display graphical content

Each media feature tag identifies a single characteristic. Values

associated with a specific tag must use the data type defined for

that tag. The list of allowed data types is presented below, in

section 2.3.

Examples of media feature tags with values are:

* the width of a display in pixels per centimeter represented as an

integer value.

* a font available to a recipient, selected from an enumerated list.

* the version of a protocol composed of integers "i.j.k", defined as

either a value in an enumerated list or with a defined mapping to

make the value isomorphic to a subset of integers (e.g. i*100 + j*10

+k, assuming j<=9 and k<=9).

Further examples of media feature tags are defined in detail

elsewhere [4].

Feature collections may be composed using a number of individual

feature tags [2]. Composition of feature collections is described

elsewhere [2]. Examples of feature collections requiring multiple

media feature tags are:

* the set of all fonts used by a document

* the width and height of a display

* the combination of color depth and resolution a display can support

This registry presumes the availability of the MIME media type

registry, and MIME media types MUST NOT be re-registered as media

feature tags. Media feature tags which are currently in use by

individual protocols or applications MAY be registered with this

registry if they might be applied outside of their current domain.

The media feature tag namespace is not bound to a particular

transport protocol or capability exchange mechanism. The registry is

limited, however, to feature tags which eXPress a capability or

preference related to how content is presented. Feature tags related

to other axes of negotiation are not appropriate for this registry.

Capability exchange mechanisms may, of course, be used to express a

variety of capabilities or preferences.

2.2 Media feature tag syntax

A media feature tag is a string consisting of one or more of the

following US-ASCII characters: uppercase letters, lowercase letters,

digits, colon (":"), slash ("/"), dot (".") percent ("%"), and dash

("-"). Feature tags are case-insensitive. Dots are understood to

potentially imply hierarchy; a feature can be suBTyped by describing

it as tree.feature.subfeature and by indicating this in the

registration. Tags should begin with an alphabetic character.

In ABNF [6], this may be represented as:

Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )

Registrants should take care to avoid creating tags which might

conflict with the creation of new registration trees; in general this

means avoiding tags which begin with an alphabetic character followed

by a dot. The current registration trees are described in section 3

below.

2.3 Media feature tag values

The registry will initially support the use of the following data

types as tag values:

- signed integers

- rational numbers

- tokens, with equality relationship

- tokens, with defined ordering relationship

- strings, with standard (octet-by-octet) equality relationship

- strings, with defined equality and/or comparison relationship

"Token" here means the token data type as defined by [7], which may

be summarized as:

token = 1*<any CHAR except CTLs or tspecials>

tspecials = "(" / ")" / "<" / ">" / "@"

/ "," / ";" / ":" / "\" / <">

/ "/" / "[" / "]" / "?" / "="

/ "{" / "}" / SP / HT

At the time of registration, each tag must be associated with a

single data type. If that data type implies a defined comparison or

an ordering, the registrant must define the ordering or comparison.

For ordered tokens, this may be by full enumeration of the tokens and

their order or by reference to an ordering mechanism. For defined

comparisons, a full description of the rules for comparison must be

provided or included by reference.

Media feature tags related to spatial or temporal characteristics

must be registered with a single canonical unit. It is strongly

preferred that units be in the SI system; where current practice has

defined units in other systems (such as pixels per inch), a

conversion method to SI units must be provided. Conversion methods

should include a defined rounding practice.

2.4 ASN.1 identifiers for media feature tags

Certain protocols use ASN.1 identifiers rather than human-readable

representations for capability exchange. In order to allow both

systems to interoperate, registrants may provide an ASN.1 identifier

or ask that IANA assign an ASN.1 identifier during registration.

These identifiers are not required for registration, but may provide

assistance to those building gateways or other cross-protocol

systems. Note that ASN.1 identifiers assigned by IANA will be

treated as tokens, not as elements from which sub-delegated

identifiers may be created or derived.

3 Media feature tag registration

Media feature tags can be registered in several different

registration trees, with different requirements as discussed below.

The vocabulary for these requirements is taken from [5]. In general,

a feature tag registration proposal is circulated and reviewed in a

fashion appropriate to the tree involved. The feature tag is then

registered if the proposal is accepted.

Review of a feature tag in the URI tree is not required.

3.1 Registration trees

The following subsections define registration "trees", distinguished

by the use of faceted names (e.g., names of the form "tree.feature-

name").

3.1.1 IETF tree

The IETF tree is intended for media feature tags of general interest

to the Internet Community, and proposals for these tags must meet the

"IETF Consensus" policies described in [5].

Registration in the IETF tree requires approval by the IESG and

publication of the feature tag specification as an RFC. Submissions

for feature tag registration in the IETF tree can originate in any WG

of the IETF or as an individual submission to the IESG.

Feature tags in the IETF tree normally have names that are not

explicitly faceted, i.e., do not contain period (".", full stop)

characters.

3.1.2 Global tree

Tags in the global tree will be distinguished by the leading facet

"g.". An organization may propose either a designation indicative of

the feature, (e.g., "g.blinktags") or a faceted designation including

the organization name (e.g., "g.organization.blinktags").

Organizations which have registered media types under the MIME vendor

tree should use the same organizational name for media feature tags

if they propose a faceted designation. The acceptance of the proposed

designation is at the discretion of the IANA. If the IANA believes

that a designation needs clarification it may request a new proposal

from the proposing organization or otherwise coordinate the

development of an appropriate designation.

Registrations of feature tags in the global tree must meet the

"Expert Review" policies described in [5]. In this case, a

designated area expert will review the proposed tag, consulting with

the members of a related mailing list. A registration may be

proposed for the global tree by anyone who has the need to allow for

communication on a particular capability or preference.

3.1.3 URI tree

A feature tag may be defined as a URI using the restricted character

set defined above. Feature tags in the URI tree are identified by the

leading facet "u.". The leading facet u. is followed by a URI [9]

which conforms to the character limitations specified in this

document. The author of the URI is assumed to be registration

authority regarding features defined and described by the content of

the URI. These tags are considered unregistered for the purpose of

this document.

3.1.4 Additional registration trees

From time to time and as required by the community, the IANA may,

with the advice and consent of the IESG, create new top-level

registration trees. These trees may be created for external

registration and management by (for example) well-known permanent

bodies, such as scientific societies for media feature types specific

to the sciences they cover. Establishment of these new trees will be

announced through RFCpublication approved by the IESG.

3.2 Location of registered feature tag list

Feature tag registrations will be posted in the anonymous FTP

Directory: "ftp://ftp.isi.edu/in-notes/iana/assignments/media-

feature-tags/" and all registered feature tags will be listed in the

periodically issued "Assigned Numbers" RFC[currently STD 2, RFC-

1700]. The feature tag description and other supporting material may

also be published as an Informational RFCby sending it to "rfc-

editor@rfc-editor.org".

3.3 IANA procedures for registering feature tags

The IANA will only register feature tags in the IETF tree in response

to a communication from the IESG stating that a given registration

has been approved.

Global tags will be registered by the IANA after review by a

designated expert. That review will serve to ensure that the tag

meets the technical requirements of this specification.

3.4 Registration template

To: media-feature-tags@apps.ietf.org (Media feature tags mailing list)

Subject: Registration of media feature tag XXXX

Instructions are preceded by `'. Some fields are optional.

Media feature tag name:

ASN.1 identifier associated with feature tag: [optional]

To have IANA assign an ASN.1 identifier,

use the value "New assignment by IANA" here.

Summary of the media feature indicated by this feature tag:

Include a short (no longer than 4 lines) description or summary

Examples:

`Use of the xyzzy feature is indicated by ...'

`Support of color display is indicated by ...'

`Number of colors in a palette which can be defined ...'

Values appropriate for use with this feature tag:

[ ] 1. The feature tag is Boolean and may have values of

TRUE or FALSE. A value of TRUE indicates an available

capability. A value of FALSE indicates the capability

is not available.

If you wish to indicate two mutually exclusive possibilities

that cannot be expressed as the availability or lack of a

capability, use a two-token list, rather than a Boolean value.

[ ] 2. The feature has an associated numeric or enumerated value.

For case 2: Indicate the data type of the value:

[ ] 2a. Signed Integer

[ ] 2b. Rational number

[ ] 2c. Token (equality relationship)

[ ] 2d. Token (ordered)

[ ] 2e. String (equality relationship)

[ ] 2f. String (defined comparison)

IMPORTANT: You may only chose one of the above data types.

(Only for case 2) Detailed description of the feature value meaning,

and of the format and meaning of the feature tag values for the

alternative results.

If you have selected 2d you must provide the ordering mechanism

or a full and ordered enumeration of possible values. If you

have selected 2f, you must provide a definition of the comparison.

Definitions by included reference must be to stable and readily

available specifications:

If the number of alternative results is small, you may

enumerate the identifiers of the different results and describe

their meaning.

If there is a limited useful numeric range of result (2b, 2c),

indicate the range.

The identifiers of the alternative results could also be

described by referring to another IANA registry, for example

the paper sizes enumerated by the Printer MIB.

The feature tag is intended primarily for use in the following

applications, protocols, services, or negotiation mechanisms:

[optional]

For applications, also specify the number of the first version

which will use the tag, if applicable.

Examples of typical use: [optional]

Related standards or documents: [optional]

Considerations particular to use in individual applications,

protocols, services, or negotiation mechanisms: [optional]

Interoperability considerations: [optional]

Security considerations:

Privacy concerns, related to exposure of personal information:

Denial of service concerns related to consequences of specifying

incorrect values:

Other:

Additional information: [optional]

KeyWords: [optional]

Related feature tags: [optional]

Related media types or data formats: [optional]

Related markup tags: [optional]

Name(s) & email address(es) of person(s) to contact for

further information:

Intended usage:

one of COMMON, LIMITED USE or OBSOLETE

Author/Change controller:

Requested IANA publication delay: [optional]

A delay may only be requested for final placement in the global

or IETF trees, with a maximum of two months. Organizations

requesting a registration with a publication delay should note

that this delays only the official publication of the tag

and does not prevent information on it from being disseminated

by the members of the relevant mailing list.

Other information: [optional]

Any other information that the author deems interesting may be

added here.

4 Security Considerations

Negotiation mechanisms reveal information about one party to other

parties. This may raise privacy concerns, and may allow a malicious

party to make better guesses about the presence of specific security

holes.

5 Acknowledgments

The details of the registration procedure in this document were

directly adapted from [1]. Much of the text in section 3 was

directly copied from this source.

The idea of creating a vocabulary of areas of media features,

maintained in a central open registry, is due to discussions on

extensible negotiation mechanisms [3] in the IETF HTTP working group.

The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman,

Dan Wing, Jacob Palme, and Martin Duerst for their contributions to

discussions about media feature tag registration.

6 References

[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail

Extensions (MIME) Part Four: Registration Procedures", BCP 13,

RFC2048, November 1996.

[2] Klyne, G., "An algebra for describing media feature sets", Work

in Progress.

[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation in

HTTP. RFC2295, March 1998.

[4] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features

for Display, Print, and Fax", RFC2534, March 1999.

[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA

Considerations Section in RFCs", BCP 26, RFC2434, October 1998.

[6] Crocker, D., Ed., "Augmented BNF for Syntax Specifications:

ABNF", RFC2234, November 1997.

[7] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T. Berners-

Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2068, January

1997.

[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC2119, March 1997.

[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC

1630, June 1994.

7 Authors' Addresses

Koen Holtman

Technische Universiteit Eindhoven

Postbus 513

Kamer HG 6.57

5600 MB Eindhoven

The Netherlands

EMail: koen@win.tue.nl

Andrew H. Mutz

Hewlett-Packard Company

11000 Wolfe Rd. 42UO

Cupertino CA 95014 USA

Fax +1 408 447 4439

EMail: andy_mutz@hp.com

Ted Hardie

Equinix

901 Marshall Street

Redwood City, CA 94063 USA

EMail: hardie@equinix.com

8 Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有