Dear Colleagues,Based on comments received from the message below, it's been suggested that a different change occur to the NETCONF-BEEP draft. Instead of NETCONF messages being transmitted in text/xml instead of application/beep+xml. I have no objection to such a change as it would bring it in line with the other drafts. This amounts to the following draft changes in the document:
In Section 2.2, insert the following paragraph:
OLD:
At this point, we are ready to proceed on BEEP channel 1 with NETCONF
operations.
NEW:
At this point, we are ready to proceed on BEEP channel 1 with NETCONF
operations.
NETCONF messages are transmitted with a Content-type header set to
"text/xml".
In the example below it:
OLD:
A: MSG 1 0 . 0 429
A: Content-type: application/beep+xml
A:
NEW:
A: MSG 1 0 . 0 457
A: Content-type: text/xml
A:
A: <?xml version='1.0' encoding="UTF-8"?>
In section Section 2.2 REMOVE the following paragraph:
OLD:
Please note in the above example an absence of an XML declaration
(e.g., <?XML version=1.0?>). This necessary variance from the other
NETCONF mappings is in accordance with Section 6.4 of [7].
Are there objections to these changes?
Eliot
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 ("&", "<", ">", "'", and """) 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 -- 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/>
-- 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/>