Subject: [Enum] Enumservices categories (COMMON, X-, P-, ...)

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 3 Mar 2008 14:41:23 +0100 (CET)

Hi,

While reading RFC3761bis and writing the IANA registration 
procedures, some idea crossed my mind:

To fulfill all the (known) requiements of Enum users, it make sense to 
split Enumservices in different categories. So far I see a need for three 
of them:

1. Ordinary (COMMON) registered Enumservices:
    - Normal IANA Registration procedures apply
    - No prefix

2. Registered Enumservices for Trial/Experimental:
    - IANA Registration procedures for Trial/Experimental apply
    - Prefix: 'X-'

3. Private Enumservices:
    - Not registered anywhere
    - Prefix: 'P-'

The last category would not need any special standardization document, as 
IMHO a short definition in RFC3761bis about usage of "P-" in private 
environment is sufficient.

Anybody second this proposal?

Objections?

cheers,
  Bernie

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

---

From: Duane <[email-masked]>
Date: Tue, 04 Mar 2008 00:54:40 +1100

>     - IANA Registration procedures for Trial/Experimental apply

This is already specified for private use in other RFCs, including
things non-enum related such as email headers...

-- 

Best regards,
 Duane

---

From: lconroy <[email-masked]>
Date: Mon, 3 Mar 2008 14:29:01 +0000

Hi Bernie, folks,

   this will require a small update to the current version of RFC  
3761bis, but IMHO
is a very good plan. If one sees such a "P-xxxx" Enumservice on the  
Internet, then
it SHOULD be ignored. I like this idea.

It also codifies the idea that stuff floating around on a private  
infrastructure
does not need to be specified other than between those "consenting  
networks".

This is different from X-xxx, where at least a notification that it  
is being used
(with some optional information on what it does) is preferred - to  
summarise my
understanding of the position at the YVR ENUM WG meeting.

all the best,
   Lawrence

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 Mar 2008 11:27:59 -0500

Chair hat off .. 

Makes sense to me ! I like it too...

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of lconroy
>  Sent: Monday, March 03, 2008 9:29 AM
>  To: Bernie Hoeneisen
>  Cc: [email-masked]
>  Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...)
>  
>  Hi Bernie, folks,
>

---

From: Duane <[email-masked]>
Date: Tue, 04 Mar 2008 07:02:28 +1100

> Makes sense to me ! I like it too...

Does it make sense to re-use something in common usage in email to
create an inconsistency as well?

-- 

Best regards,
 Duane

---

From: lconroy <[email-masked]>
Date: Mon, 3 Mar 2008 22:39:02 +0000

Hi Dwayne, folks,
Short answer is: Yes, because it isn't.

The issue is not confusion with mail headers. There is a difference  
between email
headers (or even old-style proprietary MIME types) and Enumservices  
inside NAPTRs.

We already have X- Enumservices. We have had these since RFC 3761. To  
avoid
clashes, we invite folk to at least tell people what Enumservices  
they use
on the Internet, and optionally to tell them what these Enumservices do.
(Yes - this invitation is intended for everyone - including me and  
you :).

The proposal (for P- Enumservices) is quite different. These are  
Enumservices
that should never be on the Internet - no-one outside the walled  
garden should
see them. If a client DOES encounter one, it should be ignored. The  
URI may not
be interpretable outside the walled garden, so even if you think you  
know what
the Enumservice does, don't try it at home.

Contrast this with a NAPTR containing  x-voice, or x-im, or whatever.  
I know
how to handle that, it hasn't escaped from a zoo, and so I can use  
it, out
there on the Internet.

Seems to me like P- is the hidden piece in the puzzle.

all the best,
   Lawrence

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 4 Mar 2008 10:12:40 +0100 (CET)

Hi Duane et al.

On Mon, 3 Mar 2008, lconroy wrote:

> between email headers (or even old-style proprietary MIME types) and 
> Enumservices inside NAPTRs.

I also do not see any dependency issue between ENUM NAPTR types and other 
codepoints. For example SMTP does not have a too clear concept for mail 
headers (IMHO), i.e. 'X-' is used for different purposes:

1) widely used headers e.g. X-BeenThere, X-Mailer

2) private style headers e.g. X-MyCom-MailScanner-SpamCheck, 
X-Google-Sender-Auth

Should we really blindly take over concepts discovered to be problematic 
elsewhere  just for the sake of consistency? I'd say, Bad Idea!

> Enumservices that should never be on the Internet - no-one outside the 
> walled garden should see them.

I guess it cannot be avoided that P- Enumservices appear outside the 
walled garden. After all, it is in DNS, which normally is public.

Therefore the direction "clients SHOULD ignore them, if not part of to 
walled garden" is rather important.

> If a client DOES encounter one, it should be ignored. The URI may not be 
> interpretable outside the walled garden, so even if you think you know 
> what the Enumservice does, don't try it at home.

cheers,
  Bernie