Re: Proposed LIDS Working Group

[[e-mail]]

Hi Tim,

some comments below

Please understand them not as criticism of what you proposed
but as a trial to raise important issues related to this topic
and the answer to which completely conditions the goal
of LIDS (thus the content of its charter).


-- PAP

> 
> 
> Lightweight Internet Directory Services Charter

I understand that the name cannot be IDS, but the "lightweight" here
  1. sounds like redundant with Internet
	Why would the Internet look for heavyweight?
		because ISO/ITU already taking care of DAP
		because no heavyweight at all wanted/acceptable :-)
  2. is unclear and probably misleading
       What is "light" the directory service or the access protocol?
	 I hope that the major requirement is on the access protocol,
	 but that does not appear from the name..
  3. is not consistant with the charter 
	Is the major goal focused on access protocols per se, or in
	   a service definition  (with obvioulsy implications
	   on the access protocols)

I have also some problem with the White-Pages focus:
  as there exist several understanding of this word, I think that the
  charter must give a (short) definition of White Page in this context
   (unclear for me if here it means
       a white page people and organisation directory (ie. the entries
	 are all of the O OU and people - role type)
       a white page type of structuring and queries but open to
	  any type of objects (entries) not only people.

I consider personaly that it would be totaly unwise to exclude
a directory of documents (especialy network reachable documents)
from the scope of this work. In particular there is an urgent need
for a solution to the URN, URI to URL resolution.
Directory services for document are badly needed, will be 
used much more heavily than people directory/ies
and it would be a pity to let 2  incompatible services develop
when as far as I understand the issue there is no a priori
and obvious technical/organisational reason to have
separate and different services.
I don't know if white page as used in the charter below covers
this type of use. If not, then I would suggest the area directors
to reconsider the goal of this activity before starting
discussing the details of the charter.

> 
> There is a clear need to provide and deploy a well managed Directory Service
> for the Internet. Especially a so called White Pages Directory Service is
> long overdue. Due to the very nature of such a service it needs to be based
> on a distributed database approach. 

a 2 3 lines definition of white pages needed here

a explicit statement about documents directory (included or excluded
from the scope) useful

> 
> Currently there are various protocols under development in the Internet that
> aim at providing such a service: internet X.500, WHOIS++, NETFIND, CSO etc. 

That's right but in my mind not enough
  of course we have several protocols, but even with one protocol
  (not more than a mere tool) one can build several services
  Providing a service requires also a service model

  To illustrate this:
  1. it is perfectly feasible with say X.500 to define deploy 2
     completely different services just by using schema/naming
     guidelines/attributes specific to each service
  2. on the other hand we all hope that by accepting a common
     service model it will be feasible to have several protocols
     and servers cooperating at a single service
     

The "integration" goal will only be reachable if we take into account
not only the protocols but the underlying service models

> To allow these services to evolve to a ubiquitous Internet Directory Service
> a hybrid system that allows interaction between the various different
> services is a requirement.  
> 
> The LIDS working group will identify the need for, define, evolve, and
> standardize lightweight protocols, algorithms and accesss methods for
> directory services on the Internet. Similar or related work items

That is exactly the heart of the problem.
Do we believe that with a scope limited to access methods and
protocols, it will be possible to enable and warrant "interaction"
(I mean useful interaction, that is the one perceived by the
end-user)?
In other words, does this group have to work over the directory
model (logical) or does it rely on another group to tackle
with that fundamental issue (if so which group? when? charter?
liaison?)?

Personal opinion:
  the approach is too technicaly focused
  the Internet (unfortunately?) cann't escape a "heavyweight"
    directory service
      . because of security (no network security without some
	  network directory services)
	  securing distributed application is the real today big
	  challenge of the internet
      . because of all the roles and functions that a directory
	  will have to play as soon as it is deployed
  this makes it even more crucial to
     . have a "simple" model
	 it must be implementable by several technologies
	 it must be easy to understand/master by the user
     . share a common model
	enabling cooperation between "heavy" and "light" portions
     . provide lightweight access to hide the "heavy" parts


    [[ to illustrate what I have in mind:
      from X.500 the Internet model would amongst amny more
	 . exclude such oddities as multi-AVA-RDN, 
	 . find solution to the today brain-damaged X.500 aliases. 
	 . extract a simple schema subset especially at naming level
	 . limit to a strict minimum the number of attribute syntaxes
     so that the very same model be easily implementable with
     other technologies and protocols
     ]]

> already completed or underway in this area by other groups include the
> Lightweight Directory Access Protocols (LDAP and Connectionless LDAP),
> the User Friendly Naming (UFN) and User Friendly Searching (UFS)
> specifications (all developed for internet X.500), much of the
> World-Wide-Web-based efforts, including the Hypertext Transfer Protocol
> (HTTP) and URL/URI work, the SOLO directory access and searching
> system, the WHOIS++ directory service work, and the NETFIND directory
> service.  The group is intended to focus on harmonizing, evolving and
> developing lightweight protocols and algorithms from all areas of
> directory service, both ad hoc and standards-based, and it is expected
> that this will ultimately contribute to a hybrid system that ties
> together various forms of Directory Service.

Agreed but  again in my mind the major step for harmonization
is not at protocol level but
   adopting a very simple (though open) common model,
      a simple and common schema (X.500 terminology)
Once we have this it will be easy to "harmonize" the access
protocols

> 
> Milestones
> 
> 	SOLO Internet Draft published
> 
> 	SOLO Internet Draft elevated to Proposed Internet 
> 	Standard status
> 
> 	CLDAP Internet Draft elevated to Proposed Internet 
> 	Standard status
> 
> 	X.500 URL draft published
> 
> 	LDAP URL draft published
> 
> 	SOLO URL draft published
> 
> 	Stand-alone LDAP draft published (LDAP without X.500)
> 
> 

From the list above I fear that LIDS might limit itself to be
a "home" for several protocols specifications and not
the "home" for the "Internet directory service" we all
need.

$v