Subject: [salud] Minutes Ad Hoc Meeting SALUD (Sip ALerting for User Devices WG) 29.07.2010 Lunch break (11:55-12:50)

From: <[email-masked]>
Date: Thu, 29 Jul 2010 16:49:04 +0200

Dear all,
Please find attached the minutes of the meeting.

Best Regards

Roland

@Dale Thank you for your editorial help :-)

--- Start of Minutes ----

Ad Hoc Meeting SALUD (Sip ALerting for User Devices WG) 29.07.2010 Lunch break (11:55-12:50)

Notes taken by Roland Jesske

Presentation: http://www.ietf.org/proceedings/78/slides/salud-0.ppt

Scope of meeting was discussed:
- 180 versus 18x issue -- what to do.
- Major issue: Single versus multiple URN in one message
- Semantic versus non-semantic (or rendering characteristics)
 
Slide #1
Semantics where changed to be general. "audio" was changed to "rendering"

Dale: if we do extensibility in a general way that makes this problems very easy. Both mean the same.

Paul: general nomenclature is great. The benefit of one URN is that you get a more trustworthy thing. Compared when more then more URN. Distinction between list and set. Ordering could be significant.

Dale: Different categories, they can be completely changed.

Gonzalo: It looks like people want both.

John: Also in PSTN cases a rendering approach is required.

Slide #2
Problem: 180 vs 18x Responses, Alert URN is currently only allowed in 180.
There are some in favour to do it also in 18x.
The proposal was that include it in all provisional responses (except 100).

Gonzalo: Additionally the draft should describe that alert URN is not only for alerting but also for other purposes.  This was agreed.

Slide #3
Laura: Should the requirements combined with the use cases or should this be captured in an extra section?

Dale: Requirements should not look like used cases

Laura: Ask the mailing list.

Agreed.

Slide #4 (Adam's Use Cases)
Laura: Question if Adam's use cases should be added.

Gonzalo: Questioned if this is only relevent to ISUP mapping.

Laura: There could be entities in the SIP domain which could use this too.

John: We need additional discussion on some values e.g what does "Ping Ring" mean.

Dale: (A.S0014 column) Mentioned that top three are semantic and the other three are rendering

John: TIA/EIA values are look like as rendering values except No. 7 "PBX long (normal)". He questioned also what does this mean for the user.

Paul: If Adam's proposed values are seen as semantic, than it should be provided of course as semantic and other values could be rendered.

Slide #5: ABNF Syntax change by Dale proposed

It was agreed to change it to the proposed ABNF.

Slide #6
Single vs. multiple URN

Paul: First time he heard the idea of multiple URNs in an INVITE he was not in favour for that, but now no longer. The question is what we want to do with multiple URNs. How don't they conflict. Important is that it is documented that any conflicts are excluded. Like play multiple URN in sequence or parallel.

Dale: There may be some interoperability issues with services. When do you have multiple URNs?

Paul: What will 3GPP do when the IMS is doing if they receive more than one URN.

It was assumed that the not understandable URN's will be ignored.

Dale: Want to discuss this issue.

John: Thinks that the multiple URN approach is the more attractive.

Paul: Sees this as the possibility that others (SDO) will use the more flexible approach, and add their possible values too.

Laura: Mentioned that Adam was pointing to the fact that the registration of single URN will end up in many more combinations of values that has to be registered by IANA.

Dale:  We would be register a grammar where it allows to define a URN.

Slide #7
Dale: There are three extension mechanisms possible.

Dale: (No. 1) Allow further dimensions created.

Paul: There would be further dimensions that will be allowed by Standards track.

Dale: (No. 2) Allow sub-trees is also possible

Dale: (No. 3) And allow existing items which are subdivided.
 
Paul: Which names are reserved and which are extensible by third parties?

Paul: The three proposed possibilities mentioned by Dale must be discussed.-

Dale: Repeated the three possibilities:
1. Dimensions = Category
2. New item to category
3. Take an existing item and subdivide.

Do extensions have to go in a specific sub tree like private?

Paul: We could put a rule for registry into the document and let register the values.

Dale: Said that the rules defined could be defined so that a new value shall not conflict the already existing values.

Dale: Vendors could have very specific values. So an extension mechanism is needed is such a case.

John: The danger is that registered values could overlap. They have an other name but the same semantic. And how does a implementation choose which to use?

Dale: The renderer should understand the main categories.

Paul: Either we allow to use the private. <private-name> as a real private where vendors could add what they want or register like first-come/first-serve.

Slide #7 It was agreed that Paul's proposal is a good starting point.

Conclusion on #7: The three additional extension mechanisms has to be discussed further.
 
Slide #8/#9 where not discussed

--- End of Meeting ---

--------------------------------------------------------------------------------------------------------------------------
[END]

Mit freundlichen Grüßen
Roland Jesske

Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628-2766 (Tel.)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobil)
E-Mail: [email-masked]
www.telekom.com  

Erleben, was verbindet. 

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

---

From: <[email-masked]>
Date: Fri, 30 Jul 2010 09:56:15 +0200

Dear all,
Meanwhile I have received some comments, which I incorporated into the minutes.

The changes/additions to the previous version are marked.

Thank You and Best Regards

Roland

> _____________________________________________ 
> Von: 	Jesske, Roland  
> Gesendet:	Donnerstag, 29. Juli 2010 16:49
> An:	[email-masked]
> Betreff:	Minutes Ad Hoc Meeting SALUD (Sip ALerting for User Devices WG) 29.07.2010 Lunch break (11:55-12:50)
> 
> Dear all,
> Semantics where changed to be general. > "> audio> ">  was changed to > "> rendering> "> 
> 
> Paul [change start]: general nomenclature is great. Certainly having all in one URN makes it more straightforward to define meaning. And it provides a seemingly stronger ordering relationship among the contained category values than multiple URNs do. OTOH, listing multiple URNs in an A-I header also gives an ordering relationship if we choose to use it. (So far we have not, but Dale has offered a matching algorithm that can take advantage of it. It is certainly worth considering.) [change end]
> 
> 
> 
> John [change start]: Initially I thought we just needed semantic values, but people managed to convince me that, at least for PSTN interworking, there is also a need for rendering-based values. [change end]
> 
> Slide #2
[addition start] Gonzalo also agreed that while this is a change to 3261, it is 
sufficiently minor that it is ok for this WG to make such a change. [addition end]

> John: We need additional discussion on some values e.g what does > "> Ping Ring> ">  mean.
> 
> John: TIA/EIA values are look like as rendering values except No. 7 > "> PBX long (normal)> "> . He questioned also what does this mean for the user.
> 
> Paul: First time he heard the idea of multiple URNs in an INVITE he was not in favour for that, but now no longer. The question is what we want to do with multiple URNs. How don> '> t they conflict. Important is that it is documented that any conflicts are excluded. Like play multiple URN in sequence or parallel.> 
> 
> It was assumed that the not understandable URN> '> s will be ignored.
> 
> Große Veränderungen fangen klein an > ->  Ressourcen schonen und nicht jede E-Mail drucken.
> 
>