Comments on new conneg draft

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


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.


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
negotiation.  I also think that including text on how the old system
works would be worthwhile, even if referenced material contains it; it
think it would make it easier to follow exactly why and when constructing
an elaborate Vary: header is useful. 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.


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.  If the scale is
really designed that almost half of it represents values which are all
"unacceptable", then we need to redesign the scale.

Perhaps 0.499-0.000 could read: increasingly severely degraded
representations?


Section 9.6:

I think the specification should describe at least one
negotiate-directive if it is going to include the header.  The working
group has gotten slammed on design points several times for similar
things.  Negotiate: Transparent would be a fine initial value, with a
note which recognizes that later specifications may extend this value.

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.  I know that it means extra bits
on the wire, but I believe that we should not encourage this, 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
meeting....


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.  


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.
Perhaps we should say unambiguously that transparent negotiation works
only with GET and HEAD and describe any other use as a different kind
of negotiation?


Section 15.

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

Received on Thursday, 12 September 1996 14:50:57 UTC