Subject: [salud] New version for draft-liess-dispatch-alert-info-urns submitted

From: Laura Liess <[email-masked]>
Date: Tue, 19 Oct 2010 13:46:57 +0200

Hi,

we submitted the version 03 for the Alert-Info URN in , as decided in Maastricht
http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns-03.txt

I did following main changes to the previous version:
- New Section 1.2 about the header usage change
- Section 1.3 Terminology: Definition for "ring tone" and "ringback
tone". At the meeting, Keith asked to use the E182 terminology. They
use "ringing tone" instead the ringback tone, but I think this is
confusing for many people, so I choosed to clarify the terminology.
-  Section 2 Requirements, 1-st paragraph:
- Alerting and alerting signal changed to signaling and rendering.
Gonzalo had a comment at the ad-hoc that the alert urn is not only for
alerting.
-   General: "180 Ringing responses" changed to "provisional 1xx
responses excepting the 100 responses" as decided in Maastricht
- Section 2 Requirements: REC-17: added Adam's use cases, with the
comment that the values will not be defined in this spec. Adam agreed
to this in the meeting.
- Section 4 registration template: top-level indication and
sub-indication replaced by "name".
- Sections for extenssion rules and priority rules added, but they are
still TBD.
- Editorial changes, e.g. references, consistent terminology in the document.

Thanks,
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Oct 2010 20:05:42 -0400

Hi Laura,

This is looking fairly clean. I have a few points on section 7. They 
aren't substantive - just phrasing/terminology

> This is done by including multiple URNs separated by a comma.

That is one way, but its a little misleading. Technically you do this by 
supplying multiple alert-params containing 'alert' URNs. One way of 
doing this is by separating them by a comma in one Alert-Info header. 
Another is to provide them in separate Alert-Info headers.

I guess I would word this as "This is done by including multiple 'alert' 
URNs, in one or more Alert-Info headers in the request or response."

The following from the same paragraph has related issues:

> There can be at most one instance of each alert-category in an
> Alert-Info header.

For one thing, its not normative but should be. For another, there could 
be multiple Alert-Info headers. I suggest:

"There MUST be at most one instance of each alert-category in the 
Alert-Info header(s) of a request or response."

The paragraph then goes on to talk in several places about an Alert-Info 
URN, as if there was only one. I don't have specific wording to propose, 
but I think the intent here is to talk about the collective rendering 
based on all the URIs in all the Alert-Info headers in the 
request/response. Also missing here is any mention of how the use of the 
alert URN in Alert-Info interacts with other sorts of URIs also present 
in Alert-Info.

I think the expedient thing to do is to specify behavior when all the 
Alert-Info headers contain only alert URNs, and leave the behavior 
undefined when there is a mix.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Thu, 21 Oct 2010 11:39:48 +0200

Paul,

thank you for reading the draft and for your comments. I agree with
your comments. It is important that the rules are clear. Please find
enclosed the text proposal for Section 7. Is this OK from your point
of view?

-----begin of text----

  7.  Combinations of URNs

This chapter only describes combination rules for the case when all
the Alert-Info headers only contain alert URNs. Combinations of URNs
and URIs in the Alert-Info headers of the same SIP-message are not
defined in this specification.

In many cases, more than one URNs will be needed to fully define a
particular tone. This is done by including multiple 'alert' URNs, in
one or more Alert-Info headers in a request or a response.  For
example, an internal, priority call could be indicated by Alert-Info:
<urn:alert:source:internal>,    <urn:alert:priority:high>.  A priority
call waiting tone could be indicated by Alert-Info:
<urn:alert:service:call-waiting>, <urn:alert:priority:high>.

The categories are orthogonal.  Any Alert-Info URN defined in this
specification is syntactically valid for ring and for ringback and can
be used in an INVITE or in provisional 1xx responses excepting the 100
response.  There MUST be at most one instance of each alert-category
in the Alert-Info header(s) of a request or response. 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 header(s) content and of the kind of the received message
(INVITE or provisional response).  Typically, the same UA will do the
rendering of one or more particular Alert-Info header(s) content
received in an INVITE differently from the rendering of the same
Alert-Info header(s) content received in a provisional 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 parts of the received Alert-Info URNs.

----end of text----

Thanks a lot,
Laura

2010/10/20 Paul Kyzivat <[email-masked]>:
> Hi Laura,
>
> This is looking fairly clean. I have a few points on section 7. They aren't
> substantive - just phrasing/terminology
>
> supplying multiple alert-params containing 'alert' URNs. One way of doing
> this is by separating them by a comma in one Alert-Info header. Another is
> to provide them in separate Alert-Info headers.
>
> For one thing, its not normative but should be. For another, there could be
> multiple Alert-Info headers. I suggest:
>
> "There MUST be at most one instance of each alert-category in the Alert-Info
> header(s) of a request or response."
>
> URN, as if there was only one. I don't have specific wording to propose, but
> I think the intent here is to talk about the collective rendering based on
> all the URIs in all the Alert-Info headers in the request/response. Also
> missing here is any mention of how the use of the alert URN in Alert-Info
> interacts with other sorts of URIs also present in Alert-Info.
>
> Alert-Info headers contain only alert URNs, and leave the behavior undefined
> when there is a mix.
>
>        Thanks,
>        Paul
>
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Oct 2010 09:15:10 -0400

Laura,

Those changes work for me.

	Thanks,
	Paul

On 10/21/2010 5:39 AM, Laura Liess wrote:
> <urn:alert:source:internal>,<urn:alert:priority:high>.  A priority
> <urn:alert:service:call-waiting>,<urn:alert:priority:high>.
>
> 2010/10/20 Paul Kyzivat<[email-masked]>:
>> Hi Laura,
>>