Re: OPSYS field and the Identifier

[Anders Andersson <[e-mail]>]

Peter writes in response to me:
> > port number (say, "P1" to "P16") in the user-id field?  I.e. is "P16"
> > enough of a 'real username' for you, or do you have more specific
> > requirements?
>
> No, that would be ok if that is the normal way of identifying that
> particular kind of connection "owner". 

Well, just don't take for granted that there already *is* a 'normal'
way established for our protocol to fall back on.  For certain types
of equipment (like terminal servers), it may very well be that the
'normal' way is defined by the first implementation of this protocol.
However, I'm willing to accept that for a given opsys (not "OTHER"),
there should be exactly one standard for displaying these names (i.e.
two different implementations for the cisco terminal server would be
wrong if they both used the same opsys identifier and different
syntax for identifying terminal lines, say "P16" vs. "port16").
Does that make sense, or am I on thin ice here?

> To put it the other way around; If we _don't_ say _anything_ in the
> RFC about what the identifier should be, then the current practice, of

The current draft says:

      [...]  "OTHER" must be specified if there is no
      registered format for a user id for this operating system, if
      the system wishes to return an identification which is not in
      the format registered for this system (eg. an encrypted audit
      token), or if there is a desire to hide the operating system
      type.  [...]

Isn't that enough?  It may be in need of some rephrasing due to the
removal of OS-specific user name syntax specifications *from the draft*,
but that removal does not mean that all OS-dependencies in user names are
wiped off the face of the earth, and I don't think we were discussing the
removal of the "OTHER" alternative altogether.  I guess the key issue
here is what people read into 'registered format'.  I may interpret that
in a pretty loose sense, like 'whatever the practice for identifying
users is under a particular operating system', if the phrase is kept
without further qualifications.

> No point then of displaying it at all really. (Who's interrested in seeing
> that IRC Nickname user "FOO" happens to have the RFC931 identifier
> "ERtgds435dfg" this time?) I think it would be a pity to not being able

There are perfectly valid UNIX usernames out there reading something
like "q7629180", probably used for student accounts created in large
quantities.  It does not look a lot more informative than "ERtgds435dfg"
to me.  In both cases I suppose there are (perhaps manual) methods of
finding out the real humans behind those strings at their time of use.

I can also imagine "OTHER" being used to accompany non-standard
user identification strings like "Anders Andersson, DoCS, Uppsala
University", if the implementor finds that appropriate.

Now, if you wish to use the opsys field as the discriminant for
automatically weeding out the 'probably readable' user names from
the 'probably unreadable' ones in your application, that's entirely
up to you, and I consider it a simple and perfectly valid approach,
even if it will result in a few misses like those mentioned above.

However, I see no reason to make any statement about readability in
the draft, as that would make the protocol much less useful while
transmitting a pretty arbitrarily chosen opinion about the data (i.e.
"this is a string which an IRC user may like to see" vs.
"this is a string which an IRC user may like not to see").

I don't think referring to current practice in IRC and LPMUD
implementations is a good argument either, as even RFC931 contains
no support for this interpretation of "OTHER".  What happens to be
current practice depends on a lot of real-world considerations,
like the readability of common operating system user names in
general, and not only on a particular protocol specification.
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 520, S-751 20 UPPSALA, Sweden
Phone: [phone]   EMail: [e-mail]