W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: Comments on new conneg draft

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 14 Sep 1996 01:35:05 +0200 (MET DST)
Message-Id: <199609132335.BAA14305@wsooti04.win.tue.nl>
To: hardie@nasa.gov
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1572
Ted Hardie:
>Koen, Andrew,
>	I think the new draft is a real improvement over the
>previous versions in readability; thanks for all your work.
>			Regards,
>				Ted Hardie
>				NASA Science Internet


Thanks for your comments.  See below for my comments and questions.

>Section 2.2:
>The current definition of transparently negotiable resource seems
>a bit circular.  How about:
> A resource which allows selection among variable representations,
> all of which are accessed from a single URL.

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.

>Section 4.4:
>I found the use of Vary:* in the example choice response confusing--I
>would suggest constructing an elaborate Vary: header for the example
>to reinforce the relationship between the old Vary: syntax and the new

OK.  Will be in the next version.

> As it is currently written, the
>idea of the Vary: header is introduced without it being awfully clear
>that it is not really part of the proposed system, but a legacy of
>an older one.  Section 10.5.1 clarifies it a bit, but it occurs only
>after the Vary: header is used in a lot of examples.

You are right, the status of the Vary header does need to be discussed
sooner.  It is really only there for compatibility with plain 1.1
clients.  As plain 1.1 clients aren't even deployed yet, I can't add
heuristics on when to construct elaborate vary headers or not.

>Section 5.3:
>I think the choice of "unacceptable degradation" for the 0.499-0.000
>is a little too value laden; in certain conditions people may find
>even severely degraded representations acceptable.

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

>  If the scale is
>really designed that almost half of it represents values which are all
>"unacceptable", then we need to redesign the scale.

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.

>Perhaps 0.499-0.000 could read: increasingly severely degraded

What about

     0.499-0.000 severely degraded quality

>Section 9.6:
>I think the specification should describe at least one
>negotiate-directive if it is going to include the header.

The header is not just a place-holder for the future: its presence
alone means something specific.

>   The working
>group has gotten slammed on design points several times for similar

I'm not aware of this.  Was this on the list or only in meetings?

>  Negotiate: Transparent would be a fine initial value, with a
>note which recognizes that later specifications may extend this value.

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.

>On a related note, in section 11.6, on the construction of short
>requests, you describe how the presence of a Negotiate: header
>affects the interpretation of the Accept: */* and indicate that 
>a Negotiate: header without an Accept: header should be treated
>as if Accept: */* had been sent.

Yes.  This is a rule in the HTTP/1.1 proposed spec:

 |If no Accept header field is present, then it is assumed that the client
 |accepts all media types.

>  I know that it means extra bits
>on the wire, but I believe that we should not encourage this,

The draft never explicitly encourages it, it only points out the

> for
>exactly the same design reasons. Having an absence mean something
>is bad design--and it means Stef will yell at us again at the next

This part of the design follows directly from the 1.1 proposed spec.
People have had the chance to yell about this property of the Accept
headers in 1.1, but chose to forever hold their peace.

I'll see if I can rephrase the example to more directly invoke the 1.1
spec, though.

>Section 12.2
>The first sentence would be clearer if written:
> If the user agent is displaying a variant which is not an embedded or
> inlined object and which is the result of transparent negotiation, 
> the following requirements requirements must be met:


>If some version of the note is finally approved, I would suggest
>ditching the first sentence entirely; it sounds plaintive and
>encourages contention.  I would prefer to include the justifications
>for the requirements in the requirements themselves.  

OK, we'll drop the first sentence try to merge the justifications.

>Section 13.2
>The section seems to say both that transparent negotiation can be used
>only with GET and HEAD and that it can be used with POST, provided
>that the results of the POST are returned in a 303 rather than a 200.

I guess that 13.2 is a little too opaque if you don't follow the
reference.  I'll see if I can be more clear in the next version.

>Section 15.
>If we are justifying requirements in 12.2 with security arguments,
>we should have a pointer here to those arguments.


Received on Friday, 13 September 1996 16:40:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC