Subject: [salud] Notes on the requirements

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 22 Feb 2011 15:59:23 -0500

[as individual]

Notes on draft-ietf-salud-alert-info-urns-00
Suggested wording changes are mostly indicated by >...<.

-- Wording changes that have some technical content

- In regard to section 3.1.1 that discusses the "normal" ring tone:
The current text considers the "normal" specification as a no-op or
placeholder.  But we will also need to be able to positively specify
normal ringing.  I suggest that we add a requirement that there be an
explicit "placeholder" URN, and consider "normal" to be an explicit
alternative relative to "external", "internal", etc.  Or perhaps
remove "normal" as such, since the other subsections of 3.1 attempt to
enumerate all known possibilities.  (E.g., "external" vs. "internal"
-- together these cover all possibilities!)

- In section 3.2.2 (indicating that a call has been forwarded), we
expect that the caller will hear one ringback (the call-forwarding
beep) followed by another (ringback from the destination that was
reached).  Indicating this seems to be straightforward if the second
ringback is carried in a 181 Call Is Being Forwarded response.  But it
would be more complex using only 180 response(s).  I suppose that the
natural way to do this is to either:

Send two 180s in quick succession, the first carrying "forward" and
the second coming from the destination.

Send one 180, whose Alert-Info is a combination of the "forward"
Alert-Info and the Alert-Info from the destination.

Send a 181, possibly with "Alert-Info: urn:forward", followed by the
180 from the destination.

We probably want to discuss this at some point.

The second possibility suggests a requirement that we probably need
for other reasons as well:  A way to combine two Alert-Info's to
create a combined indication, with any contradictions between the two
resolved in favor of the first one.  This isn't difficult to do within
the framework:

For example, if we use multiple URNs:

	"Alert-Info: urn:A, urn:B" combined with "Alert-Info: urn:C, urn:D"
	gives "Alert-Info: urn:A, urn:B, urn:C, urn:D"

If we use single URNs:

	"Alert-Info: urn:A:B" combined with "Alert-Info: urn:C:D"
	gives "Alert-Info: urn:A:B:C:D"

But we should specify that it must be possible.  One way to express
this is:

   REQ-XX: The mechanism must provide a simple way to combine two
   indications to produce an indication that requests a combination of
   the intentions of the two indications, where any contradictions or
   conflicts between the two indications are resolved in favor of the
   intention of the first indication.

-- Wording changes that I don't think are technically interesting

- In section 1.1 para 1, "URI" is used repeatedly.  This is correct in
general, but what we are complaining about is that Alert-Info is
always used with *URLs* (which are a subset of URIs).  So it would
clarify the situation to phrase it this way:

   tone to the user agent (UA).  In [RFC3261] this is done by
   including a URI >[delete "reference"]< in the Alert-Info header
   field, that >specifies< the tone.  The URI >[delete "reference"]< is
   most commonly the HTTP >URL< to the audio file.  On the receipt of
   the Alert-Info header the user agent may fetch the referenced
   ringback or ring tone and play it to the user.

Similarly, toward the bottom of section 1.1:

   Some advantages of a URN rather than a >URL of< a downloadable
   resource:

- Section 1.2 changes how Alert-Info is used compared to RFC 3261.
We should clarify exactly how we are changing its usage.

   This specification changes the usage of the SIP Alert-Info header
   defined in the [RFC3261] >by additionally allowing its use in all
   provisional responses to INVITE (except the 100 response)<.
   Backward compatibility issues are not expected, >as< devices that do
   not >expect an Alert-Info header in a particular response should
   ignore it<.

   >In practice, this specification extends Alert-Info in that it will
   cause the use of a new class of URIs and the use of multiple URIs.
   Backward compatibility issues are not expected, as devices that do
   not understand an Alert-Info URN should ignore it, and devices
   should not malfunction upon receiving multiple Alert-Info
   alert-params (which was syntactically permitted before, but rarely
   used).<

- In section 1.3, there is

   an "indication" or "identifier" (a URN in an Alert-Info header) 

But that text is only accurate in the "one URN" solution.  To allow
the multiple URN solution, this should be changed to

   an "indication" or "identifier" (one or more URNs in an Alert-Info header) 

- In section 2, REQ-7, add a clause to include that the ringback
indications are rendered by the caller independently of the ring tone
indications sent by the caller:

   REQ-7: An indication is transmitted from a specifier to a renderer,
   which must base its rendering decision only on the indication.  In
   particular, there is no multi-message negotiation process>,<
   carrying of context from one indication to the next, >or carrying
   of context from the caller's indication of the ring tone to the
   rendering decision by the caller of the ringback tone<.

This makes sure that the caller doesn't interpret the ringback
indication as an "answer" that is somehow based on the ring
indication.

- We may not need the last sentence of REQ-10, as what it describes is
covered by REQ-11.  The text would become:

   REQ-10: If the specifier and the renderer have designs that are
   properly coordinated, the indications must be able to reliably carry
   all extensions that are supported in the coordinated designs.
   >[delete sentence]<

- There is a word missing in REQ-11:

   REQ-11: In any situation, the renderer must be able to perform close
   to the best possible rendering that it could do even >if< the specifier
   had specific knowledge of the renderer's capabilities.

- I think we want to adjust the wording of REQ-12:

   REQ-12: The mechanism will allow interoperability for >indicating<
   services, such as call waiting, forward, transfer-recall,
   auto-callback, hold-recall.

- Adjust wording of REQ-18 and REQ-19:

   REQ-18: The mechanism must ensure that >if< a UA >receives< Alert-Info
   URNs or portions of an Alert-Info URN it does not understand, it can
   ignore them.

   REQ-19: The mechanism will allow storage of the actual encoding >of
   the rendering< locally rather than fetching it.

- We should add for completeness the possibility of service-provider
  specific indications:

   3.4  Service-provider-specific ringback tone indications for the
   public telephone network

   In the PSTN, different tones can be used by different service
   providers, even with one country.  End users are accustomed to hear
   the provider's specific ringback tone and would like to have this
   feature for SIP.

This is technically interesting only in that it may require
subdivision of the country categories, or allowing an extension
category for indicating service providers.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Feb 2011 16:22:32 -0500

Dale,

I generally agree. One comment:

> category for indicating service providers.

Do you see a reason why the SP can't use the "private" mechanism for 
this purpose?

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Fri, 25 Feb 2011 17:04:05 +0100

Dale,

Thank you for the comments- Please see inline.

> -- together these cover all possibilities!)
[LL] We could use "default" instead of "normal". Would this meet your needs?

>   intention of the first indication.
[LL] Agree. I will add this requirement as REQ-20.

>   Some advantages of a URN rather than a >URL of< a downloadable
[LL] OK
>   >In practice, this specification extends Alert-Info in that it will
[LL] OK
>   an "indication" or "identifier" (one or more URNs in an Alert-Info header)
[LL] OK
> indication as an "answer" that is somehow based on the ring

[LL] John already sent a comment and proposed a new text for REQ-7:
"The mechanism must provide only an indication capability, not a
negotiation capability. The mechanism must not require an indication
to depend on the context provided by a previous indication." If we add
"in any direction" at the end of the sentence, would this cover your
comment?
>   >[delete sentence]<

[LL] For both REQ-10 and REQ-11, I agree with you. John also had
comments for these requirements and had text proposals. Looking at
your and John's comments, I would propose following text:

"REQ-10: The mechanism will allow an indication to reliably carry
   all extensions if the specifier and the renderer have designs that are
   properly coordinated.
REQ-11: The mechanism will allow a renderer to select a tone that
approximates to that intended by the specifier if the renderer is
unable to provide the precise tone indicated."

What do you think?
>   auto-callback, hold-recall.

[LL] OK.
>   URNs or portions of an Alert-Info URN it does not understand, it can
[LL] OK.
>   the rendering< locally rather than fetching it.
[LL] OK.
> category for indicating service providers.

[LL]  We can add this, but, in my opinion, we would not be consistent
with the first sentence in Section 3 and with a decision taken in the
past. During a discussion at the salud meeting in connection with
US-specific ring tones brougt up by Adam, we agreed  include in
Section 3 and define the identifiers only for use cases where the
Alert-Info URN mechanism is needed today. We also agreed to require
the mechanism to be flexible, so people can  add identifiers when new
use cases arise.  Currently, I don't know of any SIP service provider
requiring a specific identifier for ringback tone. If, in the future
at&t needs such an identifier, it can either register a new identifier
with IANA  <urn:alert:locale:country.us.at&t> or just use
<urn:alert:locale:private.at&t-us>. My personal opinion is  to not add
this use case. But I am open if people would like to have it in this
specification.

Thanks a lot
Laura

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 25 Feb 2011 17:15:42 -0500

[as individual]

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]

At the level of requirements, this is just another form of extensibility.

In regard to the mechanism, I hope that this case can be accommodated by the same mechanism as all other extensibility.

In detail, though, it touches on an architectural issue:  The "private" mechanism in the draft does not have the properties I want.  In particular, the current mechanism makes a ring indication into essentially a series of name-value pairs.  E.g. one can say:

urn:alert:source:internal, urn:alert:priority:high

or

urn:alert:source:internal, urn:alert:priority:high, urn:country.hu

Adding "private" gives:

urn:alert:source:internal, urn:alert:priority:high, urn:country:hu, urn:private:carrier

The only way to know how to interpret that is to know what the URNs mean, and we can't assume that the recipient understands all the URNs.

The problem is that we want to specify "the tones used by carrier A within Hungary, understood as a subdivision of the tones used within Hungary".  And we want to do it in a way that can be understood as a subdivision of Hungary even if one does not know the name of the subdivision.  So I want to see something like <urn:country:hu:carrier-A>.  If one understands <urn:country:hu>, then one will understand that URN as a subdivision of Hungary, even if one does not know what it is.

If we were to specify that specialization by "urn:country:hu, urn:carrier-A", there is no way to know that <urn:carrier-A> is intended as a subdivision of Hungary unless one knows what "carrier-A" means.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Feb 2011 18:19:53 -0500

Dale,

Comments at end...

On 2/25/2011 5:15 PM, Worley, Dale R (Dale) wrote:
> The problem is that we want to specify "the tones used by carrier A within Hungary, understood as a subdivision of the tones used within Hungary".  And we want to do it in a way that can be understood as a subdivision of Hungary even if one does not know the name of the subdivision.  So I want to see something like<urn:country:hu:carrier-A>.  If one understands<urn:country:hu>, then one will understand that URN as a subdivision of Hungary, even if one does not know what it is.
>
> If we were to specify that specialization by "urn:country:hu, urn:carrier-A", there is no way to know that<urn:carrier-A>  is intended as a subdivision of Hungary unless one knows what "carrier-A" means.

If that particular semantic is what you want, then I will assert that we 
must treat some agence of Hungary as the "naming authority" responsible 
for subdivisions of urn:country:hu. If they (whoever "they" are) want to 
carve out a subspace for carriers, then they can do so.

In practice I doubt that will work out well. Its much like the problem 
ENUM has in delegating through the enum numbering space.

	Thanks,
	Paul