Subject: [BLISS] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt

From: <[email-masked]>
Date: Mon, 19 Oct 2009 14:38:54 +0200

Hi,

We've re-submitted the Alert-Info URNs draft for DISPATCH
http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns
-00.txt . (The previous version od the draft was in BLISS and we had a
presentation in BLISS at the last IETF.)

We did some major changes, as suggested on the mailing list, e.g.:
 Added:  
  - Description of the interoperability problems for PBX-services (in
the Introduction chapter) 
  - Requirements for the Alert-Info URNs mechanism 
  - Alert-Info URNs Indications for country-specific tones
 Changed: 
  - Initial IANA Registration mechanism to avoid combinatorial explosion
of IANA values. 

Many thanks for the comments and suggestions,
Laura 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, October 19, 2009 1:00 PM
To: [email-masked]
Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Alert-Info URNs for the Session Initiation
Protocol (SIP)
	Author(s)       : D. Alexeitsev, et al.
	Filename        : draft-liess-dispatch-alert-info-urns-00.txt
	Pages           : 25
	Date            : 2009-10-19

The Session Initiation Protocol (SIP) supports the capability to
provide a reference to the alternative ringback tone (RBT) for
caller, or ring tone (RT) for callee using the Alert-Info header.
However, the reference addresses only the network resources with
specific rendering properties.  There is currently no support for
predefined standard identifiers for ringback tones or semantic
indications without tied rendering.  To overcome this limitations and
support new applications a family of the URNs is defined in this
specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns
-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2009 16:44:03 -0400

This seems to be shaping up well. I think the requirements are quite 
clear now.

I don't fully understand what is intended regarding combination of 
multiple alert URNs for a specific situation. Section 4.5 states:

>    finally, a short Albanian auto-callback tone could be indicated
>    Alert-Info: <urn:alert:service:auto-callback>,
>    <urn:alert:tone:short>, <urn:alert:tone:al>.

while section 7.3.6 states:

>    Alert URN Indications from the same group should not be combined.

I could find no definition of what constitutes a "group". The first 
thing that comes to mind is "service" vs. "tone", but the above example 
violates that. It seems to me that you need some notion of orthogonal 
properties in order to define what can/cannot be combined.

It would be good to have more detail about how a recipient should deal 
with multiple URNs.

I'm also uncertain of what your intent is regarding top-level vs. 
additional indications. As specified, I believe a given "additional 
indication" name is always defined with regard to its parent, so that 
"short" as used in "normal.short" might mean something entirely 
different than "priority.short", or might not be defined for priority at 
all.

Yet from the registration text in 7.3.2 it sounds like the intent is for 
priority, short, and delayed to be defined for all pbx-tones. If that is 
the intent, then I don't think the existing text meets that intent.

I also wonder if the existing hierarchy will work well in practice, or 
if some other organization might not work better. For instance, it might 
be more convenient to specify ringing.fr with the clear understanding 
that if you don't know about ringing.fr you can just treat it as ringing.

I'm also confused by PBX tones vs. Public telephone tones. In what way 
is "normal" different from "ringing"? I would think that PBX tones would 
be a superset of common pstn tones.

A nit: in 4.3.2 I would expext the forward to be indicated, if at all, 
with a 181 rather than a 180.

	Thanks,
	Paul

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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 29 Oct 2009 08:53:34 -0500

Paul,

One comment below.

Thanks,
Alan

Paul Kyzivat wrote:
> thing that comes to mind is "service" vs. "tone", but the above 
> example violates that. It seems to me that you need some notion of 
> orthogonal properties in order to define what can/cannot be combined.
>
> different than "priority.short", or might not be defined for priority 
> at all.
>
> Yet from the registration text in 7.3.2 it sounds like the intent is 
> for priority, short, and delayed to be defined for all pbx-tones. If 
> that is the intent, then I don't think the existing text meets that 
> intent.

As it has been pointed out, short, long, and delayed are not compatible 
with the semantic approach of this draft so I think we should remove 
them as they are currently.  I need to investigate to see whether they 
have been used in the past as stand-ins for a particular service, or 
whether we need to define specific tones for them.

Priority, I still think, is useful - we just need to figure out how to 
fit it in properly.

> if some other organization might not work better. For instance, it 
> might be more convenient to specify ringing.fr with the clear 
> understanding that if you don't know about ringing.fr you can just 
> treat it as ringing.
>
> is "normal" different from "ringing"? I would think that PBX tones 
> would be a superset of common pstn tones.
>
>>  Added:    - Description of the interoperability problems for 
>> PBX-services (in
>> the Introduction chapter)   - Requirements for the Alert-Info URNs 
>> mechanism   - Alert-Info URNs Indications for country-specific tones
>>  Changed:   - Initial IANA Registration mechanism to avoid 
>> combinatorial explosion
>> of IANA values.
>>