RE: problems with 'ignore-error' <error-option>

["McDonald, Ira" <imcdonald@sharplabs.com>]

Hi,

FWIW - the Internet Printing Protocol v1.1 (RFC 2911) defined several
relevant values for the "status-code" always returned in operation
responses:

'successful-ok' - 
   The request has succeeded and no request attributes were substituted
   or ignored.

'successful-ok-ignored-or-substituted-attributes' - 
   The request has succeeded, but some supplied (1) attributes were
   ignored or (2) unsupported values were substituted with supported
   values or were ignored in order to perform the operation without
   rejecting it.  Unsupported attributes, attribute syntaxes, or values
   MUST be returned in the Unsupported Attributes group of the response
   for all operations.

'successful-ok-conflicting-attributes' -
   The request has succeeded, but some supplied attribute values
   conflicted with the values of other supplied attributes.  These
   conflicting values were either (1) substituted with (supported)
   values or (2) the attributes were removed in order to process the job
   without rejecting it.  Attributes or values which conflict with other
   attributes and have been substituted or ignored MUST be returned in
   the Unsupported Attributes group of the response for all operations
   as supplied by the client.

And later, to provide more explicit control for the submitter, the
PWG IPP Job Extensions (PWG 5100.5, October 2003), defined the new
"job-mandatory-attributes" element (translate IPP 'attribute' to
XML schema 'element' not 'attribute', by the way).

IPP/1.1 receivers are uniquely able to gracefully handle unsupported
attributes, because the IPP wire encoding includes strong typing and
lengths (so that it's always possible to skip over an unsupported
or unrecognized attribute in a request).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Thursday, February 02, 2006 8:53 PM
> To: Steve Berl
> Cc: Netconf (E-mail)
> Subject: Re: problems with 'ignore-error' <error-option>
> 
> 
> Steve Berl wrote:
> > I think I agree with you completely.
> >
> > It would be clearer if the choices were "stop-on-error",
> > "continue-on-error", and "rollback-on-error". I'll leave it 
> up to the editor
> > and WG chair to decide whether to change it or not.
> >
> >   
> 
> I don't mind.  IMO, "ignore-errors" is really confusing.
> It's not in the form of an action to take when an error occurs,
> like the other 2 choices.
> 
> A NETCONF data model should describe its referential integrity
> requirements somehow, so that implementers know which instances
> of which objects are conceptually coupled.  It does not need to
> describe any error-option specific behavior.
> 
> The real issue is not how agent implementers will deal with this,
> but rather "will applications get consistent error info for
> the same set of conditions from one agent to another?"
> 
> > The text should also make clear that these only apply to 
> errors in applying
> > the changes described in the <config> element. Errors outside of the
> > <config> element are real errors in the use of the netconf 
> protocol and
> > cannot be ignored. The result should be no change to the device
> > configuration.
> >   
> 
> Can we say "application layer errors within the <config> element."?
> Does that cover it?
> 
> Also:
> 
> "It is a data-model specific matter how an agent divides
> an <edit-config> operation into sub-operations
> for the implementation of the 'stop-on-error' and 'continue-on-error'
> error-option values.  If one or more of the sub-operations
> completes, but one or more sub-operations does not complete (due
> to errors), then the agent MUST return a 'partial-operation' error tag
> in the <rpc-reply>."
> 
> 
> 
> > -steve
> >   
> Andy
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>