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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 2 Mar 2011 17:47:17 -0500

[as individual]

> From John Elwell
> 
> 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.

(I wrote this text.  Yes, it is awkward.)

The relationship between the various "categories" is complex.  For
instance, in the category "duration", there is "duration:short" and
"duration:long".  In the category "delay", there is "delay:none" and
"delay:yes".  These two categories are "orthogonal" in that you can
combine any value from the first category with any value from the
second category to generate a meaningful combination.  For example,
"duration:short/delay:none".

Let us consider the additional category "service", which has values
"call-waiting", "forward", etc.  It doesn't make much sense to combine
these values with the "duration" and "delay" values, as (in a given
context), "service:call-waiting" will be indicated by some particular
tone, and changing its duration will probably make the tone
unrecognizable.  So "service" isn't orthogonal to "duration" in the
way that "delay" is -- you can't combine them meaningfully, you can
only decide which of the two parts of the specification is more
important and ignore the other one.

This sort of difference exists between all the categories of
"semantic" specifications and all the categories of "rendering"
specifications.

It might be simpler to drop this as a requirement, as it probably
doesn't describe a measurable property of the mechanism.

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

Again, this is the distinction made in REQ-4, but the distinction may
not need to be made.

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

Yes, that is clearer.

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

Which would make the complete REQ-9 into:

  REQ-9: The mechanism must accommodate renderers that are limited in
  the set of signals they can render, and renderers that are 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.)

The idea of giving "hearing impaired" as an examle is that some of the
characteristics that may be commonly used (e.g., pitch:high) will have
*no* corresponding feature in the UA, and yet the mechanism must allow
the UA to function in a reasonable manner.

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

    REQ-10: If the specifier and the renderer have designs that are
    properly coordinated, the mechanism must be capable of supporting
    all indications needed 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.

> Concerning the last sentence, isn't this covered by REQ-09?

I think the situation the last sentence attempts to describe is
covered by REQ-11.

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

I am having a hard time settling on a wording, although I think you've
done a better job than I have.  I do not want to require a renderer to
do the best possible rendering if the indication comes from a
specifier whose design has been not been coordinated with the renderer
(that is, from a different vendor).  But I do not want to allow the
renderer to generate a rendering that is much worse than it could have
done, either.

As Laura says:

    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.

But at the same time, we do not want to allow the AT&T phone to make
no attempt to render DT-generated indications as well as it can.

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

I'm not sure that this needs to be stated as a requirement.  The
possiblity of storing all the available renderings locally seems to be
implied by the fact that we are designating them by URNs.

There seem to be some implied requirements:  One is that the mechanism
cannot require retrieving renderings from some specific location on
the Internet.  That seems to be implied by the fact that we are
defining URNs.  The other implied requirement is that a device with a
small, fixed set of renderings can use the mechanism in an adequate
way (althouth with reduced fidelity).  That seems to be covered by
REQ-9.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 3 Mar 2011 09:02:22 +0100

Dale,

Thanks for your responses. I think your responses and Laura's responses together provide a sufficient basis for the authors to prepare an -01, which I will review again.

John

> -----Original Message-----
> From: Worley, Dale R (Dale) [mailto:[email-masked]] 
> Sent: 02 March 2011 22:47
> To: Elwell, John; [email-masked]
> Subject: RE: Everybody get to work! -- LAST CALL on requirements
> 
> [as individual]
> 
> > From John Elwell
> > 
> > 6. Section 2: