Subject: [Enum] Proposed new ABNF

From: Patrik Fältström <[email-masked]>
Date: Mon, 15 Jul 2002 14:17:07 +0900

At the IETF meeting in Yokohama, the following ABNF is proposed as a
strawman proposal which is to be used for further discussions for
registration documents.

Anyone with objections should on this mailing list say so.

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

   paf

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 15 Jul 2002 10:36:35 +0100

>   foo           = 1*32(ALPHA / DIGIT)

I object.

As I pointed out in my long email recently, "+" is a valid character in a
URI protocol field. Indeed, none of the issues I raised in that email are
addressed in that grammar.

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 15 Jul 2002 20:43:11 +0900

>>   foo           = 1*32(ALPHA / DIGIT)

Point taken. Let me explain.

> addressed in that grammar.

The reason why I still use '+' even though it is a valid character in a URI
protocol field is because I don't see any connection between the URI syntax
and the syntax for the enumservice.

BUT, the important part are your other issues.

At the discussion today, we walked up and down the path of questioning
whether the various fields in the namespace we define (because we are
defining a new namespace with N levels, and N can be one, two or three)
should be well defined or not in the base document.

One can say that one camp wanted more constraints, some people wanted less.

At the end, we agreed that the _base_ document doesn't and should not be
more specific. It is when registering the "foo":s the specifics have to be
written.

So, what you (and others) want to do is possible to do with the syntax
above -- modulo the fact that you wanted the enumservice be divided in
multiple fields, and each field have a specific meaning.

As I said above, there was another camp (not larger, not smaller) which
strongly objected, and said that the base document should NOT be too
specific. The example was "sip" which itself can do negotiation of various
kind, so it could be interesting to "just" as enumservice say that the
actual negotiation is to be done with the SIP protocol.

A similar negotiation can be done using LDAP...

Anyway. The point of locking the _syntax_ like the above for now, was that
we to be able to move forward need explicit examples of documents
specifying specific enumservices -- and our guess at the meeting was that
both people which want constraints on the enumservice (like you) and the
one that doesn't want (like some others) BOTH can be accomodated with the
given syntax.

Now, this was just an explanation. I am not trying to shut you up. Now,
given this explanation, do you still think this is a mistake _for_now_?

    paf