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.)
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
