Subject: Re: [MEDIACTRL] Fw: AD review of draft-ietf-mediactrl-vxml

From: Dave Burke <[email-masked]>
Date: Tue, 8 Jul 2008 11:43:54 -0700

Hi Jon,

Thanks for the feedback (and apologies for the very slow response until
now). Comments below. We've created and submitted a revised draft (attached
with diff).

Dave & Mark

2008/5/6 Spencer Dawkins <[email-masked]>:

> Greetings,
>
> Eric and I have received Jon's review comments for this draft, as follows.
> We encourage quick responses, so we can work through Jon's issues and move
> the draft forward.
>
> Please respond onlist.
>
> Thanks,
>
> Spencer, as co-chair
>
> ----- Original Message -----
> From: "Peterson, Jon" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 29, 2008 8:48 PM
> Subject: AD review of draft-ietf-mediactrl-vxml
>
>
>
> A few notes on this one.
>
> The biggest point of contention here is obviously the fixed 'dialog'
> user name. While I understand that this document follows the precedent
> of RFC4240, that document is Informational and this is Standards Track.
> I also understand that RFC4240 (Section 7) offers a critique of RFC3087
> in defense of fixed user names. However, I'm not sure I find that
> analysis complete, and thus I'm a bit uncomfortable that mediactrl-vxml
> simply seems to accept the analysis of RFC4240 as having proven the case
> and goes forward from there. I do think this requires a bit more
> justification. The first sentence of the Security Considerations alludes
> to one of these problems - and merely authenticate endpoint requests
> does not completely answer that concern. Internationalization is another
> concern I hear raised about standardizing user parts.
>

Our choice of RFC4240 was based on the fact that this is the defacto
standard used in the industry today. Our aim is to ensure interoperability
with media servers. Fixing the user-part to identify a known user
(tantamount to a service) of the media server does not do any harm to the
Internet in our view. This fixed part is just used between the AS and MS. We
could weaken the spec to say "dialog" is recommended or even punt on it
because our media server in this document only offers one service, but I
think that would be a blow to interoperability. We don't believe the fixed
'dialog' string needs i18n - it is merely a 6-byte token.

>
> I'd be interested in hearing from the chairs on that first point, in
> terms of how strong the consensus is in the working group for this.
>
> In 1.1.4, expand the first use of CCXML.

Fixed in new version.

>
>
> I'm a little concerned that 2.1 is providing BNF for the sip and sips
> URI schemes. Clearly BNF for those schemes is already given in RFC3261.
> While providing BNF for the various parameters is appropriate, I'm less
> sure about casting it as a 'dialog URL' or what have you; it comes
> across as a profile of the sip/sips schemes.

Pruned the ABNF to specify just "uri-parameter"s, referencing RFC 3261.

>
>
> The statement towards the end of 2.1 that
>
>   Incorrectly formed requests MUST be rejected with the appropriate 4xx
>   class response.
>
> makes me a bit nervous. What is the appropriate 4xx class response if
> the HTTP query to fetch the VoiceXML document leads to a 401 challenge
> for which the media server has no password? What if the document exists
> but is stale? The point is that if implementations are to send "the
> appropriate 4xx class response" this document needs to say what they
> are. The end of 2.2 has a couple of things along these lines, perhaps
> more could live there.

The statement in question is a hangover from before the text at the end of
2.2 was added. Removed the clause about 4xx and moved the clause about
repeated  init-params to the  end of 2.2.

>
>
> In 2.4, the 'session.connection.protocol.sip.headers' - have you
> verified that the format of this associative array is compatible with
> the syntax of all possible SIP headers? The syntactical limitation
> listed at the very end of the section strikes me as probably only one of
> many.
>

The header names / values are represented as strings to the associate array
supports all SIP headers. The caveat we're calling out (that one form of
accessing associative arrays is more fragile than the other) is just a quirk
of ECMAScript. We definitively identified based on the syntax specifications
for both SIP header names and ECMAScript, that the only exceptions were due
to (a) case, (b) short form, and (c) the minus sign, all of which are
covered by the text we have.

> In 6.2, right after the table
>
>   The 405 Method Not Allowed response can be used by the AS to
>   gracefully decline bridge transfers
>
> I'm not sure what this means. Nor am I clear, in the proceeding table,
> what the 405 response to INVITE is supposed to signify.

That's an editorial error. This is an old statement from before we rewrote
this section. Removed.

>
>
> Overall, the Sec Cons has quite a bit of "you SHOULD do this" sort of
> language and little "you MUST implement this" sort of language. I'm sure
> the Security Area reviewers will be much more interested in what the
> mandatory-to-implement protocol mechanisms are. If "the VoiceXML Media
> Server SHOULD authenticate and authorize requesting endpoints," how does
> it do that? What mandatory-to-implement authentication mechanisms does
> it share in common with endpoints? How do they pre-establish
> credentials? Etc.
>

We've strengthened the language to MUST in many cases, RECOMMEND in others,
expanded upon security mechanisms where appropriate.

>
> Downref is noted.
>
> Anyway, let me know your thoughts.
>
> - J
>
>
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 9 Jul 2008 12:02:01 +0000

Hi Jon,

I'm also in agreement with Dave's comments. If there is some IETF policy against correlating the user name of a SIP URI with a service, I'd like to hear about it. If there is strong objection within the IETF to the fixed user name for this vxml service, then I would accept making it recommended rather than mandatory in the spec as a last resort so we can get this spec published.

thanks

scott

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Burke
Sent: Tuesday, July 08, 2008 20:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Fw: AD review of draft-ietf-mediactrl-vxml

Hi Jon,

Thanks for the feedback (and apologies for the very slow response until now). Comments below. We've created and submitted a revised draft (attached with diff).

Dave & Mark

2008/5/6 Spencer Dawkins <[email-masked]<mailto:[email-masked]>>:
Greetings,

Please respond onlist.

Thanks,

Spencer, as co-chair

----- Original Message -----
From: "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, April 29, 2008 8:48 PM
Subject: AD review of draft-ietf-mediactrl-vxml

A few notes on this one.

Our choice of RFC4240 was based on the fact that this is the defacto standard used in the industry today. Our aim is to ensure interoperability with media servers. Fixing the user-part to identify a known user (tantamount to a service) of the media server does not do any harm to the Internet in our view. This fixed part is just used between the AS and MS. We could weaken the spec to say "dialog" is recommended or even punt on it because our media server in this document only offers one service, but I think that would be a blow to interoperability. We don't believe the fixed 'dialog' string needs i18n - it is merely a 6-byte token.

Fixed in new version.

The statement in question is a hangover from before the text at the end of 2.2 was added. Removed the clause about 4xx and moved the clause about repeated  init-params to the  end of 2.2.

The header names / values are represented as strings to the associate array supports all SIP headers. The caveat we're calling out (that one form of accessing associative arrays is more fragile than the other) is just a quirk of ECMAScript. We definitively identified based on the syntax specifications for both SIP header names and ECMAScript, that the only exceptions were due to (a) case, (b) short form, and (c) the minus sign, all of which are covered by the text we have.

That's an editorial error. This is an old statement from before we rewrote this section. Removed.

We've strengthened the language to MUST in many cases, RECOMMEND in others, expanded upon security mechanisms where appropriate.

Downref is noted.

- J

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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 10 Jul 2008 09:19:15 +0300

Hi,
After the long discussion I can accept the usage of RFC 4240 as Chris
suggested.

On the other hand I do not think that section 3 and mostly 3.4 and 3.5
should be in the document. 
I am not aware that codec selection has to do with the protocol
specified by this draft. Having mandatory codecs in a standard track
document may have long term implications. We suffer today in H.323 from
having to support H.261 which is specified as a mandatory codec and I
fear that H.263 baseline will go the same way. 
As for Mandatory support of G.711 in general it is not a major issue but
may be problematic when low bandwidth is available.
As for the rest of the codecs mentioned they are very specific to a
particular market and should not be there at all.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Chris Boulton
> Sent: Wednesday, May 07, 2008 9:07 PM
> To: Spencer Dawkins; [email-masked]
> [Chris Boulton] As a person who has been involved with many product
> combinations of App Server/Media Server interactions I strongly
support
> the use of RFC 4240 and its fixed strings - if for nothing else the
> extensive amount of interoperability that it has historically produced
> (yes - a shock I know - something the IETF produced that has been
> widely
> adopted and has strong interoperability).  While I agree that it's may
> not be 'true to form' in using fixed user names I simply see this as
an
> extension to an existing 'working' mechanism.  Yes, it maybe standards
> track in the case of this draft but it merely acts as closure on 4240
-
> which is widely used.  My personal view that that use of fixed names
is
> in no way harmful to the internet in general and should be accepted.
> 
> Chris
> 
> 
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 14 Jul 2008 11:49:24 -0400

[as individual]
On the one hand, I can see the issue with video, where codecs get  
insanely better each year. On the other hand, in the case of voice,  
the deployment of G.729 is so pervasive, even if something better  
comes by, I neither see it going away nor becoming a bandwidth or CPU  
burden. Thus it does no harm to mandate it for interoperability

[as chair]
Spencer and I have seen no discussion on this point, so we do not see  
a consensus to change. If you (by "you", we mean any participant, not  
just Roni) disagree, please post to the list.

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 14 Jul 2008 18:54:34 +0300

Hi,
As Roni I would say that G.729 is used in voice solution but is not
commonly used in video conferencing systems.

As for the consensus on codecs I had a question to the chairs if this is
in the scope of the Mediactrl WG to mandate codecs in a standard track
document.
 
Roni

> From: Eric Burger [mailto:[email-masked]]
> Sent: Monday, July 14, 2008 6:49 PM
> To: Even, Roni
> Cc: [email-masked]

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 14 Jul 2008 19:00:55 +0300

Hi,
I think the title should change
The chairs are looking for discussion
Roni

---

From: "Tim Melanchuk" <[email-masked]>
Date: Mon, 14 Jul 2008 09:28:30 -0700

i do not think that protocol specs should include specific mandatory codecs.
codecs are not part of the protocol and protocol specs are not where we
document configuration profiles that different devices need for interop.

cheers,
timm

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 14 Jul 2008 12:34:29 -0400

>> burden. Thus it does no harm to mandate it for interoperability

I am not sure that a MUST is necessary at all in 3.4.

In video, I think that there is a rapid convergence recently on H.264  
(AKA MPEG-4 Part 10),
which is used very commonly in streaming, IPTV and video conferencing.  
Its use I would
regard as something that is not going to go away in the foreseeable  
future. By comparison, there
is relatively little use of MPEG-4 (part 2) in streaming, IPTV or  
videoconferencing. So, if you
are going to have those "SHOULD"s, I would reference RFC3984 and H.264.

Regards
Marshall

---

From: "Steve Buko" <[email-masked]>
Date: Fri, 18 Jul 2008 13:01:12 -0400

For whatever reason, the email below got kicked back to me.  My opinion
on the mandatory codec discussion.

Steve

From: Steve Buko 
Sent: Monday, July 14, 2008 12:44 PM
To: 'Tim Melanchuk'; Even, Roni
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Mandatory codecs in of
draft-ietf-mediactrl-vxml

I tend to agree with Tim on this. 

To include specific mandatory codecs there should be a compelling reason
to do so.  I don't see one at this point.  

Steve

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tim Melanchuk
Sent: Monday, July 14, 2008 12:29 PM
To: Even, Roni
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Mandatory codecs in of
draft-ietf-mediactrl-vxml

i do not think that protocol specs should include specific mandatory
codecs.
codecs are not part of the protocol and protocol specs are not where we 
document configuration profiles that different devices need for interop.

cheers,
timm

On Mon, Jul 14, 2008 at 9:00 AM, Even, Roni <[email-masked]>
wrote:

Hi,

---

From: "Mark Scott" <[email-masked]>
Date: Fri, 18 Jul 2008 10:14:22 -0700

Hi Everyone,

Dave Burke and I have discussed this issue and the feedback provided
here, and I believe that in general we agree that there is likely not a
compelling reason to mandate the use of particular codecs, so we would
be agreeable to removing this from the draft.  However, there are a
couple of things we would like to retain (comments are welcome):

*         DTMF digit signalling is a crucial aspect of media server
operation; even though this can be thought of as a codec in some sense,
it is central enough to the operation of the media server that we feel
it should continue to be required as per section 3.5;

*         We also feel that G.711 is universally supported in practice
by every media server that we know of, and has essentially no
implementation overheads, and that it would thus be reasonable to
continue to require this to ensure at least basic interoperability.
Guaranteeing at least one profile that is universally supported can be
useful, even for something like providing a test harness that validates
compliance with the draft without having to be customized to match the
specific set of codecs selected by a particular implementation.  As
such, we would prefer to continue to include G.711 as MUST, though if
there is strong objection to this then reducing it to SHOULD seems like
a reasonable compromise.

The points in particular about the rapid evolution of video codecs, even
in comparison to when we first put the draft together, do indeed make a
good point against mandating specific behaviour in the draft.

Regards,

Mark.

Behalf Of Steve Buko
Sent: July-18-08 1:01 PM
To: [email-masked]

Steve

From: Steve Buko 

Steve

cheers,
timm

Hi,

> just Roni) disagree, please post to the list.

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 20 Jul 2008 18:04:52 +0300

Hi,

I see no problem discussing DTMF and recommending support for RFC4733 (I
wish all clients support it)

The current section 3.5 

DTMF events [RFC4733] MUST be supported.  When the user agent does

   not indicate support for [RFC4733] the VoiceXML Media Server MAY

   perform DTMF detection using other means such as detecting DTMF tones

   in the audio stream.  Implementation note: the reason why only

   [RFC4733] telephone-events must be used when the user agent indicates

   support of it is to avoid the risk of double detection of DTMF if

   detection on the audio stream was simultaneously applied.

1.       RFC 4733 is not events but RTP payload for DTMF, the text may
be confusing since events may lead people to think about KPML

2.       MUST be supported - I assume that this is on the media server
based on the rest of the text.

About g.711

For audio-only applications, G.711 mu-law and A-law MUST be supported

   using the RTP payload type 0 and 8 [RFC3551]

Comment: G.711 can be used with dynamic payload types and not only with
the 0 and 8 static one. So the media server (I assume thiese are
requirements for a media server) SHOULD or MUST support G.711 mu-law and
A-law

Roni

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Scott
Sent: Friday, July 18, 2008 8:14 PM
To: Steve Buko; [email-masked]
Subject: Re: [MEDIACTRL] Mandatory codecs in of
draft-ietf-mediactrl-vxml

Hi Everyone,

Regards,

Mark.

Steve

From: Steve Buko 

Steve

cheers,
timm

Hi,

> just Roni) disagree, please post to the list.

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.

---

From: Dave Burke <[email-masked]>
Date: Mon, 21 Jul 2008 10:58:10 +0100

On Sun, Jul 20, 2008 at 4:04 PM, Even, Roni <[email-masked]> wrote:

> 1.       RFC 4733 is not events but RTP payload for DTMF, the text may be
> confusing since events may lead people to think about KPML
>
> 2.       MUST be supported – I assume that this is on the media server
> Thanks - will clean up these editorial clarifications

> Comment: G.711 can be used with dynamic payload types and not only with the
> 0 and 8 static one. So the media server (I assume thiese are requirements
> for a media server) SHOULD or MUST support G.711 mu-law and A-law
>
>
>
Good catch - will fix

> Roni
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Mark Scott
> *Sent:* Friday, July 18, 2008 8:14 PM
> *To:* Steve Buko; [email-masked]
>
> *Subject:* Re: [MEDIACTRL] Mandatory codecs in of
> Dave Burke and I have discussed this issue and the feedback provided here,
> and I believe that in general we agree that there is likely not a compelling
> reason to mandate the use of particular codecs, so we would be agreeable to
> removing this from the draft.  However, there are a couple of things we
> would like to retain (comments are welcome):
>
>
>
> ·         DTMF digit signalling is a crucial aspect of media server
> operation; even though this can be thought of as a codec in some sense, it
> is central enough to the operation of the media server that we feel it
> should continue to be required as per section 3.5;
>
>
>
> ·         We also feel that G.711 is universally supported in practice by
> every media server that we know of, and has essentially no implementation
> overheads, and that it would thus be reasonable to continue to require this
> to ensure at least basic interoperability.  Guaranteeing at least one
> profile that is universally supported can be useful, even for something like
> providing a test harness that validates compliance with the draft without
> having to be customized to match the specific set of codecs selected by a
> particular implementation.  As such, we would prefer to continue to include
> G.711 as MUST, though if there is strong objection to this then reducing it
> to SHOULD seems like a reasonable compromise.
>
>
>
> The points in particular about the rapid evolution of video codecs, even in
> comparison to when we first put the draft together, do indeed make a good
> point against mandating specific behaviour in the draft.
>
>
>
> Regards,
>
>
>
> Mark.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Steve Buko
> *Sent:* July-18-08 1:01 PM
> *To:* [email-masked]
> *Subject:* Re: [MEDIACTRL] Mandatory codecs in of
> For whatever reason, the email below got kicked back to me.  My opinion on
> the mandatory codec discussion.
>
>
>
> Steve
>
>
>
>
>
> *From:* Steve Buko
> *Sent:* Monday, July 14, 2008 12:44 PM
> *To:* 'Tim Melanchuk'; Even, Roni
> *Cc:* [email-masked]
> *Subject:* RE: [MEDIACTRL] Mandatory codecs in of
> To include specific mandatory codecs there should be a compelling reason to
> do so.  I don't see one at this point.
>
>
>
> Steve
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Tim Melanchuk
> *Sent:* Monday, July 14, 2008 12:29 PM
> *To:* Even, Roni
> *Cc:* [email-masked]
> *Subject:* Re: [MEDIACTRL] Mandatory codecs in of
> affiliated entities. Access by the intended recipient only is authorized.
> Any liability arising from any party acting, or refraining from acting, on
> any information contained in this e-mail is hereby excluded. If you are not
> the intended recipient, please notify the sender immediately, destroy the
> original transmission and its attachments and do not disclose the contents
> to any other person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any attachments
> belongs to Alcatel-Lucent and/or its affiliated entities.
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 23 Jul 2008 11:52:56 -0400

Of course, if the media server supports RFC 3261 (SIP), it MUST  
support G.711 anyway. Given the smell of consensus on the list is to  
not have mandatory codecs, I would offer we be SILENT on the codec  
issue. Otherwise, there will be people that think that ONLY G.711 is  
supported.

On Jul 21, 2008, at 5:58 AM, Dave Burke wrote:

> I see no problem discussing DTMF and recommending support for  
> RFC4733 (I wish all clients support it)
>
> The current section 3.5
>
>
> 1.       RFC 4733 is not events but RTP payload for DTMF, the text  
> may be confusing since events may lead people to think about KPML
>
> 2.       MUST be supported – I assume that this is on the media  
> server based on the rest of the text.
>
>
>
> Comment: G.711 can be used with dynamic payload types and not only  
> with the 0 and 8 static one. So the media server (I assume thiese  
> are requirements for a media server) SHOULD or MUST support G.711 mu- 
> law and A-law
>
>
> Good catch - will fix
>
>
> Roni
>
>
>
> On Behalf Of Mark Scott
> Subject: Re: [MEDIACTRL] Mandatory codecs in of draft-ietf-mediactrl- 
> vxml
>
>
> Hi Everyone,
>
>
> here, and I believe that in general we agree that there is likely  
> not a compelling reason to mandate the use of particular codecs, so  
> we would be agreeable to removing this from the draft.  However,  
> there are a couple of things we would like to retain (comments are  
> welcome):
>
>
> operation; even though this can be thought of as a codec in some  
> sense, it is central enough to the operation of the media server  
> that we feel it should continue to be required as per section 3.5;
>
>
> ·         We also feel that G.711 is universally supported in  
> practice by every media server that we know of, and has essentially  
> no implementation overheads, and that it would thus be reasonable to  
> Guaranteeing at least one profile that is universally supported can  
> be useful, even for something like providing a test harness that  
> validates compliance with the draft without having to be customized  
> to match the specific set of codecs selected by a particular  
> implementation.  As such, we would prefer to continue to include G. 
> 711 as MUST, though if there is strong objection to this then  
> reducing it to SHOULD seems like a reasonable compromise.
>
>
> The points in particular about the rapid evolution of video codecs,  
> even in comparison to when we first put the draft together, do  
> indeed make a good point against mandating specific behaviour in the  
> draft.
>
>
> Regards,
>
>
> Mark.
>
>
> On Behalf Of Steve Buko
> Subject: Re: [MEDIACTRL] Mandatory codecs in of draft-ietf-mediactrl- 
> vxml
>
>
> For whatever reason, the email below got kicked back to me.  My  
> opinion on the mandatory codec discussion.
>
>
> Steve
>
>
>
> From: Steve Buko
> Subject: RE: [MEDIACTRL] Mandatory codecs in of draft-ietf-mediactrl- 
> vxml
>
>
> To include specific mandatory codecs there should be a compelling  
> reason to do so.  I don't see one at this point.
>
>
> Steve
>
>
>
> On Behalf Of Tim Melanchuk
> Subject: Re: [MEDIACTRL] Mandatory codecs in of draft-ietf-mediactrl- 
> vxml
>
>
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may  
> contain confidential and proprietary information of Alcatel-Lucent  
> and/or its affiliated entities. Access by the intended recipient  
> only is authorized. Any liability arising from any party acting, or  
> refraining from acting, on any information contained in this e-mail  
> is hereby excluded. If you are not the intended recipient, please  
> notify the sender immediately, destroy the original transmission and  
> its attachments and do not disclose the contents to any other  
> person, use it for any purpose, or store or copy the information in  
> any medium. Copyright in this e-mail and any attachments belongs to  
> Alcatel-Lucent and/or its affiliated entities.
>
>