Re: comments on version 2 of protocol draft

[Bobby Krupczak <rdk@krupczak.org>]

Hi!

> If you study most APIs, somewhere below the surface they do make
> assumptions and provide defaults even if the defaults weren't encoded
> directly as parameters.  printf assumes you want to print to stdout
> and you have to use a different API to do otherwise.  open() assumes you
> want to use basic read() type calls to access the data, and you have
> to use fopen or xml_parse to get something else.

I do not believe this has any bearing on our discussion.  Just because
other APIs make assumptions, does not mean that we need to make our
APIs, protocols, specifications obtuse.

> Protocol operators are not like APIs because you're discussing a fewer
> number of API like operations, because the optional parameters (IE,
> default enabled attributes) contained within frequently change the API
> itself that is being called within the implementation.

I understand the difference between a protocol, API, etc.

Keep in mind that protocol specs, APIs, and code, programs,
etc. are *all* specifications of some sort of computation.  Those
specifications cover syntax and semantics.  Making the syntax and
semantics easier to read, understand, and comprehend, 

> Sometimes.  Sometimes it bogs the screen down so much with overhead
> that you can't get as good as a grasp on what is going on.  Forced
> clutter does not make things easier to read.

Interesting.  Editors seem to do reasonable jobs (if their humans
direct them to) of formatting stuff.

I really dont see the issue here.  Maybe I am the only one that likes
clear and understandable protocols and specs.

Bobby

--
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/>