- From: Graham Klyne <GK@dial.pipex.com>
- Date: Wed, 18 Jun 1997 23:01:32 +0100
- To: http-wg@cuckoo.hpl.hp.com
The following message was originally posted to the IETF-FAX discussion
list, and is in some respects cast in terms more relevant to e-mail than
HTTP, but touches on some issues which are under discussion here. I
understand the "ealier posting" referred to in the introduction was
cross-posted here by Larry Masinter.
At the end of this message are some additional thoughts I had since the
original posting to the IETF-FAX list.
GK.
---
1. Introduction
2. Reference
3. Further review of negotiable options
4. A taxonomy of negotiable options
5. More thoughts on the negotiation procedure
1. Introduction
This note is a continuation of my earlier posting about content
negotiation. I have reviewed each entry in the list of negotiable
features, and tried to assess how it might best be handled in a negotiation
procedure.
The analysis is not scientific: I have simply made a judgement about some
aspects of each feature that seemed relevant to me, and tabulated these. I
then try to group the features according to how I think they should be
handled by the negotiation process, and thus offer a tentative taxonomy.
Finally, I offer a couple of additional thoughts about the negotiation
procedure which occurred to me as I was performing the above analysis.
2. References
[1] Internet draft <draft-ietf-http-negotiation-02.txt>
[2] RFC 1641, "Using Unicode with MIME".
3. Further review of negotiable options
Option Send Recv Default Note
------ ---- ---- ------- ----
File format 1-10 1-100 1
Character set 1-10 1-10
Character set encoding 1-4 1-4 Maybe 2
Language 1-20 1-2
Compression scheme/content encoding 1-5 1-5 None
Authentication scheme 0-4 0-4 None
Encryption scheme 0-4 0-4 None
Sender (name/address/ID) 1 No effect 10
Receiver (name/address/ID) 1 No effect 10
Last modified 0-1 0-1 No effect 3
Match some other resource or data 0-1 No effect 4
Number of intervening proxies/gateways 5
Data sub-range 0-n 0-n Send all 6
Referrer 0-1 12
Software or other product Id 0-1 0-1 No effect 7
Grey levels 1-4
Colour depth 1-8
Paper size/orientation 1-10
Display dimension 1-10
Display resolution 1-? 1-10
Authoritative capabilities? 1 1
Can negotiate? 1 1
Transmission modes 8
Recipient information available? 8
Transfer modes 8
User/admin preferences 0-n 0-n implementation 11
User selection from possible options 8,9
Explanation of columns:
Send: is an estimated number of options which may be available to
the sender of a message. Blanks indicate either that no options
would normally be available, or I have no idea.
Recv: is an estimated number of options which may be available to
the receipient of a message.
Default: indicates if, in the absence of a specific offered option there is a
clear default course of action (e.g. no encryption if no scheme
given).
For items with a clear default, the option should not be offered
unless there is a clear desire to override the default (e.g. user has
requested encryption).
Note: see below.
Notes
(1) Assumes that the number of file formats available for sending a
particular file is generally less than the total number of formats
the recipient can handle. The numbers are necessarily approximate.
(2) If no character set encoding is defined it may be possible to simply
pass the characters unchanged. But this cannot apply to multibyte
character sets (e.g. Unicode). It may be more helpful to include
encoding as part of the character set specification (as in [2]).
(3) Assumes at most one date of interest by either party.
(4) Considering the case where recipient asks for data if it is different
from some data the recipient already has.
(5) This is a transmission-path issue, and is presumed to be dealt with in
an orthogonal fashion (as transfer encoding).
(6) Considering: for sender, subranges which have changed; for recipient,
sub-ranges not (yet) received.
(7) Product Id may be taken to imply some profile set of other values.
(8) Items to be dealt with orthogonally (not as part of content negotiation)
(9) User preferences not part of negotiation scheme, but gathered later
if no definitive option is negotiated.
(10) Might have effect, for example, by reference to directory info.
(11) User preferences would include options like speed/cost/quality
trade-offs.
Default preferences are required but may be implementation dependent.
I would presume a preference for maximum quality in the absence of
preferences to the contrary.
(12) Referrer is a WWW concept which is probably not applicable to e-mail
based 'push' messaging.
4. A taxonomy of negotiable options
A: Feature options that should be offered by sender
- Sender (name/address/ID) (generally implicit)
- File format
B: Feature options that should be offered by receiver
- Receiver (name/address/ID) (generally implicit)
- Character set (but there are privacy concerns here)
- Language (but there are privacy concerns here)
- Grey levels
- Colour depth
- Paper size/orientation
- Display dimension
- Display resolution
C: Feature options that should be offered by either party
(i.e. first party to communicate makes first offer)
- Character set encoding
D: Feature options that should be offered by both parties
- Software or other product Id
- Authoritative capabilities?
- Can negotiate?
E: Feature options that may be offered by sender
(otherwise defaulted)
F: Feature options that may be offered by receiver
(otherwise defaulted)
- Match some other resource or data
- Referrer
G: Feature options that may be offered by either party
(otherwise defaulted)
- Last modified
- Data sub-range
- Compression scheme
- Authentication scheme
- Encryption scheme
- User/admin preferences
H: Features that should not be offered for negotiation
(dealt with separately by some orthogonal procedure)
- Number of intervening proxies/gateways
- Transmission modes
- Recipient information available?
- Transfer modes
- User selection from possible options
In doing this analysis, where either party could initiate a feature
negotiation, it has been generally presumed that the party likely to have
fewer options to offer should make the initial offer -- this is to minimize
the volume of negotiation data transfers. Where there is no clear such
party, it is presumed that the party initiating the transaction will make
the initial offer -- this is to minimize round-trip delays in the
negotiation phase.
5. More thoughts on the negotiation procedure
* What is negotiation? For the purposes of this note, negotiation is any
exchange of information between sender and recipient which affects the data
which is subsequently sent.
* The negotiation procedure should be defined as a clear process which
leads to an unambiguous result. (This will generally involve a full
exchange of negotiable features before any data transfer is initiated.)
The full negotiation process may be short-circuited by heuristics provided
it can be shown that the end result is the same as would have been achieved
by a full exchange. This is the general approach adopted by Transparent
Content Negotiation in [1]. The importance of this view is that the
negotiation procedure and heuristics which optimize the data transfers
performed can be dealt with as separate issues.
---------------------------------------------------
End of original posting
---------------------------------------------------
[Later...]
Having reviewed my last two postings on this subject, I have a few
additional thoughts to offer:
I said:
-------
(11) User preferences would include options like speed/cost/quality
trade-offs.
Default preferences are required but may be implementation dependent.
I would presume a preference for maximum quality in the absence of
preferences to the contrary.
I note:
-------
Current Group 3 fax has a preference for speed/cost. That is, all fax
machines I have used do not attempt to use 'fine' or 'super-fine' modes
unless specifically requested.
I said:
-------
In doing this analysis, where either party could initiate a feature
negotiation, it has been generally presumed that the party likely to have
fewer options to offer should make the initial offer -- this is to minimize
the volume of negotiation data transfers. Where there is no clear such
party, it is presumed that the party initiating the transaction will make
the initial offer -- this is to minimize round-trip delays in the
negotiation phase.
I note:
-------
There may be situations in which it is more importamt to minimize
round-trip delays (e.g. store-and-forward e-mail), and others in which it
is more important to reduce traffic volume (e.g. HTTP servers). This
suggests that the preferred course of negotiation for each feature may
depend upon the protocol being used.
I said:
-------
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 note:
-------
In offering a taxonomy of negotiable options, I have not made expilcit any
distinction between features which *must* be matched per (a)-(c) above, and
others which serve to optimize the transfer per (d) and (e).
Question: is it desirable, or even possible, to categorize features in this
way? Or should it be left to the feature-specific matching semantics to
draw these distinctions?
I tend to the latter view. Consider the example of resolution: if a
recipient-resolution is offered which the sender cannot generate, this is a
non-option per (a)-(c); but among the set of resolutions which can be
generated these are quality issues per (d)-(e).
Received on Wednesday, 18 June 1997 15:56:58 UTC