Subject: [salud] <private-name> format

From: Laura Liess <[email-masked]>
Date: Thu, 10 Jan 2013 09:19:10 +0100

Hi,

My understanding from the last discussions is that we think to have a
reasonable chance to get the IESG OK without doing major modifications
to existing implementations and to the algorithm in Section 9 if we
add the year to the domain-name in <private-name>s as in following
examples:

a) urn:alert:service:call-waiting:telephone.com~2013 or

b) urn:alert:service:call-waiting:telephone.com~13,

the URNs above representing the call-waiting Alert-Info URN used by
the company which owns the domain telephone.com during 2013.

   We also may have

c) urn:alert:service:call-waiting:telephone.com~13:foo

 and

d) urn:alert:service:call-waiting:telephone.com~12:foo:example.org~13

<private-name>s are not registred with IANA.

Is my understanding correct or did I miss something?

Are there additional examples which are relevant for the ABNF-syntax?

I am not sure about trying to leave out the year when the enterprise makes
sure that it is the first owner of the domain. I suspect the URNBIS people and
the IESG will not accept it because IMO there is no mean to ensure that the
enterprise guys who defining <private-urn>s will not just assume that
the enterprise
is the first domain owner instead of verifying it. What is your opinion?

Thank you

Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jan 2013 14:27:56 -0500

Its been so long that I had to go review the email history to recall 
where the discussion left off.

On 1/10/13 3:19 AM, Laura Liess wrote:
> Hi,
>
> My understanding from the last discussions is that we think to have a reasonable chance to get the IESG OK without doing major modifications to existing implementations and to the algorithm in Section 9 if we add the year to the domain-name in <private-name>s as in following examples:
>
> a)  urn:alert:service:call-waiting:telephone.com  <http://telephone.com>~2013 or
>
> b)  urn:alert:service:call-waiting:telephone.com  <http://telephone.com>~13,
>
> the URNs above representing the call-waiting Alert-Info URN used by the company which owns the domaintelephone.com  <http://telephone.com>  during 2013.
>
>     We also may have
>
> c)  urn:alert:service:call-waiting:telephone.com  <http://telephone.com>~13:foo
>
>   and
>
> d)  urn:alert:service:call-waiting:telephone.com  <http://telephone.com>~12:foo:example.org  <http://example.org>~13
>

What I had proposed had a number of options in the date syntax so that 
common cases can be short while still supporting other cases that 
require more to be specified about the date.

(I'm not fond of the ~ syntax. I find it ugly and "peculiar" to look at.
I like enclosing the data in () to be more visually appealing and 
intuitive to understand. But this is a secondary issue.)

> enterprise guys who defining <private-urn>s will not just assume that the enterprise

I would still like to try for it, because:
- the usage is much more convenient and readable without the date
- I think we can come up with a rule where the date won't be needed
   for a large fraction of private names
- if the date is not used in a case where it should be, the negative
   consequences are minor.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Fri, 11 Jan 2013 16:52:26 +0100

Paul,

Thank you. I am trying to put together from the e-mails the
description of the syntax itself and clarifications I can put in the
draft and there are quite a lot issues which are not clear to me.

I have your last proposal on the overall syntax
http://www.ietf.org/mail-archive/web/salud/current/msg00277.html  :

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

Then we agreed to replace the version by date and you sent the syntax
for it http://www.ietf.org/mail-archive/web/salud/current/msg00291.html
:

  CC = DIGIT DIGIT
 YY = CC
 MM = CC
 DD = CC

 DATE = [CC] YY ["-" MM ["-" DD] ]
  or
 DATE = YY [ MM [ DD ]] / CC YY MM DD

Or should we  for the date  just copy the syntax of DateId in the RFC
4198 and make CC optional like

      DateId     = [CC]YY [MM [DD]]
      CC           = 2(DIGIT)
      YY          = 2(DIGIT)
      MM          = ("0" %x31-39) / ("1" %x30-32)
      DD          = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"

Also we have following open issues:
 a) The rule for where the date is not needed.
 b) Use "@" or ":" in front of the domain names. "@" makes private
urn's easier to understand, but Dale didn't agree with and I think we
need minor modifications to the algorythm if we use it.
c) Dale proposed  "~"  as the separator  because it is the  only
"unreserved" character available according to RFC
  3986. ( http://www.ietf.org/mail-archive/web/salud/current/msg00290.html ).

What can we do with these issues? ( I still have additional questions
on the syntax, but let's first solve the issues above.)

Thank you
Laura

2013/1/10 Paul Kyzivat <[email-masked]>
>
> Its been so long that I had to go review the email history to recall where the discussion left off.
>
>
>> a)  urn:alert:service:call-waiting:telephone.com ~2013 or
>>
>> b)  urn:alert:service:call-waiting:telephone.com  ~13,
>>
>> the URNs above representing the call-waiting Alert-Info URN used by the company which owns the domain telephone.com   during 2013.
>>
>>     We also may have
>>
>> c)  urn:alert:service:call-waiting:telephone.com ~13:foo
>>
>>   and
>>
>> d)  urn:alert:service:call-waiting:telephone.com  ~12:foo:example.org  >~13
>>
>>
> What I had proposed had a number of options in the date syntax so that common cases can be short while still supporting other cases that require more to be specified about the date.
>
> I like enclosing the data in () to be more visually appealing and intuitive to understand. But this is a secondary issue.)
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2013 11:45:39 -0500

>   DATE = YY [ MM [ DD ]] / CC YY MM DD

Note that the above is two alternatives for the date.
We would need to choose one. I think I prefer the first, but I don't 
feel strongly about it. (I doubt that the month and day will be used 
much. They are only needed if you are not the first owner of the dns 
name and you need to form one of these before the year has rolled over 
after you gained ownership.)

The syntax for either of these can be tightened up regarding MM and DD, 
as is done below.

>        DD          = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"

Making CC optional above makes the syntax ambiguous. Four digits could 
be either CCYY or YYMM.

>   a) The rule for where the date is not needed.

Yep.

How about:
- if the date is absent, it defaults to 20000101
- if DD or MM are absent each default to 01
- if CC is absent it defaults to 20
- comparison is based on the full CCYYMMDD after
   defaults have been filled in.

You are permitted to use any date when you control the DNS name. If you 
are the first owner of a DNS name then you may also use dates prior to 
your ownership. This rule for use actually applies to the assignment of 
meaning to the name, rather than use of the name in a message.

>    3986. ( http://www.ietf.org/mail-archive/web/salud/current/msg00290.html ).

This is all about esthetics. I still like @ better.
Shall we vote?

> on the syntax, but let's first solve the issues above.)

You have my opinions. Lets see what others think.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Mon, 14 Jan 2013 16:51:02 +0100

Paul,

Before asking for the  WG feedback, let me write down my understanding
on your proposal with <date> instead of <version>,  just to ensure
that I didn't miss anything:

private-part    = label "@" dns-name ["(" date ")"]
date = [CC] YY ["-" MM ["-" DD] ]

Dale would prefer a different syntax for <private-part>:
private-part    = label ":" dns-name ["~" date ]

Following rules apply to the <date> usage
a) A domain is permited to use any <date> within its domain name
ownership time period.
b) Only the first owner of a DNS name is allowed to leave out the
<date> or to use <date>s prior to its ownership.
c) If the <date> is absent, it defaults to 20000101.
d) If <DD> or <MM> are absent each default to 01
e) If <CC> is absent it defaults to 20
f) Comparison is based on the full <CCYYMMDD> after defaults have been
filled in.

Is this OK?

Thanks a lot
Laura

2013/1/11 Paul Kyzivat <[email-masked]>:
> We would need to choose one. I think I prefer the first, but I don't feel
> strongly about it. (I doubt that the month and day will be used much. They
> are only needed if you are not the first owner of the dns name and you need
> to form one of these before the year has rolled over after you gained
> ownership.)
>
> The syntax for either of these can be tightened up regarding MM and DD, as
> is done below.
>
>
> Making CC optional above makes the syntax ambiguous. Four digits could be
> either CCYY or YYMM.
>
>
> You are permitted to use any date when you control the DNS name. If you are
> the first owner of a DNS name then you may also use dates prior to your
> ownership. This rule for use actually applies to the assignment of meaning
> to the name, rather than use of the name in a message.
>
>
>>    3986. (
>> http://www.ietf.org/mail-archive/web/salud/current/msg00290.html ).
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2013 14:40:06 -0500

> DIGIT-2-9       = %x32-39 ; 2-9

Yes. I have noted that this can be enhanced to be more precise about the 
month and day (so day 99 isn't syntactically valid). But we can do that 
after we have agreement on this.

> private-part    = label ":" dns-name ["~" date ]

Without looking back, I'm not certain. But it was something like this. 
(I'm thinking the it might have had the label on the right rather than 
the left.

My biggest problem with this is that it has a ":" separator in the 
middle of a private part. That at least makes it complex to explain the 
rules for dropping parts to find a match.

> f) Comparison is based on the full <CCYYMMDD> after defaults have been

Yes, more or less. We have more to sort out here, and the language to do 
it might get tricky.

The thing is that the use we are specifying the syntax for is a 
*reference* to an alert that we presume has already been defined. 
Anybody can write a reference, not just the owner. (E.g. I am allowed to 
reference your private alert.) The limitation on use applies to those 
who define them. And since we don't specify how private alerts are 
defined or advertised, this part is all very hypothetical.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Jan 2013 18:30:21 -0500 (EST)

[I am back on the Salud mailing list, so you don't have to Cc: me on
messages any more.]

I've assembled this list, which I think includes all the issues we've
been discussing regarding dates attached to domain names in
private-names.  I've tried to assemble all the issues and all of the
solutions that have been suggested so far.  (Issues regarding
private-names generically are not included.)

-----

Open issues regarding dates for domain names in private-names

(1) In order to provide every successive owner of a domain name the
ability to use the domain name in a unique way in URNs, we can extend
the domain name with (1a) the sequential number of the owner of the
domain name among all owners of the domain name, or (1b) a date on
which the domain name was owned.

Assuming choice (1b), the current baseline syntax proposal is as in
this example:

    urn:alert:service:call-waiting:telephone.com~2013:foo

(2) What syntax is used to combine the domain name with the date?
(2a) Separate the two with "~", e.g., "telephone.com~2013" (because
"~" is the only URI "unreserved" character that does not appear in any
other syntactic component of Alert-Info URNs).  (2b) Enclose the date
in "(...)", e.g., "telephone.com(2013)".

(Note:  The URI generic syntax is in RFC 3986, which is significantly
different from the predecessor, RFC 2396.  "(" and ")" are
<sub-delims>, but <sub-delims> can appear in every location that
<unreserved> can.)

(3) Is it possible to omit the date, and if so, what is the
significance of that?  (3a) The date can be omitted, and: (3a1) is
equivalent to a fixed "default" date, both for URN comparison and URN
interpretation, (3a2) is *not* equivalent to the domain name with a
date.  (3b) The date cannot be omitted.

There seems to be general agreement that the date syntax will be
somewhat like CCYY[MM[DD]], that is, it can be specified down to the
day if necessary, but the month and day can be omitted.  Omitted month
and day are equivalent to "01".

(4) How is the century indicated?  (4a) Century is not indicated, and
is always "20".  (4b) Century must always be indicated.  (4c) Century
may be omitted, in which case it defaults to "20" (both for URN
comparison and URN interpretation).

(5) Should there be separators between the CCYY, MM, and DD
components?  (5a) There are no separators.  (5b) The separator is "-".

Note:  (4c) [CC optional] together with (5a) [no separator] is
syntactically ambiguous.

(6) What date is the default if no date is provided?  (6a) Use
2000-01-01, as it is a convenient round number.  (6b) Use 2013-01-01,
since the maximizes the number of current users who can use the
default date.

(7) If an entity is the first owner of a domain name, but did not own
it on the default date, is the entity permitted to use the domain name
without a date?  (Is it possible to verify that one is the first owner
of a domain name, or at least the only owner since the default date?)
(7a) Yes, the first owner can do that.  (7b) No, the first owner
cannot do that.

-----

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2013 20:39:57 -0500

This seems to cover it.

	Thanks,
	Paul

On 1/14/13 6:30 PM, Dale R. Worley wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Jan 2013 22:09:50 -0500 (EST)

> From: Laura Liess <[email-masked]>
> 

Based on the list of issues regarding dates, this proposal is the set
of choices:

    (1b) date to extend domain name

    (2b) Use "(...)" as a separator.

    (3a1) Missing date defaults to 2000-01-01.

    (4c) Century defaults to "20".

    (5b) MM and DD are separated by "-".

    (6a) Default date is 2000-01-01.

    (7a) First owner of domain name can use dates before its ownership.

Generally, I agree with this proposal.  But I would like to change the
default date to 2013-01-01, because it may allow a larger number of
users to define URNs without dates, and there is no user who will need
to define a URN with a date before 2013.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2013 11:22:57 -0500

I'm ok with a default of 2013.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 25 Jan 2013 17:34:38 -0500 (EST)

[as chair]

Based on these e-mails:
http://www.ietf.org/mail-archive/web/salud/current/msg00312.html
http://www.ietf.org/mail-archive/web/salud/current/msg00310.html
http://www.ietf.org/mail-archive/web/salud/current/msg00305.html
it appears that we are moving toward agreement on this proposal:

       [the use of "@" is not completely agreed to yet]

    Following rules apply to the <date> usage
    a) A domain is permited to use any <date> within its domain name
    ownership time period.
    b) Only the first owner of a DNS name is allowed to leave out the
    <date> or to use <date>s prior to its ownership.
    c) If the <date> is absent, it defaults to 20130101.
                                               [note change from 20000101]
    d) If <DD> or <MM> are absent each default to 01
    e) If <CC> is absent it defaults to 20
    f) Comparison is based on the full <CCYYMMDD> after defaults have been
    filled in.

With reference to the list of choices in
http://trac.tools.ietf.org/wg/salud/trac/ticket/1
this proposal for dates is:

    (1b) Use date (rather than sequence number) to extend domain names

    (2b) Use "(...)" as a separator, i.e., "example.com(2013-01-25)".

    (3a1) Missing date is equivalent to the date specified in (6b), 2013-01-01.

    (6b) Default date is 2013-01-01.

    (7a) First owner of domain name can use dates before its ownership.
	 (I assume that this means, "No owner from 2013-01-10 until the
	 current owner acquired domain name.")

Are we all in favor of this set of choices?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jan 2013 09:25:19 -0500

Dale,

I'm generally in agreement.

As I said somewhere recently, I have realized that saying what dates 
someone is allowed to use is probably wrong, since the uses we are 
describing are *references*, not *definitions*.

So this is really more about what the reference *means*.

It also suggests to me that we let the date default to *now*.

This might require some contortions in how we describe what this means 
as a URN. Basically it means that the recipient who is interpreting the 
URN have alerts with IDs that match a range of dates.

So, *in principle* I could have one alert defined to match 
[email-masked](20112-01-01)[email-masked](2012-12-31),
and another for ([email-masked](2013-01-01)... when the ownership of 
example.com changed from somebody I had a special relationship with to 
one when I no longer did.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 28 Jan 2013 17:13:53 -0500 (EST)

[as an individual]

> From: Paul Kyzivat <[email-masked]>
> 

I'm not sure that I understand you.

My understanding is:

<urn:alert:...:[email-masked](2012-01-01)>,
<urn:alert:...:[email-masked](2012-12-31)>, and
<urn:alert:...:[email-masked](2013-01-01)> are all different.

<urn:alert:...:[email-masked]> is considered to be an abbreviation of
<urn:alert:...:[email-masked](2013-01-01)> (or which ever date is the
default).

The entity that owns "example.com" on 2012-01-01 is permitted to
define the meaning of <urn:alert:...:[email-masked](2012-01-01)>.

The meaning of any URN (character string) is independent of the time
at which it is interpreted (excepting that undefined URNs can become
defined).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jan 2013 19:41:22 -0500

> <urn:alert:...:[email-masked](2013-01-01)> are all different.

Yes, they are all different URNs. But they could all be defined to have 
the same *meaning*.

> define the meaning of <urn:alert:...:[email-masked](2012-01-01)>.

That entity defines the meaning of the URN, but somebody else may be 
defining what alert to render for it. So if I am defining the alerts, I 
can *choose* to assign the same alert to a bunch of different URNs, and 
specifically to a bunch of alert URNs that differ only by the date.

In fact, I could assign the same alert to a *range* of dates. And if I 
*choose* to assign the same alert without regard to the date part of the 
label, that is also my right. This is *policy*, so I can do as I wish.

And if somebody built an implementation that supported such policies, so 
much the better.

> at which it is interpreted (excepting that undefined URNs can become

Yes.

*Unless* we made the default for a missing date be the current day. In 
some ways that is appealing. But I think we would get a lot of grief 
from the URN police for it. So we probably don't want to do it.

	Thanks,
	Paul