RE: Proposed Resolution to PROT I-D Issues List

["McDonald, Ira" <imcdonald@sharplabs.com>]

Hi,

I've been having a long, fruitless offline discussion with Joel
Halpern about this.  The results may be summarized as follows:

(1) The IESG policy is that the plaintext English is always 
    normative.

(2) The IESG policy does NOT allow an appendix of XSD (or any
    other relatively formal language) to override the plaintext
    English, because then _parts_ of plaintext English sentences
    or paragraphs might become invalid.

I'm strongly opposed to this logic, because it implies that an RFC
should not include any formal language appendices, since they're
to be ignored anyway.

Analogy - In English and US contract law, if an illegal or invalid 
statement is later found, then the clause or the subclause is 
invalid, but the rest of the contract remains legally valid.

I suggest deleting all XSD from Appendices and references.  It
won't do you any good anyway.  And changing the IESG policy
is just hopeless.

Discouraged,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Wes Hardaker
Sent: Monday, March 21, 2005 5:00 PM
To: sberl@cisco.com
Cc: 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org
Subject: Re: Proposed Resolution to PROT I-D Issues List


>>>>> On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)"
<sberl@cisco.com> said:

Steven> Are you saying that we have a formal language description of
Steven> the syntax of the protocol messages, but that is there just
Steven> for information?

My only intent was to state that it hasn't been proven to be perfect,
and thus implementers should not rely on it as a check that an
incoming packet is indeed perfect.

The problem I've seen with XML applications is that many of them pass
an incoming packet to a validator (which is merely validating the XML,
not the data within) and then doesn't implement its own sanity error
checking afterward.  Thus, I've actually seen many security problems
in XML applications because they assume that the packet contains
everything it needs in the exact form it needs when in fact it may
not.

Andy is right, however, that an XSD probably couldn't be written which
meet every implementations requirements.

If you're going to make it normative, I don't think it should go into
the appendix as it is currently.  (If memory serves, appendices in
RFCs are supposed to be normative).

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
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/>