[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: impending publication of the NETCONF BEEP mapping - one final concern

Eliot Lear wrote:

Dear all,
After last call, a concern was raised regarding the NETCONF / BEEP application mapping that is due to be released, relating to the lack of <?xml version="1.0" encoding="UTF-8"?> in the <hello> message. I would like to clarify why this is the case on the mailing list, and I will clarify this in the netconf-beep mapping.
Section 6.4 of RFC 3080 registers the MIME subtype application/beep+xml. That registration specifically specifies two restrictions, relating to the XML: 

     First, no entity references other than the five predefined general
     entities references ("&amp;", "&lt;", "&gt;", "&apos;", and
     "&quot;") and numeric entity references may be present.

     Second, neither the "XML" declaration (e.g., <?xml version="1.0"
     ?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be
     present.  (Accordingly, if another character set other than UTF-8
     is desired, then the "charset" parameter must be present.)
For this reason the example listed in draft-ietf-netconf-beep-10.txt varies from that listed in draft-ietf-netconf-ssh-06.txt (amongst other ways). 

Regards,

Eliot



I do not see any objection to these proposed edits.
Here goes one...

I do not like the concept of <edit-config> or other RPCs working fine
if the manager connects to port 830, but doesn't work at all on port 831,
because a "different" subset of XML is supported.

I do not see any objections to applying these restrictions to the
entire protocol, regardless of transport protocol.  Is there any
reason NETCONF implementations could not be constrained in this manner?
(IMO, the character entity set is English-centric and not very useful
for documentation strings in other languages.  This will be a problem
someday.)

Also, these clarifications need to be in the protocol spec,
not the NETCONF over BEEP spec.  They need to apply to the
protocol regardless of the transport layer being used.

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>