Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt

From: Laura Liess <[email-masked]>
Date: Thu, 1 Apr 2010 17:10:35 +0200

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Freitag, 26. März 2010 03:02
> An: Laura Liess
> Cc: [email-masked]; [email-masked]; 'Gerold Pinker';
Huelsemann,
> Martin; [email-masked]
> Betreff: Re: AW: [dispatch] FW: I-D
Action:draft-liess-dispatch-alert-info-
> urns-01.txt
> 
> 
> 
> Laura Liess wrote:
> > Paul,
> >
> > Thank you for the proposal and the elaborate description. I definitively
> > like it.
> > It seems to solve the combinations problem, it is extensible and easy to
> > understand.
> > I have two comments on it, connected to "call-waiting".
> >
> > 1) It seems to me that there is some misunderstanding concerning the
meaning
> > of the "call-waiting" alert urn. It is not the callee's presence state,
but
> > the state of the call itself. The "call-waiting" tone tells the caller:
> > "Your call is temporary queued (waiting) at the callee's side because
the
> > callee is currently involved in another call. The callee was informed
that
> > your call is waiting." Having this information, the caller can decide to
> > wait for a while or to cancel the call. This is an already existing
> > PSTN-service which customers expect us to provide also when we migrate
to
> > SIP.
> > Because this urn tells the user that the service "call-waiting" was
> > performed at the other side of the call, we name "service" was choosed
for
> > this category.
> 
> I wasn't sure from the draft whether this was about the ringback to the
> caller (which is what you are describing), or whether it was about the
> "ring" to the callee, which is of typically different in this case.
> 
> As I noted, I didn't think it made that much sense as an indication to
> the callee, since the callee knows its status. So I think we are in
> agreement about the important use - for ringback when the callee is
> currently handling another call.
> 
> As I was writing things down I realized that this is really a statement
> about the state of the callee that happens to be known to the UAS and
> hence reportable. I realize in the commonly used case this is a
> "service" in the network, and hence is different from a feature of the
> UAS - such as a multi-line phone. 

This was the reason why we called this category "service".

> But the two are functionally
> equivalent to both the caller and the callee - the callee is occupied on
> some other call, and may (or may not) be delayed in answering. (Whether
> this delay is likely to be longer, or shorter, than would be the case if
> not on another call, is debatable. I guess just reporting it to the
> caller as a datum does permit the caller to make his own judgement.

> 
> If this is reported as a distinct category, then it can be reported in
> an orthogonal way. For instance maybe the ringback will be "normal" but
> there will be a display on the phone - perhaps akin to a "on hold" light.

> 
> > 2) There are already implementations of urn:alert:service:call-waiting.
This
> > syntax is used in the 3GPP Specification for the call-waiting service
(TS
> > 24.615 "Communication Waiting (CW) using IP Multimedia (IM) Core Network
> > (CN) subsystem"). If we change this name, people either change their
> > software, which means money and time for them, or they leave it as it
is,
> > which means lack of interoperability e2e. The "reason"-category contains
in
> > principles names for services, so I think it does not harm the proposal
if
> > we just replace "reason" by "service" and keep the interoperability with
> > existing implementations.
> 
> How to name things is a second order issue. If its just a matter of
> "service" vs. "reason" then I don't care very much. (I'm not especially
> attached to "reason", but I also find "service" somewhat confusing for
> the purpose.)
> 
> The orthogonality is more important. The way I partitioned the data is
> just a first cut, and I'm entirely open to alternative ways of doing
> that. But I would hate to see the categorization warped just to fit one
> preexisting use. IMO it would make more sense to special-case that one -
> perhaps treat it as a separate category of its own.

I agree. I went through the items we currently have in the category
"service" (or "reason"). We have there "transfer-recall", "auto-callback"
and "hold-recall", which are sent in an INVITE and indicate to the callee
the "reason" for the incoming call. We could put them in the "reason"
category. We also have "call-waiting" and "forward", which are sent in an
180 Ringing and indicate to the caller that some network service was applied
to the call at the calee's side. We could put them in the "service"
category. 

Would this partitioning suit your vision ?

Thanks a lot
Laura 

> 
> 	Thanks,
> 	Paul
> 
> > Thanks a lot
> > Laura
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Paul Kyzivat [mailto:[email-masked]]
> > Gesendet: Donnerstag, 25. März 2010 19:51
> > An: Laura Liess
> > Cc: [email-masked]; [email-masked]; Liess Laura; Gerold
Pinker
> > Betreff: Re: [dispatch] FW: I-D
> > Action:draft-liess-dispatch-alert-info-urns-01.txt
> >
> > I've been thinking about how the "namespace" of alert-info URNs might be
> > reorganized. My goals in doing so are:
> > - allow the different "aspects" of the alert to be specified
> > - make it clear what the combination rules are for these
> > - allow for comparable expressiveness for rings and ringbacks
> > - provide room for extension
> >
> > The following is a rough outline of a what I have in mind:
> >
> > The urn syntax is as in the current draft, *except*:
> >
> > alert-category  = "reason" / "priority" / "source" /
> >                    "duration" / "delay" / "locale" /
> >                    extension-category
> > extension-category = token
> >
> > The principle for choosing these categories is that they are orthogonal.
> > Hence there is a single rule for well-formedness of Alert-Info:
> > there can be at most one instance of each alert-category, and in
> > principle any such combination is valid. (Though some may be silly or
> > uninteresting.)
> >
> > The above doesn't distinguish ring from ringback. That is to be
> > determined from context - when present in a request it describes the
> > ring. When present in a response it describes the ringback. Again, in
> > principle any combination can be used for either ring or ringback,
> > though some combinations may be silly or uninteresting.
> >
> > The exact way in which the various categories are combined for rendering
> > is left as an implementation issue. The implementation is free to ignore
> > any or all at its whim.
> >
> > Its my intent that things previously discussed in the draft can all be
> > mapped onto these categories. Here is my swag at doing so:
> >
> > urn:alert:reason:
> >
> > - normal (default)
> > - call-waiting
> > - forward
> > - auto-callback
> > - recall.hold
> > - recall.transfer
> > - private.<private-name>
> >
> > urn:alert:priority:
> >
> > - normal (default)
> > - low
> > - high
> > - crisis
> > - private.<private-name>
> >
> > urn:alert:source:
> >
> > - unclassified (default)
> > - internal
> > - external
> > - friend
> > - family
> > - private.<private-name>
> >
> > urn:alert:duration:
> >
> > - normal (default)
> > - short (or could be "zip")
> > - long (for completeness, or omit if unneeded)
> > - private.<private-name>
> >
> > urn:alert:delay:
> >
> > - none (default)
> > - yes (not sure what to put here)
> > - private.<private-name>
> >
> > urn:alert:locale:
> >
> > - default (default)
> > - country.<ISO 3166-1 country code>
> > - private.<private-name>
> >
> > In the above the "private.<private-name>" syntax is for extensions
> > specific to independent organizations. The <private-name> is in the form
> > of a "reverse FQDN" such as is used for Java package names. This gives a
> > way of assigning unique names without the need for a new registry. The
> > namespace for each alert category is independent. Those assigning new
> > names must ensure they are in a position to assign names uniquely for
> > the FQDN they choose.
> >
> > (I have considerable reservation about introducing such an uncontrolled
> > extension mechanism. I see how it can provide a lot of flexibility in
> > providing tailored user experiences. But it can also lead to vendor lock
> > in if a device is only capable of supporting a particular vendor's
> > specific extensions. So I think this needs a lot of discussion.)
> >
> > For example, I might want to define:
> >
> > urn:alert:source:private.com.cisco.customer
> >
> > If I were to do so, I should first ensure that I speak for cisco.com
> > when coining this.
> >
> > Additions to the values above other than via the "private" mechanism
> > would be by standards action. The same for adding new categories.
> > (There could be a "private" mechanism for categories too. But I'm not at
> > all confident that is a good thing.)
> >
> > I'm not quite sure about "call-waiting" as a "reason" - it doesn't seem
> > quite right. The reason could still be any of those other things. For
> > the ring indication its far from clear to me that it is needed at all -
> > the recipient already knows it is on a call, and doesn't need to be told
> > that. It may make more sense for the ringback - in that case you are
> > being told something about the state of the other party. Perhaps this
> > should be replaced by something about the state of the party sending the
> > message. E.g.
> >
> > urn:alert:state:
> >
> > - unknown
> > - waiting (in a request, means the caller is waiting
> >             for the call to complete. The normal case.)
> > - on-a-call (in a response, means the called party
> >               is on another call - the call waiting case.
> >               But could apply to a caller as well.)
> > - away (in a request, means the call has been generated
> >          automatically and the user will be summoned if/when
> >          the call completes. This is the converse of waiting)
> >
> > (This "state" is really a form of presence. Whether its good to encode
> > it here, rather than actually transmitting pidf, is an interesting
> > question.)
> >
> > How all of this might be mapped onto actual renderings is probably not
> > something that should be standardized, but it might be worth including
> > some possibilities as examples. One that comes to mind is:
> >
> > (Assuming all rendering are audio):
> >
> > - the device has a set of possible clips it can render
> > - each is attributed with the values it matches for each
> >    category above. (none, one, several, or all for each
> >    category.)
> >
> > The device just finds the maximal match and renders that one.
> >
> > This might be augmented if there are different sorts of renderings -
> > e.g. audio, visual, tactile (vibrarion). In that case it might seek out
> > a match for each sort and render them all.
> >
> > 	Thanks,
> > 	Paul
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Apr 2010 14:41:20 -0400

> Would this partitioning suit your vision ?

I had proposed just clumping those together into a single category 
(which I called reason):

urn:alert:reason:

- normal (default)        (ring & ringback)
- call-waiting            (       ringback)
- forward                 (ring & ringback)
- auto-callback           (ring & ringback)
- recall.hold             (ring & ringback)
- recall.transfer         (ring & ringback)
- private.<private-name>  (ring & ringback)

My logic above is:

- whether this applies to ring or ringback depends on context
   (the message it is in) so doesn't have to be part of the naming.
   Making this part of the naming just introduces another sort of
   error to deal with. ("reason" can only be used in requests, while
   "service" can only be used in responses.)
   Is there a strong reason partition things that way?

- for many (but perhaps not all) it might be useful in both
   directions, though the particular alert used would differ.

For instance, its useful to inform both the holder and the holdee of a 
hold-recall.

(Note that I also changed the naming to recall.hold and recall.transfer 
because the are both "recall" functions, and it might be convenient for 
some devices to alert them both the same. I'm still debating with myself 
whether auto-callback should be recall.auto.)

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Tue, 6 Apr 2010 15:31:52 +0200

Paul,

> I had proposed just clumping those together into a single category (which I
> called reason):
>
> urn:alert:reason:
>

I think the proposal to separate urns for ring and ringback came up
some months before, either on the mailing list or in some discussion
at the IETF, in connection with the urn combinations problem. I am
fine with your proposal. In principle, also the call-waiting
indication can be sent to caller and callee. We probably have to
include a statement in the draft that the receiving UA should make the
decision about what to render to the user depending on oth the value
of the Alert-Info URN and the kind of message it received (INVITE or
18x-response).

The only problem I have here is the naming. Personally, I would prefer
to name the whole category you described above as "service", for
folowing reasons:
- "reason" is somehow to broad. In principle,  it easily may happen
that people add to this category also other "reason"-indications which
have nothing to do with services and are orthogonal to the indications
we have now in this category. But as a combination rule, we would like
to have no more than one urn from same category. The name "service"
would be more restrictive.
- All items of this category indicate that some service was initiated.
- Implementors, testers, operating guys are more familiar with
call-waiting, forward or transfer as being a service than being a
reason.

But if this name is not at acceptable for you, I would like at least
to come back to your proposal in your mail from  April 1 and treat
"call-waiting" as a separate "service" category.

> because the are both "recall" functions, and it might be convenient for some
> devices to alert them both the same. I'm still debating with myself whether
> auto-callback should be recall.auto.)

This makes sense to me. (I just used the old names in my mail.)  Only
I would choose recall.callback instead of recall.auto. I think it is
more intuitive.

Thanks  a lot
Laura

2010/4/1 Paul Kyzivat <[email-masked]>:
> I had proposed just clumping those together into a single category (which I
> called reason):
>
> urn:alert:reason:
>
> because the are both "recall" functions, and it might be convenient for some
> devices to alert them both the same. I'm still debating with myself whether
> auto-callback should be recall.auto.)
>
>        Thanks,
>        Paul
>
>> Thanks a lot
>> Laura
>>>
>>>        Thanks,
>>>        Paul
>>>
>>>> Thanks a lot
>>>> Laura
>>>>
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Apr 2010 10:13:05 -0400

Laura - responses inline.

> of the Alert-Info URN and the kind of message it received (INVITE or

Yes, that makes sense. Also, *what* is rendered, and what device it is 
rendered on, will typically vary depending on this distinction. (The 
headset vs. the ringer or speaker.) That should all be mentioned.

> call-waiting, forward or transfer as being a service than being a

I am not very attached to the name "reason". While I'm not fond of the 
name "service", I don't strongly object to it either, and if that is an 
important choice for you I can accept it.

> "call-waiting" as a separate "service" category.

I can especially accept "service" if it means all these things are in 
the same category.

> I would choose recall.callback instead of recall.auto. I think it is

Sounds good to me.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Thu, 8 Apr 2010 15:49:47 +0200

Paul,

I seems to me that we reached a consensus :-). I hope I understood
correctly all your comments. Just to avoid some possible
misunderstandings, I would like to write down my understanding of what
we agreed on:

alert-category  = "service" / "priority" / "source" /
                 "duration" / "delay" / "locale" /
                 extension-category
extension-category = token

The categories are orthogonal. Any Alert-Info URN defined in this
specification is syntacticaly valid for ring and for ringback and can
be used in an INVITE or in a 18x response.
There can be at most one instance of each alert-category in an
Alert-Info header. In principle any combination of Alert-Info URNs
with different "alert-category" is valid and can be used for either
ring or ringback, though some combinations may not make sense.
The receiving UA should make the decision about what to render to the
user and what device it is rendered on  depending on the value of the
Alert-Info URN and the kind of the received message (INVITE or
18x-response). Typically, the same UA will do the rendering of a
particular Alert-Info URN received in an INVITE differently from the
rendering of the same Alert-Info URN received in a 18x response.

The exact way in which the various categories are combined for
rendering is left as an implementation issue. The implementation is
free to ignore any or all received Alert-Info URNs.

Values for alert-indications:

urn:alert:service:

- normal (default)
- call-waiting
- forward
- recall.callback
- recall.hold
- recall.transfer
- private.<private-name>

urn:alert:priority:

- normal (default)
- low
- high
- private.<private-name>

urn:alert:source:

- unclassified (default)
- internal
- external
- friend
- family
- private.<private-name>

urn:alert:duration:

- normal (default)
- short (or "zip")   **/ Comment on this: We should check this with
Alan, but I think "short"
- long
- private.<private-name>

urn:alert:delay:

- none (default)
- yes
- private.<private-name>

urn:alert:locale:

- default (default)

The "private.<private-name>" syntax is for extensions specific to
independent organizations. The <private-name> is in the form of a
"reverse FQDN" such as is used for Java package names. This gives a
way of assigning unique names without the need for a new registry. The
namespace for each alert category is independent. Those assigning new
names must ensure they are in a position to assign names uniquely for
the FQDN they choose.

For example, Cisco might want to define:

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

Is this OK ?

Thanks a lot
Laura

2010/4/6 Paul Kyzivat <[email-masked]>:
> rendered on, will typically vary depending on this distinction. (The headset
> vs. the ringer or speaker.) That should all be mentioned.
>
> I am not very attached to the name "reason". While I'm not fond of the name
> "service", I don't strongly object to it either, and if that is an important
> choice for you I can accept it.
>
> I can especially accept "service" if it means all these things are in the
> same category.
>
>>> some
>>> some

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 10:10:38 -0400

Laura,

This all sounds good to me. I expect others may want to see some 
refinements, such as the adding or removal of specific values, renaming 
of specific values, etc. But to me the main thing is to have established 
the orthogonality, the rules for combining, and the extensibility mechanism.

I hope now get some feedback from others.

	Thanks,
	Paul

Laura Liess wrote:
>>>>>>> rendering

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 12:17:05 +0200

This sounds like quite a comprehensive proposal. Perhaps it would benefit from a little more being said on the handling of unknown or unsupported values, and whether implementations are free to ignore categories not of interest. But that can wait until we have a draft.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Laura Liess
> Sent: 08 April 2010 14:50
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [dispatch] FW: I-D
> >>> I had proposed just clumping those together into a single
> category (which
> >>> I
> >>> called reason):
> >>>
> >>> urn:alert:reason:
> >>>
> >>> devices to alert them both the same. I'm still debating
> with myself
> >>> whether
> >>>>> preexisting use. IMO it would make more sense to
> special-case that one
> >>>>> -
> >>>> and "hold-recall", which are sent in an INVITE and
> indicate to the
> >>>> callee
> >>>> category. We also have "call-waiting" and "forward",
> which are sent in
> >>>> an
> >>>> 180 Ringing and indicate to the caller that some network
> service was
> >>>> applied
> >>> I had proposed just clumping those together into a single
> category (which
> >>> I
> >>> called reason):
> >>>
> >>> urn:alert:reason:
> >>>
> >>> devices to alert them both the same. I'm still debating
> with myself
> >>> whether
> >>>>>> I've been thinking about how the "namespace" of
> alert-info URNs might
> >>>>>> be
> >>>>>> is left as an implementation issue. The implementation
> is free to
> >>>>>> ignore
> >>>>>> any or all at its whim.
> >>>>>>
> >>>>>> specific to independent organizations. The
> <private-name> is in the
> >>>>>> form
> >>>>>> of a "reverse FQDN" such as is used for Java package
> names. This gives
> >>>>>> a
> >>>>>> providing tailored user experiences. But it can also
> lead to vendor
> >>>>>> lock
> >>>>>> (There could be a "private" mechanism for categories
> too. But I'm not
> >>>>>> at
> >>>>>> I'm not quite sure about "call-waiting" as a "reason"
> - it doesn't
> >>>>>> seem
> >>>>>> the ring indication its far from clear to me that it
> is needed at all
> >>>>>> -
> >>>>>> the recipient already knows it is on a call, and
> doesn't need to be
> >>>>>> told
> >>>>>> should be replaced by something about the state of the
> party sending
> >>>>>> the
> >>>>>> message. E.g.
> >>>>>>
> >>>>>> urn:alert:state:
> >>>>>>
> >>>>>> - unknown
> >>>>>> e.g. audio, visual, tactile (vibrarion). In that case
> it might seek
> >>>>>> out
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Apr 2010 11:00:39 -0400

> This sounds like quite a comprehensive proposal. Perhaps it would benefit from a little more being said on the handling of unknown or unsupported values, and whether implementations are free to ign…

My opinion on this is that the receiving UA is free to ignore any values 
it doesn't understand or simply prefers to ignore. Its all advisory.

	Thanks,
	Paul