Subject: (IPng 6653) Re: Basic API Update Oct 18th and XNET INput may be coming!!!

From: Chris Harding <[email-masked]>
Date: Tue, 20 Oct 1998 15:47:00 +0100

Hi -

Detailed XNET input will be coming - here's why.

Use of namespace by a service implementation may give application writers
problems. They tend to assume that they can use what names they want in
their programs and get upset when they come unstuck because they picked a
name that was already in use by the implementation. So application writers
want service implementations to use namespace sparingly and cleanly.

So, for example, if you are writing an application to enable you to control
the blinds in your house, you might write functions "open()" and "close()".
When you then decide it would be nice to do it remotely over the Internet,
you run into problems (assuming you didn't already have problems because
your blind controller had some kind of file system).

There is also (as in the specific example quoted by Erik) the possibility
that you may get problems when you try to put together two service
interfaces that were designed in isolation and that don't use namespace
carefully.

This leads to the convention, used in new specifications defined by various
industry bodies, including The Open Group and POSIX, that all names used by
the implementation from the application's namespace should start with a
prefix, or small set of prefixes, that are peculiar to the interface. This
doesn't preclude the use of meaningful names - and even adds to readability
because it becomes obvious at a glance when a function from a particular
interface is used, and it is further obvious which interface is in question.

This is fine for new interfaces, but many old ones - including sockets -
don't follow this convention. Use of "close()" by the sockets interface -
as well as "socket()", "accept()", "connect()", etc - is well-established
and it would almost certainly cause more pain to change it than to leave it
alone.

But this argument doesn't apply to extensions to the sockets interface.
Keeping "namespace pollution" to a minimum in any extensions will make the
interface easier to use. So it is right to ask whether there are good
reasons for not minimising namespace pollution. And I can't think of any.

Why raise this now? Well, this is in some sense a cosmetic issue. Changing
the name of a function or a data structure has no effect on what the
function does or what the data structure contains. It is reasonable to get
the functionality right first and argue about the names afterwards. This
wastes less time than, for example, arguing heatedly about the name of a
function which is then found to be unnecessary and removed from the interface.

Detailed comments on this aspect - which will not impact the stability of
the interface from a functional point of view - will be circulated in
response to the "last call".

Folks,

Thanks for the final edits.  It appears we have a solid spec and folks
have implementations underway.  I will sumbit final edit as draft-03.txt
Monday evening.  It is just edits nothing that affects implementation.

But I heard that the XNET group is not happy with our namespace for the
API, and will be submitting a set of changes for this name space.  I
have advised the Chairs this may be happening.

It is my feeling we should go forward with last call and if this very
untimely and very late input does come in from XNET we can review it as
a WG last call item.

I have not seen any document yet privately or otherwise but here is how
I feel about this right now as an "individual IETF member and Internet
Society member":

  1.  The input is just plain too late from this standards organization,
      (XNET) they have had more than enough time to respond to this
      specification.   This is also not the way to work with the
      IETF as a standards body.  RFC 2133 has been there for a long
      time, with any suggested name space problem.

  2.  XNET does not represent all members on this list but only the 
      UNIX vendors (e.g. not PCs, Routers, BSDxxxx, other OS's), as 
      far as participating interests in that standards body.

  3.  Any name space suggestions must be proven that they are truly needed
      for this API.  At this point in time it is not enough that XNET 
      feels this is a good idea but must prove it.

  4.  If they can prove that this is a good idea, it may be that XNET
      can produce a later draft in their respective technical bodies
      and set of UNIX YEAR/YEAR (e.g. 95, 98) standards.  Then it 
      can be adopted by those supporting those standards.  The Basic
      API Informational RFC can be used as a base for that work.  If
      vendors feel this is important they can implement the change
      at the time the XNET process produces such a standard update.
      Given that this will not break any binary portability of 
      IPv6 implementations.

But at the end of the day it is up to you the working group to decide
what is best.  But I will proceed with the Chairs to request a last
call on draft-03.txt of this very important API which is needed by the
market and IPv6 implementors to become stable now. As previously stated
I will sumbit draft-03.txt Monday evening.

Sincerely,
And a very tired editor and co-author,  
/jim

<<<<

Regards,

Chris
+++++

-------------------------------------------------------------------------
           Chris Harding
  T H E    Development Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:[email-masked]   Ph: +44 118 950 8311 x2262
           WWW: http://www.opengroup.org    Fx: +44 118 950 0110  

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.
-------------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------