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

Roger Price roger at rogerprice.org
Thu Dec 30 16:26:41 GMT 2021

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?


More information about the Nut-upsdev mailing list