idnits 2.17.1 draft-ietf-conneg-requirements-01.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 20 longer pages, the longest (page 2) 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 ([4], [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 294 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 (16 February 1999) is 9195 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) == Missing Reference: '2' is mentioned on line 954, but not defined == Missing Reference: '4' is mentioned on line 966, but not defined == Missing Reference: '5' is mentioned on line 971, but not defined -- Looks like a reference, but probably isn't: 'Negotiation' on line 374 -- Looks like a reference, but probably isn't: 'A' on line 416 -- Looks like a reference, but probably isn't: 'S' on line 438 -- Looks like a reference, but probably isn't: 'R' on line 438 -- Looks like a reference, but probably isn't: 'U' on line 433 == Missing Reference: '6' is mentioned on line 976, but not defined == Missing Reference: '7' is mentioned on line 981, but not defined == Missing Reference: '8' is mentioned on line 989, but not defined == Missing Reference: '3' is mentioned on line 960, but not defined Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 7 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 16 February 1999 5 Expires: August 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. The 40 case for a cross-protocol negotiation framework is set out 41 elsewhere [4]. 43 This draft sets out terminology, an abstract framework and goals 44 for protocol-independent content negotiation, and identifies some 45 technical issues which may need to be addressed. 47 The abstract framework does not attempt to specify the content 48 negotiation process, but gives an indication of the anticipated 49 scope and form of any such specification. The goals set out the 50 desired properties of a content negotiation mechanism. 52 Internet draft Protocol-independent content negotiation framework 53 16 February 1999 55 Table of contents 57 1. Introduction.............................................3 58 1.1 Structure of this document ...........................3 59 1.2 Discussion of this document ..........................3 60 2. Terminology and definitions..............................4 61 3. Framework................................................8 62 3.1 Abstract framework for content negotiation ...........8 63 3.1.1 The negotiation process..........................9 64 3.2 Abstract model for negotiation metadata ..............10 65 3.3 Text representation for negotiation metadata .........11 66 3.4 ASN.1 description of negotiation metadata ............11 67 3.5 Protocol binding guidelines ..........................11 68 4. Goals....................................................12 69 4.1 Generic framework and metadata requirements ..........12 70 4.2 Protocol-specific deployment requirements ............12 71 5. Technical issues.........................................14 72 5.1 Non-message resource transfers .......................14 73 5.2 End-to-end vs hop-by-hop negotiations ................14 74 5.3 Third-party negotiation ..............................15 75 5.4 Use of generic directory and resulution services .....15 76 5.5 Billing issues .......................................15 77 5.6 Performance considerations ...........................15 78 5.7 Confidence levels in negotiated options ..............16 79 6. Security considerations..................................16 80 6.1 Privacy ..............................................17 81 6.2 Denial of service attacks ............................17 82 6.3 Mailing list interactions ............................17 83 6.4 Use of security services .............................17 84 6.5 Disclosure of security weaknesses ....................18 85 6.5.1 User agent identification........................18 86 6.5.2 Macro viruses....................................18 87 6.5.3 Personal vulnerability...........................18 88 6.6 Problems of negotiating security .....................18 89 7. Full copyright statement.................................19 90 8. Acknowledgements.........................................19 91 9. References...............................................19 92 10. Author's address........................................21 93 Appendix A: Amendment history...............................21 94 Internet draft Protocol-independent content negotiation framework 95 16 February 1999 97 1. Introduction 99 A number of Internet application protocols have a need to provide 100 content negotiation for the resources with which they interact. 101 While MIME media types [1, 2] provide a standard method for 102 handling one major axis of variation, resources also vary in ways 103 which cannot be expressed using currently available MIME headers. 104 The case for a cross-protocol negotiation framework is set out in 105 "Scenarios for the Delivery of Negotiated Content" [4]. 107 This memo sets out terminology, a framework and some goals for a 108 protocol-independent content negotiation framework, and identifies 109 some technical issues which may need to be addressed. 111 The framework does not attempt to specify the content negotiation 112 process; rather it gives an indication of the anticipated scope 113 and form of any such specifications. 115 The statement of goals is intended to set out the desired 116 properties of a content negotiation framework, while trying to 117 avoid any assumption of the form that framework may take. 119 1.1 Structure of this document 121 The main part of this draft addresses four main areas: 123 Section 2 defines some of the terms which are used with special 124 meaning. 126 Section 3 outlines a proposed framework for describing protocol- 127 independent content negotiation. 129 Section 4 describes various goals for content negotiation. 131 Section 5 discusses some of the technical issues which are raised 132 by this document, with cross-references to other work where 133 appropriate. 135 1.2 Discussion of this document 137 Discussion of this document should take place on the content 138 negotiation and media feature registration mailing list hosted by 139 the Internet Mail Consortium (IMC). 141 Please send comments regarding this document to: 143 ietf-medfree@imc.org 145 To subscribe to this list, send a message with the body 'subscribe' 146 to "ietf-medfree-request@imc.org". 148 Internet draft Protocol-independent content negotiation framework 149 16 February 1999 151 To see what has gone on before you subscribed, please see the 152 mailing list archive at: 154 http://www.imc.org/ietf-medfree/ 156 2. Terminology and definitions 158 This section introduces a number of terms which are used with 159 specific meaning in the content negotiation drafts. Many of these 160 have been copied and adapted from [5]. 162 The terms are listed in alphabetical order. 164 Capability 165 An attribute of a sender or receiver (often the receiver) 166 which indicates an ability to generate or process a 167 particular type of message content. 169 Characteristic 170 Some description of a sender or receiver which indicates 171 a possible capability or preference. 173 Choice message 174 A choice message returns a representation of some 175 selected variant or variants, together with the variant 176 list of the negotiable resource. It can be generated when 177 the sender has sufficient information to select a variant 178 for the receiver, and also requires to inform the 179 receiver about the other variants available. 181 Connected mode 182 A mode of operation in which sender and receiver are 183 directly connected, and hence are not prevented from 184 definitively determining each other's capabilities. 185 (See also: Session mode) 187 Content feature 188 (see Feature) 190 Content negotiation 191 An exchange of information (negotiation metadata) which 192 leads to selection of the appropriate representation 193 (variant) when transferring a data resource. 195 Internet draft Protocol-independent content negotiation framework 196 16 February 1999 198 Data resource 199 A network data object that can be transferred. Data 200 resources may be available in multiple representations 201 (e.g. multiple languages, data formats, size, 202 resolutions) or vary in other ways. 203 (See also: Message, Resource) 205 Feature A piece of information about the media handling 206 properties of a message passing system component or of a 207 data resource. 209 Feature tag 210 A name that identifies a "feature". 212 Feature set 213 Information about a sender, recipient, data file or other 214 participant in a message transfer which describes the set 215 of features that it can handle. 217 Where a 'feature' describes a single identified attribute 218 of a resource, a 'feature set' describes full set of 219 possible attributes. 221 List message 222 A list message sends the variant list of a negotiable 223 resource, but no variant data. It can be generated when 224 the sender does not want to, or is not allowed to, send a 225 particular variant. 227 Media feature 228 information that indicates facilities assumed to be 229 available for the message content to be properly rendered 230 or otherwise presented. Media features are not intended 231 to include information that affects message transmission. 233 Message Data which is transmitted from a sender to a receiver, 234 together with any encapsulation which may be applied. 235 Where a data resource is the original data which may be 236 available in a number of representations, a message 237 contains those representation(s) which are actually 238 transmitted. Negotiation metadata is not generally 239 considered to be part of a message. 241 Message data is distinguished from other transmitted data 242 by the fact that its content is fully determined before 243 the start of transmission. 245 Negotiated content 246 Message content which has been selected by content 247 negotiation. 249 Internet draft Protocol-independent content negotiation framework 250 16 February 1999 252 Negotiation 253 (See: content negotiation) 255 Negotiable resource 256 A data resource which has multiple representations 257 (variants) associated with it. Selection of an 258 appropriate variant for transmission in a message is 259 accomplished by content negotiation between the sender 260 and recipient. 262 Negotiation metadata 263 Information which is exchanged between the sender and 264 receiver of a message by content negotiation in order to 265 determine the variant which should be transferred. 267 Neighbouring variant 268 A particular representation (variant) of a variant 269 resource which can safely be assumed to be subject to the 270 same access controls as the variant resource itself. Not 271 all variants of a given variant resource are necessarily 272 neighbouring variants. The fact that a particular variant 273 is or is not a neighbouring variant has implications for 274 security considerations when determining whether that 275 variant can be sent to a receiver in place of the 276 corresponding variant resource. It may also have 277 implications when determining whether or not a sender is 278 authorized to transmit a particular variant. 280 Preference 281 An attribute of a sender or receiver (often the receiver) 282 which indicates an preference to generate or process one 283 particular type of message content over another, even if 284 both are possible. 286 Receiver A system component (device or program) which receives a 287 message. 289 Receiver-initiated transmission 290 A message transmission which is requested by the eventual 291 receiver of the message. Sometimes described as 'pull' 292 messaging. E.g. an HTTP GET operation. 294 Resource a document, data file or facility which is accessed or 295 transmitted across a network. 296 (See also: Data resource) 298 Sender A system component (device or program) which transmits a 299 message. 301 Internet draft Protocol-independent content negotiation framework 302 16 February 1999 304 Sender-initiated transmission 305 A message transmission which is invoked by the sender of 306 the message. Sometimes described as 'push' messaging. 307 E.g. sending an e-mail. 309 Session mode 310 A mode of message transmission in which confirmation of 311 message delivery is received by the sender in the same 312 application session (usually the same transport 313 connection) that is used to transmit the message. 314 (See also: connected mode, store and forward mode) 316 Store and forward mode 317 A mode of message transmission in which the message is 318 held in storage for an unknown period of time on message 319 transfer agents before being delivered. 321 Transmission 322 The process of transferring a message from a sender t a 323 receiver. This may include content negotiation. 325 User agent 326 A system component which prepares and transmits a 327 message, or receives a message and displays, prints or 328 otherwise processes its contents. 330 Variant One of several possible representations of a data 331 resource. 333 Variant list 334 A list containing variant descriptions, which can be 335 bound to a negotiable resource. 337 Variant description 338 A machine-readable description of a variant resource, 339 usually found in a variant list. A variant description 340 contains a variant resource identifier and various 341 attributes which describe properties of the variant. 343 Variant resource 344 A data resource for which multiple representations 345 (variants) are available. 347 Internet draft Protocol-independent content negotiation framework 348 16 February 1999 350 3. Framework 352 For the purposes of this document, message transmission protocol 353 capabilities are explicitly disregarded: it is presumed that these 354 will be dealt with separately by some orthogonal mechanism. 356 Content negotiation covers three elements: 358 1. expressing the capabilities of the sender and the data resource 359 to be transmitted (as far as a particular message is concerned), 361 2. expressing the capabilities of a receiver (in advance of the 362 transmission of the message), and 364 3. a protocol by which capabilities are exchanged. 366 These negotiation elements are addressed by a negotiation framework 367 incorporating a number of design elements with dependencies shown: 369 [ Abstract ] [ Abstract ] 370 [negotiation] [ negotiation ] 371 [ process ] [ metadata ] 372 | | 373 V V 374 [Negotiation] [ Negotiation ] 375 [ protocol ] [ metadata ] 376 [ binding ] [representation] 377 | | 378 ------- ------- 379 | | 380 V V 381 [Application protocol] 382 [ incorporating ] 383 [content negotiation ] 385 Within this overall framework, expressing the capabilities of 386 sender and receiver is covered by negotiation metadata. The 387 protocol for exchanging capabilities is covered by the abstract 388 negotiation framework and its binding to a specific application 389 protocol. 391 Application protocol independence is addressed by separating the 392 abstract negotiation process and metadata from concrete 393 representations and protocol bindings. 395 3.1 Abstract framework for content negotiation 397 The negotiation framework provides for an exchange of negotiation 398 metadata between the sender and receiver of a message which leads 399 to determination of a data format which the sender can provide and 401 Internet draft Protocol-independent content negotiation framework 402 16 February 1999 404 the recipient can process. Thus, there are three main elements 405 which are the subjects of the negotiation process and whose 406 capabilities are described by the negotiation metadata: the sender, 407 the transmitted data file format and the receiver. 409 The life of a data resource may be viewed as: 411 (C) (T) (F) 412 [A]-->--[S]-->--[R]-->--[U] 414 where: 416 [A] = author of document 417 (C) = original document content 418 [S] = message sending system 419 (T) = transmitted data file (representation of (C)) 420 [R] = receiving system 421 (F) = formatted (rendered) document data (presentation of (C)) 422 [U] = user or consumer of a document 424 Here, it is [S] and [R] who exchange negotiation metadata to decide 425 the form of (T), so these elements are the focus of our attention. 427 Negotiation metadata provided by [S] would take account of 428 available document content (C) (e.g. availability of resource 429 variants) as well as its own possible ability to offer that content 430 in a variety of formats. 432 Negotiation metadata provided by [R] would similarly take account 433 of the needs and preferences of its user [U] as well as its own 434 capabilities to process and render received data. 436 3.1.1 The negotiation process 438 Negotiation between the sender [S] and the receiver [R] consists of 439 a series of negotiation metadata exchanges that proceeds until 440 either party determines a specific data file (T) to be transmitted. 441 If the sender makes the final determination, it can send the file 442 directly. Otherwise the receiver must communicate its selection to 443 the sender who sends the indicated file. 445 This process implies an open-ended exchange of information between 446 sender and receiver. Not every implementation is expected to 447 implement this scheme with the full generality thus implied. 448 Rather, it is expected that every concrete negotiation can be 449 viewed as a subset of this process. 451 Internet draft Protocol-independent content negotiation framework 452 16 February 1999 454 For example, Transparent Content Negotiation (TCN) [5] uses a model 455 in which one of the following happens: 457 o The recipient requests a resource with no variants, in which case 458 the sender simply sends what is available. 460 o A variant resource is requested, in which case the server replies 461 with a list of available variants, and the client chooses one 462 variant from those offered. 464 o The recipient requests a variant resource, and also provides 465 negotiation metadata (in the form 'Accept' headers) which allows 466 the server to make a choice on the client's behalf. 468 Another, simpler example is that of fax negotiation: in this case 469 the intended recipient declares its capabilities, and the sender 470 chooses a message variant to match. 472 Each of these can be viewed as a particular case of the general 473 negotiation process described above. Similar observations can be 474 made regarding the use of directory services or MIME 475 'Multipart/alternate' in conjunction with e-mail message 476 transmission. 478 3.2 Abstract model for negotiation metadata 480 A simple but general negotiation framework has been described, 481 which is based on the exchange of negotiation metadata between 482 sender and recipient. The mechanism by which data is exchanged is 483 not important to the abstract negotiation framework, but something 484 does need to be said about the general form of the metadata. 486 The terminology and definitions section of this document places 487 constraints on the form of negotiation metadata, and the 488 descriptions that follow should be read in conjunction with the 489 definitions to which they refer. 491 Negotiation metadata needs to encompass the following elements: 493 o Media feature: a way to describe attributes of a data resource. 495 o Feature set: a description of a range of possible media feature 496 combinations which can be: offered by a sender; represented by 497 a data file format; or processed by a receiver. 499 o One or more naming schemes for labelling media features and 500 feature sets. These should be backed up by some kind of 501 registration process to ensure uniqueness of names and to 502 encourage a common vocabulary for commonly used features. 504 Internet draft Protocol-independent content negotiation framework 505 16 February 1999 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 3.5 Protocol binding guidelines 550 Specific protocol bindings will be needed to use the abstract 551 framework for negotiation. 553 Details of protocol bindings would be beyond the scope of this 554 work, but guidelines maybe not. (SASL might provide a useful model 555 here.) 557 Internet draft Protocol-independent content negotiation framework 558 16 February 1999 560 4. Goals 562 These goals are presented in two categories: 564 1. Negotiation framework and metadata requirements which address the 565 broad goals of negotiation in a protocol-independent fashion. 567 2. Specific requirements which relate to the deployment of 568 negotiation in the context of a specific protocol (e.g. relation 569 to HTTP protocol operations, cache interactions, security issues, 570 existing HTTP negotiation mechanisms, application to variant 571 selection, etc.). These would be addressed by a specific 572 protocol binding for the negotiation framework. 574 4.1 Generic framework and metadata requirements 576 o A common vocabulary for designating features and feature sets. 578 o A stable reference for commonly used features. 580 o An extensible framework, to allow rapid and easy adoption of new 581 features. 583 o Permit an indication of quality or preference. 585 o Capture dependencies between feature values 587 o A uniform framework mechanism for exchanging negotiation metadata 588 should be defined that can encompass existing negotiable features 589 and is extensible to future (unanticipated) features. 591 o Efficient negotiation should be possible in both receiver 592 initiated ('pull') and sender initiated ('push') message 593 transfers. 595 o The structure of the negotiation procedure framework should stand 596 independently of any particular message transfer protocol. 598 o Be capable of addressing the role of content negotiation in 599 fulfilling the communication needs of less able computer users. 601 4.2 Protocol-specific deployment requirements 603 o A negotiation should generally result in identification of a 604 mutually acceptable form of message data to be transferred. 606 o If capabilities are being sent at times other than the time of 607 message transmission, then they should include sufficient 608 information to allow them to be verified and authenticated. 610 Internet draft Protocol-independent content negotiation framework 611 16 February 1999 613 o A capability assertion should clearly identify the party to whom 614 the capabilities apply, the party to whom they are being sent, 615 and some indication of their date/time or range of validity. To 616 be secure, capability assertions should be protected against 617 interception and substitution of valid data by invalid data. 619 o A request for capability information, if sent other than in 620 response to delivery of a message, should clearly identify the 621 requester, the party whose capabilities are being requested, and 622 the time of the request. It should include sufficient 623 information to allow the request to be authenticated. 625 o In the context of a given application, content negotiation may 626 use one or several methods for transmission, storage, or 627 distribution of capabilities. 629 o The negotiation mechanism should include a standardized method 630 for associating features with resource variants. 632 o Negotiation should provide a way to indicate provider and 633 recipient preferences for specific features. 635 o Negotiation should have the minimum possible impact on network 636 resource consumption, particularly in terms of bandwidth and 637 number of protocol round-trips required. 639 o Systems should protect the privacy of users' profiles and 640 providers' inventories of variants. 642 o Protocol specifications should identify and permit mechanisms to 643 verify the reasonable accuracy of any capability data provided. 645 o Negotiation must not significantly jeopardize the overall 646 operation or integrity of any system in the face of erroneous 647 capability data, whether accidentally or maliciously provided. 649 o Intelligent gateways, proxies, or caches should be allowed to 650 participate in the negotiation. 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 Internet draft Protocol-independent content negotiation framework 660 16 February 1999 662 5. Technical issues 664 5.1 Non-message resource transfers 666 The ideas for generic content negotiation have been conceived and 667 developed in the context of message-oriented data transmissions. 669 Message data is defined elsewhere as a data whose entire content is 670 decided before the start of data transmission. The following are 671 examples of non-message data transfers. 673 o streamed data, 675 o interactive computations, 677 o real-time data acquisition, 679 Does a proposed approach to negotiation based on message data 680 reasonably extend to streamed data (e.g. data whose content is not 681 fully determined by the time the first data items are transmitted)? 683 It may be that the metadata will be applicable, but the abstract 684 negotiation process framework may be insufficient to these more 685 demanding circumstances. 687 5.2 End-to-end vs hop-by-hop negotiations 689 Could this distinction place any special demands or constraints on 690 a generic negotiation framework, or is this simply a protocol 691 issue? 693 o End-to-end negotiation gives greatest confidence in the outcome. 695 o Hop-by-hop may have advantages in a network of occasionally- 696 connected systems, but will place additional demands on 697 intervening message transmission agents. 699 Hop-by-hop negotiation implies that negotiation responses are not 700 necessarily a definitive indication of an endpoint system's 701 capabilities. This in turn implies a possible need for time-to- 702 live and re-verification mechanisms to flush out stale negotiation 703 data. 705 Note that one of the stated goals is to allow proxies and caches to 706 participate in the negotiation process, as appropriate. 708 Internet draft Protocol-independent content negotiation framework 709 16 February 1999 711 5.3 Third-party negotiation 713 An extension of the hop-by-hop vs. end-to-end negotiation theme is 714 to consider the implications of allowing any system other than an 715 endpoint participant in the message transmission to supply 716 negotiation metadata. 718 Any use of a third party in the negotiation process inevitably 719 increases the possibilities for introducing errors into the 720 negotiation metadata. 722 One particular example of a third party participant in a 723 negotiation process that is frequently suggested is the use of a 724 directory service using LDAP or similar protocols. What additional 725 steps need to be taken to ensure reasonable reliability of 726 negotiation metadata supplied by this means? 728 5.4 Use of generic directory and resulution services 730 It is clearly helful to use existing protocols such as LDAP to 731 exchange content negotiation metadata. 733 To achieve this, it be necessary to define directory or other 734 schema schema elements which are specific to content negotiation. 735 For example, an LDAP attribute type for a media feature set. 737 5.5 Billing issues 739 Negotiation may raise some billing-related issues in some contexts 740 because it potentially incurs a two-way exchange of data not 741 necessarily completed during a single connection. There is an 742 issue of who pays for return messages, etc., in a non-connected 743 environment like e-mail or fax. 745 The Internet Draft "Extensions to Delivery Status Notifications for 746 Fax" [6], and others, raise issues in this area. 748 5.6 Performance considerations 750 Negotiation can impact performance in both positive and negative 751 ways. 753 The obvious negative impact arises from the exchange of additional 754 data which necessarily consumes some additional bandwidth. There 755 is also an issue of round-trip or third-party query delays while 756 negotiation metadata is being exchanged before transmission of the 757 message itself is commenced. 759 Internet draft Protocol-independent content negotiation framework 760 16 February 1999 762 Over the Internet, there are some bandwidth/latency trade-offs 763 which can be made. For example, in Internet e-mail the MIME type 764 'multipart/alternate' can be used to send multiple versions of a 765 resource: this preserves latency by using additional bandwidth to 766 send a greater volume of data. On the other hand, HTTP [7] 767 suggests a negotiation mechanism which preserves bandwidth at the 768 cost of introducing a round-trip delay (section 12.2, Agent-driven 769 negotiation). 771 To set against the negative performance impact of content 772 negotiation, it is to be hoped that overall network efficiency is 773 to be improved if it results in the most useful data format being 774 delivered to its intended recipient, first time, almost every time. 776 5.7 Confidence levels in negotiated options 778 In some cases (e.g. when there has been a direct exchange of 779 information with the remote system) the communicating parties will 780 have a high degree of confidence in the outcome of a negotiation. 781 Here, a data exchange can be performed without need for subsequent 782 confirmation that the options used were acceptable. 784 In other cases, the options will be a best-guess, and it may be 785 necessary to make provision for parties to reject the options 786 actually used in preference for some other set. 788 This consideration is likely to interact with performance 789 considerations. 791 A useful pattern, adopted by TCN [5], is to define a negotiation 792 procedure which guarantees a correct outcome. This forms the 793 foundation for a procedure which attempts to use easily-obtained 794 but less reliable information in an attempt to optimize the 795 negotiation process but that contains checks to guarantee the final 796 result will be the same as would have been obtained by the full 797 negotiation procedure. Such procedures sometimes have to resort to 798 the original "full cycle" negotiation procedure, but in a majority 799 of cases are expected to reach their conclusion by an optimized 800 route. 802 6. Security considerations 804 The purposes of this section is to identify and catalogue some 805 security issues that feature negotiation protocols should consider. 807 Internet draft Protocol-independent content negotiation framework 808 16 February 1999 810 6.1 Privacy 812 Privacy may be adversely affected by: 814 o Unintended disclosure of personal information. 816 o Spoofed requests for negotiation data simply for the purposes of 817 gathering information, and not as part of a bona fide message 818 transmission. 820 6.2 Denial of service attacks 822 Service denial may be caused by: 824 o Injection of false negotiation data. 826 o Excessive requests for negotiation data 828 6.3 Mailing list interactions 830 Content negotiation with final recipients is somewhat at odds with 831 normal practice for maintaining lists for redistribution of 832 Internet mail. 834 It may be appropriate for a sender to negotiate data formats with a 835 list manager, and for a list manager to negotiate with message 836 recipients. But the common practice of keeping confidential the 837 identities and addresses of mailing list subscribers suggests that 838 end-to-end negotiatian through a mailing list is not consistent 839 with good security practice. 841 6.4 Use of security services 843 Protocols that employ security services for message transfer should 844 also apply those services to content negotiation: 846 o Authenticated requests for negotiation metadata provide a means 847 for a potential recipient to moderate the distribution of media 848 capability information. 850 o Authentication of negotiation metadata provides a means for 851 potential message senders to avoid using incorrect information 852 injected by some other party. 854 o Encryption of negoitiation data may help to prevent disclosure of 855 sensitive capability-related information to snoopers. 857 Internet draft Protocol-independent content negotiation framework 858 16 February 1999 860 o Conducting a negotiation exchange over an authenticated or 861 encrypted protocol session (e.g. SASL), transport connection or 862 network path (e.g. TLS, IPSEC) can provide for mutual 863 authentication of both parties in an exchange of negotiation 864 data. 866 6.5 Disclosure of security weaknesses 868 6.5.1 User agent identification 870 Disclosure of capability information may allow a potential attacker 871 to deduce what message handling agent is used, and hence may lead 872 to the exploitation of known security weaknesses in that agent. 874 6.5.2 Macro viruses 876 Macro viruses are a widespread problem among applications such as 877 word processors and spreadsheets. Knowing which applications a 878 recipient employs (e.g. by file format) may assist in a malicious 879 attack. However, such viruses can be spread easily without such 880 knowledge by sending multiple messages, where each message infects 881 a specific application version. 883 6.5.3 Personal vulnerability 885 One application of content negotiation is to enable the delivery of 886 message content that meets specific requirements of less able 887 people. Disclosure of this information may make such people 888 potential targets for attacks that play on their personal 889 vulnerabilities. 891 6.6 Problems of negotiating security 893 If feature negotiation is used to decide upon security-related 894 features to be used, some special problems may be created if the 895 negotiation procedure can be subverted to prevent the selection of 896 effective security procedures. 898 The security considerations section of GSS-API negotiation [8] 899 discusses the use of integrity protecting mechanisms with security 900 negotiation 902 Internet draft Protocol-independent content negotiation framework 903 16 February 1999 905 7. Full copyright statement 907 Copyright (C) The Internet Society 1999. All Rights Reserved. 909 This document and translations of it may be copied and furnished to 910 others, and derivative works that comment on or otherwise explain 911 it or assist in its implementation may be prepared, copied, 912 published and distributed, in whole or in part, without restriction 913 of any kind, provided that the above copyright notice and this 914 paragraph are included on all such copies and derivative works. 915 However, this document itself may not be modified in any way, such 916 as by removing the copyright notice or references to the Internet 917 Society or other Internet organizations, except as needed for the 918 purpose of developing Internet standards in which case the 919 procedures for copyrights defined in the Internet Standards process 920 must be followed, or as required to translate it into languages 921 other than English. 923 The limited permissions granted above are perpetual and will not be 924 revoked by the Internet Society or its successors or assigns. 926 This document and the information contained herein is provided on 927 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 928 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 929 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 930 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 931 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 933 8. Acknowledgements 935 Some material in this draft has been derived from earlier memos by 936 Koen Holtman, Andrew Mutz, Ted Hardie, Larry Masinter, Dan Wing, 937 Neil Joffe. Matters relating to the importance and relevance of 938 content negotiation to less-able users were raised by Al Gilman. 940 This draft has also been informed by the debates of the IETF 941 'conneg' working group. 943 9. References 945 [1] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 946 Part 1: Format of Internet message bodies" 947 N. Freed, Innosoft 948 N. Borenstein, First Virtual 949 November 1996. 951 Internet draft Protocol-independent content negotiation framework 952 16 February 1999 954 [2] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 955 Part 2: Media types" 956 N. Freed, Innosoft 957 N. Borenstein, First Virtual 958 November 1996. 960 [3] "The Alternates Header Field" 961 K. Holtman, TUE, 962 et al. 963 Internet draft: 964 Work in progress, November 1997. 966 [4] "Scenarios for the Delivery of Negotiated Content" 967 T. Hardie, NASA Network Information Center 968 Internet draft: 969 Work in progress, November 1997. 971 [5] RFC 2295, "Transparent Content Negotiation in HTTP" 972 Koen Holtman, TUE 973 Andrew Mutz, Hewlett Packard 974 March 1998. 976 [6] "Extensions to Delivery Status Notifications for Fax" 977 Dan Wing, Cisco Systems 978 Internet draft: 979 Work in progress, November 1997. 981 [7] RFC 2068, "Hyptertext Transfer Protocol -- HTTP/1.1" 982 R. Fielding, UC Irvine 983 J. Gettys, 984 J. Mogul, DEC 985 H. Frytyk, 986 T. Berners-Lee, MIT/LCS 987 January 1997. 989 [8] "The Simple and Protected GSS-API Negotiation Mechanism" 990 Eric Blaize, 991 Denis Pinkas, Bull 992 Internet draft: 993 Work in progress: March 1998. 995 Internet draft Protocol-independent content negotiation framework 996 16 February 1999 998 10. Author's address 1000 Graham Klyne 1001 5th Generation Messaging Ltd. Content Technologies Ltd. 1002 5 Watlington Street Forum 1, Station Road 1003 Nettlebed Theale 1004 Henley-on-Thames, RG9 5AB Reading, RG7 4RA 1005 United Kingdom United Kingdom. 1006 Telephone: +44 1491 641 641 +44 118 930 1300 1007 Facsimile: +44 1491 641 611 +44 118 930 1301 1008 E-mail: GK@ACM.ORG 1010 Appendix A: Amendment history 1012 00a 06-Dec-1997 1013 Document initially created. 1015 00b 07-Dec-1997 1016 Added definition of "transmission". 1017 Copied and adapted requirements from Internet fax 1018 requirements draft. Updated framework with details from 1019 Internet fax requirements draft. 1021 00c 27-Feb-1998 1022 Update mailing list details. 1023 Updated terminology entries, particularly to distinguish 1024 between a feature and a feature set. 1025 Fleshed out the abstract framework sections. 1026 Added more requirements, and reorganized that section. 1027 Written up technical issues, as identified so far. 1029 01a 10-Mar-1998 1030 Added more text and headings to security considerations. 1031 Spell-checked (!). 1033 01b 16-Feb-1999 1034 New Internet draft boilerplate in 'status' preface. Move 1035 amendment history to appendix. Changed from document 1036 title. Tidied up sections dealing with goals, technical 1037 issues, security considerations and acknowledgements. 1038 Updated some references.