Errors in RFC's 1831 RPC, 1832 XDR - NFS

This is a discussion on Errors in RFC's 1831 RPC, 1832 XDR - NFS ; I believe I've found errors in RFC's 1831 and 1832, which are internet standards for remote procedure call (RPC) and external data representation (XDR). Currently, RFC Editor is showing no errata for these RFC's. http://www.rfc-editor.org/errata.html First, in accordance with the ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Errors in RFC's 1831 RPC, 1832 XDR

  1. Errors in RFC's 1831 RPC, 1832 XDR

    I believe I've found errors in RFC's 1831 and 1832, which are
    internet standards for remote procedure call (RPC) and external
    data representation (XDR). Currently, RFC Editor is showing no
    errata for these RFC's.

    http://www.rfc-editor.org/errata.html

    First, in accordance with the procedure to report technical
    issues, I'd like to verify the problems with the author, Raj
    Srinivasan, but he's apparently no longer at the e-mail address
    of phone number given in the RFC's. A quick search finds more
    than one Raj Srinivasan in related fields.

    Does anyone know how I can reach Raj Srinivasan, formerly at
    Sun? If I can't reach Raj, I should send this to the
    appropriate IESG area director. Could someone tell me what
    area would cover this?

    http://www.ietf.org/iesg.html

    You can reach me by following-up this post, or at my acm.org
    e-mail address:

    firstname dot lastname at (a)ssociation for (c)omputing (m)achinery dot org.

    Thanks, --Bryan Olson

    Now here's the tech stuff. I've written the following in a curt,
    matter-of-fact-this-is-wrong style. That's not meant to be a
    comment on the overall quality of these RFC's.


    RFC 1832 section 3.19 'Optional-data' states:

    For example, the following defines a type "stringlist" that
    encodes lists of arbitrary length strings:

    struct *stringlist {
    string item<>;
    stringlist next;
    };

    According to the grammar in section 5.3 'Syntax Information', that's
    not legal, and neither is one of the given alternatives:

    or as a variable-length array:

    struct stringlist<1> {
    string item<>;
    stringlist next;
    };

    Outside of comments, "struct" can appear either in a struct-type-spec,
    where it always appears in the context:

    "struct" "{"

    Or in a type-def, where it always appears in the context,

    "stuct" identifier "{"

    According to section 5.2 'Lexical Notes', an identifier cannot begin
    with "*" or end with "<1>".

    According to section 5.4 'Syntax Notes', "struct" is keyword and
    cannot be used as an identifier, so it cannot appear in any other
    context.


    RFC 1831 section 11.1 'An Example Service Described in the RPC
    Language' states:

    Here is an example of the specification of a simple ping program.

    program PING_PROG {
    /*
    * Latest and greatest version
    */
    version PING_VERS_PINGBACK {
    void
    PINGPROC_NULL(void) = 0;

    /*
    * Ping the client, return the round-trip time
    * (in microseconds). Returns -1 if the operation
    * timed out.
    */
    int
    PINGPROC_PINGBACK(void) = 1;
    } = 2;

    /*
    * Original version
    */
    version PING_VERS_ORIG {
    void
    PINGPROC_NULL(void) = 0;
    } = 1;
    } = 1;

    const PING_VERS = 2; /* latest version */

    Again, according to the grammar in 11.2 'The RPC Language
    Specification', the above is not legal.

    procedure-def:
    type-specifier identifier "(" type-specifier
    ("," type-specifier )* ")" "=" constant ";"

    The keyword "void" appears several times where a type-specifier
    is required, and according to the referenced grammar in RFC 1014
    section 5.3 'Syntax Information' (or as updated in RFC 1832) a
    type-specifier cannot reduce to the keyword "void".


    These problems appear to be in the grammar, and not just the
    examples. The abstract for RFC 1831 states:

    This document describes the ONC Remote Procedure Call (ONC RPC
    Version 2) protocol as it is currently deployed and accepted.

    I've checked two "rpcgen" programs, an "rpcgen programming
    guide", and a number of alleged XDR files, including a Sun XDR
    file for NFS. The definition of 'type-specifier' and its use
    within 'declaration' seem to be broken. None of the following
    qualifies as a type- specifier according to the grammer, but in
    practice they are used that way.

    * These are not type specifiers:

    "void"
    "string"
    "opaque"

    But they frequently appear as procedure return values or
    parameters, where a type-specifier is required.


    * None of these are type-specifiers either:

    "enum" identifier
    "struct" identifier
    "union" identifier

    So, for example, the following is not a legal declaration:

    "struct" identifier identifier


    * Similarly, these are also not type type-specifiers

    "struct" identifier struct-body
    "enum" identifier enum-body
    "union" identifier union-body

    They each form a type-def if followed by ";", but they
    often appear inside a struct-body or union-body where
    only declarations are allowed.


    * The single word "unsigned" is not a type-specifier, but
    occasionally gets used that way.


    A couple other notes:

    * Hex constants such as 0x2000008 frequently appear where a
    constant is required. RFC 1832 section 5.2 'Lexical Notes'
    states:

    A constant is a sequence of one or more decimal digits,
    optionally preceded by a minus-sign ('-').


    * The grammar does not allow a union to have two case with
    no declaration in between, but the construct appears in
    widely-used XDR files, as in:

    union createhow3 switch (createmode3 mode) {
    case UNCHECKED:
    case GUARDED:
    sattr3 obj_attributes;
    case EXCLUSIVE:
    createverf3 verf;
    };

  2. Re: Errors in RFC's 1831 RPC, 1832 XDR

    bryanjugglercryptographer@yahoo.com (Bryan Olson) wrote in message news:<1a517b5.0405101111.5c00039f@posting.google.com>...
    > I believe I've found errors in RFC's 1831 and 1832, which are
    > internet standards for remote procedure call (RPC) and external
    > data representation (XDR). Currently, RFC Editor is showing no
    > errata for these RFC's.
    >
    > http://www.rfc-editor.org/errata.html
    >
    > First, in accordance with the procedure to report technical
    > issues, I'd like to verify the problems with the author, Raj
    > Srinivasan, but he's apparently no longer at the e-mail address
    > of phone number given in the RFC's. A quick search finds more
    > than one Raj Srinivasan in related fields.
    >
    > Does anyone know how I can reach Raj Srinivasan, formerly at
    > Sun? If I can't reach Raj, I should send this to the
    > appropriate IESG area director. Could someone tell me what
    > area would cover this?



    The NFSv4 working group now has responsibility for these
    RFCs. You should post your comments there. You comments
    look valid to me.

+ Reply to Thread