Enumservices categories (COMMON, X-, P-, ...)

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,

Re: Enumservices categories (COMMON, X-, P-, ...)

Bernie Hoeneisen wrote:

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

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

--

-- 

Best regards,
 Duane

Re: Enumservices categories (COMMON, X-, P-, ...)

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

On 3 Mar 2008, at 13:41, Bernie Hoeneisen wrote:
> 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  

Re: Enumservices categories (COMMON, X-, P-, ...)

Chair hat off .. 

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

>  -----Original Message-----
>  From: enum-bounces <at> ietf.org [mailto:enum-bounces <at> ietf.org] On Behalf
>  Of lconroy
>  Sent: Monday, March 03, 2008 9:29 AM
>  To: Bernie Hoeneisen
>  Cc: enum <at> ietf.org
>  Subject: Re: [Enum] Enumservices categories (COMMON, X-, P-, ...)
>  
>  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.

Re: Enumservices categories (COMMON, X-, P-, ...)

Richard Shockey wrote:
> Chair hat off .. 
> 
> 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

Re: Enumservices categories (COMMON, X-, P-, ...)

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

Re: Enumservices categories (COMMON, X-, P-, ...)

Hi Duane et al.

On Mon, 3 Mar 2008, lconroy wrote:

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

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!

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

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.

ENUM Final Agenda.

Most of the time probably should be spent on RFC 3761 and any last issues in
the ENUM Service Registration documents etc.

****************************

IETF 71 Telephone Number Mapping (ENUM) WG Agenda 

THURSDAY, March 13, 2008 

1510-1610 Afternoon Session II
Franklin 3/4	INT	savi	Source Address Validation Improvements BOF
Franklin 11/12	RAI	avt	Audio/Video Transport WG
Franklin 6/7	RAI	enum	Telephone Number Mapping WG
Salon I	SEC	smime	S/MIME Mail Security WG

Chair(s):
Patrik Faltstrom <paf <at> cisco.com> 
Richard Shockey <rich.shockey <at> neustar.biz>

WG Secretary:
Alexander Mayrhofer <alexander.mayrhofer <at> enum.at> 

RAI Director(s):
Jon Peterson jon.peterson <at> neustar.biz
Cullen Jennings fluffy <at> cisco.com

RAI Area Advisor:
Jon Peterson jon.peterson <at> neustar.biz

Comments on RFC3761bis - draft-ietf-enum-3761bis-02.txt

_______________________________________________
enum mailing list
enum <at> ietf.org
https://www.ietf.org/mailman/listinfo/enum

I-D Action:draft-ietf-enum-calendar-service-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title           : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services
	Author(s)       : R. Mahy
	Filename        : draft-ietf-enum-calendar-service-04.txt
	Pages           : 7
	Date            : 2008-03-10

This document registers a Telephone Number Mapping (ENUM) service for
Internet Calendaring Services.  Specifically, this document focuses
on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt