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 ***