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

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 9 Jul 2002 13:38:14 +0100

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

I have to say that this is a classic case of putting the cart before the
horse. *First* you need to decide what information you actually want to put
in the enumservice field. Once you've done that, addressing syntax issues
is fairly simple.

A couple of weeks ago, Robert Walter wrote:
> I reiterate that the purpose of the service field is to allow an
> application to rapidly select NAPTR records that are meaningful
> to its purpose and/or function.

That, I would suggest, remains key.

Okay, what I'm seeing people want is:
(1) Service, though this isn't a particularly well-specified concept.
(2) Protocol.
(3) URI scheme. Are these two the same ?
(4) Additional information.
People also seem to have different views of what should be mandatory and
which order things would come in.

When I think through what I want to see in a NAPTR record, what I come up
with is:
(A) What kind of interactivity do I want ?
  - I am sending something for the recipient to study (email, voicemail);
  - I want information from the recipient (web site, public key);
  - I want to interact with the recipient (phone, chat).
(B) What type of material do I want to send ?
  - text
  - text and graphics
  - voice
  - video
  - application-specific data
(C) What "situation" of the recipient do I want ?
  - work
  - home
  - urgent, wherever she is
  - when she's got time

In some sense all of these are "service".

I don't particularly care about the URI scheme, because that will be in
the resulting URI. I don't think I care about "protocol", because that's up
to my software and it depends on the URI as well. I *can* see the advantage
of additional data.

One other note to make is that the indirections available in the system
mean that the eventual URI can vary enormously even without changing the
NAPTR record. So any description system has to allow for alternatives.

----

Putting all this together, and adding some other thoughts that I haven't
expressed here but are based on previous discussions, let me try to come
up with some semantic proposals.

(1) The enumservice field should provide information to allow the user (or,
more precisely, the application software) to know whether or not it's worth
expanding the NAPTR record to find the resulting URI.

(2) The field should be able to hold one or more descriptions which are
alternatives. If the user "likes" any of the descriptions, it is worth
expanding the NAPTR record. The case of no descriptions is useful: it means
that things are too complicated to just describe here.

(3) Each description consists of a number of components. The NAPTR record
is only "interesting" if all the components match the user's requirements.

(4) There is no consensus on the relative importance of the components. nor
which are essential. This says to me that *all* the components should be
optional, with an omitted component meaning "always interesting".

(5) The ordering of the components is not intrinsically important. It can
be left for second-order or syntactic considerations.

(6) Therefore the obvious way to distinguish the different sorts of
component is to use different delimiters.

This produces the following top-level syntax:

    service-field = "E2U" *("|" description)
    description = 1*(component)
    component = delimiter value

Note: I've used | rather than + because RFC 2396 allows - and + in URI
scheme names. Therefore these are bad characters to use as delimiters.
If people really want "E2U+", then the correct syntax is:

    service-field = "E2U" [ "+" description *( "|" description )]

Now we can look at the specific components:

* Service. This wants to be one of a list of registered names. The name
  indicates the format and type of data being transferred.
* Interactiveness. I think this is a useful concept, over and above
  service. That is, rather than having "voice" and "voicemail" as
  separate services, let them be "voice-chat" and "voice-send". Except
  that, since there are only three cases, we can use single characters
  to indicate them.
* Situation. This would also be a list of registered names, just so that
  software had an idea of what they mean.
* URI scheme. 
* Protocol. If this is actually useful, separate from URI scheme, then
  once again, it is a list of registered names.
* Additional information. This is the one thing that is unstructured, since
  it's essentially a comment.

However, I would be loath to claim that that's all we're ever going to
want, and some attempts to construct examples make me wonder whether more
will be needed. My inclination is therefore to combine service, situation,
and protocol into a single concept of "property", which is something that
is defined and can be tested for.

When it comes to the ordering of components, I can see the following
points.

(7) There are benefits to forcing a standard order, though they are
relatively minor.

(8) If two descriptions differ in only one or two components, it seems
silly to repeat the whole thing. So some kind of "factoring" would be
useful. In particular, there's going to be a certain amount of use for
things like "voice at work or voicemail at home". But we don't want
anything that will require major parsing effort.

Okay, let me try to put all this into a formal proposal for text.

========

Syntax:

    service-field   = "E2U" [ "+" alternative *( "|" alternative )]
    alternative     = property-set *uri / 1*uri
    property-set    = property-list *("/" property-list)
    property-list   = direction / [direction] property *("," property)
    direction       = d-get [d-send][d-talk] / d-send [d-talk] / d-talk
    d-get           = "<"
    d-send          = ">"
    d-talk          = "#"
    property        = name
    uri             = ":" URI-scheme
    URI-scheme      = name
    name            = 1*32n-char    ; names beginning "x-" are reserved
                                    ; for experimentation; all others must
                                    ; be registered
    n-char          = ALPHA / DIGIT / "+" / "-" / "."
    comment         = "(" *(c-char / comment) ")"
    c-char          = <any character except "(" or ")">

Note: the non-terminal "comment" does not appear in the grammar, but it is
the intent that it may appear anywhere after the initial "+" except within
a "name". This requires scanners to ignore delimiters within parentheses;
if this is a problem, alternative approaches can be developed, so please
don't see it as a show-stopper.

Semantics of service-field:

The service-field states that, when the NAPTR record is expanded, it will
result in a URI that is described by one of the alternatives (which one
is not stated and may vary; it might be described by more than one).

The "/" notation is a way to abbreviate alternatives that have the
same URI-schemes. That is:
    >home,urgent/>#work:tel
is the same as:
    >home,urgent:tel|>#work:tel
and might describe a telephone number that can be used to call the
recipient at work, or to leave messages either at work or (if urgent) at
home.

A "basic alternative" is one that has no "/" delimiters. It says that:
- the URI can be used for the direction(s) specified (with none being
  the same as all);
- if one or more URI-schemes are specified, the URI will use one of them;
- the URI will have all the properties specified.

Semantics of directions:

<  the URI is intended for use in obtaining data from a server without
   human interaction at the recipient's end (e.g. an HTTP: URL).
>  the URI is intended for use in sending an item of data to the
   recipient without immediate response (e.g. a mailto: URL).
#  the URI is intended for use in real-time interaction with both
     parties (e.g. a telephone call).

Semantics of properties:

Properties form a namespace which IANA is requested to maintain. Values
beginning with "x-" are for experimentation and MUST NOT be registered.
Other values can be registered by IANA as a result of this specification
or by being defined in another RFC.

This specification registers the following properties:

    voice    - the URI is for voice communications (telephone, voice mail,
               recorded information services)
    text     - the URI is for text services (email, chat)
    video    - the URI is for video services
    pubkey   - this URI should be used for obtaining a public key
    business - the URI is associated with business rather than home
    home     - the URI is associated with home rather than business
    mobile   - the URI is for a communications device that travels with
               the recipient
    fixed    - the URI is for a communications device which can only be
               used when the recipient is present
    remote   - the URI is for a "fixed" communications device which the
               recipient can nevertheless sometimes access from other
               locations
    urgent   - this URI should be used when the matter is urgent
    deferred - this URI should be used where an indefinite delay will
               not cause problems.

========

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change

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