Subject: [dispatch] Alert-Info URN charter issue

From: <[email-masked]>
Date: Thu, 17 Dec 2009 16:43:11 +0100

Hi,

During the Alert-Info URN discussion in Hiroshima we had consensus that there is interest in chartering a mini-WG on Alert-Info URNs.  However, we didn't come to an agreement about whether or not we need to decide before chartering if the Alert-Info URNs must be semantic.  We need to clarify this issue before submitting the charter proposal for Anaheim. 
 
Some thoughts on this: 
 - The decision wether or not we allow non-semantic Alert-Info URNs is tightly coupled with which problems/use cases we want to solve. The problem to be solved /use cases  must, as far as I know, be decided before chartering.   

 - The Alert-Info URNs for use cases as call waiting and other services, country ringback, priority ringing, are semantic anyway. So these use cases are definitively in the charter. 

 - The critical use cases, for which we need non-semantic, rendering-oriented Alert-Info URNs, are ringing tones used in PBX-systems (e.g. "short", as described in §4.3.8 of the draft) and in local exchanges in some countries (e.g. the TIA ring tones described by Adam in http://www.ietf.org/mail-archive/web/bliss/current/msg01020.html, which is not in the draft). In these use cases, the Alert-Info URNs are not transmitted end-to-end, as, e.g. in case of country ringback tones, but are sent by the PBX-system or local exchange to an end device within its own domain. In most cases, we can expect that the end device was configured by the user or service provider how to handle the rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA.

 - Rendering-oriented ring tones as described above are use cases which we encounter today and people will be implement them in some way. If we do not provide a standard which can be used for the implementation, people will provide proprietary, non-interoperable solutions. For this reason, I wouldn't like that the Alert-Info URN scheme we are going to define can not be used to implement these use cases. This does not imply that we should also define Alert-Info URN identifiers for all these cases, but we should at least define the scheme which can be used by other people to define the specific identifiers.  

Based on the thoughts above, I would propose to handle the issue as follows:

 1) Include into the charter, as one of the problems to be solved:  "special ring tones for incoming calls (used in enterprise networks and in some countries) when the proxy and the UAs are from different vendors with no external ring file being used"  
 
 2) In the draft, define a requirement which states something like that:
      - Alert-Info URNs must be semantic whenever they are used across different domains or if the sender has no reason to assume that the receiver has the same understanding of non-semantic Alert-Info URNs. 
      - Non-semantic, rendering-oriented Alert-Info URNs may be used inside closed environements, when there are predefined rules which define the semantic of a specific rendering and the sender can expect that the receiver is able to understand the rendering-oriented Alert-Info URNs. If an UA receives an Alert-Info URN it does not understand, it ignores the Alert-Info URN. 

Is this an acceptable proposal or does anyone have a better idea how to handle this issue? 

Thanks a lot
Laura

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Dec 2009 17:13:11 +0100

Laura,

I suspect the wording you propose below goes somewhat beyond what would be appropriate for charter text. However, you are correct in that the charter needs to say something about semantic versus non-semantic tones.

In Hiroshima I heard a justification for non-semantic tones that is not captured below: cases where a TDM gateway detects a certain tone pattern and can only convey in SIP some characteristic of that pattern (e.g., "short"), rather than a specific meaning. This sounds like a more compelling use case for non-semantic tones than what is described below.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 17 December 2009 15:43
> To: [email-masked]; Elwell, John; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Alert-Info URN charter issue
> 
> 
> Hi,
> 
> During the Alert-Info URN discussion in Hiroshima we had 
> consensus that there is interest in chartering a mini-WG on 
> Alert-Info URNs.  However, we didn't come to an agreement 
> about whether or not we need to decide before chartering if 
> the Alert-Info URNs must be semantic.  We need to clarify 
> this issue before submitting the charter proposal for Anaheim. 
>  
> Some thoughts on this: 
>  - The decision wether or not we allow non-semantic 
> Alert-Info URNs is tightly coupled with which problems/use 
> cases we want to solve. The problem to be solved /use cases  
> must, as far as I know, be decided before chartering.   
> 
>  - The Alert-Info URNs for use cases as call waiting and 
> other services, country ringback, priority ringing, are 
> semantic anyway. So these use cases are definitively in the charter. 
> 
>  - The critical use cases, for which we need non-semantic, 
> rendering-oriented Alert-Info URNs, are ringing tones used in 
> PBX-systems (e.g. "short", as described in §4.3.8 of the 
> draft) and in local exchanges in some countries (e.g. the TIA 
> ring tones described by Adam in 
> http://www.ietf.org/mail-archive/web/bliss/current/msg01020.ht
> ml, which is not in the draft). In these use cases, the 
> Alert-Info URNs are not transmitted end-to-end, as, e.g. in 
> case of country ringback tones, but are sent by the 
> PBX-system or local exchange to an end device within its own 
> domain. In most cases, we can expect that the end device was 
> configured by the user or service provider how to handle the 
> rendering-oriented Alert-Info URNs sent by its own proxy/B2BUA.
> 
>  - Rendering-oriented ring tones as described above are use 
> cases which we encounter today and people will be implement 
> them in some way. If we do not provide a standard which can 
> be used for the implementation, people will provide 
> proprietary, non-interoperable solutions. For this reason, I 
> wouldn't like that the Alert-Info URN scheme we are going to 
> define can not be used to implement these use cases. This 
> does not imply that we should also define Alert-Info URN 
> identifiers for all these cases, but we should at least 
> define the scheme which can be used by other people to define 
> the specific identifiers.  
> 
> 
>  1) Include into the charter, as one of the problems to be 
> solved:  "special ring tones for incoming calls (used in 
> enterprise networks and in some countries) when the proxy and 
> the UAs are from different vendors with no external ring file 
> being used"  
>  
>       - Alert-Info URNs must be semantic whenever they are 
> used across different domains or if the sender has no reason 
> to assume that the receiver has the same understanding of 
> non-semantic Alert-Info URNs. 
>       - Non-semantic, rendering-oriented Alert-Info URNs may 
> be used inside closed environements, when there are 
> predefined rules which define the semantic of a specific 
> rendering and the sender can expect that the receiver is able 
> to understand the rendering-oriented Alert-Info URNs. If an 
> UA receives an Alert-Info URN it does not understand, it 
> ignores the Alert-Info URN. 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Dec 2009 10:33:32 -0600

>
> I would propose to handle the issue as follows:
>

I like this approach. Depending on how we end up defining combinations 
of various aspects of ring/ringback tones, the final sentance may end up 
reading something like "...it ignores the portions of the Alert-Info URN 
that it does not understand," but I don't think that's a fundamental 
change to your proposal.

I'd also point out, on point 1, that the closed environments in which 
rendering-oriented ringtones may apply extends beyond enterprises and 
specific countries. It can also apply, for example, when mapping from 
any legacy protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the 
edge of a network.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 17 Dec 2009 12:09:43 -0600

When I was looking at Laura's note, I was worried that the inclusion of 
non-semantic Alert-Info URNs would make semantic Alert-Info URNs less 
attractive - I like semantic Alert-Info URNs, and wasn't happy about 
anything that might lessen the deployment and use of semantic Alert-Info 
URNs.

Looking at John's followup, and at Adam's note below, I'm convinced that 
there is a role for standardized non-semantic Alert-Info URNs, and agree 
that including this in the charter would be useful, if people think that's a 
decision that can happen pre-charter. Of course, I'm the poster child for 
"but the working group needs to decide that", and if the working group needs 
to decide that, I'd be good.

Thanks,

Spencer

----- Original Message ----- 
From: "Adam Roach" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Thursday, December 17, 2009 10:33 AM
Subject: Re: [dispatch] Alert-Info URN charter issue

>>   1) Include into the charter, as one of the problems to be solved: 
>> "special ring tones for incoming calls (used in enterprise networks and 
>> in some countries) when the proxy and the UAs are from different vendors 
>> with no external ring file being used"
>>
>>        - Alert-Info URNs must be semantic whenever they are used across 
>> different domains or if the sender has no reason to assume that the 
>> receiver has the same understanding of non-semantic Alert-Info URNs.
>>        - Non-semantic, rendering-oriented Alert-Info URNs may be used 
>> inside closed environements, when there are predefined rules which define 
>> the semantic of a specific rendering and the sender can expect that the 
>> receiver is able to understand the rendering-oriented Alert-Info URNs. If 
>> an UA receives an Alert-Info URN it does not understand, it ignores the 
>> Alert-Info URN.
>>
>>
> I like this approach. Depending on how we end up defining combinations of 
> various aspects of ring/ringback tones, the final sentance may end up 
> specific countries. It can also apply, for example, when mapping from any 
> legacy protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the edge of 
> a network.

---

From: <[email-masked]>
Date: Fri, 18 Dec 2009 16:26:43 +0100

Hi John and Adam, 

Thank you very much for your quick comments and proposals. My understanding is that modifications should be done to the charter proposal: 
	- short sentence in the charter about "semantic vs. non-semantic" 
	- add the use case "TDM gateway mapping from any legacy protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the edge of a network"

By adding the TDM gateway use case (which I think is a very good use case), my original assumptions that non-semantic Alert-Info URNs are:
- only sent by the proxy to end devices of its customers/end users and
- never sent end-to-end 
are no longer valid. I have to remove the restriction for non-semantic Alert-Info URN identifiers derived from these assumptions.  

Let's do a second trial for charter text changes:
 1) Add to the use cases:   
   " - special ringing tones, e. g. tones used in enterprise networks, tones used in some countries or tones from legacy protocols which TDM gateways must map to SIP at the edge of a network"    
2) Add folowing sentence: 
  " For better interoperability and flexibility, the Alert-Info URNs identifiers should be semantic whenever possible."  

I am not absolutely happy with the formulation "whenever possible" because it is somehow imprecise, but I don't currently see any precise criteria to  allow or disallow non-semantic URNs. Any better idea or can we leave it this way, at least for the charter?

Note: I did not ignore the comments about how the receiver handles unknown Alert-Info URN identifiers/portions, but I think this is part of the specification (requirements or UA behaviour), not of the charter, and I would postpone this discussion for now. 

Thanks a lot
Laura

> 
> I suspect the wording you propose below goes somewhat beyond 
> what would be appropriate for charter text. However, you are 
> correct in that the charter needs to say something about 
> semantic versus non-semantic tones. 
> 
> In Hiroshima I heard a justification for non-semantic tones 
> that is not captured below: cases where a TDM gateway detects 
> a certain tone pattern and can only convey in SIP some 
> characteristic of that pattern (e.g., "short"), rather than a 
> specific meaning. This sounds like a more compelling use case 
> for non-semantic tones than what is described below.
> 
> John
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Dec 2009 17:07:42 -0500

Perhaps this is more theoretical than real, but I have been imagining 
another broad use of "non-semantic" URNs:

URNs that identify specific media "by name". For instance, is there a 
standard identifier for music, as there is an ISBN for books? I'm 
thinking of a name for a particular "work" independent of its specific 
rendering, such as "Beethoven's Fifth". You wouldn't want that entire 
thing as a ring tone, but maybe the first 4/8 note intro. You might want 
something longer for a ringback.

This sort of alert could be used e2e, though there is no guarantee that 
the other end will understand it. Given a URN you don't understand, you 
could search out some definitions of it (possibly different renderings) 
and pick one you like.

This sort of usage seems to be on the borderline of "semantic".

	Thanks,
	Paul

This usage brid

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Dec 2009 17:27:33 -0500

Not sure it's used for music, but see DOIs:
http://www.doi.org/

(Almost) every scientific paper has one these days, although they probably don't make good ring tones.

On Dec 18, 2009, at 5:07 PM, Paul Kyzivat wrote:

> Perhaps this is more theoretical than real, but I have been imagining another broad use of "non-semantic" URNs:
> 
> URNs that identify specific media "by name". For instance, is there a standard identifier for music, as there is an ISBN for books? I'm thinking of a name for a particular "work" independent of its specific rendering, such as "Beethoven's Fifth". You wouldn't want that entire thing as a ring tone, but maybe the first 4/8 note intro. You might want something longer for a ringback.
> 
> This sort of alert could be used e2e, though there is no guarantee that the other end will understand it. Given a URN you don't understand, you could search out some definitions of it (possibly different renderings) and pick one you like.
>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 18 Dec 2009 19:32:13 -0500

On Dec 18, 2009, at 5:27 PM, Henning Schulzrinne wrote:

>> Perhaps this is more theoretical than real, but I have been  
>> imagining another broad use of "non-semantic" URNs:
>>
>> URNs that identify specific media "by name". For instance, is there  
>> a standard identifier for music, as there is an ISBN for books? I'm  
>> thinking of a name for a particular "work" independent of its  
>> specific rendering, such as "Beethoven's Fifth". You wouldn't want  
>> that entire thing as a ring tone, but maybe the first 4/8 note  
>> intro. You might want something longer for a ringback.

No. This is a big issue in music license payments online, with, e.g.,  
SoundExchange (the US payment agent for online music royalties)  
holding onto hundreds of millions of dollars for royalties paid on  
music whose that can't be located - see, e.g.,

http://www.p2pnet.net/story/18864

The industry is rampant with complaints that royalty payments are not  
passed along (not just be SoundExchange) and the cynics in the music  
industry (who are not hard to find) think that the lack of a URN for  
music (either performances or compositions) is a feature, not a bug,  
of the payment system.

There are a number of companies that offer digital "fingerprints" to  
recognize a given performance or composition, generally in connection  
with DRM or fighting against file sharing - see, e.g.,

http://www.drmwatch.com/drmtech/article.php/3363151

but these are proprietary and not really intended as a public index.

Regards
Marshall

>>
>> This sort of alert could be used e2e, though there is no guarantee  
>> that the other end will understand it. Given a URN you don't  
>> understand, you could search out some definitions of it (possibly  
>> different renderings) and pick one you like.
>>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Dean Willis <[email-masked]>
Date: Sun, 20 Dec 2009 22:00:34 -0600

Marshall Eubanks wrote:

> music (either performances or compositions) is a feature, not a bug,  of 
> the payment system.

Oh cool! Another industry to disrupt! Santa Clause did bring me a 
present after all.

--
Dean

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 21 Dec 2009 12:59:02 +0100

Hi Laura,

I think your proposal for the charter are ok and I think what we hopefully will end up with is only specifying the use of non-semantic identifiers in certain interworking scenarios and using the preferred semantic identifiers in all other cases.

Regards
Andy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 18 December 2009 15:27
To: Elwell, John; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Alert-Info URN charter issue

Hi John and Adam, 

Thanks a lot
Laura

---

From: <[email-masked]>
Date: Mon, 21 Dec 2009 14:05:31 +0100

Paul,

The idea sounds very interesting to me. I think the syntax and the rules for the Alert-Info URN should be flexible enough so that Alert-Info URN can be used later for use-cases as you described. 

I could add your description to the text of the draft, as an example of possible future use cases, but because I don't know of any real use case and the concrete requirements for it, I would not try to define now a concrete Alert-Info URN identifier. Maybe later, when somebody thinks about a real implementation in this direction.   

Is this OK for you? 

Thanks a lot
Laura

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, December 18, 2009 11:08 PM
> To: Liess, Laura
> Cc: [email-masked]; Jesske, Roland; Hülsemann, Martin
> specific 
> > Thank you very much for your quick comments and proposals. 
> My understanding is that modifications should be done to the 
> charter proposal: 
> > 	- add the use case "TDM gateway mapping from any legacy 
> protocol (e.g. 3GPP2 IOS, GR-303, V5.2, etc) to SIP at the 
> edge of a network"
> > 
> > By adding the TDM gateway use case (which I think is a very 
> good use case), my original assumptions that non-semantic 
> Alert-Info URNs are:
> > are no longer valid. I have to remove the restriction for 
> non-semantic Alert-Info URN identifiers derived from these 
> assumptions.  
> > 
> >    " - special ringing tones, e. g. tones used in 
> enterprise networks, tones used in some countries or tones 
> from legacy protocols which TDM gateways must map to SIP at 
> the edge of a network"    
> >   " For better interoperability and flexibility, the 
> Alert-Info URNs identifiers should be semantic whenever possible."  
> > 
> > I am not absolutely happy with the formulation "whenever 
> possible" because it is somehow imprecise, but I don't 
> currently see any precise criteria to  allow or disallow 
> non-semantic URNs. Any better idea or can we leave it this 
> way, at least for the charter?
> > 
> > Note: I did not ignore the comments about how the receiver 
> handles unknown Alert-Info URN identifiers/portions, but I 
> think this is part of the specification (requirements or UA 
> behaviour), not of the charter, and I would postpone this 
> discussion for now. 
> > 
> > 
> > Thanks a lot
> > Laura
> > 
> > 
> >          
> > 
> >

---

From: <[email-masked]>
Date: Mon, 21 Dec 2009 14:16:09 +0100

Andrew, 

I think so too. We should use non-semantic identifiers only when there no other posibility, but we should not exclude them conmpletely. 

Thanks a lot
Laura

> From: Hutton, Andrew [mailto:[email-masked]] 
> Sent: Monday, December 21, 2009 12:59 PM
> To: Liess, Laura
> Cc: [email-masked]
> Subject: RE: Alert-Info URN charter issue
> 
> Hi Laura,
> 
> I think your proposal for the charter are ok and I think what 
> we hopefully will end up with is only specifying the use of 
> non-semantic identifiers in certain interworking scenarios 
> and using the preferred semantic identifiers in all other cases.
> 
> Regards
> Andy 
> 
>  
> 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Thank you very much for your quick comments and proposals. My 
> understanding is that modifications should be done to the 
> charter proposal: 
>    " - special ringing tones, e. g. tones used in enterprise 
> networks, tones used in some countries or tones from legacy 
> protocols which TDM gateways must map to SIP at the edge of a 
> network"

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Dec 2009 14:09:22 -0500

Its just an idea of mine with no concrete needs. So whatever you want to 
do is fine with me. I certainly don't see any reason to delay needed 
work for it.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Tue, 22 Dec 2009 13:41:04 +0100

Paul,

It's a very nice idea and it shouldn't get lost.  I will find a place for it in the draft, overview or so. Maybe later someone will implement a nice service with it. 

Thanks a lot
Laura

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, December 21, 2009 8:09 PM
> To: Liess, Laura
> > The idea sounds very interesting to me. I think the syntax 
> and the rules for the Alert-Info URN should be flexible 
> enough so that Alert-Info URN can be used later for use-cases 
> as you described. 
> > 
> > I could add your description to the text of the draft, as 
> an example of possible future use cases, but because I don't 
> know of any real use case and the concrete requirements for 
> it, I would not try to define now a concrete Alert-Info URN 
> identifier. Maybe later, when somebody thinks about a real 
> implementation in this direction.   
> > 
> > Is this OK for you? 
> > 
> > 
> > Thanks a lot
> > Laura
> > 
> >  
> >

---

From: <[email-masked]>
Date: Thu, 24 Dec 2009 13:50:25 +0100

Hi, 

It seems to me that we reached a consensus on the "semantic vs. non-semantic" issue, at least at the WG-charter level. Please find attached the updated charter proposal:  

		The SIP Alert-Info URN (SAIU) working group is chartered to define a new URN-scheme which allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN solves interoperability problems which we encounter today around the use of the Alert-Info header field. 

		RFC 3261 allows a UAS or proxy to provide a specific ring-/ringback-tone as a reference (e.g. HTTP URI) which can be played to the user in the Alert-Info header. 
		This mechanism does not ensure interoperability when there is no common understanding of the referenced content (different countries, different vendors for the proxy and UAs, hearing impaired) or when the user has his own tones configured in the end device. This is the case, e.g. for:

*	ring-/ringback-tones which indicate services as call waiting, call forwarding, blind transfer, automatic callback, call hold 
*	ring tones for emergency announcements sent over PBX systems or over the local telephone network 
*	country-specific ringback tones
*	special ringing tones, e. g. ringing tones used in closed in enterprise networks, ringing tones used in some countries or when TDM gateways must map ring-/ringback-tones from legacy protocols to SIP at the edge of a network

		There are a variety of URI conventions and proprietary Alert-Info header field parameters to provide this today, all of which are non-interoperable.  
		A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions.
		The group will produce a specification which:
*	describes the problem statement
*	describes the requirements and the use cases we know about today
*	defines an Alert-Info URN-scheme which allows to solve the interoperability problems described in the use cases
*	defines the specific Alert-Info URNs identifiers for some of the use cases above

		The Alert-Info URN scheme must be open, so that additional Alert-Info URN identifiers can be defined later if necessary.  Whenever possible, the Alert-Info URNs identifiers should be semantic.  

		Goals and Milestones
		====================
		Apr 2011 - Alert-Info URN specification to IESG (PS)

Please let me know what you think about it, if we can go ahead with it for Anaheim, if you see open issues or if changes are needed. 

Kind regards
Laura