Subject: Ftp-WG: Re: More ABNF issues with draft-ietf-ftpext-mlst-14.txt (fwd)

From: Robert Elz <[email-masked]>
Date: Fri, 8 Feb 2002 05:03:50 -0500

Date:        Fri, 08 Feb 2002 10:02:56 +0100
    From:        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
    Message-ID:  <8557370.1013162576@localhost>

[Quotes from Bill Fenner]

  | Earlier I wondered about case-sensitive type facts, and suggested that
  | the "File" should read "file" in the definition of the type-val
  | rule.  That was before I realized that strings are case-insensitive
  | in ABNF; the only way to make a case-sensitive string is to specify it
  | in hex, e.g. %x66.69.6C.65

Yes, that was (the essence of) my reply when this was first mentioned.

  | -- so, the easier thing would be to explicitly
  | define that type-vals are case-insensitive.

That will be in the updated draft.   It was always the intention.  Note:

   The "os-name" indicates the specific system type which supports the
   particular localtype.  OS specific types are registered by the IANA  
   using the procedures specified in section 10.  The "os-type" provides
   the system dependent information as to the type of the file listed.
   The os-name and os-type strings in an os-type are case independent.

from the top of page 30 of the -14 draft (section 7.5.1.5).   The updated
draft has this more clearly specified for all type-vals (so the ones that
were case independent by virtue of being specified as ABNF strings are
not quite as magic now - ie: you don't have to be as much an ABNF expert to
get this right).

  | (Section 2.1's line of
  | reasoning that claims that "token" is case sensitive would seem to
  | apply to "value" as well, the value of a fact.)

Yes, it would, and in general it does.   But anywhere a specific set of
values is allowed, and they are listed as ABNF strings, then those strings
must be treated case-independently.   So, for the strings like "file", any
representation (FILE file File FiLe) must be treated the same.   Where some
value is possible that isn't specified as an ABNF string, then without anything
stating the contrary, case dependent comparisons would be required.

Having a value which was case dependent sometimes, and independent others,
would be a nightmare - which is why 7.5.1.5 made the OS dependent stuff
be explicitly case independent.

So, I think that all of this was actually consistent all the time - but
certainly having the rules more explicit is a good idea.

  | In 7.5.1.5, the "os-type" rule is defined twice:

Oops - thanks for spotting that one!

  | One or the other should probably be renamed; perhaps the second one
  | could become "os-specific-type" or something.

Too long (screws the doc formatting).   I'll probably rename the first,
there are more (short) reasonable choices available...

  | A type fact where the type is an os-type does not match the
  | grammar for facts.

Hmm.   Yes.

  | I don't know if the right answer is to redefine [value]
  | or to say that it's OK that an os-type is not a value since there's
  | an explicitly seperate grammar for it, or what.

I will ponder this one for a few more days, and listen to WG suggestions.

There isn't going to be a new draft submitted for (at least) several days
anyway (I am too bust with other work to work on the FTP server so I can
generate the requested example without cdir/pdir at the head of MLSD output).

kre

ps: I'm impressed by any effort to actually verify the grammar fragments
in this doc - it was never really complete enough (being just an add-on to
an existing protocol) to allow a complete grammar for anything to be written,
just the isolated pieces.

---

From: Robert Elz <[email-masked]>
Date: Fri, 8 Feb 2002 05:13:54 -0500

Date:        Fri, 08 Feb 2002 10:02:56 +0100
    From:        Patrik Fältström <[email-masked]>
    Message-ID:  <8557370.1013162576@localhost>

[Quoting Bill Fenner]

I actually (unless there are other suggestions from the WG of course)
decided on making the second one be "os-kind" - the 4 character word
keeps the formatting looking nice...  (and so the first one stays as
"os-type").

kre