Subject: RE: [MEDIACTRL] Packages

From: "Chris Boulton" <[email-masked]>
Date: Tue, 10 Apr 2007 10:07:20 +0100

<chair-hat off>
The whole package concept is pretty big.  Are we going to have, for
example,
versioning?

[Chris Boulton] There is already a simplistic versioning mechanism in
the package drafts that is linked to the Control Package name that is
registered.  E.g. 'msc-ivr-basic/1.0'.

  What happens if a requested version doesn't match?

[Chris Boulton] At the moment you negotiate which packages you support
based on the tokens (see the core framework).  If some don't match - we
have a SIP response that contains the one supported.

  What if the
requested version is "less than" the supported version? 

[Chris Boulton] Not covered at the moment - you either support or not
based on the token registered which include the version).  If we need to
support a more sophisticated mechanism then it would be great to discuss
the alternatives etc etc.

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: "Eric Burger" <[email-masked]>
Date: Fri, 13 Apr 2007 10:44:41 -0700

Would it be fair to say that packages do not version, and if you want to
"upgrade" a package, you create a new package?

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 5:07 AM
To: Eric Burger; [email-masked]
Subject: RE: [MEDIACTRL] Packages

<chair-hat off>
example, versioning?

  What if the

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.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: "Adnan Saleem" <[email-masked]>
Date: Fri, 13 Apr 2007 11:22:27 -0700

I think it is very useful to have versioning for packages.
The versioning scheme should be fairly high level though,
ie not every tweak or schema change should result in a
version update.

I'm inclined to agree with Chris's proposal below and
as documented in the control-framework draft 
(eg. 'msc-ivr-basic/1.0') with a major and minor number.

Adnan

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: Tuesday, April 10, 2007 5:07 AM
To: Eric Burger; [email-masked]
Subject: RE: [MEDIACTRL] Packages

<chair-hat off>

  What if the

Chris.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.

---

From: "Tim Melanchuk" <[email-masked]>
Date: Mon, 16 Apr 2007 08:01:22 -0700

we discussed this when we created the current set of packages.
i don't think we had stong reasons to do it either way and included
version numbers to be more explicit,  although the version numbers
work much like a new package. either a token identifying a
package/version matches (and is supported) or it doesn't.

more sophisticated versioning requires additional mechanism.
i think we want to be careful about adding complexity here but
this is worth further discussion.

timm

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 16 Apr 2007 19:47:23 -0700

But what would one do with a version number? 

-----Original Message-----
From: Adnan Saleem [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 2:22 PM
To: Eric Burger; 'Chris Boulton'
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Packages

I think it is very useful to have versioning for packages.
The versioning scheme should be fairly high level though, ie not every
tweak or schema change should result in a version update.

I'm inclined to agree with Chris's proposal below and as documented in
the control-framework draft (eg. 'msc-ivr-basic/1.0') with a major and
minor number.

Adnan

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: Tuesday, April 10, 2007 5:07 AM
To: Eric Burger; [email-masked]
Subject: RE: [MEDIACTRL] Packages

<chair-hat off>

  What if the

Chris.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by
email
and then delete it.

---

From: "Adnan Saleem" <[email-masked]>
Date: Mon, 16 Apr 2007 22:21:20 -0700

Versioning would allow AS to determine specific capability support
from the MS. Eg. IVR v1 has features X and Y. And IVR v2 adds feature Z.
AS supporting both v1 and v2 can dynamically tailor its interaction with
the MS based on the capability support indicated by the MS, v1 or v2.
Or if AS only supports v1, then AS can obviously only take advantage 
of feaures offered by v1 eventhough the MS may support both v1 and v2.
AS and MS can be upgraded independently and don't necessarily need
to be in lock-step with each other, especially when v2 is not fully
backwards compatible with v1.

Without version numbers, I don't understand how specific level of feature
support by a certain package would evolve over time. Eg 'IVR' package
available today would be called what in the future 'new-IVR' ? Or, no
need to label new versions if we can *always* ensure fully backwards 
compatible changes to packages ?

-----Original Message-----
From: Adnan Saleem [mailto:[email-masked]]
Sent: Friday, April 13, 2007 2:22 PM
To: Eric Burger; 'Chris Boulton'
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Packages

I think it is very useful to have versioning for packages.
The versioning scheme should be fairly high level though, ie not every tweak
or schema change should result in a version update.

I'm inclined to agree with Chris's proposal below and as documented in the
control-framework draft (eg. 'msc-ivr-basic/1.0') with a major and minor
number.

Adnan

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: Tuesday, April 10, 2007 5:07 AM
To: Eric Burger; [email-masked]
Subject: RE: [MEDIACTRL] Packages

<chair-hat off>
The whole package concept is pretty big.  Are we going to have, for example,
versioning?

[Chris Boulton] There is already a simplistic versioning mechanism in the
package drafts that is linked to the Control Package name that is
registered.  E.g. 'msc-ivr-basic/1.0'.

[Chris Boulton] At the moment you negotiate which packages you support based
on the tokens (see the core framework).  If some don't match - we have a SIP
response that contains the one supported.

  What if the

[Chris Boulton] Not covered at the moment - you either support or not based
on the token registered which include the version).  If we need to support a
more sophisticated mechanism then it would be great to discuss the
alternatives etc etc.

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.

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 17 Apr 2007 08:29:08 +0200

I think versioning is important, and I agree that minor versioning number would
not be the answer. They only work when there's a single implementation node,
and the only way to define standard extensions would be defining them here.

We could have an optional additional tag in the packages negotiation that only
tells the AS that this package HAS extensions (e.g something like
"msc-ivr-basic/1.0.x" or "msc-ivr-basic/1.0/x"). Then, if the AS wants, it can
furtherly negotiate, before sycnhing, with any extended control package through
the control channel by explicitely checking if it supports a specific feature,
i.e. if it exposes a specific method it can exploit. Of course this specific
features should be relatively known because recently implemented, even if not
standard, added features. A bit like 'configure' scripts work.

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]

> have received this message in error, please immediately return this by email

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 17 Apr 2007 10:30:37 +0200

A precisation inline on my previous words...

<cut>

> "msc-ivr-basic/1.0.x" or "msc-ivr-basic/1.0/x").

Of course this x I used as example tag would not be substituted by a 
minor version number (i.e. no 1.0.1 and the like). I thought exactly 
about a specific tag, a token, to indicate that the standard 1.0 package 
has been extended, without specifying how and where. The 1.0 would tell 
the AS what the package surely has and can do, the tag that the package 
can do something more, and this 'more' can be investigated through 
further negotiation. All this would be done right after the connection 
establishment and before the SYNCH.

Lorenzo

---

From: "Tim Melanchuk" <[email-masked]>
Date: Tue, 17 Apr 2007 07:15:21 -0700

are you thinking of standardized extensions or proprietary extensions?
for example, currently the  voicexml package extends the basic ivr
package but this relationship is not explicit within their identifying
tokens (msc-ivr-vxml/1.0  and msc-ivr-basic/1.0). rather the relationship
is defined as part of the voicexml package specification). in this sense,
"what" a package does, maps directly to a token (name/version) and
specification, and the name/version token is either supported or not.
do we really want and need more complexity for negotiation?

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 17 Apr 2007 17:05:49 +0200

Hi Tim,

> do we really want and need more complexity for negotiation?

I'm thinking to small extensions that would normally only need a minor 
version number increase, since they would not enhance the package to the 
point of justifying a major package version number increase.
This could apply to both standardized and proprietary extensions. 
Someone might add a feature and publicize it, and someone else could 
find it useful. 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.

About the example you made (vxml and ivr), I agree with you upon the 
explicit relationship problem, but in that case, and in similar ones, 
I'd talk more of dependency of one package on another, than of 
enhancements on a base package. As I'd see it, in case the depending 
package (e.g. vxml) relies on a non-standard feature that someone added 
to the base package (e.g. ivr) to make available another non-standard 
feature itself, it would be task of the depending package to check for 
the actual availability of the feature, while the AS would trust what 
the individual packages say they provide.

Lorenzo

> On 4/17/07, *Lorenzo Miniero* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Email: [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www1.ietf.org/mailman/listinfo/mediactrl>
>     Supplemental Web Site: