rfc2703.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   o  interactive computations,

   o  real-time data acquisition,

   Does a proposed approach to negotiation based on message data
   reasonably extend to streamed data (e.g. data whose content is not
   fully determined by the time the first data items are transmitted)?

   It may be that the metadata will be applicable, but the abstract
   negotiation process framework may be insufficient to these more
   demanding circumstances.

5.2 End-to-end vs hop-by-hop negotiations

   Could this distinction place any special demands or constraints on a
   generic negotiation framework, or is this simply a protocol issue?

   o  End-to-end negotiation gives greatest confidence in the outcome.

   o  Hop-by-hop may have advantages in a network of occasionally-
      connected systems, but will place additional demands on
      intervening message transmission agents.

   Hop-by-hop negotiation implies that negotiation responses are not
   necessarily a definitive indication of an endpoint system's
   capabilities.  This in turn implies a possible need for time-to-live
   and re-verification mechanisms to flush out stale negotiation data.

   Note that one of the stated goals is to allow proxies and caches to
   participate in the negotiation process, as appropriate.





Klyne                        Informational                     [Page 14]

RFC 2703        Protocol-independent Content Negotiation  September 1999


5.3 Third-party negotiation

   An extension of the hop-by-hop vs. end-to-end negotiation theme is to
   consider the implications of allowing any system other than an
   endpoint participant in the message transmission to supply
   negotiation metadata.

   Any use of a third party in the negotiation process inevitably
   increases the possibilities for introducing errors into the
   negotiation metadata.

   One particular example of a third party participant in a negotiation
   process that is frequently suggested is the use of a directory
   service using LDAP or similar protocols.  What additional steps need
   to be taken to ensure reasonable reliability of negotiation metadata
   supplied by this means?

5.4 Use of generic directory and resolution services

   It is clearly helpful to use existing protocols such as LDAP to
   exchange content negotiation metadata.

   To achieve this, it be necessary to define directory or other schema
   elements which are specific to content negotiation.  For example, an
   LDAP attribute type for a media feature set.

5.5 Billing issues

   Negotiation may raise some billing-related issues in some contexts
   because it potentially incurs a two-way exchange of data not
   necessarily completed during a single connection.  There is an issue
   of who pays for return messages, etc., in a non-connected environment
   like e-mail or fax.

5.6 Performance considerations

   Negotiation can impact performance in both positive and negative
   ways.

   The obvious negative impact arises from the exchange of additional
   data which necessarily consumes some additional bandwidth.  There is
   also an issue of round-trip or third-party query delays while
   negotiation metadata is being exchanged before transmission of the
   message itself is commenced.

   Over the Internet, there are some bandwidth/latency trade-offs which
   can be made. For example, in Internet e-mail the MIME type '
   multipart/alternative' can be used to send multiple versions of a



Klyne                        Informational                     [Page 15]

RFC 2703        Protocol-independent Content Negotiation  September 1999


   resource:  this preserves latency by using additional bandwidth to
   send a greater volume of data.  On the other hand, HTTP [7] suggests
   a negotiation mechanism which preserves bandwidth at the cost of
   introducing a round-trip delay (section 12.2, Agent-driven
   negotiation).

   To set against the negative performance impact of content
   negotiation, it is to be hoped that overall network efficiency is to
   be improved if it results in the most useful data format being
   delivered to its intended recipient, first time, almost every time.

5.7 Confidence levels in negotiated options

   In some cases (e.g. when there has been a direct exchange of
   information with the remote system) the communicating parties will
   have a high degree of confidence in the outcome of a negotiation.
   Here, a data exchange can be performed without need for subsequent
   confirmation that the options used were acceptable.

   In other cases, the options will be a best-guess, and it may be
   necessary to make provision for parties to reject the options
   actually used in preference for some other set.

   This consideration is likely to interact with performance
   considerations.

   A useful pattern, adopted by TCN [5], is to define a negotiation
   procedure which guarantees a correct outcome.  This forms the
   foundation for a procedure which attempts to use easily-obtained but
   less reliable information in an attempt to optimize the negotiation
   process but that contains checks to guarantee the final result will
   be the same as would have been obtained by the full negotiation
   procedure.  Such procedures sometimes have to resort to the original
   "full cycle" negotiation procedure, but in a majority of cases are
   expected to reach their conclusion by an optimized route.

6. Security Considerations

   The purposes of this section is to identify and catalogue some
   security issues that feature negotiation protocols should consider.

6.1 Privacy

   Privacy may be adversely affected by:

   o  Unintended disclosure of personal information.





Klyne                        Informational                     [Page 16]

RFC 2703        Protocol-independent Content Negotiation  September 1999


   o  Spoofed requests for negotiation data simply for the purposes of
      gathering information, and not as part of a bona fide message
      transmission.

6.2 Denial of service attacks

   Service denial may be caused by:

   o  Injection of false negotiation data.

   o  Excessive requests for negotiation data

6.3 Mailing list interactions

   Content negotiation with final recipients is somewhat at odds with
   normal practice for maintaining lists for redistribution of Internet
   mail.

   It may be appropriate for a sender to negotiate data formats with a
   list manager, and for a list manager to negotiate with message
   recipients.  But the common practice of keeping confidential the
   identities and addresses of mailing list subscribers suggests that
   end-to-end negotiation through a mailing list is not consistent with
   good security practice.

6.4 Use of security services

   Protocols that employ security services for message transfer should
   also apply those services to content negotiation:

   o  Authenticated requests for negotiation metadata provide a means
      for a potential recipient to moderate the distribution of media
      capability information.

   o  Authentication of negotiation metadata provides a means for
      potential message senders to avoid using incorrect information
      injected by some other party.

   o  Encryption of negotiation data may help to prevent disclosure of
      sensitive capability-related information to snoopers.

   o  Conducting a negotiation exchange over an authenticated or
      encrypted protocol session (e.g. SASL), transport connection or
      network path (e.g. TLS, IPSEC) can provide for mutual
      authentication of both parties in an exchange of negotiation data.






Klyne                        Informational                     [Page 17]

RFC 2703        Protocol-independent Content Negotiation  September 1999


6.5 Disclosure of security weaknesses

6.5.1 User agent identification

   Disclosure of capability information may allow a potential attacker
   to deduce what message handling agent is used, and hence may lead to
   the exploitation of known security weaknesses in that agent.

6.5.2 Macro viruses

   Macro viruses are a widespread problem among applications such as
   word processors and spreadsheets.  Knowing which applications a
   recipient employs (e.g. by file format) may assist in a malicious
   attack.  However, such viruses can be spread easily without such
   knowledge by sending multiple messages, where each message infects a
   specific application version.

6.5.3 Personal vulnerability

   One application of content negotiation is to enable the delivery of
   message content that meets specific requirements of less able people.
   Disclosure of this information may make such people potential targets
   for attacks that play on their personal vulnerabilities.

6.6 Problems of negotiating security

   If feature negotiation is used to decide upon security-related
   features to be used, some special problems may be created if the
   negotiation procedure can be subverted to prevent the selection of
   effective security procedures.

   The security considerations section of GSS-API negotiation [8]
   discusses the use of integrity protecting mechanisms with security
   negotiation.

7. Acknowledgements

   Some material in this memo has been derived from earlier memos by
   Koen Holtman, Andrew Mutz, Ted Hardie, Larry Masinter, Dan Wing, Neil
   Joffe.  Matters relating to the importance and relevance of content
   negotiation to less-able users were raised by Al Gilman.

   This memo has also been informed by the debates of the IETF "conneg"
   working group.







Klyne                        Informational                     [Page 18]

RFC 2703        Protocol-independent Content Negotiation  September 1999


8. References

   [1]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part 1: Format of Internet message bodies",
        RFC 2045, November 1996.

   [2]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part 2: Media Types", RFC 2046, November 1996.

   [3]  Holtman, K., et al., "The Alternates Header Field", Work in
        Progress.

   [4]  Hardie, T., "Scenarios for the Delivery of Negotiated Content",
        Work in Progress.

   [5]  Holtman, K. and A. Mutz, "Transparent Content Negotiation in
        HTTP", RFC 2295, March 1998.

   [6]  Wing, D., "Indicating Supported Media Features Using Extensions
        to DSN and MDN", RFC 2530, March 1999.

   [7]  Fielding, R., Gettys, J., Mogul, J., Frytyk, H. and T. Berners-
        Lee, "Hyptertext Transfer Protocol -- HTTP/1.1", RFC 2068,
        January 1997.

   [8]  Blaize, E. and D. Pinkas, "The Simple and Protected GSS-API
        Negotiation Mechanism", RFC 2478, December 1998.

9. Author's Address

   Graham Klyne
   5th Generation Messaging Ltd.  Content Technologies Ltd.
   5 Watlington Street            1220 Parkview, Arlington Business Park
   Nettlebed                      Theale
   Henley-on-Thames, RG9 5AB      Reading, RG7 4SA
   United Kingdom                 United Kingdom.

   Phone: [phone]        [phone]
   Fax:   [phone]        [phone]
   EMail: [e-mail]











Klyne                        Informational                     [Page 19]

RFC 2703        Protocol-independent Content Negotiation  September 1999


10. 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Klyne                        Informational                     [Page 20]