Nut upsdev - Dec 2021 - NUT I-D (future RFC): XML encoded responses

I have received a comment asking me to add XML encoded responses from the server
as an option.  This looks to me to be a very interesting and useful addition to 
the I-D (the future RFC).  However it would be a significant addition, and is 
not something in which I have the necessary experience.

We have the choice of placing such an addition in the current draft, or 
publishing it in a new (much shorter) draft RFC.

Given the IETF habit of "rough consensus and working code", I would
prefer to
wait until the NUT project has working code for this, but I am more than ready 
to listen to your ideas.

We would also need volunteer(s) to write the new text.  This would require a 
rigorous, standards quality, specification of the the XML grammar used and its 
meaning.  The comment proposed REST.  Is this the best choice?  Would SOAP be 
better in an RFC?

Roger

PS: a piece of IETF jargon: a future RFC is known in the IETF as an I-D.  I 
shall begin using this terminology.

For background, I'm a longtime nut user and list lurker.  I was on a
number of IETF WG mailing lists from 1995 to say about 2015, and
attended some IETF meetings from 1995 to around 1999.

Roger Price <roger at rogerprice.org> writes:
> I have received a comment asking me to add XML encoded responses from
> the server as an option.  This looks to me to be a very interesting
> and useful addition to the I-D (the future RFC).  However it would be
> a significant addition, and is not something in which I have the
> necessary experience.
Do you mean

  there is already XML and you are going to document it

or

  there is not XML, and someone is asking to draft a description of what
  XML might be for the document, in the hopes  that somebody in some
  NUT-compliant implementation will implmenent it?

As I grep the sources to 2.7.4 (yes I know that's old, but it's the most
recent release, and what is handy in pkgsrc), I see a driver that talks
XML to Eaton units, but I don't see a user-to-nut XML interface.
> We have the choice of placing such an addition in the current draft,
> or publishing it in a new (much shorter) draft RFC.
> Given the IETF habit of "rough consensus and working code", I
would
> prefer to wait until the NUT project has working code for this, but I
> am more than ready to listen to your ideas.
I completely agree.   Really we're a little off the rails to be
documenting a single-implementation protocol, but given that it's
Informational and the implementation is Free Software, that seems ok.
> We would also need volunteer(s) to write the new text.  This would
> require a rigorous, standards quality, specification of the the XML
> grammar used and its meaning.  The comment proposed REST.  Is this the
> best choice?  Would SOAP be better in an RFC?
Posing that question makes it clear to me that the XML situation is not
baked enough to put in an RFC, and I think it's much better to document
what's already established, and then after the XML has settled down,
create a revision that includes XML also, along with any other fixes.

(As an aside, I wonder why there is XML instead of JSON.  I suppose there
is schema benefit, but XML just seems so much more awkward these days.)

Greg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20211230/133846dd/attachment.sig>