Subject: [Enum] RFC4114 <update> example breaks RFC3731?

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 15 Feb 2006 16:59:40 +0100

Hi,

i'm currently looking at RFC4114 to see how it fits potential infrastructure 
  ENUM applications. In section 3.2.5, there is the following example of an 
<update>:

    C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
    C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
    C:     epp-1.0.xsd">
    C: <command>
    C:  <update>
    C:   <domain:update
    C:    xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
    C:    xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
    C:    domain-1.0.xsd">
    C:    <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name>
    C:     </domain:update>
    C:   </update>
    C:   <extension>
... (remaining lines removed) ...

Clearly, this request uses the domain mapping specified in RFC3731. Section 
3.2.5 of RFC3731 says:

-----
The <domain:update> element contains the following child elements:

    -  A <domain:name> element that contains the fully qualified name of
       the domain object to be updated.

    -  An OPTIONAL <domain:add> element that contains attribute values to
       be added to the object.

    -  An OPTIONAL <domain:rem> element that contains attribute values to
       be removed from the object.

    -  An OPTIONAL <domain:chg> element that contains object attribute
       values to be changed.

    At least one <domain:add>, <domain:rem>, or <domain:chg> element MUST
    be provided.  The <domain:add> and <domain:rem> elements contain the
    following child elements:
-----

However, the example above does not contain such an element required by the 
last sentence. It passes the schema, though, because the above requirement 
cannot be easily expressed there.

So, my question is:

- is the example in RFC4114 broken? Or
- is it ok to use RFC3731 schemas without being RFC3731 compliant? Or
- is the example not considered normative? ;)

(BTW, i don't see any reason for the mandatory elements in a RFC4114 
scenario though, so i'd actually prefer to implement it the way it is 
outlined in the example)

Any comments appreciated.

Alex

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 15 Feb 2006 22:57:01 +0100 (CET)

Ciao Axel!

RFC 3731 (as well as the other EPP RFCs) is currently being revised.
See below Scott's email concerning this sent to the PROVREG mailing list.

cheers,
  Bernie

--- BEGIN ---

Date: Fri, 9 Sep 2005 14:27:45 -0400
From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] 3731bis Submitted

I just sent the -00 version of 3731bis to the I-D administrator for
publication.  Here's the list of changes copied from Appendix A:

[...]

3.  Changed text in Section 3.2.1.4 from "At least one <domain:add>,
     <domain:rem>, or <domain:chg> element MUST be provided." to "At
     least one <domain:add>, <domain:rem>, or <domain:chg> element
     MUST be provided if the command is not being extended.  All of
     these elements MAY be omitted if an <update> extension is
     present.".

[...]

--- END --

On Wed, 15 Feb 2006, Alexander Mayrhofer wrote:

> (BTW, i don't see any reason for the mandatory elements in a RFC4114 scenario 
> though, so i'd actually prefer to implement it the way it is outlined in the 
> example)
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 15 Feb 2006 23:03:27 +0100

> See below Scott's email concerning this sent to the PROVREG mailing list.

Bernie,

thanks for pointing that out - i've unsubscribed from the provreg list when 
the set of RFCs was published :-/

cheers

Alex