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

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>

On Thu, 30 Dec 2021, Greg Troxel wrote:
>> I have received a comment asking me to add XML encoded responses from
>> the server as an option.
>
> 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?
The proposal is to create and document a simple XML encoding for the responses 
from the Attachment Daemon, to facilitate the use of mobile Management Daemons 
(clients on iPhone, Android, ...)
> 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.
XML encoding of responses would be completely new.
>> 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.
That's a likely path for a future RFC. A second text (which following the
IETF
process, would have a new number) which corrects and extends the first and which
is carried along a standards track.  But in the meantime is there a volunteer to
write text and demonstration code for the current I-D?

Roger

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>