🚀 go-pugleaf

Jeff Buffum writes:

> In the CMIP specification, get, set, delete, and action all have both positive
> and negative response types defined in ASN1.  Create only has a positive response
> type although section 8.3.4.1 of CMIS indicates error values for a response.  How 
> are these errors returned?  Section 8.3.4.2 (procedures) of CMIS says that if an 
> error occurs, to ignore the remainder of the section.  It does not provide an 
> explanation of what to do.  In section 6.7.3 of CMIP, they indicate that a APDU
> should be constructed but not which APDU.
> 


None of the primitives have "negative response types" defined. If you
are looking at the OPERATION macros in section 7.4 of 9596 (CMIP) you
will see that each operation have an argument, a result and a number of
errors. The error are defined later in the same section using the ERROR
macro, which lists the error number and the name of the syntax (the
type) of the parameter to be carried in the error response.

Thus, each primitive is answer with either a (positive) result or an
error (negative) result.

I think you are confusing error parameter types e.g. GetListError with a
general negative response type for the primiteves (here Get). But
GetListError is nothing more than the parameter carried in the response
in case of a "get list error" error, cnf. CMIS (9595) section
8.3.1.1.14. The GetListError type just happens to carry almost the same
information as in case of a positive response. Nevertheless it is only
carried in negative responses. In case of the Get primitive, the get
list error is not returned on every kind of error: Only if one or more
of the requested attributes were not present in the Managed Object this
error is returned. If e.g. the filter specified in the request was
invalid, the error returned will be "InvalidFilter" which does not carry
the GetListError type but insted the CMISFilter type.

Thus, to answer your question "How are these errors returned?": It
depends. It depends of which error occured. You have to look at the
ERROR macros in section 7.4 of CMIP and find the appropriate macro.
There you will see which information so send with the error.

An other thing: To reject a request is *NOT* the same as to return a
negative (error) response. Section 8.3.4.2.2 states that if the CMIS
Service provider (The CMIP protocol machine) does not accept the
request it should be rejected and the rest of section 8.3.4.2 ignored.
This could happen e.g. if the request contained a filter and the Filter
functional Unit had not been succesfully negotiated. When rejecting a
request you use the RO_Reject primitive not the RO_Result/RO_Error
primitive used when responding to a request. In this case the performing
CMIS user will never know that a (rejected) request were being sent to
it.


> Any help would be appreciated.

You're welcome


-- 
Ole Frank Larsen                        ofl@dowtyns.dk                         
                                        ...!mcsun!dkuug!dowtyns!ofl
Research & Development                  Voice: +45 44530100 
Dowty Network Systems A/S - Denmark     Fax:   +45 44531415