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

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

i'm one of the co-authors of the document. Please find my responses
inline:

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

Please remove the column. It was never really specified, and the ENUM WG
decided to remove it - it does not have any additional value.

> - 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, this is not needed for the registration - This was intended as a
"display headline" for the registration. The "caption" can be created
from Type and Subtype, as indicated in the text above.

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

We are working on a draft that assigns such Class information to all
existing Enumservices - see
http://tools.ietf.org/html/draft-hoeneisen-enum-enumservices-transition-
01

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

Contact info is expected to be expected from the registration document.
Please indicate if there are other preferences.
 
> - Some old-style registrations have no registration document.

Should be fixed by the transition draft.

> - Some old-style registrations have no type.

huh? Can you name one?
 
thanks,

Alex