Subject: [NSIS] GIST issue on Error Message Formatting

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 11 Oct 2006 11:47:29 +0100

Hi all,

An issue has been raised on error message formatting. It is in the
tracker as issue #130
(http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue130),
and the summary text is included below.

This is a solicitation for input, especially from the implementors, on
this matter. In the absence of input, my preference would be to leave to
spec unchanged, but if people feel (even not particularly strongly) that
a more structured syntax would be preferable it is not that much effort
to change. It would be very good to see change/no change comments either
way.

cheers,

robert h.

========================================================================
===
The current error message formats are essentially fixed and predefined
for each
error code; that is:
- if you know the error code, you know precisely what should be in the
message
and you can parse it completely. Someone generating the error has no
freedom
about what information to include (cannot include other Additional Info
fields,
for example).
- if you don't know the error code (typically because it is a new
error), you
cannot parse anything about it beyond the MRI - you cannot parse any
additional
info field or the debugging comment.

It's been suggested that it would be possible to make the additional
info fields
some kind of object in their own right, in which case there would be
some kind
of TLV format for them, and probably a registry for their type codes. 

The advantage of this is that every message can always be parsed.
(However,
without knowing the semantics of the error code, it still may be hard to
do
anything useful with the information.)

The disadvantage is that there is a minor change in protocol
specification
complexity.

It isn't clear what the impact is on implementation complexity. The
error
message parser might be a little more complex but would be more future
proof and
with less special cases.
========================================================================
==

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 11 Oct 2006 15:21:33 +0300 (EEST)

Hi Rob,

I feel giving more structure to the error messages would help 
implementations and deployment. I guess we have something like that in the 
QoS NSLP spec, and at least so far no one has complained. :)

Jukka

---

From: Ruud Klaver <[email-masked]>
Date: Thu, 12 Oct 2006 15:24:11 +0200

Hi Robert,

> robert h.

Comments inline below.

If you are suggesting that the error generating node should be free in
what information to include, I think it is a good idea to have the
specification at least dictate what information SHOULD be included.
The infos mandated right now make sense for the errors they are
included with. The current situation however is that certain
information MUST be included, because not including it would make full
message parsing impossible.

> info field or the debugging comment.

Except for the case where the number of info fields is 0.

> anything useful with the information.)

If a node does get an error code that it does not know about, the best
thing it can hope for is printing all received infos and the debugging
comment to a log somewhere for human inspection. The hope in this case
of course is that the error generating node is smart enough to realize
that it is using an error code that may be unknown and provides a
descriptive debug message just in case. Because of the situation you
are describing exactly this would be impossible at the moment, as the
knowledge of the infos included is directly coupled to the knowledge
of the existence of the error message. For this reason I think that
giving the infos some sort of TLV header would be a good idea.

If we look at existing error messages, I think that your proposal
increases flexibility, as in the case of the SHOULD/MUST comment
above. If an error generating node for some reason decides to include
more/less/other info than that which is dictated, this is not an error
condition anymore. And if there's one thing you want to avoid it's
errors causing errors...

> message parser might be a little more complex but would be more future

Quite a bit of my error message parsing code right now is dedicated to
strict checking of the infos based on the value of the error code and
subcode. In case of a more flexible TLV solution this would no longer
be needed. It will however need to be replaced with something to parse
the TLV. In my particular case, because of the code structure, I
woudld say that the complexity of the proposal would be roughly equal
to what I have now.

As for future proofness, the complexity of adding new error codes that
should contain infos will indeed be decreased.

In conclusion, to me it sounds like a good idea, provided that the
specification dictates which infos SHOULD be included with each error
message.

One last comment, I've hard more problems with the QoS-NSLP Info
objects than with GIST. None are dictated and there is no way to glean
which info object is included except for object length. It would be a
good idea to have something similar for QoS-NSLP error messages. 
-- 
Best regards,
 Ruud                            mailto:[email-masked]

---

From: Roland Bless <[email-masked]>
Date: Mon, 16 Oct 2006 16:48:56 +0200

Hi all,

> this matter. In the absence of input, my preference would be to leave to

The error object caused indeed some implementation pain.
While the current definition for additional info contents makes
sense, I agree to the comments in general:
- the format is not very extensible and robust due to a missing TLV
  structure, e.g. cannot skip additional info and give out debug
  comment.
- if a node generates a malformed error message, recovering from
  wrong syntax in the additional info field is difficult.
- Having a normal TLV format for objects in the additional info
  section would make implementations easier (you don't have to
  construct a structure depending on the error type) and
  implementation errors less harmful (e.g., if you forgot to
  include mandatory additional info objects). So according to
  implementation complexity: at least for us it would be easier
  to parse a list of TLV objects, because that's already done
  for other PDU objects. The implementation would be simpler
  on the parsing side due to less special handling, so I would
  state: "The error message parser is less complex and
  would be more future proof and with less special cases."

Hope that helped.
 Roland