XML 및 NETCONF XML 관리 프로토콜 컨벤션 개요
클라이언트 애플리케이션은 XML 및 NETCONF XML 관리 프로토콜 규칙을 준수해야 합니다. 클라이언트 애플리케이션의 각 요청은 잘 형성된 XML 문서여야 합니다. 즉, 요청에 인코딩된 정보의 종류에 대해 NETCONF 및 Junos XML 문서 유형 정의(DTD)에 정의된 구조적 규칙을 준수해야 합니다. 클라이언트 애플리케이션은 필수 순서로는 법적 맥락에서만 태그 요소를 방출해야 합니다. Junos OS 또는 NETCONF 프로토콜이 변경된 경우에도 호환 애플리케이션을 더 쉽게 유지할 수 있습니다.
마찬가지로, NETCONF 서버의 각 응답은 잘 형성된 XML 문서(NETCONF 서버는 XML 및 NETCONF 규칙을 준수함)를 구성합니다.
다음 섹션에서는 NETCONF XML 관리 프로토콜 규칙에 대해 설명합니다.
요청 및 응답 태그 요소
요청 태그 요소는 장비의 현재 상태 또는 구성에 대한 정보를 요청하거나 구성을 변경하기 위해 클라이언트 애플리케이션에 의해 생성되는 요소입니다. 요청 태그 요소는 CLI 운영 또는 구성 명령에 해당합니다. 태그 내에서 <rpc>
만 발생할 수 있습니다. 요소에 <rpc>
대한 자세한 내용은 NETCONF 서버로 요청 보내기를 참조하십시오.
응답 태그 요소는 요청 태그 요소에 대한 NETCONF 서버의 회신을 나타내며 태그 내에서 <rpc-reply>
만 발생합니다. 요소에 <rpc-reply>
대한 자세한 내용은 NETCONF 서버 응답을 파스(Parse)를 참조하십시오.
다음 예는 클라이언트 애플리케이션이 요청 태그 요소를 flag와 함께 내 <get-interface-information>
보낸 EXCHANGE를 <extensive/>
나타내며 NETCONF 서버는 <interface-information>
응답 태그 요소를 반환합니다.
클라이언트 애플리케이션
<rpc> <get-interface-information> <extensive/> </get-interface-information> </rpc> ]]>]]>
NETCONF 서버
<rpc-reply xmlns="URN" xmlns:junos="URL"> <interface-information xmlns="URL"> <!-- children of <interface-information> --> </interface-information> </rpc-reply> ]]>]]>
이 예는 이 가이드의 다른 모든 요소와 마찬가지로 클라이언트 애플리케이션과 NETCONF 서버에서 방출되는 태그 스트림의 개별 라인에 있는 각 태그 요소를 보여줍니다. 서버가 이러한 공백을 자동으로 폐기하기 때문에 실제로 클라이언트 애플리케이션은 태그 요소 사이에 새라인 문자를 포함할 필요가 없습니다. 자세한 내용은 공백, 새 문자 및 기타 공백을 참조하십시오.
오프닝 <rpc-reply>
태그의 속성에 대한 자세한 내용은 NETCONF 서버 응답을 파스(Parse)를 참조하십시오. 오프닝 태그의 xmlns
속성에 대한 자세한 내용은 NETCONF를 사용하여 운영 정보 요청(Request Operational Information)을 참조하십시오.<interface-information>
문자 시퀀스에 대한 ]]>]]>
자세한 내용은 잘 형성된 XML 문서 생성을 참조하십시오.
요청 태그 요소의 하위 태그 요소
일부 요청 태그 요소에는 하위 태그 요소가 포함되어 있습니다. 구성 요청의 경우 각 하위 태그 요소는 구성 요소(계층 수준 또는 구성 객체)를 나타냅니다. 운영 요청의 경우, 각 자식 태그 요소는 동등한 CLI 명령을 발행할 때 명령줄에서 제공하는 옵션 중 하나를 나타냅니다.
일부 요청에는 필수 하위 태그 요소가 있습니다. 요청을 성공적으로 실행하려면 클라이언트 애플리케이션은 요청 태그 요소의 오프닝 및 닫는 태그 내에서 필수 태그 요소를 내셔야 합니다. 모든 자식이 컨테이너 태그 요소인 경우, 각 요소에 대한 오프닝 태그는 포함된 태그 요소 앞에 반드시 발생해야 하며, 닫는 태그는 계층 수준에서 다른 태그 요소에 대한 오프닝 태그 이전에 발생해야 합니다.
대부분의 경우, 클라이언트 애플리케이션은 컨테이너 태그 요소 내에서 어떤 순서로든 동일한 수준에서 발생하는 어린이를 방출할 수 있습니다. 중요한 예외는 구성 요소를 해당 유형의 다른 요소와 구별하는 식별자 태그 요소가 있는 구성 요소입니다. 식별자 태그 요소는 컨테이너 태그 요소의 첫 번째 하위 태그 요소여야 합니다. 가장 자주, 식별자 태그 요소는 구성 요소의 이름을 지정하고 호출 <name>
합니다. 자세한 내용은 식별자가 있는 객체에 대한 매핑을 참조하십시오.
응답 태그 요소의 하위 태그 요소
응답 태그 요소의 하위 태그 요소는 특정 요청에 대해 NETCONF 서버가 반환한 개별 데이터 항목을 나타냅니다. 자식은 개별 태그 요소(빈 태그 또는 태그 요소 트리플) 또는 자체 자식 태그 요소를 포함하는 컨테이너 태그 요소 중 하나가 될 수 있습니다. 일부 컨테이너 태그 요소의 경우 NETCONF 서버는 자식들을 알파벳 순으로 반환합니다. 다른 요소의 경우, 자식들이 구성에서 생성된 순서대로 나타납니다.
응답 또는 컨테이너 태그 요소 내에서 발생할 수 있는 하위 태그 요소 세트는 Junos XML API의 이후 릴리스에서 변경될 수 있습니다. 클라이언트 애플리케이션은 NETCONF 서버 출력에 특정 태그 요소가 존재하거나 존재하지 않아야 하며, 응답 태그 요소 내 하위 태그 요소의 순서에 의존해서는 안 됩니다. 가장 강력한 운영을 위해 예상 태그 요소의 부재 또는 예기치 않은 요소의 존재를 가능한 한 우아하게 처리하는 클라이언트 애플리케이션의 로직을 포함합니다.
공백, 새 문자 및 기타 공백
XML 사양에 따라 NETCONF 서버는 클라이언트 애플리케이션에서 생성되는 태그 스트림의 태그 요소 간에 발생하는 공백(공백, 탭, 새 문자 및 공백을 나타내는 기타 문자)을 무시합니다. 클라이언트 애플리케이션은 태그 요소 간의 공백을 포함할 수 있지만, 그렇게 할 필요는 없습니다. 그러나 여는 태그나 닫는 태그 내에 공백을 삽입해서는 안 돼요. 후보 구성에 변경으로 제출하는 태그 요소 내용에 공백을 포함할 경우 NETCONF 서버는 구성 데이터베이스의 공백을 보존합니다.
응답에서 NETCONF 서버는 파일에 저장되는 응답의 가독성을 향상시키기 위해 태그 요소 간의 공백을 포함합니다. 새로운 문자를 사용하여 각 태그 요소를 고유 라인에 배치하고 부모에 비해 오른쪽에 있는 아이 태그 요소에 대한 공간을 제공합니다. 클라이언트 애플리케이션은 특히 사용자들이 나중에 검토할 수 있도록 응답을 저장하지 않는 경우, 공백을 무시하거나 폐기할 수 있습니다. 그러나 태그 스트림을 구문 분석할 때 특정 위치에 공백이 있는지 여부에 따라 달라서는 안 됩니다.
XML 문서의 공백에 대한 자세한 내용은 http://www.w3.org/TR/REC-xml/ W3C(World Wide Web Consortium), XML(Extensible Markup Language) 1.0의 XML 사양을 참조하십시오.
XML 설명
클라이언트 애플리케이션과 NETCONF 서버는 생성되는 태그 스트림의 태그 요소 간에 XML 주석을 삽입할 수 있지만 태그 요소 내에는 삽입할 수 없습니다. 클라이언트 애플리케이션은 NETCONF 서버의 출력에 대한 주석을 적절히 처리해야 하지만 해당 컨텐트를 의존해서는 안 됩니다. 서버가 수신하는 주석을 자동으로 폐기하기 때문에 클라이언트 애플리케이션은 주석을 사용해 NETCONF 서버에 정보를 전달할 수 없습니다.
XML 주석은 문자열 <!--
내에 동봉되며 -->
문자열(2개의 하이픈)을 --
포함할 수 없습니다. 설명에 대한 자세한 내용은 http://www.w3.org/TR/REC-xml/ XML 사양을 참조하십시오.
다음은 XML 설명의 예입니다.
<!-- This is a comment. Please ignore it. -->
사전 정의된 엔터티 참조
XML 규칙에 따라 특정 문자가 정규 형식으로 표시될 수 없는 두 가지 컨텍스트가 있습니다.
열기 및 닫는 태그 사이에 나타나는 문자열(태그 요소의 내용)
오프닝 태그 속성에 할당된 문자열 값
두 컨텍스트에서 허용되지 않는 문자를 포함할 때 클라이언트 애플리케이션은 허용되지 않는 문자를 나타내는 문자 문자열인 동급 사전 정의된 엔티티 참조를 대체해야 합니다. NETCONF 서버는 응답 태그 요소에서 동일한 사전 정의된 엔티티 참조를 사용하기 때문에 응답 태그 요소를 처리할 때 클라이언트 애플리케이션은 이를 실제 문자로 변환할 수 있어야 합니다.
표 1 에는 태그 요소의 열기 및 닫는 태그 사이에 나타나는 문자열에 대해 허용되지 않는 문자와 사전 정의된 엔티티 참조 간의 매핑이 요약되어 있습니다.
허용되지 않는 문자 |
사전 정의된 엔터티 레퍼런스 |
---|---|
& |
& |
>(기호보다 더 큰) |
> |
<(서명이 아닌 경우) |
< |
표 2 에는 허용되지 않는 문자와 속성 값에 대한 사전 정의된 엔티티 참조 간의 매핑이 요약되어 있습니다.
허용되지 않는 문자 |
사전 정의된 엔터티 레퍼런스 |
---|---|
& |
& |
' (아포스트로피) |
' |
>(기호보다 더 큰) |
> |
<(서명이 아닌 경우) |
< |
"(견적표) |
" |
예를 들어, 다음 문자열이 태그 요소에 포함된 <condition>
값이라고 가정합니다.
if (a<b && b>c) return "Peer’s not responding"
<condition>
태그 요소는 다음과 같습니다(가독성만을 위해 두 줄에 나타납니다).
<condition>if (a<b && b>c) return "Peer’s not \ responding"</condition>
마찬가지로 태그 요소 속성의 heading
값 <example>
이Peer’s "age" <> 40
면 오프닝 태그는 다음과 같습니다.
<example heading="Peer's "age" <> 40">