Subject: [salud] Concern #2 and ABNF-syntax change proposal

From: Laura Liess <[email-masked]>
Date: Thu, 13 Sep 2012 14:27:27 +0200

Hi,

I have following questions/change proposals:

1) On how to deal with <private-name>s and the Concern #2:

To reach a compromise, I would propose to adopt Alfred's second
proposal to add a simple sequence number to reverse domain name, as
proposed in http://www.ietf.org/mail-archive/web/salud/current/msg00257.html
from June 29:

"IANA could delegate a branch of the salud namespace to a domain name
owner using a past year alone (that is related to activity of the
domain owner in this field), or a simple sequence number, as a
disambiguating component in the naming scheme."

An example would be
urn:alert:service:call-waiting:org.example.somecompany.1:abc.

Is this OK for you?

2) It seems to me that there are  small inconsistencies/ambiguities
concerning <private-name> in version 06 Section4, ABNF-syntax:

We have now:
           alert-URN        = "urn:alert:" alert-identifier
           alert-identifier = alert-category ":" alert-indication
           alert-category   = name
           alert-indication= name *(":" name)
           name = standard-name / private-name
           standard-name = label
           private-name = label "." label *[ "." label ]

     According to this definition:
         - org.example.somecompany  is a  <name>, so it can be an
alert-category, which I think we don't want.
         - In the example
urn:alert:service:call-waiting:org.example.somecompany.1:abc,
"call-waiting" and "abc" are both <standard-name>s. Also this is
correct from the syntax point of view,  we need to distinguish somehow
between  "call-waiting",  which is registered with IANA and  "a.b.c",
which is valid only inside somecompany.example.org and is not
registred with IANA.
Also in the same example "org.example.somecompany.1" is a
<private-name>.  I think  "org.example.somecompany.1" can not be used
alone, it is more a qualifier or prefix than a <name> ( it can not be
rendered).
In my opinion, the current syntax at least leads to some confusion, or
did I miss something here?

I would propose to change the ABNF-syntax so that the the meaning and
the registration process for them becomes more clear. Here is a
proposal:

           alert-identifier = alert-category ":" alert-indication
           alert-category   = standard-name/ (
reverse-domain-name-seq:private-name)
           alert-indication = (standard-name *(":" standard-name)) /
              (standard-name *(":" standard-name) 1*(":"
reverse-domain-name-seq) *(":" private-name) *(":"
reverse-subdomain-name-seq) *(":" private-name))
           standard-name =label
           private-name    = label
           reverse-domain-name-seq     = reverse-domain-name.seq-number
           reverse-domain-name= domain-name-label "."
domain-name-label *[ "." domain-name-label ]
           reverse-subdomain-name-seq     =
reverse-subdomain-name.seq-number
           reverse-subdomain-name= subdomain-name-label "."
subdomain-name-label *[ "." subdomain-name-label ]
           domain-name-label = let-dig [ *let-dig-hyp let-dig ]
           domain-name-label = let-dig [ *let-dig-hyp let-dig ]
           label            = let-dig [ *let-dig-hyp let-dig ]

The IANA registration proces is as follows:
   - <standard-name>s  must be registered with IANA.
   - <reverse-domain-name-seq>es must be registred with IANA by the
owner of the domain name obtained from <reverse-domain-name-seq> by
dropping the <seq-number> and reversing the reminder.
    - IANA delegates the registration process for <private-name>s used
behind a  <reverse-domain-name-seq> to the domain owner. When a domain
changes the owner and if the new owner intends to change the usage or
define new <private-names>, he must register a new
<reverse-domain-name-seq> with the same <reverse-domain-name> and
incremented   <seq-number>.
    - Domains owners should have an internal registration process for
<private-name>s and <reverse-subdomain-name-seq>s.
    - Domains owners may delegate the registration process for
<private-name>s used within subdomains to the subdomain owner.

The new syntax is quite long, I know, and it means a lot of changes in
the draft, but to me it is more clear this way. Maybe we can drop the
subdomain stuff and allow only one reverse-domain-name in an
alert-indication?
alert-indication = (standard-name *(":" standard-name)) /
(standard-name *(":" standard-name) 1*(":" reverse-domain-name-seq)
*(":" private-name) *)

Please let me know your opinion. I hope I am not completely wrong.

Thanks a lot
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Sep 2012 20:04:48 -0400

Laura,

I generally agree with where you are trying to go, but I'm not in love 
with the proposed syntax. Let me propose something else. It's more of a 
change, but I think in good ways.

alert-URN       = "urn:alert:" alert-identifier
alert-identifier= alert-category ":" alert-indication
alert-category  = label
alert-indication= standard-name / private-name
standard-name   = standard-part *(":" standard-part)
private-name    = [standard-name ":"] private-part *(":" alert-part)
alert-part      = standard-part / private-part
standard-part   = label
private-part    = label "@" dns-name ["(" version ")"]
dns-name        = label "." label *[ "." label ]
version         = DIGIT-2-9 / DIGIT-1-9 1*2DIGIT; 2...999
label           = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp     = let-dig / "-"
let-dig         = ALPHA / DIGIT
ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT           = %x30-39 ; 0-9
DIGIT-1-9       = %x31-39 ; 1-9
DIGIT-2-9       = %x32-39 ; 2-9

Key differences to prior attempts:

- I've switched from reverse-dns to regular dns names.
   I did this because it's more readable and I can no
   longer see any reason not to.

- I put the version number in, but made it optional,
   with values 2...999. (You can consider the default
   to be 1.) This way you only need to insert the version
   when it's not the first. (In practice this means you
   never need to put it in.)

- I was bothered by the fact that the individual parts
   that can be stripped away in looking for something
   understood were not syntactically distinguished.
   And I saw an opportunity after switching to forward
   dns, so I changed from foo.bar:baz to [email-masked].

- Everything after the <private-part> is scoped within the
   domain of the prior private name. (AFAIK this isn't
   really a change, but I want to make it clear.) The
   syntax now doesn't suggest that those parts are standard.

- I allowed switching to a second dns scope within the
   same alert-indication. I just did it because I could.
   I can remove it if desired. This allows one organization
   to "extend" the private names of another organization.

- I've used a lot of "unnecessary" symbols in the syntax.
   I did it mostly for readability. I also strived to
   leave in all those symbols that are used in the text,
   so it is hopefully largely unaffected.
   If people like this it can be cleaned up to remove the
   least necessary ones.

Some examples:

alert-info:urn:service
alert-info:urn:service:recall
alert-info:urn:alert:service:[email-masked]
alert-info:urn:alert:service:[email-masked]:bar
alert-info:urn:alert:service:[email-masked](2):baz
alert-info:urn:alert:service:recall:[email-masked]
alert-info:urn:alert:service:[email-masked]:bar:[email-masked]:baz

I see one major issue with this, or any form based on a version number:

I am concerned that we can't define the version number semantics in a 
way that will satisfy Albert. As used above, it assumes that the person 
using the dns-name has a way to know how many prior owners of the domain 
name there have been. There really isn't any way to know that.

The above syntax could be adapted to putting in something other than a 
version (such as a date). It would be nice to find something with a 
default that is sufficient most of the time. But I'm not certain that is 
possible.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Tue, 18 Sep 2012 16:31:50 +0200

Paul,

Thank you for the proposal and for all the work you put in it. I like
it. I like especially your idea with [email-masked].
I just have some questions, to ensure I understand you correctly.

> alert-part      = standard-part / private-part

[LL] What is the reason to have
     alert-part      = standard-part / private-part  instead of
     alert-part  = label / private-part  ?

My understanding here is that  <standard-part> behind a a
<private-part> is has nothing to do with the IANA registration, it is
scoped only within the domain of the prior <private-name>.  One can
use here any label he likes. Is this correct or did I miss something?

>   to "extend" the private names of another organization.
[LL]  Great,  I think this is a realy usefull new feature :-).
>   If people like this it can be cleaned up to remove the

[LL]  I would not remove anything. Readability is very important.

> I am concerned that we can't define the version number semantics in a way
> that will satisfy Albert. As used above, it assumes that the person using
> the dns-name has a way to know how many prior owners of the domain name
> there have been. There really isn't any way to know that.

[LL]. You are right. In my proposal, I assumed that domain owners
intending to use alert-info urns register the string
reverse-dns+version  with IANA  (I called it "prefix" there). Now it
is clear to me that this does not realy work.
> version (such as a date).
[LL] In my proposal,  I switched from "date" to "version" because
people said on the ML that "date" is too long.  Maybe we can use just
the "year"?

> It would be nice to find something with a default
> that is sufficient most of the time. But I'm not certain that is possible.
[LL] Probably there isn't anything we can do here. And you are right,
it's somehow ugly to add the date/year when they are unnecessary in
most cases ..

Thank you
Laura

>> proposed in
>> http://www.ietf.org/mail-archive/web/salud/current/msg00257.html
>> from June 29:
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Sep 2012 13:34:50 -0400

>       alert-part  = label / private-part  ?

Those are equivalent representations. I just did it for clarity.
("standard-part" has some implied semantics, while "label" not so much.)

If/when we come to an agreement that the ABNF describes what we want it 
to describe, then the ABNF can be tweaked in whats that don't change the 
set of valid strings, to suit everyone's biases. :-)

> use here any label he likes. Is this correct or did I miss something?

OK. Now I see why you asked the question above. Yes, I agree and 
intended that a standard-part behind a private-part is not "standard".
So my attempt to get the implied semantics right failed here. :-(

I can work on that later. As long as we agree on the intended semantics 
we can continue to discuss if the proposed *syntax* meets our needs.

> is clear to me that this does not realy work.

It could work if they register it. But I think we have a goal that they 
not need to register it. (Because they probably won't!) If they are 
willing to register, then there are easier schemes we can use.

Perhaps we should have the discussion of whether some system involving 
registration would be acceptable. Such a scheme would no longer need to 
involve dns names at all.

Maybe we could introduce a one-time registry for an organization, for an 
id that could be used to introduce a private name anywhere in here. Or 
perhaps we can find some existing identifier that many likely users of 
this would already have that we could use for this purpose. (Aren't 
there some global "organization" codes?)

	Thanks,
	Paul