Subject: Re: Comments & work to do on protocol draft

From: Nicolas Popp <[email-masked]>
Date: Mon, 3 Apr 2000 09:53:11 -0700

Leslie and al.

I used some of the time spent at the airport and in the plane to massage the
protocol document. That should cover/clarify many of the issues discussed in
Adelaide about terminology/properties/ranking/mixed results/discovery.

Marshall, to facilitate integration with the master document, each section
starts with a few bullets that describe what's being added or modified. Let
me know how you want to proceed so that we can quiclky move to the final
document

Cheers.

-Nico

-----Original Message-----
From: Leslie Daigle
To: [email-masked]
Sent: 00/03/27 15:03
Subject: Re: Comments & work to do on protocol draft

Howdy,

Ben Schepens wrote:
> > Result set ordering: are results presented in some kind of an
> > ordered list? (would facilitate presenting per-result errors).
>
> Formally speaking, as the DTD is defined, 'Errors' are grouped
> per 'Result'.  If you meant to say per-'Resource' errors, I am

Gee, Ben, if you're going to be snooty about splitting a semantic hair
with me, get it right!  The element is "Results", not "Result".  The
further point being that I wasn't speaking in DTD elements, but rather
general terminology -- "result" being one thing in a "result set".

> not sure how that would be useful.  It seems to me that a 'Resoure'
> returned in the Result represents a successful answer.  If there
> were a problem, an 'Error' element would have been returned in the
> 'Result' INSTEAD of a 'Resource'.

To explain a bit further:

        In the case of non-fatal errors, e.g., hints ignored.

        In the general case of system messages, can also include
        informational messages.

        Thinking ahead, perhaps, there's also the issue of what happens
        if the service you're connected to is in fact fronting for a
        number of services or namespaces; having only "failed" or
        "succeeded" as report codes for the entire result set is pretty
        much lame.  (This is the part that Michael referred to).

The most important thing to get resolved in the CNRP document is
whether or not the client should expect the components of the "Results"
to be ordered for any reason.

Next, do we want to impose any semantics on the ordering (if they
are ordered) -- e.g., error messages that apply only to the
resource/record element that follows, etc.  This may make more sense
in the context of messages that are "system messages including
error messages", as opposed only to fatal/non-fatal error messages.

It may well be the case that we don't want to impose such an ordering
 -- but we need to be clear either way.

> Mealling > Ahh, yes. Since we assume that a given set of results may
have a
> Mealling > records from different servers then how do we associate an
error
> Mealling > with a given set of records.
>
> Could we add a ServiceRef to each error so that the errors
> could be related to a Service source the same way that Resources are?

This works to the granularity of per-service errors/system messages.
It doesn't work within a given service.

Leslie.

--

-------------------------------------------------------------------
"My body obeys Aristotelian laws of physics."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: "Marshall L. Moseley" <[email-masked]>
Date: Tue, 4 Apr 2000 10:04:36 -0700

I won't be able to get to integrating this into the final document until
next week, but at that time it should go fairly quickly.  A day, or less.

--Marshall