Subject: Re: [salud] #1: Year/version for domain names used in private-names

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

[as chair]

I've decided to use the IETF Trac tracker as a *personal* tool for the
chair (me) to track the open issues in the draft.  That is, I am using
it as a personal reference; other WG members do not need to pay
attention to it.

But it seems that the WG mailing list receives messages whenever a
ticket is created or updated; please forgive the extra e-mail.

WG members should feel free to look at the tickets if they want.  The
listing is at http://trac.tools.ietf.org/wg/salud/trac/report/1  If
you find any errors, please tell me and I will correct them.

Dale

> From: "salud issue tracker" <[email-masked]>
> 
> #1: Year/version for domain names used in private-names
> 
>  The URN scheme uses domain names to provide unique namespaces for private
>  extensions.  However, a single domain name may be owned by different
>  entities over the years, and so an entity does not have clearly unique
>  ownership of a namespace identified only by a domain name.  Thus, we need
>  to extend domain names with some sort of indicator to produce identifiers
>  that are uniquely owned by entities.
> 
[etc.]

---

From: Laura Liess <[email-masked]>
Date: Tue, 15 Jan 2013 14:15:32 +0100

Dale,

We have an additional issue concerning the separator between the
<label> and the <dns-name> in the <private-part>. It's not a major
issue, just syntax, but it has to be clarified.

The alternatives which I know about up to now:
a) "@"
b) ":"

Thank you
Laura

2013/1/15 Dale R. Worley <[email-masked]>:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Jan 2013 14:56:24 -0500 (EST)

[as an individual]

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

Yes.  Let me summarize what I've seen about this syntax question:

(1) When a FQDN is added to create a private-name component, do we
require an additional label (whose meaning is defined by the owner of
the FQDN)?

(2) Suggested syntaxes (omitting any date specification):

    ...:label@FQDN:...

    ...:FQDN:label:...

(Of course there are other possibilities.)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jan 2013 16:30:45 -0500

> require an additional label (whose meaning is defined by the owner of

IMO the issue isn't *if* we require it. The issue is how it is 
represented if it is present.

IOW, I am ok with allowing both:

  ...:label@FQDN:...
and
  ...:FQDN:...

> (2) Suggested syntaxes (omitting any date specification):

The issue I have with the latter syntax is:

the FQDN:label syntax is very similar to label:label. It implies that 
you can drop the label while looking for a match. That is OK if FQDN is 
itself intended to have meaning without a subsequent label.

With the @ syntax, it is clear (I hope) that label@FQDN is a single 
element that must be dropped as a whole.

Either way, you can then have subsequent labels, that will be in the 
scope of this one.

So maybe you can consider the @ syntax to be an extension to your : 
syntax, rather than an alternative.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Sat, 19 Jan 2013 21:33:37 +0100

Hi,

> the FQDN:label syntax is very similar to label:label. It implies that you
> can drop the label while looking for a match. That is OK if FQDN is itself
> intended to have meaning without a subsequent label.
>
> With the @ syntax, it is clear (I hope) that label@FQDN is a single element
> that must be dropped as a whole.

IMO this aspect is essential.
If we expect an UA which receives e.g.
urn:alert:service:recall:hold<separator>telephone.com and does not
understand it to remove both "hold" and "telephone.com" and proceed
with the urn:alert:service:recall  and not with
urn:alert:service:recall:hold, we should not use ":" as a separator.
Previously to Paul's mail I thought we want the UA to remove just
telephone.com and continue with   urn:alert:service:recall:hold  so
urn:alert:service:recall:hold:telephone.com was OK for me. I do not
really like the format   urn:alert:service:recall:telephone.com:hold
for the reason described by Paul.
I vote for using "@" as a separator because it is intuitive and we do
not have to change the algorithm.

By the way, do we need to add to Section 6.2.1
urn:alert:service:recall or to say something about a default value?

Thank you
Laura

2013/1/16 Paul Kyzivat <[email-masked]>:
> IMO the issue isn't *if* we require it. The issue is how it is represented
> if it is present.
>
> the FQDN:label syntax is very similar to label:label. It implies that you
> can drop the label while looking for a match. That is OK if FQDN is itself
> intended to have meaning without a subsequent label.
>
> With the @ syntax, it is clear (I hope) that label@FQDN is a single element
> that must be dropped as a whole.
>
> Either way, you can then have subsequent labels, that will be in the scope
> of this one.
>
> So maybe you can consider the @ syntax to be an extension to your : syntax,
> rather than an alternative.
>
>         Thanks,
>         Paul
>
>

---

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

[as an individual]

Regarding how we specify private extensions, which is the syntax of
<private-part>:

I believe that we are all agreed that within a URN, an FQDN
(<dns-name>) can be specified, and that can be followed by one or more
<label>s, all of which are interpreted based on some definition made
by the owner of the FQDN.

I believe that we are all agreed that if URN specifies an FQDN
(<dns-name>), then there must be at least one following label, i.e.,
that a URN can't simply say "example.com's version of
urn:alert:service:call-waiting" (which would be
urn:alert:service:call-waiting:example.com"), it has to include some
specification of a particular modification
("urn:alert:service:call-waiting:example.com:xyz").

Two syntaxes have been proposed:

    private-part    = label "@" dns-name ["(" date ")"]
    Example: urn:alert:service:call-waiting:[email-masked]

    private-part    = dns-name ["(" date ")"] ":" label
    Example: urn:alert:service:call-waiting:example.com:xyz

Desirable features for the syntax:

1. Expresses the hierarchical relationship of the labels, that is, for
   each label, it is visually clear which elements provide the context
   within which this label must be interpreted.

2. Expresses what the components are that are to be deleted during the
   loop in the resolution process.

Let us consider a specialization of urn:alert:service:call-waiting,
defined by example.com, which has a level of subdivision, so its
labels are (primary) "abc" and (secondary) "def".  The two syntax
proposals above would express this as:

    urn:alert:service:call-waiting:[email-masked]:def

    urn:alert:service:call-waiting:example.com:abc:def

What I notice is that the first example does not conform well to
desideratum 1, because "abc" is to the left of "example.com", whereas
the general hierarchical structure is that the primary categories are
to the left and the secondary categories are to the right.

("desideratum" = "something that is wished for, or considered
desirable"
http://en.wiktionary.org/wiki/desideratum#English
It is not a requirement because we do not *need* this to be true, but
it is desirable for it to be true.)

The second example does not conform to desideratum 2, because the ":"
between "example.com" and "abc" suggests that "abc" can be removed
from the URN without removing "example.com".

I think we need a different syntax, one that places "example.com"
before "abc", but does not use ":" as a separator.  One possibility is

    urn:alert:service:call-waiting:example.com@abc:def

but that conflicts with the normal uses of "@", where the hostname
always goes after "@".

Based on RFC 3986, the URI syntax, I believe that we can use the
following characters freely in alert-info URNs:

   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

   pct-encoded   = "%" HEXDIG HEXDIG

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

   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Since ALPHA, DIGIT, ".", and "-" are allowed in <labels>, we don't
want to use them as delimiters.

Perhaps we could use this syntax:

    urn:alert:service:call-waiting:example.com=abc:def

or even use the old UUCP addressing syntax:

    urn:alert:service:call-waiting:example.com!abc:def

I suppose we could use parentheses, if we weren't using them for
dates:

    urn:alert:service:call-waiting:(example.com)abc:def

Dale

---

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

[as an individual]

> urn:alert:service:recall or to say something about a default value?

There is a similar question regarding urn:alert:locale:country.  But I
don't think that we need to assign a meaning to these URNs.  If a UA
is processing a list of URNs, and it removes a component for a URN and
that results in a URN that is undefined (and thus the UA knows now
meaning for it), the rules specify that it must remove another
component.  In these cases, that results in urn:alert:service or
urn:alert:locale.  Those URNs have no <alert-indication> and are thus
discarded.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Jan 2013 19:08:15 -0500

Dale,

I agree with most of your analysis, but not the conclusion. More inline.

> to the left and the secondary categories are to the right.

This component has a familiar look to it, and so the "left of the 
domain" is comfortable. I am just not bothered by this. I view 
[email-masked] as a *single* component - the label isn't optional. It 
satisfies (1) in that xyz follows it.

>     sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"

I don't find any of these to be as pleasant as the @ notation.

But of course this is all in the realm of esthetics, so it's not 
surprising that there are multiple preferences.

	Thanks,
	Paul

---

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

[as an individual]

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

I agree that this question is all a matter of esthetics.  Which do
other people prefer?

Dale

---

From: Laura Liess <[email-masked]>
Date: Tue, 29 Jan 2013 16:16:48 +0100

My personal preference is @.  I agree with Paul's view about (1) and I
think it is easy to understand and to keep in mind.

Thank you
Laura

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 29 Jan 2013 16:02:34 -0500 (EST)

[as an individual]

> think it is easy to understand and to keep in mind.

I certainly don't feel strongly enough about the matter to stand in
the way of a consensus.  So let us agree on the
...:label@FQDN:... syntax.

Dale