Re: [netconf] RFC6241: "xs:QName" text values in <nc:rpc-error> instances
Andy Bierman <andy@yumaworks.com> Thu, 01 June 2023 19:10 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3A5C15199B for <netconf@ietfa.amsl.com>; Thu, 1 Jun 2023 12:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVtqW7yfTuOx for <netconf@ietfa.amsl.com>; Thu, 1 Jun 2023 12:10:42 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB7CC151085 for <netconf@ietf.org>; Thu, 1 Jun 2023 12:10:40 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-4f3bb61f860so1671229e87.3 for <netconf@ietf.org>; Thu, 01 Jun 2023 12:10:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1685646638; x=1688238638; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/S/CHriv8vMnG42C94I/hz2fb+8hlbhtsFO7XYdiu4I=; b=TgL7IW5fOXbrJ3wdC7NHeD8NCf3+8n+bRRKOGlatXQLu4zjajyFspN/8uWZpUsqDTP pZYtSd8NYBqBP4J3LVdyyZhKenKzQRVaAMuPffnQ8xG+p/FkxoUg3Yn2W7eA1M/PVLg4 +T4Fslezz4L5KWImil5RJOT1P0o+dCWtBZTrlnKqTXZKX29okTaWBQrGbtRHhJfj0Y2c 0+xRYqDL2hiY9eDxeHiDEj5ER0mRq3ssjHlz6nInlnl8qC5RIM/76pCh7DTm45ot/Bb2 /2h0bVTYb8YOZ85/kHbZAKbXje954J01d3QfaGCxXPkPT9b9Q92ysqqZG9+DkA247eFK XT4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685646638; x=1688238638; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/S/CHriv8vMnG42C94I/hz2fb+8hlbhtsFO7XYdiu4I=; b=G7CrzY/GXbrfzdpIMip/rw0wf6ctTvjzM1VZftpXPOnwdjVOPyHStrfvb4yhJQf0wg VrbeaNR/AFQD+tkeAs9iEU0Mp7NHx1QVEK5XDmB5l5d50wPz+UJABB8/h0JdQIsV0bTh m58iZm6fBPyHRGCewuGDf8KO2xadRL8PV1zqpglPKSYj+BZPbsPesZBv+rK7Q4S5t1Pl vie/tl41ukLW3inq5tY93BpydabIw+FG8VOn0RoeMyR2GpJqVWGT69ab6C6XpRf2p4Sf hs5iis6/a3/0dnpbeybJrSeD5Fh7+Mo46UA2eNfgxZMXkbtZ5JfJ/WKj8rwFBYfoWspp EapA==
X-Gm-Message-State: AC+VfDxobhXOH0xPuB9KiMuczVj47UCKduCOnh2MK3/LZkT4q4AXvOv2 UydZL3tIW46Y60fon1NyaMP0Aok62bNQYyi+BO4vBcSnlVe8jAlcpZm9zQ==
X-Google-Smtp-Source: ACHHUZ4FX52kkzG99YWQrVfJ6Igqug4gBi6Re/Ss4HQVSffJIsFqKx+69mYQkrWb2dfpjpTKt6SgtluNwZ4FIwgRN+Y=
X-Received: by 2002:a2e:92cb:0:b0:2b0:770f:c83c with SMTP id k11-20020a2e92cb000000b002b0770fc83cmr302227ljh.4.1685646638264; Thu, 01 Jun 2023 12:10:38 -0700 (PDT)
MIME-Version: 1.0
References: <59252a86-3889-16e8-5542-e12790958b94@mg-soft.si>
In-Reply-To: <59252a86-3889-16e8-5542-e12790958b94@mg-soft.si>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 01 Jun 2023 12:10:26 -0700
Message-ID: <CABCOCHReETyPw2KZmcBPoLJT1PYCgoFftBs6+Vr9hF8ND-YjNw@mail.gmail.com>
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
Cc: Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000017466605fd163118"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3kZmuMoPbYHMVf8D_3HoynNAscc>
Subject: Re: [netconf] RFC6241: "xs:QName" text values in <nc:rpc-error> instances
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jun 2023 19:10:46 -0000
On Thu, Jun 1, 2023 at 2:13 AM Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote: > Hi, > > RFC 6241 contains the following example in section 4.3. > > Example: An error is returned if an <rpc> element is received > without a "message-id" attribute. Note that only in this case is > it acceptable for the NETCONF peer to omit the "message-id" > attribute in the <rpc-reply> element. > > <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > <get-config> > <source> > <running/> > </source> > </get-config> > </rpc> > > <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > <rpc-error> > <error-type>rpc</error-type> > <error-tag>missing-attribute</error-tag> > <error-severity>error</error-severity> > <error-info> > <bad-attribute>message-id</bad-attribute> > <bad-element>rpc</bad-element> > </error-info> > </rpc-error> > </rpc-reply> > > I think this <rpc-reply> is semantically incorrect. It should be > corrected to: > > <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> > <nc:rpc-error> > <nc:error-type>rpc</nc:error-type> > <nc:error-tag>missing-attribute</nc:error-tag> > <nc:error-severity>error</nc:error-severity> > <nc:error-info> > <nc:bad-attribute>message-id</nc:bad-attribute> > <nc:bad-element>nc:rpc</nc:bad-element> > </nc:error-info> > </nc:rpc-error> > </nc:rpc-reply> > > You should file an Errata. OLD: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>rpc</error-type> <error-tag>missing-attribute</error-tag> <error-severity>error</error-severity> <error-info> <bad-attribute>message-id</bad-attribute> <bad-element>rpc</bad-element> </error-info> </rpc-error> </rpc-reply> NEW: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>rpc</error-type> <error-tag>missing-attribute</error-tag> <error-severity>error</error-severity> <error-info> <bad-attribute xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">nc:message-id</bad-attribute> <bad-element xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">nc:rpc</bad-element> </error-info> </rpc-error> </rpc-reply> Andy > NETCONF messages layer is modeled with XML Schema 1.1 (XSD 1.1) in > Appendix B. > > While the <rpc-reply> in the original example is valid according to XML > 1.1 Schema in Appendix B, it does not seem to be consistent with > requirements described in Appendix A. The text value of XML elements > <bad-attribute> and <bad-element> should be a valid "xs:QName" that > references a known attribute or element by its name ({namepace-name, > local-part} tuple, not a string literal). Since the "message-id" > attribute and "rpc" element do not belong to the same namespace in an > <rpc> message, one of the text values in the original <rpc-reply> cannot > be semantically correct. > > It is also unclear which namespace unprefixed text values of XSD 1.1 > modeled data map to (and RFC 6241 says nothing about this), so my > correction above is intentionally verbose in order to eliminate the > default namespace. Note that the intention of the authors of XSD 1.1 > specification seems to be that such values are _always_ mapped to the > null namespace, unlike in some other XML schema languages, where the > default namespace would be used instead (if it exists), which would > imply that only the value of <bad-element> in the original <rpc-reply> > is problematic. The following could also be semantically correct: > > <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> > <rpc-error> > <error-type>rpc</error-type> > <error-tag>missing-attribute</error-tag> > <error-severity>error</error-severity> > <error-info> > <bad-attribute>message-id</bad-attribute> > <bad-element>nc:rpc</bad-element> > </error-info> > </rpc-error> > </rpc-reply> > > However, XSD 1.1 specification does not seem to explicitly confirm this > anywhere. > > Can someone please clarify what the intention of RFC 6241 was here? > Specifically, why was XSD 1.1 "xs:QName" chosen as the data type for > such XML elements in Appendix B, and what does "name" in Appendix A > refer to? > > Jernej > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >
- [netconf] RFC6241: "xs:QName" text values in <nc:… Jernej Tuljak
- Re: [netconf] RFC6241: "xs:QName" text values in … Andy Bierman
- Re: [netconf] RFC6241: "xs:QName" text values in … Jernej Tuljak