Re: Comments on new conneg draft

Koen writes:
> >Section 2.2:
> That would just define a varying resource.  Transparently negotiable
> resources are those varying resources which use transparent content
> negotiation.  How about this:
> 
>    transparently negotiable resource
> 
>      A resource which allows selection among multiple variants using
>      the transparent content negotiation mechanism.  A transparently
>      negotiable resource always has a variant list bound to it, which
>      can be represented as an Alternates header.
> 

I think it would be useful to include somewhere in the definition that
all of the variants are bound to a single URL; that was the change I
was trying to get into my replacement text.  Obviously that was not
clear; sorry.  I am chiefly worried that this definition might be
cited in other works, and that without the full spec around, it is
less than obvious that this negotiation mechanism works (only) for
resources bound to a single URL.

> >Section 5.3:
> The scale is for value judgments by the service author; end users
> could of course disagree with an `unacceptable' assigned by the
> service author.

> The particular shape of the scale is a result of the properties of
> multiplication of degradation factors; I agree that it does look a
> little strange from an `addition' standpoint to have most information
> in the upper half.  But you can't redesign the scale without also
> reworking the overall quality calculation formulae.
> 
> What about
> 
>      0.499-0.000 severely degraded quality

I like this a lot better.  Thanks for the change.

> >Section 9.6:
> >

> >   The working
> >group has gotten slammed on design points several times for similar
> >things.
> 
> I'm not aware of this.  Was this on the list or only in meetings?

Primarily at the meetings.  


> I don't see how Negotiate: transparent is better design than just
> Negotiate:, Negotiate: has perfectly fine semantics even if there is
> no value in the header field.  I modeled it after Keep-Alive.  Are
> you saying that some people hate such constructs enough that a token
> keyword is needed to keep them happy?  I thought the general trend on
> this list was to resist unnecessary bytes.

The problem occurs once you start adding values.  At the moment Negotiate:
has a single meaning, and there is no semantic difficulty.  Now suppose
that Larry has a stroke of genius one morning and proposes a great new way
to negotiate.  And when we start using Negotiate: Masinter, we will all
know that the Negotiation took place using the new Masinter negotiation
syntax.  But what happens when we want to negotiate using Transparent *and*
Masinter?  If we use Negotiate: Transparent, Masinter, it's dead clear.  If
we use Negotiate: Masinter, it is not clear whether the presence of the
Negotiate: header is enough alone to indicate whether transparent
negotiation is available, or was used.  So having an initial value may
save us from having to add cruft in the form of a later Negotiate-Masinter:
header.

	Thanks again for all your work on this,

					Ted Hardie
					NASA NIC

Received on Monday, 16 September 1996 16:50:52 UTC