Subject: [Enum] Propoals on ABNF syntax for discussion in Yokohama

From: Richard Shockey <[email-masked]>
Date: Mon, 08 Jul 2002 13:34:50 -0400

Perhaps the core issue for Yokohama is coming to rough consensus on the 
ABNF syntax for the NAPTR enumservice field

After reviewing previous mails I wanted to make sure we all understood the 
2 options proposed.

ABNF Syntax for enumservice
–       Faltstrom/Mealling

service_field = "E2U" + 1*(“+” enumservice)
enumservice   = service [":" protocol]
service       = 1*32(ALPHA / DIGIT) [mandatory]
protocol      = 1*32(ALPHA / DIGIT) [optional]

ABNF Syntax for enumservice
–       Brandner/Stastny/Conroy

servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo]
uri-scheme   : "tel" | "mailto" | "sip" | "ldap" | ... etc etc  [mandatory]
enumservice  : "voice" | "video" | "email" | "sms" | "talk" | "msg" | etc 
etc [optional]
addinfo      : "home" | "business" | "mobile" | etc etc [optional]
other        : <TOKEN>

Do I have this right ... I wanted to have some slides ready to illustrate 
the options?

Additions Modifications etc?

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: "Robert H. Walter" <[email-masked]>
Date: Mon, 8 Jul 2002 14:24:39 -0400

Richard,

May I suggest that you drop the [mandatory]/[optional]
commentary because:

1. The ABNF already illustrates this...
2. It may be confused with an optional ABNF production.

Alternatively, use the ABNF comment ";" specifier to drive
point home for those that are unfamilar with ABNF i.e.

  service_field = "E2U" + 1*(“+” enumservice)
  enumservice   = service [":" protocol]
  service       = 1*32(ALPHA / DIGIT)  ; mandatory
  protocol      = 1*32(ALPHA / DIGIT)  ; optional

Also the "other" production is not reference anywhere, so
it should be eliminated i.e.

  servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo]
  uri-scheme   : "tel" | "mailto" | "sip" | "ldap"  ; mandatory
  enumservice  : "voice" | "video" | "email" | "sms" | "talk" | "msg"  ; optional
  addinfo      : "home" | "business" | "mobile"  ; optional

Regards,

Bob Walter
NetNumber, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Richard Shockey
> Sent: Monday, July 08, 2002 1:35 PM
> To: [email-masked]
> Subject: [Enum] Propoals on ABNF syntax for discussion in Yokohama
>
>
>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 08 Jul 2002 20:26:10 +0200

--On 2002-07-08 13.34 -0400 Richard Shockey <[email-masked]>
wrote:

> service_field = "E2U" + 1*(?+? enumservice)

This should be:

 service_field = "E2U" + 1*("+" enumservice)
 enumservice   = service [":" protocol]
 service       = 1*32(ALPHA / DIGIT)
 protocol      = 1*32(ALPHA / DIGIT)

     paf

---

From: Richard Shockey <[email-masked]>
Date: Mon, 08 Jul 2002 14:59:04 -0400

>   protocol      = 1*32(ALPHA / DIGIT)  ; optional

thanks my mistake .. but what do you think about reversing the order?

IYHO is a 'label' function useful?

>   addinfo      : "home" | "business" | "mobile"  ; optional

Well yes this is not in a draft,  but it was offered up by Rudolf on the 
list  as a rough approximation of the position taken by him Larry and 
Richard in their drafts... I'll let them A/M/D as necessary ...

> >        Faltstrom/Mealling
> >        Brandner/Stastny/Conroy

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 08 Jul 2002 20:40:48 +0200

> 2. It may be confused with an optional ABNF production.

It should not be there. The ABNF is clear enough.

  paf

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 8 Jul 2002 21:50:34 +0100

Hi Rich, Folks,
  Hmm... framed - me?
I have said this before, but, in the words of a famous (U.K.) Liberal
Politician, "One More Push"

First off - Please note that the URI-scheme or protocol or whatever
IS available, as Richard S pointed out ("just look to the left").

There seemed to be a strong view ->from others<- that this information
should be available within the service field. Personally, I still think
of this as a copy, but at this point a little duplication is acceptable.
Thus, I acquiesce in this situation. Note this word - it's descriptive.

->IF<- we are going to have uri-scheme in the services field, then it
is going to be a pain if implementors have to play "hunt the uri-scheme".

Thus, the argument went, if it's going to be there, then please can it
be the first element in the list. As the enumservices should be optional
(as pointed out by Rich, for privacy reasons), first is better than last.

However, as there is no URI-scheme in some NAPTRs (e.g. non-terminals),
we could do with some way of indicating that it isn't there. Hence the
proposal that it use a different delimiter from the enumservices.

In this case, an implementation would be easy even if both enumservices
and URI-scheme were independently included in some NAPTRs and not in others.

Thus, I didn't want URI-scheme in there as it's only a duplicate, but if
this keeps folks up at night we can copy it into the service field. I ->do<-
want a service (i.e. an indication of the end user's communications interest).
This is not generally available from the generated URI or any other information
in the NAPTR.

--------

Re. other - this seems to have been replaced by "etc, etc". Bizarre.
BTW, I note that the production in 2916bis seems to have been restricted to
32 characters that are digits or alphabetics. Not quite the same as TOKEN.
Finally, the enumservices shouldn't, IMHO, be enumerated explicitly in
a "real" framework ABNF as they will be defined in an RFC. These were only
->examples<- of candidate enumservice labels.

--------

Richard S proposed an add-info section to cover things like office/home/mobile
labels. I have no idea whether or not these will be useful (that's what trials
are for :), but *as long as we can find some sensible program and/or user
behaviour for them* it can be added without breaking anything, IMHO.
It has to be optional and I guess may not even be considered by some client
implementations. The add-info syntax could be appended to either of the ABNFs
you listed.

---------

The new version of 2916bis explicitly excludes implicit definition
of the "protocol" element, so we DON'T just have a copy of the uri-scheme.
Losing that is fine by me as I never liked it anyway.

The original tel enumservice draft was an attempt to define an enumservice
using the then proposed service field structure - on reflection, it's very
low level - IMHO, this was true for the sip draft as well, as what's really
happening in that draft is 'SRS', using the protocol indicated in the
generated URI-scheme (which is expected to be sip:). IMHO, with very slight
re-writing/expansion, the sip-e164 draft looks a good candidate for the
'SRS' enumservice definition. There's little point in a re-write of the
'tel' draft until it's clear quite what it's supposed to say.

So my only question is - "what's a 'protocol', how is it used, why on
earth would one ever need more than one in any single NAPTR, and have we
drifted beyond RFC2396 into specifying more behaviour that we can control"?

BTW, for an entertaining read on the 'plane, look out 3GPP's TS23.140 on MMS.
fetch from <ftp://ftp.3gpp.org/specs/2002-06/Rel-4/23_series/23140-470.zip>.
BTW, this implies that the server supports the FTP protocol.

Consider the architecture diagram therein - what protocol(s) exactly are
we supposed to specify in the NAPTR, and how are we going to enforce this
for the MMS enumservice?
(Hint - section 7 covers interfaces MM1, MM2, MM3, MM4, MM5, MM6 and MM7).

See y'all.

In reply to comments from...

At 2:59 pm -0400 8/7/02, Richard Shockey wrote:
>Well yes this is not in a draft,  but it was offered up by Rudolf on 
>the list  as a rough approximation of the position taken by him 
>Larry and Richard in their drafts... I'll let them A/M/D as 
>necessary ...
>
>>Regards,
>>
>>Bob Walter
>>NetNumber, Inc.
>>

-- 
All the best, Lawrence
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : legal relationship.