[Enum] Preliminary notes from IETF ENUM WG meeting in Yokohama

[Richard Shockey <[e-mail]>]

Once again thanks to Jay Hilton for a excellent job of note taking...

If you have any comments additions or clarifications please post.


#############

1.0     AGENDA BASHING

Richard Shockey  (Neustar) and Patrik Falstrom (Cisco) co-chairs.
Agenda accepted w/o modification.

1.1     IU-T SG2 developments:
         SG2 has reached temporary agreement on registration of national 
country codes in e.164arpa.  Six nation states have registered so 
far.  Population of e164.arpa is proceeding.  We need to come to agreement 
on ABNF syntax. (See below).
         Patrik Falstrom:  RFC2916bis agreement could be submitted to the 
next SG2 meeting if we can get agreement before next SG2 meeting.

2.0     RFC2916bis -01 REV - Faltstrom/Mealing
The goal of these discussions is to give the document authors definitive 
direction on the draft so that it can begin to move forward with all 
deliberate speed.  The 01 revision is in the hopper so we should see it 
shortly.
Patrik Falstrom:  The ABNF Syntax is as follows:
        service_field = “E2U” 1*(“+” enumservice)
        Enumservice = service [“:” protocol]
        Service  = 1*32(alpha / digit)
        Protocol = 1*32(alpha / digit)
Want to get agreement on the definition of  “service” and 
“protocol”.  Services will have to be  registered via an RFC (one service 
per RFC).
Many people on mail list want to be more specific on the definition of 
service and protocol.

2.1     DISCUSSION:

Jon Peterson:  which should be the mandatory element, service or protocol 
or both?  Will 2916 define this?  What will the URIs tell us about the service?
Patrik Falstrom:  We are describing the URI, i.e. what might be reached 
when you go to this URI.
Dave Crocker:  URIs are used in two different ways.  One talks about the 
service and the other talks about the protocol.
Rich Shockey:  We are defining a verbose description of the namespace.
Dave Crocker: We need a three level name space definition.
Andy Z: Level of specificity is up to the service provider to define.
PF:  The namespace is used to describe the URI.
JP:  Whatever it is that is being represented by the description should 
have whatever level of specificity that is required to fully define the URI.
Andy Z:  We are really trying to define the service behind the URI.
Richard Stazney: The subscriber wants a service that could have multiple 
URIs.  We should stay with the generic services in RFCs.  We should have a 
common consensus of how to write these things.  Need a general principle 
agreed to go forward.
JP:  Leave it up to people as to how they want to define these 
things.  Want to be able to just specify E2U + sip.
Greg V:  May need to repost an expired Operations Document that addresses 
issues we may need to discuss.

3.      The ENUMSERVICE's documents [Stastny/Conroy/Brandner]

It is clear from the mail list discussions that these documents have 
generated the most discussion and we want this meeting in Yokohama to come 
to some reasonable consensus on the next steps for these documents.  We are 
close to agreement on several points but we have several proposals on what 
is the proper ABNF syntax to use and the exact terms and definitions to be 
used in describing the data elements.  For instance, there is still 
disagreement on URI scheme vs. a more expanded 'protocol' element for the 
mandatory portion of the enumservice field.
Presenters were asked to be prepared to precisely define their proposals 
and the rationale for them.

3.1     Categorical enumservices (This was discussed right after the 
2916bis discussions)
http://www.ietf.org/internet-drafts/draft-brandner-enum-categorical-enumservices-00.txt

This document defines the set of enumservices describing "high level" 
communications categories.  These are used as elements within the services 
field of NAPTR resource records within ENUM domain space. Each category 
identifies a kind of communications service in which an end user might want 
to engage using the associated resource. It includes the expected "low 
level" service that comes under each category, together with a list of the 
URI schemes that are appropriate for use with each categorical enumservice.
Uses matrices that have low-level teleservices like voice, video, fax, 
etc.  Or high-level categories (groups) like talk, msg, info , etc.
RS: What is a specific syntax that you would propose?  What PF has 
proposed, will it meet your needs?
Rudy: Yes the proposal will meet this need.
RS:  How many fields are necessary to describe the options you are trying 
to define (PF provides two in 2916bis now).
Rudy: 2 would be okay.
JP:  Do you want to limit what could be in the service/protocol fields?
Rudy:  Yes, want to limit what can be there.  Want to keep generality.
JP: Concern that generality proposed will allow you to define accurately 
what is expected / provided with the URI.  Comes down to what is innate to 
these URIs.  Should not limit what goes into foo (the mandatory side of the 
enumservice).
Andy Z: If we can support E2U + sip, then that would solve the concern.
RS:  sip can be service and protocol at the same time.
PF: You can have
         E2U+voice:sip
         E2U+voice:h323
         E2U+sip
         E2U+voice:sip+sip+voice:sip:rtp
Scott Bradner:  It seems that Andy and PF are saying the same thing.
Richard Stazney:  We do not need to be specifying protocols, this is not a 
problem for enum.
Dave Crocker: We need to have a concrete use in mind to go forward.  Syntax 
needs a specific use to make sense.  Proposal to create some concrete 
proposals for real use and that will help you define the syntax.  We are 
having an abstract naming debate w/o these concrete uses.
Dave C:  Sounds like we do not have specific requirements.  We will loose 
time and resources until we define these concrete examples.
PF and RS:  We have several specific examples on the mail list and in 
earlier drafts.
Andy:  There are least two camps that  want to use enum.  One that already 
knows what protocol they are looking for.  The other is that it has an 
idea, but not specific idea of what will be used.
JP:  Do not feel this is just a name space problem.  We need to tell the 
client what to do with the information.  People will use this string to 
arrive at a record.
RS:  No consensus yet.  Do we need to specifically define foo and bar?
PF: Can we come up with a proposal to specify what foo and bar mean to the 
mailing list?  We need to include this in 2916bis.
Andy Z: foo and bar should be in order if there is a hierarchical reason.
Scott B:  I have not seen a set of requirements yet to bound this 
discussion.  We may be putting the cart before the horse.
R Stazney:  We can come up with examples.  And also, he feels that the foo 
defines the bar.
PF: That is what 2916bis says at this time.
Greg V:  I have a draft in development (VPIM?) that is waiting on 
syntax.  Need syntax, just decide so we can go forward.
R Shockey:  If we are going to go more hierarchical …
Andy:  Hierarchy is the rat hole we have been in for months on the list.
Greg: Looking for a tag for enumservice to define services.  Do not see nay 
examples where a client has any benefit in using a hierarchy.
J Peterson:  Lets go ahead and look at a document that looks at various 
foos and bars.  We seem to agree on the definition and level of agreement 
in 2916bis.
Proposal from Patrik:

A:
Service_field    = “E2U 1*(“+” enumservice)
enumservice     = foo*[bar]
foo             = 1*32(ALPHA / DIGIT)
bar             = “:” foo

B:
Service_field   = “E2U 1*(“+” enumservice)
enumservice     = 1*32(ALPHA /DIGIT)
Richard Shockey: Do we have consensus that A represents how 2916bis should 
be structured?  Hum was yes, no negatives!  AGREEMENT!!!
Greg:  There is no issue of sub addressing in the document.  In the world 
of PBXs, this could be an issue.  Greg will provide some text to progress 
this issue.
RShockey:  Are there any other IANA requirements for registration?  None 
identified.


3.2     Scenarios for ENUM and ENUM-like Systems
http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt 
(Informational)

This is an informational document and was noted, but not discussed.
This document analyzes scenarios for ENUM and ENUM-like Systems, both for 
ENUM used by End Users and also for ENUM-like Systems used by operators for 
network-specific or infrastructure purposes. It also gives some examples of 
ENUM Usage and proposes a new URI scheme to be used with ENUM. This may 
allow a way forward for the definition of ENUM Services and also for the 
definition of the required URIs and their parameters.
This document therefore deals with information stored in the ENUM and the 
look-up process and the usage of the information retrieved in this look up 
process.  It does not deal with the administrative process related to the 
population of the relevant zones.

3.3     Analysis of the Usage of ENUM and ENUM Services
http://www.ietf.org/internet-drafts/draft-stastny-enum-services-analysis-00.txt 
(Informational)

This is an informational document and was noted, but not discussed.
This document analyzes the usage of the URI-schemes, services and 
"enumservices" under discussion for the ENUM System. It tries to combine 
the existing proposals for "enumservices" and proposes examples of a 
compatible approach as a way forward for the definition of the 
"enumservices" to be used in the ENUM trials planned.

4.      The 'enum' URI
http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt

This document specifies the "enum:" URI scheme. This URI is intended for 
use where a resource can be returned by evaluating the URI value using the 
ENUM DDDS application. It also includes a definition of an optional URI 
parameter to indicate a list of enumservices that should be considered in 
the returned response to the ENUM query. Syntactically, it uses a subset of 
the format defined for the "tel:" URI scheme.
PF: This implies a different interpretation of the tel URI inside or 
outside of the lookup scheme.  Also, are you somehow concatenating all of 
the tel URIs?
RStazney:  One reason for the enum URI is to clarify when to go to enum and 
when you can just dial a number using the tel URI.
PF:  Are you saying that the Tel URI means do not do an enum query?
RShockey: Not necessarily.
PF:  This means that the context determines when the tel URI means to stop.
Jpeterson:  This should be tel URI parameters (RFC2806bis needs to have 
these), not enum.
Rstazney:  A tel URI gives you a telephone number.
Andy:  This is a good time to add this parameter to the Tel URI RFC.
RShockey:  We need to take this to the list.

5.0     OPTIONAL IF  there is any time left
Did not have time for this discussion.

The tel URI...
http://www.ietf.org/internet-drafts/draft-brandner-tel-svc-00.txt
This document describes the 'svc' parameter for use within a 'tel:' 
URI.  This is intended to indicate the uses to which a resource 
identified  in the 'tel:' URI can be put. It is an optional parameter, and 
if not understood can be ignored. It allows the user to "hint" at the 
features supported at the resource. There are guidelines for how this 
parameter might be used, and for expected behavior on detection of this 
parameter.

- End of Notes -



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza   Bldg 10    Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
<http://shockey.us > ; <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


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