Re: I-D Action:draft-hoeneisen-enum-x-service-regs-02.txt

Thanks for the comments, Bernie. My responses are inline.

Comments appreciated,
Romek.

Bernie Hoeneisen wrote:
> Hi Romek
> 
> On Thu, 25 Oct 2007, Romek Szczesniak wrote:
> 
>> draft-hoeneisen-enum-x-service-regs-02.txt. I haven't seen any 
>> discussion on it here so I thought I would.
> 
> Nice idea!
> 
> Inline some questions for clarification.
> 
>> (iii) when a client does not wish a service type to be evaluated by a 
>> standards-based ENUM clients.
> 
> I do not understand the use case you describe here. Could you please 
> enlighten this a bit?
> 
Currently someone who crafts an X-service has no specific reason to 
publish how my experimental service works. It can therefore be 
proprietary, defined for a specific client for a special yet to be 
defined usecase.

For example, most ENUM clients will not interpret E2U+x-rss it has not 
been defined or published it to the list as a service to be reviewed, 
Instead, they will either show it as an unrecognised service type or 
(more likely) ignore it completely. And yet,

"E2U+X-rss:http" "!^.*$!http://<rss-feed>!" .

could be valid (as RFC 3761, Sect. 2.4.2.1 states) "with the active 
agreement of the parties exchanging them".

>> I suggest that:
>>
>> 1. We specify that X- services SHOULD follow the same syntax as other 
>> registered services (so that ENUM clients do not break on receipt of 
>> such rules).
> 
> For what reason do you think ENUM clients would break?
> Do you mean the "-" char, which is not allowed as per RFC3761?
> 

I meant that a proprietary X-service which has not been approved may 
still be read by a standards-based ENUM client. As X-services need not 
follow RFC3761 to the letter, they have the capability to break them too 
using the regexp and replacement fields. On further thought, I am not 
sure that this is a problem.

By following the ENUM Experiences draft here, perhaps with an extra note 
for drawing up X-services, these should be reasonably well formed.

>> 2. Provide a standardised mechanism for service types (if needed for 
>> public use) to be appended to the list of Enum service types after 
>> review. This review period should be at most about 6 months (to 
>> prevent all service types remaining as X- ).
> 
> Do you mean any X-Enumservice should expire latest after 6 months and be 
> removed from the IANA registry?
> 

I state here that most implementors will lose interest in registration 
(or forget what they had registered) if the process takes too long. For 
me, this would be roughly 6 months.

The registration process has to be relatively quick to prevent 
implementors ignoring the registered E2U service types and only using 
X-service types.

> cheers,
>  Bernie