Subject: RE: [MEDIACTRL] Packages

From: "Chris Boulton" <[email-masked]>
Date: Wed, 18 Apr 2007 11:16:22 +0100

Someone might add a feature and publicize it, and someone else could 
find it useful.

[Chris Boulton] [With my IETF hat on] you have standards track
extensions to the control framework - for interoperability amongst
vendors this MUST be a registered token in the registry and you must
abide by its rules.  If you want to change a package(or just add to it)
- you need to register a new token.

[Without my IETF hat on] we COULD include text in the Control Framework
that allows 'vendor' specific tokens to be used.  This would allow folks
to do what ever they want BUT don't come crying to us if you don't work
with a new box.  Would this be sufficient?  For example - I negotiate in
the Control-Packages header: msc-ivr-basic/1.0,
msc-ivr-basic/1.0-with_cool_new_widget.  The second token is not
standards track and so when I insert a new MS into my network - he
rejects this request the AS knows why (cos in the current spec it lists
packages supported in an error response).  BUT as you say, if I happen
to send it to an MS that knows about the cool new widget - we are all
happy.  

 A configure-like approach could let AS check if they can 
exploit this feature by explicitely checking for its presence in the 
package, otherwise limiting itself to access the standardized methods. 
It would actually add complexity to negotiations, but it would only be 
done at 'boot', i.e. when the AS contacts the MS to establish the 
connection.

[Chris Boulton] I have concerns if this is not done in a central place.
Who governs the space?  Who publicizes it?  Doesn't my previous
suggestion cover this? 

Chris.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 18 Apr 2007 13:01:19 +0200

Hi Chris,

> - you need to register a new token.

Of course, I agree with you on that. My suggestion was a less "strict" 
approach to allow quicker (and optional) updates someone might need on 
existing packages.

> to send it to an MS that knows about the cool new widget - we are all

Yes, the idea I had in mind would actually work only if both the AS and 
the MS *did* understand that 'msc-ivr-basic/1.0-with_cool_new_widget' 
and 'msc-ivr-basic/1.0' are exactly the same package for what concerns 
standard features. The additional negotiation after the COMEDIA setup I 
thought of would then take care of the rest. So, in your example, the 
new MS should accept the COMEDIA negotiation, and reject the 
non-standard features the AS may check for availability later, so that 
the AS would know not to use them.

> Who governs the space?  Who publicizes it?  Doesn't my previous

Of course these are only rough ideas, suggestions that are all but 
perfect, so the issues you correctly raised should be investigated 
considering the various scenarios we have to handle.

Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

---

From: "Tim Melanchuk" <[email-masked]>
Date: Wed, 18 Apr 2007 07:55:32 -0700

good discussion ;-) i think we have to get a little further along
before exploring whether/how to support non-standard extensions
but we're making progress understanding different interests.

--timm