Subject: [salud] Thoughts and responses

From: Dale R Worley <[email-masked]>
Date: Thu, 4 Oct 2012 12:24:41 -0400 (EDT)

Here are my thoughts and responses to the messages of the last month:

(1) Following Paul regarding the ordering of domain names, since we've
dropped the idea of removing individual labels from domain names, it
seems clearer to use FQDNs rather than reversed FQDNs.

(2) Based on what other people have said, here is another proposal for
how to disambiguate FQDNs, suggested by the "fdc" (RFC 4198)
namespace:  (Thanks to Laura for the reference.)

  urn:alert:service:call-waiting:example.com~12:special

The FQDN is (always) followed by a qualifier, which is a "~" followed
by a date in the format YY[MM[DD]].  The entity that defines the
following standard-name components is the entity that owned the
specified domain name on the specified date.  (at 12:00:00 UTC, where
MM and DD default to 01, and the century is always "20")

- No external information is needed to apply the defaults to the
  qualifier.  An entity needs no other information than its ownership
  history of the domain name to select a valid qualifier for its use.

- There is a rigorous rule for determining what entity is responsible
  for which components of the URN.  We have copied the rule
  (essentially) from RFC 4198, and I think that Alfred suggested a
  similar possibility.  So it should be possible to get this approved
  by urnbis and the IESG.

- Since there is an objective rule for determining ownership, we can
  probably avoid the complexity of requiring the users of
  private-names to register the private-names or the URNs built using
  them.

- In the ordinary case, when the entity has owned a domain name for
  more than a year, only 3 characters need to be added to the FQDN.
  This is longer than a simple sequence number, but it is unclear how
  to allocate sequence numbers.

- We can allow for a day-by-day delegation of URNs if needed, by using
  the MM and DD fields, but that will probably only be done for
  experimental purposes.  We define private-names with the MM/DD
  fields to be equivalent to the MM/DD fields with the default values,
  to avoid problems with "two 'different' URNs that mean the 'same'
  thing".

- This syntax avoids splitting the standard part from the private part
  in any ring-indication, which makes it easier to describe how the
  interpretation algorithm operates.

- I chose "~" (tilde) as the separator character because it is the
  only URI generic syntax "unreserved" character available.  See RFC
  3986 section 2.3:

      unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

  ALPHA, DIGIT, "-", and "." appear in FQDNs; "_" is forbidden from
  FQDNs because it can be confused with "-".  That leaves "~".

  I was originally going to use "/", which is prettier, but "/" has
  syntactic meaning in URIs.

- Fixing the century part as "20" gives this syntax an 87-year
  lifetime, but it should be sufficient for practical use.

(3) I like Laura's idea of adjusting the BNF to distinguish which
parts of URNs are standard and which are private, even when the parts
have the same syntax.

(4) In regard to using private names as alert-categories, I think we
    want
to allow that, because in some cases, an implementer will want to
invent an entirely new alert-category.

(5) I like Laura's idea that each private-name (FQDN) must be followed
by at least one standard-name (label), because the FQDN alone does not
specify anything in particular.

Actually, if we allow private-names to be the final element in a URN,
I expect implementers do so.  For example, I expect "telephone.com" to
create

  (A) urn:alert:service:call-waiting:telephone.com

to mean their own special form of call-waiting signal.  And then a
year later, they will want to have a second private call-waiting
signal, without having properly allowed for extensibility.  If we
require them to create

  (B) urn:alert:service:call-waiting:telephone.com:special

they are less likely to make this mistake, as

  (C) urn:alert:service:call-waiting:telephone.com:special2

is the obvious second version.

If "telephone.com" was careful, they could have used sub-domain names
to provide subdivision of their private-name space, in this manner:

  (D) urn:alert:service:call-waiting:telephone.com.special
  (E) urn:alert:service:call-waiting:telephone.com.special2

I am not sure that there is any benefit to be obtained from
specifically supporting this technique, as (B) and (D) have the same
length.

(6) I'm not fond of using "[email-masked]" because it isn't pretty.
But maybe I could be convinced.

(7) I agree with Paul's idea that multiple FQDNs might appear in a
URN.  In some cases, I would expect one organization to "extend" the
private names of another organization sometimes.  And this sort of
extension doesn't require any extra processing in implementations.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Oct 2012 15:28:44 -0400

Minor comments inline.

>    urn:alert:service:call-waiting:example.com~12:special

If this can be approved then it isn't too bad.

> MM and DD default to 01, and the century is always "20")

perhaps it could be defined to allow the century to be optional with 
default of 20, rather than implied 20. That would require some change to 
the above syntax to be unambiguous. E.g.

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

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

>    syntactic meaning in URIs.

This works for me.

>    lifetime, but it should be sufficient for practical use.

I wonder if we could make the ~nn optional for an FQDN when the owner is 
the *first* owner of that FQDN. (But is it even possible to reliably 
learn if you are the first owner?)

Or maybe make it optional if you have been the owner continuously since 
before 2012.

>    (E) urn:alert:service:call-waiting:telephone.com.special2

With FQDNs, that would be special.telephone.com & special2.telephone.com

> But maybe I could be convinced.

Depends on your measure of "pretty". :-)

I agree it could be a bit confusing in changing the order in which you 
read things.

What I liked about it is that it is a familiar construction for names 
within a domain.

Another thing I liked about it is that it looks like a single entity, 
and so its intuitive that it dropped as an entity if not understood. So 
IMO it seems to work more naturally for the rule that each domain name 
must be accompanied by at least one label.

With that syntax we *could* make the "label@" part be optional. 
(Effectively a label of "".) With or without it becomes a single element 
that is interpreted or else dropped if unknown.

> extension doesn't require any extra processing in implementations.

Exactly. I don't foresee this being used often. But I saw no reason to 
exclude it.

	Thanks,
	Paul

---

From: Dale R Worley <[email-masked]>
Date: Fri, 5 Oct 2012 13:32:40 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 
> I wonder if we could make the ~nn optional for an FQDN when the
> owner is the *first* owner of that FQDN. (But is it even possible to
> reliably learn if you are the first owner?)
> 
> Or maybe make it optional if you have been the owner continuously
> since before 2012.

This isn't elegant, but:  We could make the default year be 2012, so
if there is no qualifier at all, the specified time is 12:00 UTC, 1
Jan 2012.  In practice, all of the existing equipment manufacturers
would never need to use a qualifier.

> > If "telephone.com" was careful, they could have used sub-domain
> > names to provide subdivision of their private-name space, in this
> > manner:
> >

Oops, yes, I got the order wrong.  It made more visual sense when we
used reversed FQDNs.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Oct 2012 14:16:52 -0400

> would never need to use a qualifier.

Ugh!

"First owner" would work more broadly.
We might spin it that the default year is 1970 (or 2000 if you prefer), 
and at the same time say that the first owner of a domain is considered 
to have owned it retroactively back to the default year. I suspect that 
all of the companies you have in mind are original and continuous owners 
of their domain - directly or via acquisitions and mergers.

	Thanks,
	Paul

> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 8 Oct 2012 14:26:19 -0400 (EDT)

> of their domain - directly or via acquisitions and mergers.

Can one learn from the registar(s) that one is the first owner of a
domain name?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Oct 2012 14:54:26 -0400

> Can one learn from the registar(s) that one is the first owner of a

I just did a little googling, and it seems that domaintools.com has 
whois history back to 1995 or so. But you have to pay to check it.
I don't know how complete it is.

But that seems to suggest that it is *possible* to do this.
If we wanted to go this way then I guess it would be the responsibility 
of someone using a domain without a date to verify that they are the 
original owner. (wink wink)

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 11 Oct 2012 15:17:37 -0400 (EDT)

> original owner. (wink wink)

I can see several variations might work.  I think the principles we
need to keep in mind are:

- Each syntactic variation needs to have a stable enough meaning to
satisfy the URN people.

- We need to clearly define which syntactic variations are
*abbreviations* of others (and thus are considered equivalent) and
which are not.  E.g., are "example.com" and "example.com~2000"
equivalent or do they just happen to refer to the same organization?

- The syntax should provide URN components that are not much longer
than the FQDN in almost all of the common cases.

- The syntax should be attractive to the eye.

- The syntax should correspond to the conceptual structure of the
URNs.

However, interestingly enough, the colon (":") character generally
does not have a special syntactic role in URIs. (See RFC 2396,
"Uniform Resource Identifiers (URI): Generic Syntax".)  In some
positions, a colon's presence is important, but in URNs like
"urn:ietf:params:xml:ns:copycontrol", the generic syntax ABNF only
divides the URN into "urn" and "ietf:params:xml:ns:copycontrol".

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Oct 2012 16:35:22 -0400

> equivalent or do they just happen to refer to the same organization?

The forms that remove default digits from the date can satisfy this 
rule. So for those a shorter date can be turned into a longer one. And 
then the comparison rules can always use the long ones.

But I don't think the omission of a date for a domain you are the first 
owner of fits that rule. But IMO that is ok.

Similarly, if I own it today, and I still own it tomorrow then I could 
construct names using either date. They won't compare equal, and I don't 
think we can/should define rules so that they do.

> than the FQDN in almost all of the common cases.

I'm trying to get there with the "first owner" approach. I think that 
will fit most users.

> - The syntax should correspond to the conceptual structure of the

Having the domain, with date if needed, being a single element, rather 
than multiple elements, helps with this.

	Thanks,
	Paul