Subject: [salud] WGLC comments

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 9 May 2012 13:07:02 +0000

Laura
All,

I reviewed the draft and think it is ready to move forward.
A couple comments/questions:
1.      REQ-10, "uncommon" is misspelled;
2.      I do not understand the use case for the following requirement, is this in Section 8.2? (add reference)
   REQ-21: The mechanism must provide a simple way to combine two
   alerting indications to produce an alerting indication that requests
   a combination of the intentions of the two alerting indications,
   where any contradictions or conflicts between the two alerting
   indications are resolved in favor of the intention of the first
   alerting indication.

3.      Why is the following not a MUST?, "Registered URNs SHOULD be transmitted as
      registered."

4.      RFC is need to make extensions, right? Adding new categories and adding alert-indication
   values other than via the "private" mechanism described in
   Section 7.2 is standards action.

Regards,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
[email-masked]<mailto:[email-masked]>
+1-609-903-3360

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 9 May 2012 17:01:31 -0400

[as individual]

> From: DOLLY, MARTIN C [[email-masked]]
> 
> 2.      I do not understand the use case for the following
>    requirement, is this in Section 8.2? (add reference)
> 

The idea is that if an INVITE is passing through a middlebox, the
middle box needs a way to modify the ring tone specification in known
ways without having to understand the incoming ring tone specification
in detail.

One example is if the middlebox wants to mandate that the ring tone
include the "external source" indication if at all possible.  In the
current draft, this is done by placing <urn:alert:source:external>
*before* the current Alert-Info arguments.  The processing is defined
that this means that the UAS must indicate "source:external" if
at all possible.

An alternative is if the middlebox wants to *suggest* that the ring
tone include the "external source" indication.  In the current draft,
this is done by placing <urn:alert:source:external> *after* the
current Alert-Info arguments.  The processing is defined that this
means that the UAS must indicate "source:external" if that is
possible, given the previous URNs and the capabilities of the UAS.

> 3.      Why is the following not a MUST?, "Registered URNs SHOULD be
>       transmitted as registered."

Given that comparisons MUST be case-insensitive, it seems overly
strong to use "MUST" here.

>    Section 7.2 is standards action.

Yes, that's what the last paragraph of 7.1 and the first paragraph of
6.1 say.

At one point I favored that adding a new alert-category should be a
standards action, adding a new alert-identifier should be by expert
review, and adding a third-level identifier should be even more
relaxed.  But it's not clear that there are any use cases for more
relaxed extension rules.

Dale