idnits 2.17.1 draft-ietf-conneg-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 285 has weird spacing: '...esource a doc...' == Unrecognized Status in 'Category: Work-in-progress', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 March 1999) is 9162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Negotiation' on line 379 -- Looks like a reference, but probably isn't: 'A' on line 419 -- Looks like a reference, but probably isn't: 'S' on line 441 -- Looks like a reference, but probably isn't: 'R' on line 441 -- Looks like a reference, but probably isn't: 'U' on line 436 == Unused Reference: '3' is defined on line 946, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 952, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 962, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Experimental RFC: RFC 2295 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2068 (ref. '7') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2478 (ref. '8') (Obsoleted by RFC 4178) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF conneg working group Graham Klyne 3 Internet draft 5GM/Content Technologies 4 Category: Work-in-progress 25 March 1999 5 Expires: September 1999 7 Protocol-independent content negotiation framework 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) 1999, The Internet Society 33 Abstract 35 A number of Internet application protocols have a need to provide 36 content negotiation for the resources with which they interact. 37 MIME media types [1,2] provide a standard method for handling one 38 major axis of variation, but resources also vary in ways which 39 cannot be expressed using currently available MIME headers. 41 This draft sets out terminology, an abstract framework and goals 42 for protocol-independent content negotiation, and identifies some 43 technical issues which may need to be addressed. 45 The abstract framework does not attempt to specify the content 46 negotiation process, but gives an indication of the anticipated 47 scope and form of any such specification. The goals set out the 48 desired properties of a content negotiation mechanism. 50 Internet draft Protocol-independent content negotiation framework 52 Table of contents 54 1. Introduction.............................................2 55 1.1 Structure of this document ...........................3 56 1.2 Discussion of this document ..........................3 57 2. Terminology and definitions..............................4 58 3. Framework................................................8 59 3.1 Abstract framework for content negotiation ...........9 60 3.1.1 The negotiation process..........................9 61 3.2 Abstract model for negotiation metadata ..............10 62 3.3 Text representation for negotiation metadata .........11 63 3.4 ASN.1 description of negotiation metadata ............11 64 3.5 Protocol binding guidelines ..........................12 65 4. Goals....................................................12 66 4.1 Generic framework and metadata goals .................12 67 4.2 Protocol-specific deployment goals ...................13 68 5. Technical issues.........................................14 69 5.1 Non-message resource transfers .......................14 70 5.2 End-to-end vs hop-by-hop negotiations ................14 71 5.3 Third-party negotiation ..............................15 72 5.4 Use of generic directory and resolution services .....15 73 5.5 Billing issues .......................................15 74 5.6 Performance considerations ...........................15 75 5.7 Confidence levels in negotiated options ..............16 76 6. Security considerations..................................16 77 6.1 Privacy ..............................................17 78 6.2 Denial of service attacks ............................17 79 6.3 Mailing list interactions ............................17 80 6.4 Use of security services .............................17 81 6.5 Disclosure of security weaknesses ....................18 82 6.5.1 User agent identification........................18 83 6.5.2 Macro viruses....................................18 84 6.5.3 Personal vulnerability...........................18 85 6.6 Problems of negotiating security .....................18 86 7. Full copyright statement.................................19 87 8. Acknowledgements.........................................19 88 9. References...............................................19 89 10. Author's address........................................21 90 Appendix A: Amendment history...............................21 92 1. Introduction 94 A number of Internet application protocols have a need to provide 95 content negotiation for the resources with which they interact. 96 While MIME media types [1, 2] provide a standard method for 97 handling one major axis of variation, resources also vary in ways 98 which cannot be expressed using currently available MIME headers. 100 Internet draft Protocol-independent content negotiation framework 101 This memo sets out terminology, a framework and some goals for a 102 protocol-independent content negotiation framework, and identifies 103 some technical issues which may need to be addressed. 105 The framework does not attempt to specify the content negotiation 106 process; rather it gives an indication of the anticipated scope 107 and form of any such specifications. 109 The statement of goals is intended to set out the desired 110 properties of a content negotiation framework, while trying to 111 avoid any assumption of the form that framework may take. 113 1.1 Structure of this document 115 The main part of this draft addresses four main areas: 117 Section 2 defines some of the terms which are used with special 118 meaning. 120 Section 3 outlines a proposed framework for describing protocol- 121 independent content negotiation. 123 Section 4 describes various goals for content negotiation. 125 Section 5 discusses some of the technical issues which are raised 126 by this document, with cross-references to other work where 127 appropriate. 129 1.2 Discussion of this document 131 Discussion of this document should take place on the content 132 negotiation and media feature registration mailing list hosted by 133 the Internet Mail Consortium (IMC). 135 Please send comments regarding this document to: 137 ietf-medfree@imc.org 139 To subscribe to this list, send a message with the body 'subscribe' 140 to "ietf-medfree-request@imc.org". 142 To see what has gone on before you subscribed, please see the 143 mailing list archive at: 145 http://www.imc.org/ietf-medfree/ 147 Internet draft Protocol-independent content negotiation framework 149 2. Terminology and definitions 151 This section introduces a number of terms which are used with 152 specific meaning in the content negotiation drafts. Many of these 153 have been copied and adapted from [5]. 155 The terms are listed in alphabetical order. 157 Capability 158 An attribute of a sender or receiver (often the receiver) 159 which indicates an ability to generate or process a 160 particular type of message content. 162 Characteristic 163 Some description of a sender or receiver which indicates 164 a possible capability or preference. 166 Choice message 167 A choice message returns a representation of some 168 selected variant or variants, together with the variant 169 list of the negotiable resource. It can be generated when 170 the sender has sufficient information to select a variant 171 for the receiver, and also requires to inform the 172 receiver about the other variants available. 174 Connected mode 175 A mode of operation in which sender and receiver are 176 directly connected, and hence are not prevented from 177 definitively determining each other's capabilities. 178 (See also: Session mode) 180 Content feature 181 (see Feature) 183 Content negotiation 184 An exchange of information (negotiation metadata) which 185 leads to selection of the appropriate representation 186 (variant) when transferring a data resource. 188 Data resource 189 A network data object that can be transferred. Data 190 resources may be available in multiple representations 191 (e.g. multiple languages, data formats, size, 192 resolutions) or vary in other ways. 193 (See also: Message, Resource) 195 Feature A piece of information about the media handling 196 properties of a message passing system component or of a 197 data resource. 199 Internet draft Protocol-independent content negotiation framework 201 Feature tag 202 A name that identifies a "feature". 204 Feature set 205 Information about a sender, recipient, data file or other 206 participant in a message transfer which describes the set 207 of features that it can handle. 209 Where a 'feature' describes a single identified attribute 210 of a resource, a 'feature set' describes full set of 211 possible attributes. 213 List message 214 A list message sends the variant list of a negotiable 215 resource, but no variant data. It can be generated when 216 the sender does not want to, or is not allowed to, send a 217 particular variant. 219 Media feature 220 information that indicates facilities assumed to be 221 available for the message content to be properly rendered 222 or otherwise presented. Media features are not intended 223 to include information that affects message transmission. 225 Message Data which is transmitted from a sender to a receiver, 226 together with any encapsulation which may be applied. 227 Where a data resource is the original data which may be 228 available in a number of representations, a message 229 contains those representation(s) which are actually 230 transmitted. Negotiation metadata is not generally 231 considered to be part of a message. 233 Message data is distinguished from other transmitted data 234 by the fact that its content is fully determined before 235 the start of transmission. 237 Negotiated content 238 Message content which has been selected by content 239 negotiation. 241 Negotiation 242 (See: content negotiation) 244 Negotiable resource 245 A data resource which has multiple representations 246 (variants) associated with it. Selection of an 247 appropriate variant for transmission in a message is 248 accomplished by content negotiation between the sender 249 and recipient. 251 Internet draft Protocol-independent content negotiation framework 253 Negotiation metadata 254 Information which is exchanged between the sender and 255 receiver of a message by content negotiation in order to 256 determine the variant which should be transferred. 258 Neighbouring variant 259 A particular representation (variant) of a variant 260 resource which can safely be assumed to be subject to the 261 same access controls as the variant resource itself. Not 262 all variants of a given variant resource are necessarily 263 neighbouring variants. The fact that a particular variant 264 is or is not a neighbouring variant has implications for 265 security considerations when determining whether that 266 variant can be sent to a receiver in place of the 267 corresponding variant resource. It may also have 268 implications when determining whether or not a sender is 269 authorized to transmit a particular variant. 271 Preference 272 An attribute of a sender or receiver (often the receiver) 273 which indicates an preference to generate or process one 274 particular type of message content over another, even if 275 both are possible. 277 Receiver A system component (device or program) which receives a 278 message. 280 Receiver-initiated transmission 281 A message transmission which is requested by the eventual 282 receiver of the message. Sometimes described as 'pull' 283 messaging. E.g. an HTTP GET operation. 285 Resource a document, data file or facility which is accessed or 286 transmitted across a network. 287 (See also: Data resource) 289 Sender A system component (device or program) which transmits a 290 message. 292 Sender-initiated transmission 293 A message transmission which is invoked by the sender of 294 the message. Sometimes described as 'push' messaging. 295 E.g. sending an e-mail. 297 Session mode 298 A mode of message transmission in which confirmation of 299 message delivery is received by the sender in the same 300 application session (usually the same transport 301 connection) that is used to transmit the message. 302 (See also: connected mode, store and forward mode) 304 Internet draft Protocol-independent content negotiation framework 306 Store and forward mode 307 A mode of message transmission in which the message is 308 held in storage for an unknown period of time on message 309 transfer agents before being delivered. 311 Syntax The form used to express some value; especially the 312 format used to express a media feature value, or a 313 feature set. 314 (See also: feature value, feature set, type.) 316 Transmission 317 The process of transferring a message from a sender to a 318 receiver. This may include content negotiation. 320 Type The range of values that can be indicated by some 321 identifier of variable; especially the range of values 322 that can be indicated by a feature tag. 323 (See also: feature, syntax.) 325 NOTE: this differs from usage employed by the LDAP/X.500 326 directory community, who use the terms "attribute type" 327 to describe an identifier for a value in a directory 328 entry, and "attribute syntax" to describe a range of 329 allowed attribute values. 331 User agent 332 A system component which prepares and transmits a 333 message, or receives a message and displays, prints or 334 otherwise processes its contents. 336 Variant One of several possible representations of a data 337 resource. 339 Variant list 340 A list containing variant descriptions, which can be 341 bound to a negotiable resource. 343 Variant description 344 A machine-readable description of a variant resource, 345 usually found in a variant list. A variant description 346 contains a variant resource identifier and various 347 attributes which describe properties of the variant. 349 Variant resource 350 A data resource for which multiple representations 351 (variants) are available. 353 Internet draft Protocol-independent content negotiation framework 355 3. Framework 357 For the purposes of this document, message transmission protocol 358 capabilities are explicitly disregarded: it is presumed that these 359 will be dealt with separately by some orthogonal mechanism. 361 Content negotiation covers three elements: 363 1. expressing the capabilities of the sender and the data resource 364 to be transmitted (as far as a particular message is concerned), 366 2. expressing the capabilities of a receiver (in advance of the 367 transmission of the message), and 369 3. a protocol by which capabilities are exchanged. 371 These negotiation elements are addressed by a negotiation framework 372 incorporating a number of design elements with dependencies shown: 374 [ Abstract ] [ Abstract ] 375 [negotiation] [ negotiation ] 376 [ process ] [ metadata ] 377 | | 378 V V 379 [Negotiation] [ Negotiation ] 380 [ protocol ] [ metadata ] 381 [ binding ] [representation] 382 | | 383 ------- ------- 384 | | 385 V V 386 [Application protocol] 387 [ incorporating ] 388 [content negotiation ] 390 Within this overall framework, expressing the capabilities of 391 sender and receiver is covered by negotiation metadata. The 392 protocol for exchanging capabilities is covered by the abstract 393 negotiation framework and its binding to a specific application 394 protocol. 396 Application protocol independence is addressed by separating the 397 abstract negotiation process and metadata from concrete 398 representations and protocol bindings. 400 Internet draft Protocol-independent content negotiation framework 402 3.1 Abstract framework for content negotiation 404 The negotiation framework provides for an exchange of negotiation 405 metadata between the sender and receiver of a message which leads 406 to determination of a data format which the sender can provide and 407 the recipient can process. Thus, there are three main elements 408 which are the subjects of the negotiation process and whose 409 capabilities are described by the negotiation metadata: the sender, 410 the transmitted data file format and the receiver. 412 The life of a data resource may be viewed as: 414 (C) (T) (F) 415 [A]-->--[S]-->--[R]-->--[U] 417 where: 419 [A] = author of document 420 (C) = original document content 421 [S] = message sending system 422 (T) = transmitted data file (representation of (C)) 423 [R] = receiving system 424 (F) = formatted (rendered) document data (presentation of (C)) 425 [U] = user or consumer of a document 427 Here, it is [S] and [R] who exchange negotiation metadata to decide 428 the form of (T), so these elements are the focus of our attention. 430 Negotiation metadata provided by [S] would take account of 431 available document content (C) (e.g. availability of resource 432 variants) as well as its own possible ability to offer that content 433 in a variety of formats. 435 Negotiation metadata provided by [R] would similarly take account 436 of the needs and preferences of its user [U] as well as its own 437 capabilities to process and render received data. 439 3.1.1 The negotiation process 441 Negotiation between the sender [S] and the receiver [R] consists of 442 a series of negotiation metadata exchanges that proceeds until 443 either party determines a specific data file (T) to be transmitted. 444 If the sender makes the final determination, it can send the file 445 directly. Otherwise the receiver must communicate its selection to 446 the sender who sends the indicated file. 448 Internet draft Protocol-independent content negotiation framework 449 This process implies an open-ended exchange of information between 450 sender and receiver. Not every implementation is expected to 451 implement this scheme with the full generality thus implied. 452 Rather, it is expected that every concrete negotiation can be 453 viewed as a subset of this process. 455 For example, Transparent Content Negotiation (TCN) [5] uses a model 456 in which one of the following happens: 458 o The recipient requests a resource with no variants, in which case 459 the sender simply sends what is available. 461 o A variant resource is requested, in which case the server replies 462 with a list of available variants, and the client chooses one 463 variant from those offered. 465 o The recipient requests a variant resource, and also provides 466 negotiation metadata (in the form 'Accept' headers) which allows 467 the server to make a choice on the client's behalf. 469 Another, simpler example is that of fax negotiation: in this case 470 the intended recipient declares its capabilities, and the sender 471 chooses a message variant to match. 473 Each of these can be viewed as a particular case of the general 474 negotiation process described above. Similar observations can be 475 made regarding the use of directory services or MIME 476 'Multipart/alternative' in conjunction with e-mail message 477 transmission. 479 3.2 Abstract model for negotiation metadata 481 A simple but general negotiation framework has been described, 482 which is based on the exchange of negotiation metadata between 483 sender and recipient. The mechanism by which data is exchanged is 484 not important to the abstract negotiation framework, but something 485 does need to be said about the general form of the metadata. 487 The terminology and definitions section of this document places 488 constraints on the form of negotiation metadata, and the 489 descriptions that follow should be read in conjunction with the 490 definitions to which they refer. 492 Negotiation metadata needs to encompass the following elements: 494 o Media feature: a way to describe attributes of a data resource. 496 o Feature set: a description of a range of possible media feature 497 combinations which can be: offered by a sender; represented by 498 a data file format; or processed by a receiver. 500 Internet draft Protocol-independent content negotiation framework 502 o One or more naming schemes for labelling media features and 503 feature sets. These should be backed up by some kind of 504 registration process to ensure uniqueness of names and to 505 encourage a common vocabulary for commonly used features. 507 o A framework of data types for media features, indicating the 508 range and properties of value types which can be represented. 510 o A way to combine media features into feature sets, capable of 511 expressing feature dependencies within a feature set (e.g. 512 640x480 pixel size and 256 colours, or 800x600 pixel size and 16 513 colours). 515 o Some way to rank feature sets based upon sender and receiver 516 preferences for different feature values. 518 3.3 Text representation for negotiation metadata 520 A concrete textual representation for media feature values and 521 feature set descriptions would provide a common vocabulary for 522 feature data in text-based protocols like HTTP and SMTP. 524 In defining a textual representation, the issue of allowable 525 character sets needs to be addressed. Whether or not negotiation 526 metadata needs to support a full gamut of international characters 527 will depend upon the framework of data types adopted for media 528 features. As negotiation metadata would be used as a protocol 529 element (not directly visible to the user) rather than part of the 530 message content, support for extended character sets may be not 531 required. 533 A textual representation for negotiation metadata would imply a 534 textual representation for media feature names, and also for 535 expressions of the media feature combining algebra. 537 3.4 ASN.1 description of negotiation metadata 539 For use with non-text-based protocols, an ASN.1 description and 540 encoding designation for negotiation metadata could be helpful for 541 incorporating the common negotiation framework into ASN.1-derived 542 protocols like X.400, X.500, LDAP and SNMP. 544 An ASN.1 description of negotiation metadata formats suggests that 545 separate media feature naming scheme based on ISO object 546 identifiers would be valuable. 548 Internet draft Protocol-independent content negotiation framework 550 3.5 Protocol binding guidelines 552 Specific protocol bindings will be needed to use the abstract 553 framework for negotiation. 555 Details of protocol bindings would be beyond the scope of this 556 work, but guidelines maybe not. (SASL might provide a useful model 557 here.) 559 4. Goals 561 These goals are presented in two categories: 563 1. Negotiation framework and metadata goals which address the broad 564 goals of negotiation in a protocol-independent fashion. 566 2. Specific goals which relate to the deployment of negotiation in 567 the context of a specific protocol (e.g. relation to HTTP 568 protocol operations, cache interactions, security issues, 569 existing HTTP negotiation mechanisms, application to variant 570 selection, etc.). These would be addressed by a specific 571 protocol binding for the negotiation framework. 573 4.1 Generic framework and metadata goals 575 o A common vocabulary for designating features and feature sets. 577 o A stable reference for commonly used features. 579 o An extensible framework, to allow rapid and easy adoption of new 580 features. 582 o Permit an indication of quality or preference. 584 o Capture dependencies between feature values 586 o A uniform framework mechanism for exchanging negotiation metadata 587 should be defined that can encompass existing negotiable features 588 and is extensible to future (unanticipated) features. 590 o Efficient negotiation should be possible in both receiver 591 initiated ('pull') and sender initiated ('push') message 592 transfers. 594 o The structure of the negotiation procedure framework should stand 595 independently of any particular message transfer protocol. 597 o Be capable of addressing the role of content negotiation in 598 fulfilling the communication needs of less able computer users. 600 Internet draft Protocol-independent content negotiation framework 602 4.2 Protocol-specific deployment goals 604 o A negotiation should generally result in identification of a 605 mutually acceptable form of message data to be transferred. 607 o If capabilities are being sent at times other than the time of 608 message transmission, then they should include sufficient 609 information to allow them to be verified and authenticated. 611 o A capability assertion should clearly identify the party to whom 612 the capabilities apply, the party to whom they are being sent, 613 and some indication of their date/time or range of validity. To 614 be secure, capability assertions should be protected against 615 interception and substitution of valid data by invalid data. 617 o A request for capability information, if sent other than in 618 response to delivery of a message, should clearly identify the 619 requester, the party whose capabilities are being requested, and 620 the time of the request. It should include sufficient 621 information to allow the request to be authenticated. 623 o In the context of a given application, content negotiation may 624 use one or several methods for transmission, storage, or 625 distribution of capabilities. 627 o The negotiation mechanism should include a standardized method 628 for associating features with resource variants. 630 o Negotiation should provide a way to indicate provider and 631 recipient preferences for specific features. 633 o Negotiation should have the minimum possible impact on network 634 resource consumption, particularly in terms of bandwidth and 635 number of protocol round-trips required. 637 o Systems should protect the privacy of users' profiles and 638 providers' inventories of variants. 640 o Protocol specifications should identify and permit mechanisms to 641 verify the reasonable accuracy of any capability data provided. 643 o Negotiation must not significantly jeopardize the overall 644 operation or integrity of any system in the face of erroneous 645 capability data, whether accidentally or maliciously provided. 647 o Intelligent gateways, proxies, or caches should be allowed to 648 participate in the negotiation. 650 Internet draft Protocol-independent content negotiation framework 652 o Negotiation metadata should be regarded as cacheable, and 653 explicit cache control mechanisms provided to forestall the 654 introduction of ad-hoc cache-busting techniques. 656 o Automatic negotiation should not pre-empt a user's ability to 657 choose a document format from those available. 659 5. Technical issues 661 5.1 Non-message resource transfers 663 The ideas for generic content negotiation have been conceived and 664 developed in the context of message-oriented data transmissions. 666 Message data is defined elsewhere as a data whose entire content is 667 decided before the start of data transmission. The following are 668 examples of non-message data transfers. 670 o streamed data, 672 o interactive computations, 674 o real-time data acquisition, 676 Does a proposed approach to negotiation based on message data 677 reasonably extend to streamed data (e.g. data whose content is not 678 fully determined by the time the first data items are transmitted)? 680 It may be that the metadata will be applicable, but the abstract 681 negotiation process framework may be insufficient to these more 682 demanding circumstances. 684 5.2 End-to-end vs hop-by-hop negotiations 686 Could this distinction place any special demands or constraints on 687 a generic negotiation framework, or is this simply a protocol 688 issue? 690 o End-to-end negotiation gives greatest confidence in the outcome. 692 o Hop-by-hop may have advantages in a network of occasionally- 693 connected systems, but will place additional demands on 694 intervening message transmission agents. 696 Hop-by-hop negotiation implies that negotiation responses are not 697 necessarily a definitive indication of an endpoint system's 698 capabilities. This in turn implies a possible need for time-to- 699 live and re-verification mechanisms to flush out stale negotiation 700 data. 702 Internet draft Protocol-independent content negotiation framework 703 Note that one of the stated goals is to allow proxies and caches to 704 participate in the negotiation process, as appropriate. 706 5.3 Third-party negotiation 708 An extension of the hop-by-hop vs. end-to-end negotiation theme is 709 to consider the implications of allowing any system other than an 710 endpoint participant in the message transmission to supply 711 negotiation metadata. 713 Any use of a third party in the negotiation process inevitably 714 increases the possibilities for introducing errors into the 715 negotiation metadata. 717 One particular example of a third party participant in a 718 negotiation process that is frequently suggested is the use of a 719 directory service using LDAP or similar protocols. What additional 720 steps need to be taken to ensure reasonable reliability of 721 negotiation metadata supplied by this means? 723 5.4 Use of generic directory and resolution services 725 It is clearly helpful to use existing protocols such as LDAP to 726 exchange content negotiation metadata. 728 To achieve this, it be necessary to define directory or other 729 schema elements which are specific to content negotiation. For 730 example, an LDAP attribute type for a media feature set. 732 5.5 Billing issues 734 Negotiation may raise some billing-related issues in some contexts 735 because it potentially incurs a two-way exchange of data not 736 necessarily completed during a single connection. There is an 737 issue of who pays for return messages, etc., in a non-connected 738 environment like e-mail or fax. 740 5.6 Performance considerations 742 Negotiation can impact performance in both positive and negative 743 ways. 745 The obvious negative impact arises from the exchange of additional 746 data which necessarily consumes some additional bandwidth. There 747 is also an issue of round-trip or third-party query delays while 748 negotiation metadata is being exchanged before transmission of the 749 message itself is commenced. 751 Internet draft Protocol-independent content negotiation framework 752 Over the Internet, there are some bandwidth/latency trade-offs 753 which can be made. For example, in Internet e-mail the MIME type 754 'multipart/alternative' can be used to send multiple versions of a 755 resource: this preserves latency by using additional bandwidth to 756 send a greater volume of data. On the other hand, HTTP [7] 757 suggests a negotiation mechanism which preserves bandwidth at the 758 cost of introducing a round-trip delay (section 12.2, Agent-driven 759 negotiation). 761 To set against the negative performance impact of content 762 negotiation, it is to be hoped that overall network efficiency is 763 to be improved if it results in the most useful data format being 764 delivered to its intended recipient, first time, almost every time. 766 5.7 Confidence levels in negotiated options 768 In some cases (e.g. when there has been a direct exchange of 769 information with the remote system) the communicating parties will 770 have a high degree of confidence in the outcome of a negotiation. 771 Here, a data exchange can be performed without need for subsequent 772 confirmation that the options used were acceptable. 774 In other cases, the options will be a best-guess, and it may be 775 necessary to make provision for parties to reject the options 776 actually used in preference for some other set. 778 This consideration is likely to interact with performance 779 considerations. 781 A useful pattern, adopted by TCN [5], is to define a negotiation 782 procedure which guarantees a correct outcome. This forms the 783 foundation for a procedure which attempts to use easily-obtained 784 but less reliable information in an attempt to optimize the 785 negotiation process but that contains checks to guarantee the final 786 result will be the same as would have been obtained by the full 787 negotiation procedure. Such procedures sometimes have to resort to 788 the original "full cycle" negotiation procedure, but in a majority 789 of cases are expected to reach their conclusion by an optimized 790 route. 792 6. Security considerations 794 The purposes of this section is to identify and catalogue some 795 security issues that feature negotiation protocols should consider. 797 Internet draft Protocol-independent content negotiation framework 799 6.1 Privacy 801 Privacy may be adversely affected by: 803 o Unintended disclosure of personal information. 805 o Spoofed requests for negotiation data simply for the purposes of 806 gathering information, and not as part of a bona fide message 807 transmission. 809 6.2 Denial of service attacks 811 Service denial may be caused by: 813 o Injection of false negotiation data. 815 o Excessive requests for negotiation data 817 6.3 Mailing list interactions 819 Content negotiation with final recipients is somewhat at odds with 820 normal practice for maintaining lists for redistribution of 821 Internet mail. 823 It may be appropriate for a sender to negotiate data formats with a 824 list manager, and for a list manager to negotiate with message 825 recipients. But the common practice of keeping confidential the 826 identities and addresses of mailing list subscribers suggests that 827 end-to-end negotiation through a mailing list is not consistent 828 with good security practice. 830 6.4 Use of security services 832 Protocols that employ security services for message transfer should 833 also apply those services to content negotiation: 835 o Authenticated requests for negotiation metadata provide a means 836 for a potential recipient to moderate the distribution of media 837 capability information. 839 o Authentication of negotiation metadata provides a means for 840 potential message senders to avoid using incorrect information 841 injected by some other party. 843 o Encryption of negotiation data may help to prevent disclosure of 844 sensitive capability-related information to snoopers. 846 Internet draft Protocol-independent content negotiation framework 848 o Conducting a negotiation exchange over an authenticated or 849 encrypted protocol session (e.g. SASL), transport connection or 850 network path (e.g. TLS, IPSEC) can provide for mutual 851 authentication of both parties in an exchange of negotiation 852 data. 854 6.5 Disclosure of security weaknesses 856 6.5.1 User agent identification 858 Disclosure of capability information may allow a potential attacker 859 to deduce what message handling agent is used, and hence may lead 860 to the exploitation of known security weaknesses in that agent. 862 6.5.2 Macro viruses 864 Macro viruses are a widespread problem among applications such as 865 word processors and spreadsheets. Knowing which applications a 866 recipient employs (e.g. by file format) may assist in a malicious 867 attack. However, such viruses can be spread easily without such 868 knowledge by sending multiple messages, where each message infects 869 a specific application version. 871 6.5.3 Personal vulnerability 873 One application of content negotiation is to enable the delivery of 874 message content that meets specific requirements of less able 875 people. Disclosure of this information may make such people 876 potential targets for attacks that play on their personal 877 vulnerabilities. 879 6.6 Problems of negotiating security 881 If feature negotiation is used to decide upon security-related 882 features to be used, some special problems may be created if the 883 negotiation procedure can be subverted to prevent the selection of 884 effective security procedures. 886 The security considerations section of GSS-API negotiation [8] 887 discusses the use of integrity protecting mechanisms with security 888 negotiation 890 Internet draft Protocol-independent content negotiation framework 892 7. Full copyright statement 894 Copyright (C) The Internet Society 1999. All Rights Reserved. 896 This document and translations of it may be copied and furnished to 897 others, and derivative works that comment on or otherwise explain 898 it or assist in its implementation may be prepared, copied, 899 published and distributed, in whole or in part, without restriction 900 of any kind, provided that the above copyright notice and this 901 paragraph are included on all such copies and derivative works. 902 However, this document itself may not be modified in any way, such 903 as by removing the copyright notice or references to the Internet 904 Society or other Internet organizations, except as needed for the 905 purpose of developing Internet standards in which case the 906 procedures for copyrights defined in the Internet Standards process 907 must be followed, or as required to translate it into languages 908 other than English. 910 The limited permissions granted above are perpetual and will not be 911 revoked by the Internet Society or its successors or assigns. 913 This document and the information contained herein is provided on 914 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 915 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 916 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 917 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 918 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 920 8. Acknowledgements 922 Some material in this draft has been derived from earlier memos by 923 Koen Holtman, Andrew Mutz, Ted Hardie, Larry Masinter, Dan Wing, 924 Neil Joffe. Matters relating to the importance and relevance of 925 content negotiation to less-able users were raised by Al Gilman. 927 This draft has also been informed by the debates of the IETF 928 'conneg' working group. 930 9. References 932 [1] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 933 Part 1: Format of Internet message bodies" 934 N. Freed, Innosoft 935 N. Borenstein, First Virtual 936 November 1996. 938 Internet draft Protocol-independent content negotiation framework 940 [2] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 941 Part 2: Media types" 942 N. Freed, Innosoft 943 N. Borenstein, First Virtual 944 November 1996. 946 [3] "The Alternates Header Field" 947 K. Holtman, TUE, 948 et al. 949 Internet draft: 950 Work in progress, November 1997. 952 [4] "Scenarios for the Delivery of Negotiated Content" 953 T. Hardie, NASA Network Information Center 954 Internet draft: 955 Work in progress, November 1997. 957 [5] RFC 2295, "Transparent Content Negotiation in HTTP" 958 Koen Holtman, TUE 959 Andrew Mutz, Hewlett Packard 960 March 1998. 962 [6] "Extensions to Delivery Status Notifications for Fax" 963 Dan Wing, Cisco Systems 964 Internet draft: 965 Work in progress, November 1997. 967 [7] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 968 R. Fielding, UC Irvine 969 J. Gettys, 970 J. Mogul, DEC 971 H. Frytyk, 972 T. Berners-Lee, MIT/LCS 973 January 1997. 975 [8] RFC 2478, "The Simple and Protected GSS-API Negotiation 976 Mechanism" 977 Eric Blaize, 978 Denis Pinkas, Bull 979 December 1998. 981 Internet draft Protocol-independent content negotiation framework 983 10. Author's address 985 Graham Klyne 986 5th Generation Messaging Ltd. Content Technologies Ltd. 987 5 Watlington Street Forum 1, Station Road 988 Nettlebed Theale 989 Henley-on-Thames, RG9 5AB Reading, RG7 4RA 990 United Kingdom United Kingdom. 991 Telephone: +44 1491 641 641 +44 118 930 1300 992 Facsimile: +44 1491 641 611 +44 118 930 1301 993 E-mail: GK@ACM.ORG 995 Appendix A: Amendment history 997 [[[RFC Editor note: please remove this section on publication]]] 999 00a 06-Dec-1997 1000 Document initially created. 1002 00b 07-Dec-1997 1003 Added definition of "transmission". 1004 Copied and adapted requirements from Internet fax 1005 requirements draft. Updated framework with details from 1006 Internet fax requirements draft. 1008 00c 27-Feb-1998 1009 Update mailing list details. 1010 Updated terminology entries, particularly to distinguish 1011 between a feature and a feature set. 1012 Fleshed out the abstract framework sections. 1013 Added more requirements, and reorganized that section. 1014 Written up technical issues, as identified so far. 1016 01a 10-Mar-1998 1017 Added more text and headings to security considerations. 1018 Spell-checked (!). 1020 01b 16-Feb-1999 1021 New Internet draft boilerplate in 'status' preface. Move 1022 amendment history to appendix. Changed from document 1023 title. Tidied up sections dealing with goals, technical 1024 issues, security considerations and acknowledgements. 1025 Updated some references. 1027 Internet draft Protocol-independent content negotiation framework 1029 02a 25-Mar-1999 1030 Add terminology entries for 'Type' and 'Syntax', to 1031 explicitly indicate difference from LDAP/X.500 directory 1032 community usage of these terms. Updated references and 1033 removed citations to work in progress from the body text. 1034 Change indications of "requirements" to "goals".