Subject: Re: [Enum] Re: I-D Action:draft-hoeneisen-enum-x-service-regs-02.txt

From: Bernie Hoeneisen <[email-masked]>
Date: Sat, 3 Nov 2007 11:08:32 +0100 (CET)

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?

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

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

cheers,
  Bernie

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Romek Szczesniak <[email-masked]>
Date: Mon, 05 Nov 2007 14:39:41 +0000

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

Comments appreciated,
Romek.

Bernie Hoeneisen 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!
> 
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".

>> registered services (so that ENUM clients do not break on receipt of 
>> such rules).
> 

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

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.