Subject: Advanced Status Reporting and XML vs HTML

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 19 Dec 2000 13:02:18 -0800

A couple issues from the discussion of advanced status reporting in San
Diego:

1)  Somebody suggested looking at the discussion that occurred in Australia
w.r.t. status reporting.  I can't find it:  it seems only the DeltaV group
met in Australia, and they didn't post their meeting notes.  I've looked at
the main WebDAV mailing list traffic for Jan to Sept 2000, and can't see an
obvious thread about either Australia meeting notes or status reporting.
What should I be looking for?

2)  Roy suggested that the machine-parsable XML be embedded inside HTML.
Sean objected that this is actually much harder to find and expose than one
might like.  My opinion is that a client that wants the XML will not want
the HTML, and vice versa.

So, my proposal is to kill two birds with one stone.  We pretty much agreed
that the client should advertise its support for this feature in requests,
presumably by adding a header.  It's straight-forward to allow this header
to provide information on what kind of thing the client wants to receive.

Request header: "DAV-status-response"
Header parameters:
 - user-text
 - response-format

E.g.:
  DAV-status-response: user-text=T; content-type="text/xml"

For the purposes of this specification:
 - user-text can take the values T or F.  A value of F means that the server
does not need to bother to provide any text for user display, whether in XML
or HTML, because the client will ignore it.
 - response-format should be a comma-separated list of acceptable formats
for the status-response body.  "text/xml" will include the elements already
discussed. "text/html" tells the server it may return HTML with error text,
which many already do.

For the future:
 - user-text parameter coud take additional values like "extended"
 - response-format could be some other format, or list of formats.

Does this seem reasonable?  Anybody have other suggestions?

lisa

---

From: John Stracke <[email-masked]>
Date: Tue, 19 Dec 2000 16:38:50 -0500

Lisa Dusseault wrote:

> for the status-response body.

This feels a lot like Accept:...but, of course, we can't actually use Accept:,
because that would affect what kind of responses come back on success.  Do we
want an Accept-Error:, maybe?

As for the user-text option...is it really that important to be able to turn
off the user text? In probably over 90% of the cases, you're going to want to
be able to present an error message to the user (or else log something, if
you're a robot), and that user text might have extra explanatory information
that couldn't be expressed in the standard machine-readable part.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |There are many intelligent species in the    |
[email-masked]|cosmos. All are owned by cats.               |
\==============================================================/