[IANA #171390] FW: Revision of IANA Enumservice registry

Bernie,

The XML chunk for the new version of the registry is not quite completed yet but we are working to 
have that done.  We need some help answering some questions to help transition from the current 
registry to the revised registry.  See below.

Please let me know if I've missed something.  We've been exchanging lots of information and I want to 
make sure that I'm not missing anything.

Michelle



Here is a list of questions that must be answered before we can convert
to the new style (i.e. draft-ietf-enum-enumservices-guide):

- In the old style, registrations have a "Service Name". This is absent
in the new style. It isn't clear if this is intentional. If so, do we
remove the column or do we leave it as optional?

- I'm having trouble understanding the following instruction from
Section 11.1.3:

   Each Enumservice starts with a caption, which is composed of Type and
   Subtype, separated by a colon; e.g. if the Type is "foo" and the
   Subtype "bar", the resulting caption is "foo:bar".

Do we need to create a new column such as the following?

+---------------+--------+----------+-...
|    Caption    |  Type  | Subtype  |
+---------------+--------+----------+-...
| "ifax:mailto" | "ifax" | "mailto" |
+---------------+--------+----------+-...
|      ...      |  ...   |   ...    |

- No registration in the old style have an "Enumservice Class". This is
required in the new style. What do we do? Some ideas:
  - Go to authors of old-style registrations and ask them to define one.
  - Assuming all previous registrations belong to the same class, assign
this class.
  - Make the class optional in the schema and trust IANA editors to
provide one for new registrations. This reduces the schema's
bug-catching power.

- This note in Section 5.2 seems to contradict current IANA practices:

      Note: You MUST NOT put email addresses in the authors field of an
      IANA Registration.

Does this mean one of the following?
  - There will be no registration contact info.
  - There will be separate columns "Author" and "Registrant", the latter
containing contact info.
  - Contact info is expected to be extracted from the registration document.
  - The note should be revised.

- Some old-style registrations have no registration document.

- Some old-style registrations have no type.





On Fri Oct 10 12:47:26 2008, [email protected] wrote:
> Hi Michelle
> 
> Ist is feasible to get an example XML chunk by TODAY so that we
> can work on it during the weekend? (see also below)
> 
> cheers,
>   Bernie
> 
> ---------- Forwarded message ----------
> 
> 1)
> 
> > If someone writes a document to add a new registration to the enum-
> services
> > registry, it would be great if they included in their document an
> XML chunk
> > that IANA would simply cut and paste in the registry itself after
> the
> > registration is approved. The spec itself does not have to be in
> XML.
> 
> If you provide us with an example, we'd be more than happy to include
> an XML
> chunk to -13. (See also 5) further below)
> 
> [...]
> 
> 5)
> 
> > Also, for the document, having the xml chunk for the registration
> itself
> > would be very useful. We can help with providing what that should
> look like
> > as we convert the registry in the next few weeks.
> 
> As the IANA template of the Enumservice registry is about to change, I
> recommend to wait.
> 
> draft-hoeneisen-enum-enumservices-transition-01 is addressing these
> changes for
> the existing services. If we get an example of an XML chunk, we'll
> publish a
> revision of the enumservices-transition I-D, which will include all
> existing
> registrations (including the template changes) as XML chunks.
>