[Nut-upsdev] NUT I-D (future RFC): XML encoded responses

[Ted Mittelstaedt]

A huge issue with any interchange protocol is not just defining what you 
are exchanging but how it's exchanged.  The entire point of the RFC 
effort is to define what is what.  Take for example section 4.2.7.6 from 
the draft RFC:

Command:|LIST UPS|

The response is:

BEGIN LIST UPS
UPS <upsname> "<description>"
...
END LIST UPS

The Command that is sent to the UPS is very rigidly defined - it is 
"LIST UPS" with a newline at the end. A UPS that adheres to the RFC has 
no choice but to accept that command, it MUST accept that command and do 
what the command says, which is "to report a list of the UPS units to 
which it is attached"

The problem is in the response.  It's undefined.  Whatever sent the LIST 
UPS command is expecting what? An ASCII string terminated with 
newlines?   Notice that there's a statement in there about U+0022 
QUOTATION MARK characters are supposed to be part of the response 
because Roger already ran into this issue.

But if you enclose the response in the XML I posted earlier.  The 
response would be:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<list_ups_response>
    <parameter name="UPS">
                 <value>SmartUPS 1000</value>
                 <value>APC SmartUPS 1000 located on "accounting office" 
3'rd floor</value>
    </parameter>
    <parameter name="UPS">
                 <value>Eaton 1000</value>
<value></value>
    </parameter>
</list_ups_response>

This gives the recipient a great deal of information.  On the first 
item, if for example the admin wants to put quote characters in the 
response description - no big deal at all
The recipient also knows when the end of the list is.  The recipient 
also knows that on the second UPS parameter that the sender deliberately 
has nothing in the description.
The RFC defines 2 values to the UPS parameter and the recipient knows if 
a value was deliberately left empty instead of making assumptions.

And there's already XML parsing libraries out there and XML itself is 
defined.  You can't put a space in the parameter and the RFC can define 
how many values are supposed
to be returned from a parameter.  You don't get tripped up because some 
joker put a reserved character into the response output and if you 
define XML as an output it
automatically disallows using a construction like </ in the UPS name 
itself, and if the NUT daemon programs are outputting XML then they know 
to strip those characters
out of any UPS-provided description that a user might have typed in at 
the UPS front panel.

And all of the XML requirements can be listed under a "SHOULD" in the 
RFC such that 'XML output is optional but if it is made available then 
this is the format that the
responses are in'  In essence you are "reserving" the special characters 
used in XML for use in an optional XML output.

Remember that you do NOT have to implement every last thing in an RFC in 
code.  You can define suggested future and experimental things.

Ted


On 12/30/2021 4:49 AM, Greg Troxel wrote:
> 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.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20211230/90af280d/attachment.htm>