Redirect Ref. teleconference, Mar. 8, 2000

Redirect References Teleconference
March 8, 2000

Present: Judy Slein, Chuck Fay, Jason Crawford, Jim Whitehead, Geoff Clemm
Minutes recorded by Jim Whitehead

*** Note that decisions made during the teleconference are always
subject to review on the mailing list.  The mailing list is the final
arbiter of consensus on any issue.  Note also, that the revised
Redirect References protocol  produced as a result of this
conference call will also be subject to review by the mailing list. ***


Issue #16: We accept the proposed language.  There is no way we can
guarantee that redirect references will be easy to implement for all
implementations.

Issue #17: There is a need for both the Location header, which alway returns
an absolute URL, and some means of getting the actual value of the Redirect
Target, which can be a relative URL.  This is why just using  the Location
header to retrieve this value is insufficient, since it cannot return a
relative URL.  We will eed some mechanism (REFGET method?) for retrieving
the relative URL value.

Issue #18: Agreed that we should not create a registration procedure for
resource types.  New resource types are not created that often, and need to
be defined by an RFC, and are not expected to be created by end-users.
However, we agree that this should be listed in the IANA considerations
section.  Of course, in general, there is a need for registration
proceedures for new HTTP methods, headers, as well as for DAV properties.

Issue #19: Agree that the language needs to be changed, and we will revise
it.

Issue #20: Disagree.  We are creating a document that will be used for many
years, and 5-10 years from now, MKRESOURCE will not be a "new" method. But,
we will add language stating that the method is defined normatively in this
document.

Issue #21: It is an oversight that these sentences are still present. They
will be removed. Everything except for the first sentence of the paragraph
can be deleted.

Issue #23: There most frequently used HTTP clients do not display the
response body on a redirect, and thus it doesn't seem to make much sense to
provide remote authoring capability for this.  However, it is a SHOULD level
requirement in HTTP/1.1 that a 302 return a body that might be displayed.
There are 4 cases here: GET, GET with Apply-to-RR, PUT, PUT with
Apply-to-RR.  GET needs to be able to return a body, due to HTTP/1.1
requirements.  GET with Apply-to-RR we feel should fail (403 or 405). PUT
should fail, as should PUT with Apply-to-RR.

Issue #26: Will take this under advisement when we revise this section.

Issue #27: Will evaluate this in its use cases to see if it clarifies the
language.

Issue #28: Agreed.  Will change the language to reflect this.

Issue #29: Agreed that it is obvious.  Will remove it.

Issue #30: Will keep up to "MUST be returned", then remove the rest of the
sentence.

Issue #31: Agreed that this section can be removed, it does list obvious
consequences.

Issue #32: Agreed that we will remove the mention of ORDERPATCH.

Issue #33: Agreed, will replace "forward" with "redirect" throughout where
it is appropriate.

Issue #34: Agreed, we will remove all references to bindings from this
specification.

Issue #35: Agreed to remove these paragraphs (this is a consequence of
resolution to Issue #34).

Issue #36: We will re-write the specification to remove the use of the term
"server" as much as possible.

Issue #37: The key issue is that the target value is completely under the
control of the client, the server must not modify the value of the redirect
reference.  We will rewrite the integrity statement to say this instead.

Issue #38: We will rewrite this to retain the motivation of having something
in a collection by-reference, but remove discussion of hierarchy. But,
should motivate the HTTP/1.1 uses of redirect references first, then go on
to WebDAV motivations later in the introduction.

Issue #39: Already agreed to do this in issue #15 resolution.

Issue #40: Will remove word server.  We will look at uses of "forward" in
this section to see if they should be "redirect".  Will also remove
discussion of direct reference resources in this section.Will  mention the
difference between the definition of "forward" and "redirect" in the spec
(perhaps in this section).

Issue #43: Went back on our discussion of last week, and agreed that we
would like to have a DAV:Reftarget property available for WebDAV compliant
servers. This would allow a client to quickly retrieve the Reftargets of all
Redirect Reference resources in a particular collection. This property
would, of course, not be available for HTTP/1.1 only servers.

Issue #44: Did not find arguments against the current marshalling to be
compelling, will keep this as-is.  There do not appear, in general, to be
compelling reasons to choose one marshalling over another.

Issue #45: We found the note to be incorrect.  A request on a redirect
reference resource with the Apply-to-RR header must behave according to the
specification, and hence by definition there is no case where you can
receive a 302 back without following the behavior of the spec. So, we will
not include the proposed note.

Issue #46: We have agreed to remove all references to bindings from this
specification.

Issue #47: The comment about 207 no longer applies, since MKRESOURCE has
been replaced with MKREF. Will add to the text of the 409 response to note
that some of the conditions only apply to WebDAV collection cases.

Issue #48: Agreed that most of the text in Section 6 can be removed.  Will
provisionally accept Yaron's text (excepting the word "blindly").  Will keep
the requirements about the Redirect-Ref and Location header being
(relative|absolute) and absolute URLs respectively.

*** End of teleconference ***

Received on Wednesday, 8 March 2000 19:26:38 UTC