Re: Proposed LIDS Working Group

[Tim Howes <[e-mail]>]

> From:    [e-mail]
> To:      [e-mail], [e-mail], [e-mail],
	   [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).

Paul-Andre, thanks for the comments, that's exactly what I wanted.
My response is below.

But first, a procedural suggestion.  I suggest that further discussion
of this charter (and the larger problem) occur only on the [e-mail]
list.  I imagine many of you, like me, have been getting about 4 copies
of all this mail, and it's probably getting pretty annoying!

So, unless anybody objects, anyone replying please send your replies
only to [e-mail].  Anyone not on that list who wants to stay
involved in the discussion, please send a note to [e-mail]
and request to join.

> > 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)

Good point, and I agree.  I think Erik's suggested name of ASID for
Access and Synchronization of Internet Directory will do for a better
name, at least for the moment.  I will update the charter accordingly.

> 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.

Clearly, we want a framework that will eventually evolve into a general
directory service for the Internet.  But the most important short-term
problem to be solved is the white pages problem (finding information
about people and organizations on the Internet).  I think it's
important to keep ourselves focused on this problem so we can get
something done.  Some of the pices to the white pages solution (e.g.,
WHOIS++, X.500, LDAP, and SOLO) will undoubtedly go on to play a role
in a more general directory service solution.  Other pieces (e.g.,
NETFIND) may or may not have a role beyond white pages.

With regard to the charter, I'd be willing to add a sentence that
says this group's efforts are part of a longer-term strategy to
develop a more general directory service for the Internet that's
appropriate for handling documents, etc.

> 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.

I think it has to cover this kind of use, at least as far as a UR*
refers to white-pages kinds of information.  And once you've done
it for this, it should pretty much fall into place for everything else.

> > 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

Will do.

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

Do you see this as part of a white pages (people + orgs) directory?
If so, we could add an explicit statement.  But I am leary of broadening
the charter too much.

> > 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

I think these concerns are taken care of with Erik's message
describing the overall strategy and other working groups to be
created.

> > 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

Schema, templates, etc. are all important components of the overall
solution.  They are to be done by different groups, though.

Re: simplicity.  I think the key to getting anything done is to start
small and simple and expand from there.  This can be interpreted to
mean the development of something like WHOIS++, or the deployment of
something like X.500.  One big mistake with X.500 in the past has been
the deployment of something of which people only ended up using 10%.

> > 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

Harmonizing needs to happen at both levels.  There is protocol work
to be done, for example, so that X.500 can play in the UR* world.
And as you point out above, there is lots that needs to be done in
the "information model" area, too.

> > 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.

I'll make the changes outlined above, and resubmit the charter
to the wps list.                                      -- Tim