Re: Proposed Resolution to PROT I-D Issues List

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "McDonald, Ira" <imcdonald@sharplabs.com>
> To: "'Randy Presuhn'" <randy_presuhn@mindspring.com>; <netconf@ops.ietf.org>
> Sent: Tuesday, March 22, 2005 12:05 PM
> Subject: RE: Proposed Resolution to PROT I-D Issues List
?

> Hi,
>
> It would be nice if there were some agreement in this advice.
>
> Randy says the XSD *is* normative, but the plaintext wins in
> conflicts (which Joel says is not true under the prevailing
> IESG policy, because nothing but plaintext can be normative).

I base my claim on the statement "We therefore expect that people
will continue using English to describe protocols, with formal
languages as a supporting mechanism" from
http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt

> Joel says the IESG doesn't bother much about labelling parts
> of RFCs normative or informative (the RFC Editor certainly
> doesn't agree with this one - a number of RFC's and I-Ds on
> proper RFC style address which body parts and appendices are
> or should be normative).

Even within a normative section, there may be material which is obviously
non-normative.  Phrases like "for example" are frequently a clue.
The normal MIB boilerplate contains non-normative material: "For
a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]."  Helpful background material is a Good Thing,
even though it may be non-normative.

> I liked Steve's formulation very much, but it's broken by
> the "plaintext always wins" rule.  An incoming message could
> _fail_ the XSD check and still be valid under ambiguously
> written plaintext body parts...
...

When such cases arise, the document should go back to the WG.
However, to make up an example, if the English says "it MAY
contain an optional element Z", but the XSD says Z is mandatory,
then I think the burden of proof is clearly on those who would claim
that the XSD is not in error.  I trust humans to spot errors in human-
readable text more than I trust them to spot semantic errors in
formal notations.

Randy



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