Forwarded message 1
1. Introduction
2. References
3. The nature of negotiation
4. A survey of negotiable features
5. Toward a model for negotiation
6. Acknowledgement
1. Introduction
I have recently read some proposals related to negotiation, and this note
is my attempt to draw together some of the resulting ideas.
My goal is not to try and promote or denigrate any particular negotiation
protocol, but to try and build a model of the fundamental purpose and
structure of negotiation, against which specific schemes might be assessed
or a specific set of requirements drawn up.
2. References
[1] RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1
[2] Internet draft <draft-ietf-http-negotiation-02.txt>
[3] Internet draft <draft-mutz-http-attributes-02.txt>
[4] To-be-published internet draft <draft-ietf-fax-transport-XX.txt>
(previously circulated to this mailing list).
[5] RFC 821: Simple Mail Transfer Protocol
[6] RFC 1651: SMTP Service Extensions
[7] RFC 1652: SMPT Service for 8bit-MIMEtransport
3. The nature of negotiation
In the context of this note, negotiation is a process where the sender and
intended recipient of a message exchange information to determine the form
in which the message should be transferred.
This information takes into account a variety of possibilities, including
(but not limited to):
(a) the type of message data to be sent
(b) the capabilities of the message transfer path
(c) the capabilities of the intended recipient of the message
(d) user preferences regarding quality and transmission "costs" for the
message
The ultimate goal of negotiation is to ensure that the intended recipient
receives the message in a form which is useful to him. Where several
useful forms are available, the negotiation process MAY attempt to choose
one which is in some sense best (recognizing that it might not be best in
all senses).
4. A survey of negotiable features
>From my reading of the cited references, and other sources, I have noted
the following negotiable attributes of a message transfer:
- file format (MIME content-type)
- character set (sometimes subsumed by file format, but separated in [2])
- language (the natural language of an intended recipient)
- encoding (from [1], refers to content encoding (e.g. compression) rather
than transfer encoding (e.g. base64)).
- authorization (theoretically negotiable in [1])
- identity of person making a request (theoretically negotiable in [1])
- identity of server to which request is directed (theoretically in [1])
- date of last modification (from [1]: if-modified-since, if-unmodified-since)
- difference from some other resource [or message content] (from [1]:
if-match, if-none-match, if-range).
- number of intervening proxies or gateways (theoretically negotiable in [1])
- requested sub-range of data
- resource identitifier of referrer (theoretically negotiable in [1])
- product identification of the receiving user agent (from [1]).
- colour vs monochrome capability
- colour or grey-scale depth
- paper size and orientation
- display (or printer) resolution
- use of compession, and algorithm used
- use of authenticiation, and scheme used
- use of encryption, and scheme used
- user preferences (interactively gathered)
- are capabilities supplied authoritative? (from a later version of [4])
- is feature negotiation available? (from [6])
- message transmission modes available (e.g. from [5,6]: TURN, SEND, etc)
- can recipient information be provided? (e.g. from [5,6]: EXPN)
- acceptable transfer modes (e.g. from [7]: 8bit-MIMEtransport)
I cannot claim this list is exhaustive, but I hope it gives a reasonably
broad view of the range of features which may be subject to negotiation.
Much of the surveyed work on negotiation is concerned with a 'pull' model
for message transfer -- the World Wide Web and HTTP. The IETF-FAX WG is
currently focused on a 'push' model, but I believe that 'pull' model issues
should not be ignored because there are future possibilities such as fax
polling to be considered.
5. Towards a model for negotiation
I find that the idea of a generic negotiable "feature" introduced by [2] is
very useful. The items listed above are examples of possible "feature"s.
[2] also identifies "4 dimensions" of negotiation:
(1) MIME content type
(2) character set
(3) language
(4) features
I find these 4 dimensions are unsatisfying as the basis for a generic model
in that they seem to be defined more by accident of history than some
fundamental distinction. I would argue that dimensions (1)-(3) could
readily be subsumed by (4); the authors of this draft claim that new
dimensions of negotiation can be added as sub-dimensions of (4).
To achieve a 'useful' transfer it is necessary to identify a form of
message which:
(a) can be generated by the sending agent,
(b) can be carried by the transmission path, and
(c) can be rendered (displayed, printed, played, etc.) by the receiving agent.
Further, we wish to:
(d) minimize the loss of information and/or maximize the use of the
recipient's rendering capabilities
(e) take account of user preferences with regard to transmission costs and
quality of the transferred data.
An imperative is to identify a set of "features" which satisfy (a)-(c).
Where there is more than one such set of features, we wish to select a
particular set which in some sense optimizes (d) and (e).
I think the only feature which significantly impacts (b) is the content
transfer encoding. This is taken care of by existing the SMTP protocol and
extensions to it [5,6,7,et al], and can be treated pretty much orthogonally
to the other features.
This leaves (a) and (c) to be satisfied. Simplistic solutions would be to
have one party to announce a supported feature set and the other to take
their pick. Experience with HTTP suggests this is not very scalable (at
least with respect to recipient announcement of capabilities, according to
[2]).
A more scalable approach might be for either party to announce a small
number of supported features (or non-supported features) to reduce the
feature set that the other party would need to offer. This is essentially
the approach proposed by [2], and with some refinements that proposal aims
to achieve many if not most transfers without the delay of a two-way
negotiation.
To reduce round-trip delays, it seems reasonable for the party making the
first contact to make the initial offering: in the case of 'pull'
messaging this would be the recipient (and this approach is described in
[2]); in the case of 'push' messaging this would be the sender, but I am
not aware of a currently deployed system which does this and I note that
current fax and ESMTP have the recipient announce capabilities.
This leaves the question of what features would be best announced by which
party? I don't have a ready-made answer, and I think this message is
already long enough, so I'll leave it as "an exercise for the reader" ;-).
(I plan to proceed by reviewing the list of negotiable features and making
a judgement as to how the total volume of negotiation traffic might be
reduced.)
6. Acknowledgement
My thanks to Larry Masinter for pointing out to me that negotiation is
about far more than just file formats.
------------
Graham Klyne
GK@ACM.ORG