Re: RFCE: More comments

[Bill Kelly <[e-mail]>]

Peter,

Thanks for the input.  First, to nit-pick, I just want to clarify that
we're talking about RFCS here (the subject line says RFCE, which is Cleve's
experimental RFC).  On to more substantial stuff...

On Tue, 20 Jul 1993, Peter DiCamillo wrote:

> 1. In the introduction, right before the overview, is the sentence
>    "It is not clear whether clients should support 3270 structured
>    fields."  I think I understand the intent here, but I suggest
>    clarifying it. How about "There is no mechanism by which the server
>    can determine if a client supports 3270 structured field, or a client
>    can request that it receive them."

Sounds reasonable to me.

>
> 2. I'm puzzled by the inclusion of NVT-DATA as one of the data types,
>    and RFC provides no explanation for its presence, or how it is
>    intended to be used.  I'm not necessarily saying it should be
>    removed, but could someone explain the motivation behind it?
>    Traditionally, NVT data is sent either before 3270 mode has been
>    negotiated, or later only after negotiating an end to 3270 mode.
>    Nothing in the RFC would seem to preclude continuing to do that.
>    Also, nothing in the RFC seems to preclude sending a block of
>    NVT data at any arbitrary time in the middle of a 3270 session.
>    What is a client expected to do if that happens?  If it's not
>    intended to be used that way, that needs to be clarified.

I wasn't sure how this could be useful, either, but it was in the
presentation that Bob did (and that I think Scott Herzog and Jon Penner of
DCA pretty much wrote) at the March IETF.  I don't remember it being
discussed, but I could've missed it if it was.  Azi's comments on this
subject make me think it would be worth including NVT-DATA even if only a
few vendors make use of it.  Perhaps Jon (or some of the other vendors)
could elaborate on its usefulness, or if there was any discussion of it at
IETF someone could summarize it to the list?

>
> 3. Reference 7 in the original draft is an IBM "LY" manual, that
>    is, a licensed manual.  My understanding is that such manuals
>    are available only to licensees of the associated program
>    products, and like a program product remain the property of
>    IBM.  Typically, each page includes "Restricted Materials of
>    IBM" and "Licensed Materials - Property of IBM".  Can't we
>    find a generally-available manual that includes sufficient
>    information for our purposes?  Even as an IBM (but non-SNA)
>    customer, I'm not certain I can obtain a copy of that manual.
>    I think references in an RFC should be as generally available
>    as RFCs, even if they're not free.  Also, use of an LY manual
>    in this way may not be allowed by IBM.

Hmmm...I believe it's certainly *legal* to include such a reference (in
fact, it would be legal to include brief quotes as long as they are
properly referenced); your point about the appropriateness is a different
issue.  I tend to agree that the references should be to documents
available to everyone.  Several options(?):

- find a generally available IBM publication
- find a generally available non-IBM publication
- write our own minimal document that covers only the necessary pieces;
  this is essentially telling people to "take our word for it, this is how
  things work
- remove the reference altogether and leave people to their own devices

I'll look around for a generally-available IBM manual that would suit our
purposes.

-Bill

Bill Kelly               phone: [phone]
Auburn University     Internet: [e-mail]