Subject: RE: AW: [Enum] New version of rfc2916bis - new compendium

From: "Stastny Richard" <[email-masked]>
Date: Wed, 27 Nov 2002 12:29:52 +0100

Rich wrote in reply to me:

> >And if they are different, I do not think that clients have 
> a problems 
> >to separate the functions.
> 
> tell that to a coder....
> 
> But Richard ..this also highlights the direction enumservices 
> compendium 
> needs to take.
> 
> Broken apart with clear and unambiguous definitions of type 
> and subtype and 
> what URI to expect for each option each document can stand on its own.
> 

Yes, Rich, we already discussed this and are planning to do this
(after overcoming our depressions ;-).

The question is only if we should keep an (extremely slimmed down) 
informational brander-compendium as a framework (high level outline) and overview.
It could also give information on the usage and meaning of order 
and preference(or was it priority?) if you use combinations of enumservices.

Regarding this issue, see also the e-mail below I received from Mark Enzmann:

From: Enzmann, Mark [mailto:[email-masked]] 
Sent: Friday, November 22, 2002 11:20 PM
To: Stastny Richard
Cc: Clif Campbell (E-mail); Tom Richter (E-mail)
Subject: RE: [Enum] Compendium on enumservices registration

Richard, 
I also believe that the compendium should be a workgroup document.  I would propose that in order to simplify the document and give it more value, perhaps we can change it into more of a high level outline.  That is, start by defining the categories, then the services related to each category.  The detailed service description could be in another document. This would be similar to the work being done in sipping as relates to conferencing.  

There has been effort expended to pull this document together and I hate to see it wasted.  In addition, should the idea of an overall services document with the details in individual service detail description documents be implemented, it should be simpler to add a newly defined service into what would be a live "menu" of services.  

You may share this with the list as you see appropriate. 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Wed, 27 Nov 2002 16:04:53 -0500

At
>I also believe that the compendium should be a workgroup document.  I 
>would propose that in order to simplify the document and give it more 
>value, perhaps we can change it into more of a high level outline.  That 
>is, start by defining the categories, then the services related to each 
>category.  The detailed service description could be in another document. 
>This would be similar to the work being done in sipping as relates to 
>conferencing.
>
>There has been effort expended to pull this document together and I hate 
>to see it wasted.  In addition, should the idea of an overall services 
>document with the details in individual service detail description 
>documents be implemented, it should be simpler to add a newly defined 
>service into what would be a live "menu" of services.
>

Actually this is a excellent suggestion but may I suggest that it take the 
form of a "Requirements for enumservices"  This is a well known tried and 
true IETF model and one that is being used with great success in SIPPING.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<