Subject: Re: [salud] -05: Mostly editorial issues

From: Laura Liess <[email-masked]>
Date: Thu, 1 Mar 2012 11:41:45 +0100

Dale,

Thank you. That's fine for me.

Laura

2012/2/29 Worley, Dale R (Dale) <[email-masked]>:
> I agree with all of this, except I would change
>
>      alert-URN       = "URN:alert:" alert-identifier
>
> to
>
>      alert-URN       = "urn:alert:" alert-identifier
>
> because it seems to be the universal convention to use
> "urn" to start URNs.  (Laura has already discussed this
> on 10 Feb.)
>
> (I think this is the end of the case issues.)
>
> Dale
> ________________________________________
> From: Laura Liess [[email-masked]]
> Sent: Wednesday, February 22, 2012 9:09 AM
> To: Paul Kyzivat; Worley, Dale R (Dale)
> Cc: [email-masked]
> Subject: Re: [salud] -05: Mostly editorial issues
>
> Hi,
>
> After this discussion I would change the do following text changes on page 13:
>
> ===-Begin of changes ===
> Change #1:
> Old text:
> "The alert-indications are hierarchical identifiers, consisting of
>      one label or a sequence of labels separated by colons.  The set of
>      allowable characters is the same as that for domain names
>      [RFC1123].  Labels are case-insensitive, but MUST be specified in
>      all lower-case."
>
> New text:
> "The alert-indications are hierarchical identifiers. The set of
>      allowable characters is the same as that for domain names
>      [RFC1123].  Labels are case-insensitive. Comparisons MUST be
> case-insensitive. Registered URNs SHOULD be transmitted as registered.
> A new name MUST NOT be registered if it is equal by case-insensitive
> comparison to an already registered name. "
>
> Change #2:
> Old text:
>       " alert-URN       = "URN:alert:" alert-identifier
>        alert-identifier= alert-category ":" alert-indication
>        alert-category  = name
>        alert-indication= name *(":" name)
>        name = 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 "
>
> New text:
>      " 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 ]
>        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
>
> Throughout this document, "<private-name>" is used as a syntactic
>   variable for any string conformant to the "private-name" ABNF
>   above. "
>
> ===End of changes===
>
> Is the new text correct or did I miss something?
>
> Thank you
> Laura
>
>
>
>
>
>
>
>
>
> 2012/2/20 Paul Kyzivat <[email-masked]>:
>> On 2/20/12 3:51 PM, Worley, Dale R (Dale) wrote:
>>>>
>>>> From: Paul Kyzivat [[email-masked]]
>>>>
>>>> For the private ones, that aren't registered with IANA, you already
>>>> brought up the problem of dns names that are customarily represented in
>>>> mixed case. We already know that dns names are required to be case
>>>> insensitive, so we won't have a conflict between Example.com and
>>>> example.com. I find it very unnatural to require the same name to be
>>>> represented all in lower case in the URN.
>>>
>>>
>>> I don't remember bringing it up, but you're right that it complicates
>>> things.  In theory it's no more complex.  But in practice, people will
>>> not universally downcase DNS names.
>>>
>>> So how should we adjust the rules?  We want case-insensitive
>>> comparison.  Should we say "Comparisons are case-insensitive.
>>> Transmitted URNs SHOULD be in lower case.  Registered URNs MUST be
>>> lower case."?
>>
>>
>> IMO:
>>
>> Comparisons MUST be case-insensitive.
>>
>> Registered URNs SHOULD be transmitted as registered.
>>
>> A new name MUST NOT be registered if it is equal by case-insensitive
>> comparison to an already registered name.
>>
>>        Thanks,
>>        Paul
>>
>> _______________________________________________
>> salud mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/salud

---

From: Laura Liess <[email-masked]>
Date: Fri, 9 Mar 2012 17:06:45 +0100

Dale,

I found out that I miss to answer following of yours comments in
http://www.ietf.org/mail-archive/web/salud/current/msg00207.html :

2012/2/8 Worley, Dale R (Dale) <[email-masked]>:
> [as individual]
>
> I'm finally starting to read Laura's new -05 draft, and clearly we are
> getting close to finished.  This message mentions a number of minor
> points.
.........
>Section 4
.....
>
> I'm not sure I understand this paragraph:
>
>   Identifier uniqueness considerations:  An Alert-Info URN identifies a
>      logical service or tone, specified in the alert-indication
>      registration (see Section 11).  Resolution of the registered URN
>      will return a particular instance of the alert identifier.  Alert
>      identifier URNs MUST be unique for each unique indication; this is
>      guaranteed through the registration of each alert indication
>      within this namespace, described in Section 11.
>

[LL] This draft text is very old (written before I took over the draft
editorship). I think it is based on the corresponding paragraph in the
RFC 5031. However, text doesn’t really fit the current version of the
draft. I would modify it as follows:

>> An Alert-Info URN identifies a logical rendering at the caller’s or callee’s end device.   A logical rendering identified by an Alert-Info URN is persistent and unique; this is guaranteed through the IANA  registration of each alert-category and alert-identifiers as  described in Section 11.<<

I am fully open for better ideas or wording for this text.

Thanks  a lot
Laura

---

From: Laura Liess <[email-masked]>
Date: Fri, 23 Mar 2012 14:15:30 +0100

Hi,

When I submit the version 06 which incorporates the received comments,
the idnits tool returns following warning:

" Found possible FQDN 'org.example.somecompany' in position 3; this
doesn't match RFC 2606's suggested ".example" or
".example.(com|org|net)".

The warning refers to the change based on the following comment:

>
> This example is given:
>
>   For example, some company SomeCompany.example.org could use
>   urn:alert:service:call-waiting:SomeCompany.example.org, which is the
>   SomeCompany's private version for call-waiting or it may have several
>   distinct private versions of call-waiting, e.g.
>   urn:alert:service:call-waiting:abc.SomeCompany.example.org and
>   urn:alert:service:call-waiting:def.SomeCompany.example.org (which are
>   siblings in the tree under urn:alert:service:call-waiting).  Also it
>   can subdivide its private version of call-waiting in
>   urn:alert:service:call-waiting:SomeCompany.example.org:abc and
>   urn:alert:service:call-waiting:SomeCompany.example.org:def (which are
>   siblings in the tree under service:call-
>   waiting:SomeCompany.example.org).
>
> It has two problems:  "SomeCompany" is not in lower case (as demanded
> by section 4), and the value is given as the FQDN rather than the
> reversed FQDN.  The correct example would be
>
>   For example, some company SomeCompany.example.org could use
>   urn:alert:service:call-waiting:org.example.somecompany, which is the
>   SomeCompany's private version for call-waiting or it may have several
>   distinct private versions of call-waiting, e.g.
>   urn:alert:service:call-waiting:abc.org.example.somecompany and
>   urn:alert:service:call-waiting:def.org.example.somecompany (which are
>   siblings in the tree under urn:alert:service:call-waiting).  Also it
>   can subdivide its private version of call-waiting in
>   urn:alert:service:call-waiting:org.example.somecompany:abc and
>   urn:alert:service:call-waiting:org.example.somecompany:def (which are
>   siblings in the tree under service:call-
>   waiting:org.example.somecompany).
>

Any opinion on how to handle this issue?

Thanks a lot
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Mar 2012 20:44:18 +0200

> The warning refers to the change based on the following comment:
[snip]

>> reversed FQDN.

[snip]

> Any opinion on how to handle this issue?

The nits tool as generated a false positive here. It found a "possible 
FQDN" but the problem isn't real because it isn't actually an FQDN.

The nits tool is not normative. So I think the solution is for the 
document shepherd to mention in the proto writeup that the nits tool 
falsely reports this.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 26 Mar 2012 17:59:52 -0400

Looking at both versions of this paragraph, I think that the text
dates to before we settled on the "multiple URN approach", and the
text is now incorrect.

I've tried to rewrite it so that it describes each URN as identifying a
"feature" of the rendering.  I'm not sure we want to introduce a new
word ("feature") in this paragraph, but maybe someone can see
a better way to describe it.  Here is my draft:

>> An Alert-Info URN identifies a semantic or sensory feature of alert
   rendering at the caller’s or callee’s end device.  The feature
   identified by a particular Alert-Info URN is persistent and
   distinct from the feature identified any other Alert-Info URN
   through the IANA registration of each Alert-Info URN (that is, each
   defined combination of alert-category and alert-identifier) as
   described in Section 11.<<

Dale

________________________________________
From: Laura Liess [[email-masked]]
Sent: Friday, March 09, 2012 11:06 AM
To: Worley, Dale R (Dale)
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [salud] -05: Mostly editorial issues

Dale,

.........
.....

Thanks  a lot
Laura

---

From: Laura Liess <[email-masked]>
Date: Tue, 27 Mar 2012 16:09:09 +0200

I am OK with it.

Laura