Subject: [salud] -05: Mostly editorial issues

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 8 Feb 2012 15:07:18 -0500

[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.

Overall

I don't know how URN namespaces are properly organized.  It seems to
me that section 4 (the namespace registration template), section 5
(the defined values of alert-info URNs), and section 11.2 (the IANA
registration are very tightly connected.  Would it make more sense to
combine them, or at least group them together?  (Is there a good model
to emulate?)

Section 1.1

   As a result, Alert-Info currently
   only works when the same vendor provides >>>proxy<<< and UA, as only then
   is the same "fake" proprietary URI convention used.

I think the marked word should be changed to "PBX", as the previous
sentences discuss "PBX", and in most situations a proxy would not
modify the Alert-Info header.

Section 1.3

The marker "[E182]" is used for ITU E.182.  I think it would look
better if we used "[E.182]".

Section 3.2.1

   As call-waiting information may be subject to the callee's
   privacy concerns, the exposure of this information shall be done only
   if explicitly required by the >>>user<<<.

I think the marked word should be "callee", as there are two users,
and the callee is the user that is intended here.

Section 3.2.4

   This feature is used when a user has utilized a server to implement
   an automatic callback service.

It would be informative to add a footnote here:

   [I-D.ietf-bliss-call-completion]
              Worley, D., Huelsemann, M, Jesske, R., and D. Alexeitsev,
	      "Call Completion for Session Initiation Protocol (SIP)",
	      draft-ietf-bliss-call-completion-14 (work in progress),
              November 2011.

Section 4

This rule is given:

      Labels are case-insensitive, but MUST be specified in
      all lower-case.

That suggests that these two grammar rules should be modified to
remove the upper-case letters:

        alert-URN       = "URN:alert:" alert-identifier

        ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z

become:

        alert-URN       = "urn:alert:" alert-identifier

        ALPHA           = %x61-7A   ; a-z

But the latter depends on whether we are presenting a grammar to
*generate* Alert-Info URNs or a grammar to *parse* them.

      The Alert-
      Info URN does not prescribe a particular resolution mechanism, but
      it is assumed that a number of different entities could operate
      and offer such mechanisms.

I think that it would be better to warn the reader that we expect the
rules in section 7 to apply:

      The Alert-Info URN does not prescribe a particular resolution
      mechanism, but any resolution SHOULD (MUST?) comply with the
      rules in section 7.

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.

   Process of identifier assignment:  The process of identifier
      assignment is described in Section 11.

I think that the above should mention the "private" extensions:

   Process of identifier assignment:  The process of identifier
      assignment is described in Section 11, which includes the
      extension rules for independent organizations described in section
      6.2.

Section 6.1

   Adding new categories and adding alert-indication
   values other than via the "private" mechanism described >>>above<<< is
   standards action.

I think that the marked word should be "below".  Better would probably
be "in section 6.2".

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).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Feb 2012 21:44:06 -0500

> *generate* Alert-Info URNs or a grammar to *parse* them.

Its really unclear what the intent is. If the labels MUST be specified 
in lower-case then they aren't really case insensitive.

IMO this is a perfect place for use of SHOULD rather than MUST.

Or, perhaps it would be better to say that the representation in 
Alert-Info SHOULD be identical (in case) to the representation of the 
URN in its registration. (But comparison MUST be made 
case-insensitively, and there MUST NOT be multiple registrations of URNs 
that differ only in case.)

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 9 Feb 2012 15:34:02 -0500

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

There are other situations where one is required to accept either case
but required to generate only one case.  Unfortunately, I can't
remember the example right now.

Dale

---

From: Laura Liess <[email-masked]>
Date: Fri, 10 Feb 2012 10:45:02 +0100

Dale,

Please see inline.

> combine them, or at least group them together? (Is there a good model to emulate?)

[LL] I think a good model is the RFC 5031, where the sections
"Registration Template" and " IANA Considerations" are together. I
think it would make sense to shift section11 after section 5.

 >
> modify the Alert-Info header.

[LL] Agree.
> better if we used "[E.182]".

[LL] In the previous versions up to 02, we had [E.182]. I had to
change it in version 03 because one of the submission tools (xml2rfc
or idnits) changed and did not accept the dot any more.
> and the callee is the user that is intended here.
[LL] Agree.

>              draft-ietf-bliss-call-completion-14 (work in progress),

[LL]  I am not realy familiar with the call completion draft, but it
seems to me that there is no reference in the draft about a possible
ussage of an Alert-Info URN. Also Section 3 describes existing use
cases and implementations today. I think a reference to the draft
would eventually be confusing.

> *generate* Alert-Info URNs or a grammar to *parse* them.

[LL] Would it be OK to:
       1) Take Paul's first proposal and use SHOULD rather than MUST  and
       2) Use  "urn:alert:" alert-identifier  instead of "URN:alert:"
alert-identifier  ?

>      mechanism, but any resolution SHOULD (MUST?) comply with the
[LL] Yes. The current text is old and must be changed. I think MUST is
correct because we use MUST in section 7.

>      extension rules for independent organizations described in section

[LL] Agree.
> I think that the marked word should be "below".  Better would probably
[LL] Agree.
>   waiting:org.example.somecompany).

[LL]  Agree.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Feb 2012 14:12:11 -0500

> remember the example right now.

What is the point here? (Of mandating what must be generated.)
Is it to simplify implementations? (It doesn't.)

IMO the most important thing is to ensure that two differently cased 
spellings of the same name aren't being used with the expectation that 
they are distinct.

For those that are registered with iana, that can be achieved by 
requiring that each registration be unique in a case-insensitive way 
from all others.

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.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Mon, 20 Feb 2012 17:08:56 +0100

Dale,

Concerning your proposal to add a reference to the call completion draft:

I thought again about it and discussed the issue with Martin. I agree
with the reference.

Thanks
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 20 Feb 2012 15:51:58 -0500

> 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."?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Feb 2012 17:04:36 -0500

> Transmitted URNs SHOULD be in lower case.  Registered URNs MUST be

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

---

From: Laura Liess <[email-masked]>
Date: Wed, 22 Feb 2012 15:09:26 +0100

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 29 Feb 2012 17:53:22 -0500

I agree with all of this, except I would change

to 

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,

===-Begin of changes ===
Change #1:
Old text:

New text:

Change #2:
Old text:

New text:

===End of changes===

Thank you
Laura