Subject: [salud] Everybody get to work! -- LAST CALL on requirements

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 10 Feb 2011 13:15:07 -0500

[as chair]

I apologize that I've not been keeping up with the work in Salud.

As you know, there has been little or no discussion of Laura's most recent draft, draft-ietf-salud-alert-info-urns-00.  So I am calling a mini-Last Call on the context and requirements sections, sections 1, 2, and 3.  This LC will run until Thursday, 24 February.

So everybody please read through those sections and respond regarding anything that is incorrect, incomplete, or unworkable.  Also, please examine any apparent technical issues you have been considering; very often technical issues are requirements issues in disguise, and we want to make those requirements issues explicit.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Feb 2011 11:51:35 +0100

I have reviewed sections 1 to 3. In general this is on the right track, but some attention to the wording is needed in a number of places. In particular, in section 2, the language in the requirements statements should be a lot more precise in some cases. Specific comments:

1. Section 1.1:
"The Session Initiation Protocol (SIP) [RFC3261] allows for user agent
   servers (UAS) and proxies to provide the specific ringback or ring
   tone to the user agent (UA)."
The mention of UAS is confusing and probably not relevant, given the bidirectional usage of Alert-Info (in INVITE request, in 180 response). Also, SIP doesn't provide a specific ringback or ring tone - it merely suggests a ringback tone or ring tone to be used. I would suggest rewording as:
"The Session Initiation Protocol (SIP) [RFC3261] includes a means to suggest to a user agent (UA) a particular ringback tone or ring tone to be used during session establishment."

2. Section 1.1
"This mechanism does not ensure interoperability when there is no
   common understanding of the referenced content (different countries
   or vendors, hearing impaired) or when the user wants his own tones
   configured in the end device."
I think this needs re-organising. The fundamental problem we are trying to describe is "no common understanding", and this leads to issues when the user wants his own tones or other forms of rendering (e.g., hearing impaired). I would suggest the following rewording:
"This mechanism hinders interoperability when there is no common understanding of the meaning of the referenced tone, which might be country- or vendor-specific. It can lead to problems for the user tying to interpret the tone and problems for the UA wanting to substitute its own tone (e.g., in accordance with user preferences) or provide an alternative alerting mode (e.g., for hearing-impaired users)."

3. Section 1.1:
"The downside is that if the recipient does not understand the URN
   then it will only be able to render a default ringback or ring tone.
   To provide the general awareness about the Alert-Info URNs this
   document provides IANA template for registering the URNs and defines
   several typical identifiers."
I think these should be two separate paragraphs. Moreover, I think the second sentence needs some attention - the template is not "to provide general awareness". Perhaps the following would be better:
"This document provides a template for registering alert URNs and defines several typical values."
Or alternatively:
"This document creates a new URN namespace and registry for alert indications and registers some initial values."

4. Section 1.3:
"This specification uses a number of terms to refer to the roles
   played by participants in, and objects of, the SIP Alerting for User
   Devices."
This is hard to understand. What is/are "the SIP Alerting for User Devices"? Why can't it just say:
"This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP".

5. Section 2:
"   This section discusses the requirements for an identifier to
   transport the semantics of the signaling situation or the
   characteristics of the rendering."
Would it be better to change "signaling situation" to "alerting situation"?

6. Section 2:
"REQ-4: Indications include subsets which have distinctly different
   semantics, that is, they form disjoint "value spaces".  For example,
   some indications should describe the semantics of the signaling
   situation whereas others should describe the audio characteristics of
   the signal.  This implies that there is no single set of categories
   that can be used as independent coordinates of the value-space of
   indications."
I am not sure I understand this at all. Are we trying to say that indications within a subset have different semantics (in which case, what is the purpose of a subset?) or indications within a subset have similar semantics but indications within different subsets have different semantics? Concerning the last sentence, how do "categories" relate to "subsets" in the first sentence? What is meant by "coordinates of the value-space"? What exactly is the requirement being expressed? It just seems to be a statement of facts. I can't really propose new text without understanding intentions of the authors.

7. Section 2:
" - add further value spaces of indications whose semantics are not
   related to existing indications, and thus, whose categories differ
   from and do not interact with existing categories."
How does this differ from the earlier bullet:
- add further categories that are orthogonal to existing categories"?

8. Section 2:
"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 or carrying
   of context from one indication to the next."
This sounds more like a requirement on a recipient (UA) rather than a requirement on the mechanism. This section should confine itself to requirements on the mechanism. Perhaps it should be expressed something like (as two separate requirements):
"The mechanism must provide only an indication capability, not a negotiation capability"
and
"The mechanism must not require an indication to depend on context provided by a previous indication."

9. Section 2:
"  REQ-9: The renderer may be customized in ways that limit the set of
   signals that it can render, or it may be provided with a set of
   signals that have uncommon semantics.  (The canonical example is a UA
   for the hearing-impaired.)  (By REQ-7, the renderer has no way of
   transmitting this fact to the specifier.)"
Not sure what the requirement is here. Should it be something along the lines of:
"The mechanism must accommodate renderers that are limited in the set of signals they can render..."

10. Section 2:
"   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.  In any
   other situation, it is not required from the renderer to perform the
   best possible rendering."
Rather than "the indications must be able to reliably carry all extensions that are supported in the coordinated designs", how about "the mechanism must be capable of supporting all indications needed"?
Concerning the last sentence, isn't this covered by REQ-09?

11. Section 2:
"REQ-11: In any situation, the renderer must be able to perform close
   to the best possible rendering that it could do even the specifier
   had specific knowledge of the renderer's capabilities."
I am not sure what this is trying to say. Is it trying to say that the specifier might not know the renderer's capabilities, and that despite this, the renderer should try to get as close as possible to what the specifier has specified? I don't know whether the following captures the intent:
"The mechanism should facilitate rendering that is close to the intention of the specifier, even when the renderer does not have capabilities for an exact rendering."
Note that I don't think this can be more than should strength - it will be hard to measure the mechanism against this requirement.

12. Section 2:
"   REQ-12: The mechanism will allow interoperability for services as
   call waiting, forward, transfer-recall, auto-callback, hold-recall."
Allowing these services to interoperate is outside the scope of this work. It is only the indications relating to these services that are relevant. This should say:
"   REQ-12: The mechanism will support indications relating to services such as call waiting, forward, transfer-recall, auto-callback and hold-recall."

13. Section 2:
"   REQ-19: The mechanism will allow storage of the actual encoding
   locally rather than fetching it."
Should it say "rendering" rather than "encoding"?

14. 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."
We should not use RFC 2119 language in use case descriptions.

Nits:
- Change "header" to "header field" throughout (I don't think there is anywhere that refers to the entire SIP header) -  it is inconsistent at present.
- Use "ringback tone" instead of "ringback" throughout  - it is inconsistent at present.
- Change "Alert-Info SIP-header" to "SIP Alert-Info header field".
- The language in the requirements should be made consistent. Sometimes "will" is used, sometimes "must" is used, and sometimes other constructs. The subject of any requirement should in general be "the mechanism". Note that in some requirements documents we have used RFC 2119 language, but there are also opinions it should not be used for requirements. Given that this document also includes the mechanism, it would be better to avoid RFC 2119 language for requirements, and keep it for the mechanism.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Worley, Dale R (Dale)
> Sent: 10 February 2011 18:15
> To: [email-masked]
> Subject: [salud] Everybody get to work! -- LAST CALL on requirements
> 
> [as chair]
> 
> As you know, there has been little or no discussion of 
> Laura's most recent draft, 
> draft-ietf-salud-alert-info-urns-00.  So I am calling a 
> mini-Last Call on the context and requirements sections, 
> sections 1, 2, and 3.  This LC will run until Thursday, 24 February.
> 
> So everybody please read through those sections and respond 
> regarding anything that is incorrect, incomplete, or 
> unworkable.  Also, please examine any apparent technical 
> issues you have been considering; very often technical issues 
> are requirements issues in disguise, and we want to make 
> those requirements issues explicit.
> 
> Dale
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Laura Liess <[email-masked]>
Date: Tue, 15 Feb 2011 14:42:18 +0100

John,

Thank you for the comments and especially for the elaborate text
proposals. I agree with you and with your text proposals in most
cases. Please see inline.

> "The Session Initiation Protocol (SIP) [RFC3261] includes a means to suggest to a user agent (UA) a particular ringback tone or ring tone to be used during session establishment."
[LL]  Sounds good. The restriction to the UAS in the draft is wrong.

> "This mechanism hinders interoperability when there is no common understanding of the meaning of the referenced tone, which might be country- or vendor-specific. It can lead to problems for the use…
[LL] OK

> "This document creates a new URN namespace and registry for alert indications and registers some initial values."
[LL] Yes. I am fine with both proposals, with a slight preference for
the second.

> "This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP".
[LL] Agree.
> Would it be better to change "signaling situation" to "alerting situation"?
[LL] OK for me.
> I am not sure I understand this at all. Are we trying to say that indications within a subset have different semantics (in which case, what is the purpose of a subset?) or indications within a subset have similar semantics but indications within different subsets have different semantics?
[LL] The second is the case. The text is more an explanation of REQ-3
than an independent requirement, but in fact im makes things more
confusing. I think the best thing would be to discard it.

> - add further categories that are orthogonal to existing categories"?
 [LL] There is practically no difference between the two bullets. I
think the first bullelt is more clear, so let's discard the last
bullet. Is this OK?

> "The mechanism must not require an indication to depend on context provided by a previous indication."
[LL ] It's OK for me.

>"The mechanism must accommodate renderers that are limited in the set of signals they can render..."
[LL] What do you think about "The mechanism must be able to
accommodate renderers that are customized with a limited or uncomon
set of signals they can render."  Just "Limited" is to me like the
renderer would be an old, very simple PSTN-phone. I wouldn't call
hearing-impaired phones customized  for video and text  to be "limited
in the set of signals they can render", rather "uncommon".

> Rather than "the indications must be able to reliably carry all extensions that are supported in the coordinated designs", how about "the mechanism must be capable of supporting all indications nee…
[LL]Fine.

> Concerning the last sentence, isn't this covered by REQ-09?
[ LL] I wouldn't say so. Req-9 means that the mechanism should work
well also, e.g., for end devices of hearing impaired, customized to
render text or video instead of ringing tones. The last sentence in
Req-10 means that, e.g., if we attach an AT&T  SIP-phone  the DT
SIP-network we may not get the rendering intended by DT and this is
fine.

> Note that I don't think this can be more than should strength - it will be hard to measure the mechanism against this requirement.
[LL] Yes, a "no" is missing in the text. I like much better your text
proposal. An should is fine.

> "   REQ-12: The mechanism will support indications relating to services such as call waiting, forward, transfer-recall, auto-callback and hold-recall."
[LL] Yes, fine.

> Should it say "rendering" rather than "encoding"?
[LL] What would you say to "rendering representation" ? But I am OK
with "rendering", too.

> We should not use RFC 2119 language in use case descriptions.
[LL] OK. I will put shall in lower case letters. Otherrwise it is ok, I think?

> - The language in the requirements should be made consistent. Sometimes "will" is used, sometimes "must" is used, and sometimes other constructs. The subject of any requirement should in general be…
[LL] OK.

Thanks a lot
Laura

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Feb 2011 16:35:42 +0100

Laura,

I have stripped out those items where we are in agreement. See below for other comments:

> > I think these should be two separate paragraphs. Moreover, 
> I think the second sentence needs some attention - the 
> template is not "to provide general awareness". Perhaps the 
> following would be better:
> > "This document provides a template for registering alert 
> URNs and defines several typical values."
> > Or alternatively:
> > "This document creates a new URN namespace and registry for 
> alert indications and registers some initial values."
> >
[JRE] Yes, my slight preference is for the second.

> > I am not sure I understand this at all. Are we trying to 
> say that indications within a subset have different semantics 
> (in which case, what is the purpose of a subset?) or 
> indications within a subset have similar semantics but 
> indications within different subsets have different semantics?
[JRE] Deletion would be fine.

> think the first bullelt is more clear, so let's discard the last
[JRE] Yes.

> >"The mechanism must accommodate renderers that are limited 
> in the set of signals they can render..."
[JRE] I would be happy with your modified text, although we might wish to cite hearing-impaired phones as an example of devices that have uncommon renderings - otherwise it might no be clear what is meant.

> > Rather than "the indications must be able to reliably carry 
> all extensions that are supported in the coordinated 
> designs", how about "the mechanism must be capable of 
> supporting all indications needed"?
> [LL]Fine.
> 
[JRE] I think I understand. With REQ-09 the renderer understands the received indication and chooses to render in a different way, whereas with REQ-10 the renderer doesn't understand the indication precisely but understands enough to render in a way that approximates to what the specifier intended. So in your example above, the renderer might understand a concept like "external ring tone", but not "German external ring tone", and rendering its own external ring tone would be good enough, given that it can't render German external ring tone. Am I correct?

If so, perhaps we should consider rewording, e.g., as follows:
"REQ-10: 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."

> [LL] What would you say to "rendering representation" ? But I am OK
[JRE] OK

> [LL] OK. I will put shall in lower case letters. Otherrwise 
[JRE] Yes, that would be sufficient.

John

---

From: Laura Liess <[email-masked]>
Date: Tue, 15 Feb 2011 17:08:38 +0100

John,

Thank you. The rewording for REQ-10 is great.
Please see below the text proposal for 9. Section 2

> [JRE] I would be happy with your modified text, although we might wish to cite hearing-impaired phones as an example of devices that have uncommon renderings - otherwise it might no be clear what i…
[LL] So, the whole text could be: " The mechanism must be able to
accommodate renderers that are customized with a limited or uncomon
set of signals they can render. The canonical example is a UA for the
hearing-impaired, customized with an uncomon set of signals, video or
text instead of audio. (By REQ-7, the renderer has no way of
transmitting this fact to the specifier.)"

Kind regards
Laura

2011/2/15 Elwell, John <[email-masked]>:
>> designs.  In any

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Feb 2011 18:10:32 +0100

OK

John 

> From: Laura Liess [mailto:[email-masked]] 
> Sent: 15 February 2011 16:09
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [salud] Fwd: Everybody get to work! -- LAST CALL 
> on requirements
> 
> John,
> 
> > [JRE] I would be happy with your modified text, although we 
> might wish to cite hearing-impaired phones as an example of 
> devices that have uncommon renderings - otherwise it might no 
> be clear what is meant.
> > [JRE] I would be happy with your modified text, although we 
> might wish to cite hearing-impaired phones as an example of 
> devices that have uncommon renderings - otherwise it might no 
> be clear what is meant.
> >
> >>
> >> >
> >> > 10. Section 2:
> > [JRE] I think I understand. With REQ-09 the renderer 
> understands the received indication and chooses to render in 
> a different way, whereas with REQ-10 the renderer doesn't 
> understand the indication precisely but understands enough to 
> render in a way that approximates to what the specifier 
> intended. So in your example above, the renderer might 
> understand a concept like "external ring tone", but not 
> "German external ring tone", and rendering its own external 
> ring tone would be good enough, given that it can't render 
> German external ring tone. Am I correct?
> >
> > "REQ-10: 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."
> >
> >> > 13. Section 2: