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

Alexander Mayrhofer wrote:
>> - 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.

We understand that the Caption field will not be present in the
registry's XML source data.

Now, on the presentation side of things, I want to make sure we really
understand what's desired. We could generate the Caption column from the
XML data so that it would show on the XHTML rendering available on
IANA's website.

It's a cosmetic issue exactly like showing the double quotes around Type
and Subtype, and the single quotes around the URI Scheme. These quotes
are not present in the XML data. They are automatically added when
converting to XHTML for presentation on IANA's website.

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

Thanks for the pointer. We'll make the class optional in the schema
until this draft is finalized.

>> - Some old-style registrations have no registration document.
> 
> Should be fixed by the transition draft.

We'll also make the registration document optional in the schema until
the transition draft is finalized.

>> - Some old-style registrations have no type.
> 
> huh? Can you name one?

There are two of them:

Service Name: "H323"
     URI Scheme(s): "h323:"
     Functional Specification:  See Section "3. The E2U+H323 ENUM
Service" of [RFC3762]
     Security considerations: see section "5. Security Considerations"
of [RFC3762]
     Intended usage: COMMON
     Author: Orit Levin
     [RFC3762]

Service Name: "pres"
    URI Scheme(s): "pres:"
    Functional Specification: see Section 4 of [RFC3953]
    Security considerations: see Section 6 of [RFC3953]
    Intended usage: COMMON
    Author: Jon Peterson (jon.peterson&neustar.biz)
    Any other information that the author deems interesting: See
    Section 3 of [RFC3953]
    [RFC3953]

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.