Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identificatio ninSIP

From: "Andrew Allen" <[email-masked]>
Date: Fri, 16 Feb 2007 14:59:17 -0500

John
 
I think whether an AS in the terminating network is considered a contact is a debatable point. Certainly it doesnt register feature tags using RFC 3840 mechanisms and (at least in IMS) they dont show up as registered contacts in the reg-event notifications. Also AS in the originating network (which may need to be involved in some communication services) are certainly not contacts for the resource identified by the Request-URI and Accept-Contact certainly has no defined role in routing to them.
 
In addition 3GPP TS 23.228 v7.6.0 subcaluse 4.13.2 specifies 15 requirements for IMS Communication Service Identifier and only one of these is regarding matching to the correct contact:
 
11. The communication service identifier shall be taken into account when selecting the correct UE(s), if multiple UEs are registered for the same Public User Identity(s).

 Several of the other requirements are in my view totally incompatible with Accept-Contact being the transport for the identifier and indeed may limit the use of Accept-Contact for its intended purpose. This includes charging and policy control:
 
8.   Based on operator policy S-CSCF and AS shall consider the IMS communication service identifier for online and offline charging, e.g. put appropriate data into call detailed records.

9.   The communication service identifier shall be capable of being an input into the policy control and charging rules.

Also:
 
2.   Based on operator policy the S-CSCF or an AS shall be able to validate an IMS communication service identifier in a SIP request. This includes e.g. to check the syntactical correctness of a service identifier, and policing the usage of a communication service identifier.

10. It shall be possible to use the IMS communication service identifier as a means to authorise whether a subscriber is allowed to initiate or receive request for a communication service.

Another problem with UAs placing feature tags in Accept-Contact headers as Service Identifiers is how does the initiator obtains the service identifier of the destination party for the related service? The concept only works in the scenario where all networks and devices have a common understanding of the same services and the identifiers that identify them. As far as I am aware SIP doesnt provide a mechanism to discover proprietary non standard feature tags that are used by other devices in other domains and map them to services that they relate to. This means that if Accept-Contact is used the communication services are closed and can only be used by those who are part of the closed network, (unless of course IETF were to get into standardising services which I think is highly unlikely). If URIs are used as the container for the Service Identifier these can be obtained using Presence as proposed in Jonathan's draft.
 
This helps fulfil the following requirements in 3GPP TS 23.228:
 
12. The usage of communication service identifiers shall not adversely affect interoperability between IMS networks and interoperability with external SIP networks and CS networks. The behaviour of a network receiving the IMS requests without an IMS communication service identifier is a matter of operator policy. Usage of communication service identifiers shall not decrease the level of interoperability with networks and UEs that are unaware of the communication service identifier.

14. The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

SDP is not good for routing decisions for service identification. Firstly SDP is intended to be end to end only. It may be encrypted and understanding the details of the service may require service or application level understanding of the SDP and the service which is knowledge that proxies should not need to have. Also I dont think that SDP can always uniquely identify a service in any case. In addition not all requests that are related to a service will contain SDP in any case.
 
Andrew
________________________________

From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 3:12 AM
To: Andrew Allen; Malleswara Rao Ankem
Cc: Andrew Allen; [email-masked]
Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identificatio ninSIP

Andrew,
 
Well, an AS is just another contact (perhaps a permanently registered one, rather than one that uses SIP REGISTER), isn't it? So caller preferences can be used to choose an AS or any other contact that supports the desired capability.
 
I agree caller preferences is not a suitable basis for charging. Just because I say I have a preference for a contact that supports video, doesn't mean that I will necessarily use video during that call. That might be determined during some mid-call session-re-negotiation. Surely charging has to be based on what is actually used, not what might be used, and you can't always determine this at INVITE time.
 
So I am saying use caller preferences to select a preferred contact, use SDP to negotiate and re-negotiate the session with the contact that you end up with. I haven't heard any compelling arguments for anything else so far.
 
John

________________________________

	From: Andrew Allen [mailto:[email-masked]] 
	Sent: 16 February 2007 03:51
	To: Elwell, John; Malleswara Rao Ankem
	Cc: [email-masked]; Andrew Allen
	Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identificatio n inSIP

	John,
	 
	If Service Identification was only about selecting the appropriate contacts from those registered agaisnt the AOR then RFC 3840/3841 would be fine however Service Identification is much more than that and may be used to route requests to application servers for service logic invocation, and used as the basis for charging. Accept-Contact is basically just a filter expression to filter a set of registered contacts. Including a parameter in a filter expression and using that as the basis for charging, authorisation and service invocation is going to cause problems.
	 
	Andrew
	 
________________________________

	From: Elwell, John [mailto:[email-masked]] 
	Sent: Thursday, February 15, 2007 6:16 AM
	To: Malleswara Rao Ankem
	Cc: [email-masked]
	Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identificatio n inSIP

	Mallesh,
	 
	Yes, I agree that some means of selecting a preferred device might be needed, but that is indeed what RFC3841/3840 does. Why do you consider this overkill?
	 
	John

________________________________

		From: Malleswara Rao Ankem [mailto:[email-masked]] 
		Sent: 15 February 2007 10:54
		To: Elwell, John
		Cc: Göran Eriksson AP (KI/EAB); [email-masked]
		Subject: Re: Device architecture? WAS: RE: [Sipping] Service Identificatio n in SIP

		Inorder to identify a endpoint that has the capabilities to serve a very specialized functionality, I guess it is simpler to name the functionality. Naming the functionality not only helps in decision making while routing the request to that specific endpoint but also helps the endpoint identify which specialized application on the endpoint can take up the responsibility. Instead of all the routing entities looking into the SDP/message bodies it should be easier/faster if they can look for a specific header. 
		I thought feature tag mechanisms indicated in the RFC3841/3840 combination should have sufficed but implementing those RFCs seems to be a overkill for describing/selecting/routing requests to the specific endpoint and also choosing a service/feature/application on the endpoint. 
		 
		-Mallesh

		On 2/15/07, Elwell, John <[email-masked] > wrote: 

			Göran,
			
			Your interpretation is different from what is stated in the Rosenberg draft.
			Anyway, let's not dwell on this particular use case, which may or may not be 
			realistic. The important thing is whether the media being sent is suitable
			for general purpose devices or requires or could be used by some special
			class of application.
			
			If a medium is somehow specialised ( e.g., audio modulated for interpretation
			by a modem or fax machine), then the necessary information needs to be
			conveyed along with the m-line in the SDP. Perhaps even if it is
			human-intelligible voice but with a restricted repertoire of words that make 
			it suitable for a particular class of application, maybe that information
			too should be conveyed with the m-line. Perhaps the case described in
			Jonathan's draft fits this latter category: I believe the medium is just 
			regular voice that can be interpreted by a human, but is also constrained in
			its repertoire of words such that it can be used by a chess application.
			
			The important thing is that there be sufficient information in the SDP to 
			allow appropriate application selection at the end device. I am not
			convinced by a need for information at the SIP level during call
			establishment, because of course SDP can be re-negotiated during the call
			( e.g., when the users decide to use a particular application) and what is
			indicated in SIP at call establishment time might no longer be valid later
			in the call.
			
			John

			> -----Original Message----- 
			> From: Göran Eriksson AP (KI/EAB)
			> [mailto:[email-masked]]
			> Sent: 14 February 2007 23:34 
			> To: Elwell, John
			> Cc: [email-masked]
			> Subject: Device architecture? WAS: RE: [Sipping] Service 
			> Identification in SIP
			>
			> My humble, perhaps faulty, understanding of the "chess game"
			> was not that voice commands were used to control the chess 
			> itself, rather
			> that the chess game, while having some IP-based proprietary 
			> gaming interaction protocol, also had a feature letting
			> the users talk to each others while playing. The scenario are 
			> two, or more, users play a chess game of the (Inter)net, talkin
			> to eachother from time to time during the game (yeah, don't 
			> ask me if I think people will love this!!).
			>
			> The purpose, as I understand it, was a)to show that the 
			> 'voice component' in the chess game application is similar to that
			> in a stand alone POC-Only application when it comes to 
			> exchange and transfer of voice samples and associated floor control 
			> and b) to point to differences, for instance when it comes to
			> supplementary services, which may not apply in the chess game case. 
			>
			> Perhaps it is important to be clear on the assumed user
			> device realisation, as far as I understand it:
			>
			>  The "chess game + voice" example is, as I understand it,
			> discussed under the assumption that voice and chess game is 
			>  managed by custome designed appliction, or client, which is 
			> a necessary/likely approach in a mobile device given the
			>  limited MMI (and also other factors in the mobile context).
			>
			>  In a PC, I could easily handle this as two different 
			> applications/client, like when I use Skype/MSN to talk to my 
			> friends while
			>  playing some turn based game, but again, the discussion is
			> held under the assumption that usability requirements 
			>  leads to an application client integrating voice and chess
			> game events.
			>
			> The alternative device realisation You describe- different
			> clients managing different portions of what is negotiated in 
			> the SDP or MSRP MIME attachment-
			> is, I think, a good illustration of the need to be precise 
			> and explicit about the assumed device architecture when
			> discussing the "service identification" issue(s). 
			>
			> Regards
			> Göran
			>
			>
			>
			>
			> -----Original Message----- 
			> From: Elwell, John [mailto: [email-masked] <mailto:[email-masked]> ]
			> Sent: den 14 februari 2007 11:57
			> To: Henry Sinnreich; [email-masked] 
			> Subject: RE: [Sipping] Service Identification in SIP
			>
			> Having followed this thread, I too find the chess example
			> very contrived. If chess moves are sent as voice commands,
			> then surely it would be acceptable for the normal telephone 
			> application to answer the call, i.e., the remote player
			> listens to the move, performs this move on a conventional or
			> electronic chess board and speaks his next move. The calling
			> UA should not care whether the call is answered by a computer 
			> application or a person.
			> Furthermore, even if the audio needs to consumed by a
			> particular chess application at the called UA, then other
			> media in the same session such as video or messaging might 
			> not be. So any qualification of the nature of media to be
			> exchanged probably should be at the media level, not at the
			> session level or SIP level. As yet another variation, what if
			> the players set up a conventional telephone call and then 
			> mutually agree to switch in their chess applications?
			>
			> Now, let's consider another case. I establish an MSRP
			> session. Within this MSRP session I can send messages with
			> various MIME attachments that are intended for consumption by 
			> various applications. I should not need to know in advance
			> what applications I will use during the course of the MSRP
			> session. All I should put in the INVITE request is the fact
			> that I want to establish an MSRP session. 
			>
			> John
			>
			> > -----Original Message-----
			> > From: Henry Sinnreich [mailto:[email-masked] ]
			> > Sent: 13 February 2007 18:19
			> > To: [email-masked]
			> > Subject: RE: [Sipping] Service Identification in SIP 
			> >
			> > It must be my lack of imagination for not being able to
			> come up with a 
			> > credible usage scenario, given the following:
			> >
			> > - Is playing chess by voice a credible usage scenario? :-) 
			> Especially
			> > since voice recognition is now so often found in PCs and in mobile 
			> > phones as well. In other words, chess playing by voice may
			> also be an
			> > endpoint application, without any network involvement. Actually, if 
			> > placed in the endpoint it works just as well on poor 
			> bandwidth links
			> > by contrast to chess in the network that may require adequate
			> > broadband.
			> >
			> > - Is anyone's boss or spouse going to approve extra phone charges 
			> > above the flat rate for playing chess at a time when the gaming
			> > industry has pioneered free VoIP?
			> > Will such a service be taxed extra and if yes using by what
			> criteria?
			> > Gambling comes to my mind :-) 
			> >
			> > - VoIP is reported in the press as a give-away and I have seen no
			> > reports of any VoIP provider recording a profit on VoIP. I
			> assume the
			> > losses are often hidden by bundling in triple play, etc. 
			> >
			> > Given my lack of imagination, can anyone share a more
			> credible usage
			> > scenario for Service Identification in SIP?
			> >
			> > What's the use of a standard without a credible usage scenario? 
			> >
			> > Thanks, Henry
			> >
			> >
			> > _______________________________________________
			> > Sipping mailing list   https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping> 
			> > This list is for NEW development of the application of SIP Use
			> > [email-masked] for questions on current sip Use
			> > [email-masked] for new developments of core SIP 
			> >
			>
			> _______________________________________________
			> Sipping mailing list   https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping> 
			> This list is for NEW development of the application of SIP
			> Use [email-masked] for questions on current 
			> sip Use [email-masked] for new developments of core SIP 
			>
			
			_______________________________________________
			Sipping mailing list   https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping> 
			This list is for NEW development of the application of SIP
			Use [email-masked] for questions on current sip 
			Use [email-masked] for new developments of core SIP

________________________________

	This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2007 12:29:20 -0500

Andrew Allen wrote:
>  
> John
>  
> I think whether an AS in the terminating network is considered a contact 
> is a debatable point. Certainly it doesnt register feature tags using 
> RFC 3840 mechanisms and (at least in IMS) they dont show up as 
> registered contacts in the reg-event notifications.

I have long considered this a deficiency in IMS. The applicability of 
caller preferences to ASs is never discussed. IMO IMS needs to clarify 
this. In particular:
- should callerprefs be taken into account when the S-CSCF is
   deciding whether to route a request to a particular AS?
- when an AS receives a request from the S-CSCF, should it apply
   callerprefs before deciding if/how to process the request?

Take voicemail as an example. RFC 4596 discusses, among other things, 
how callerprefs can be used by a caller either avoid going to voicemail 
or to go directly to voicemail without attempting another UAS. These use 
cases work if the voicemail server is registered.

While I haven't found it specified in any IMS docs I have read, its my 
understanding that in IMS the intended way to handle VM is to route any 
call that *might* need to go to VM to a VM aware server. This server 
will then act as a proxy, and eventually the call will be routed to 
candidate registered target UAs. The VM aware proxy then monitors the 
call. If it isn't answered, then eventually the proxy will cancel those 
attempts and route the call to a VM server that was not registered as a 
candidate.

In such a scenario, the callerprefs capability to select only voicemail 
or reject voicemail won't work by default. It *might* be made to work if 
the VM aware proxy is also callerprefs aware and takes suitable actions. 
But it will be a bit odd, because in general it doesn't have any 
awareness of the actual registered candidates.

It is possible that the reason IMS feels it needs new features such as 
service id is because it has broken existing mechanisms.

	Paul

> Also AS in the 
> originating network (which may need to be involved in some communication 
> services) are certainly not contacts for the resource identified by the 
> Request-URI and Accept-Contact certainly has no defined role in routing 
> to them.
>  
> In addition 3GPP TS 23.228 v7.6.0 subcaluse 4.13.2 specifies 15 
> requirements for IMS Communication Service Identifier and only one of 
> these is regarding matching to the correct contact:
>  
> 
> 11. The communication service identifier shall be taken into account 
> when selecting the correct UE(s), if multiple UEs are registered for the 
> same Public User Identity(s).
> 
>  
>  Several of the other requirements are in my view totally incompatible 
> with Accept-Contact being the transport for the identifier and indeed 
> may limit the use of Accept-Contact for its intended purpose. This 
> includes charging and policy control:
>  
> 
> 8.   Based on operator policy S-CSCF and AS shall consider the IMS 
> communication service identifier for online and offline charging, e.g. 
> put appropriate data into call detailed records.
> 
> 9.   The communication service identifier shall be capable of being an 
> input into the policy control and charging rules.
> 
> Also:
>  
> 
> 2.   Based on operator policy the S-CSCF or an AS shall be able to 
> validate an IMS communication service identifier in a SIP request. This 
> includes e.g. to check the syntactical correctness of a service 
> identifier, and policing the usage of a communication service identifier.
> 
> 10. It shall be possible to use the IMS communication service identifier 
> as a means to authorise whether a subscriber is allowed to initiate or 
> receive request for a communication service.
> 
> Another problem with UAs placing feature tags in Accept-Contact headers 
> as Service Identifiers is how does the initiator obtains the service 
> identifier of the destination party for the related service? The concept 
> only works in the scenario where all networks and devices have a common 
> understanding of the same services and the identifiers that identify 
> them. As far as I am aware SIP doesnt provide a mechanism to discover 
> proprietary non standard feature tags that are used by other devices in 
> other domains and map them to services that they relate to. This means 
> that if Accept-Contact is used the communication services are closed and 
> can only be used by those who are part of the closed network, (unless of 
> course IETF were to get into standardising services which I think is 
> highly unlikely). If URIs are used as the container for the Service 
> Identifier these can be obtained using Presence as proposed in 
> Jonathan's draft.
>  
> 12. The usage of communication service identifiers shall not adversely 
> affect interoperability between IMS networks and interoperability with 
> external SIP networks and CS networks. The behaviour of a network 
> receiving the IMS requests without an IMS communication service 
> identifier is a matter of operator policy. Usage of communication 
> service identifiers shall not decrease the level of interoperability 
> with networks and UEs that are unaware of the communication service 
> identifier.
> 
> SDP is not good for routing decisions for service identification. 
> Firstly SDP is intended to be end to end only. It may be encrypted and 
> understanding the details of the service may require service or 
> application level understanding of the SDP and the service which is 
> knowledge that proxies should not need to have. Also I dont think that 
> SDP can always uniquely identify a service in any case. In addition not 
> all requests that are related to a service will contain SDP in any case.
>  
> Andrew
> ------------------------------------------------------------------------
> *From:* Elwell, John [mailto:[email-masked]]
> *Sent:* Friday, February 16, 2007 3:12 AM
> *To:* Andrew Allen; Malleswara Rao Ankem
> *Cc:* Andrew Allen; [email-masked]
> *Subject:* RE: Device architecture? WAS: RE: [Sipping] Service 
> Identificatio ninSIP
> 
> Andrew,
>  
> Well, an AS is just another contact (perhaps a permanently registered 
> one, rather than one that uses SIP REGISTER), isn't it? So caller 
> preferences can be used to choose an AS or any other contact that 
> supports the desired capability.
>  
> I agree caller preferences is not a suitable basis for charging. Just 
> because I say I have a preference for a contact that supports video, 
> doesn't mean that I will necessarily use video during that call. That 
> might be determined during some mid-call session-re-negotiation. Surely 
> charging has to be based on what is actually used, not what might be 
> used, and you can't always determine this at INVITE time.
>  
> So I am saying use caller preferences to select a preferred contact, use 
> SDP to negotiate and re-negotiate the session with the contact that you 
> end up with. I haven't heard any compelling arguments for anything else 
> so far.
>  
> John
> 
>     ------------------------------------------------------------------------
>     *From:* Andrew Allen [mailto:[email-masked]]
>     *Sent:* 16 February 2007 03:51
>     *To:* Elwell, John; Malleswara Rao Ankem
>     *Cc:* [email-masked]; Andrew Allen
>     *Subject:* RE: Device architecture? WAS: RE: [Sipping] Service
>     Identificatio n inSIP
> 
>      
>     John,
>      
>     If Service Identification was only about selecting the appropriate
>     contacts from those registered agaisnt the AOR then RFC 3840/3841
>     would be fine however Service Identification is much more than that
>     and may be used to route requests to application servers for service
>     logic invocation, and used as the basis for charging. Accept-Contact
>     is basically just a filter expression to filter a set of registered
>     contacts. Including a parameter in a filter expression and using
>     that as the basis for charging, authorisation and service invocation
>     is going to cause problems.
>      
>     Andrew
>      
>     ------------------------------------------------------------------------
>     *From:* Elwell, John [mailto:[email-masked]]
>     *Sent:* Thursday, February 15, 2007 6:16 AM
>     *To:* Malleswara Rao Ankem
>     *Cc:* [email-masked]
>     *Subject:* RE: Device architecture? WAS: RE: [Sipping] Service
>     Identificatio n inSIP
> 
>     Mallesh,
>      
>     Yes, I agree that some means of selecting a preferred device might
>     be needed, but that is indeed what RFC3841/3840 does. Why do you
>     consider this overkill?
>      
>     John
> 
>         ------------------------------------------------------------------------
>         *From:* Malleswara Rao Ankem [mailto:[email-masked]]
>         *Sent:* 15 February 2007 10:54
>         *To:* Elwell, John
>         *Cc:* Göran Eriksson AP (KI/EAB); [email-masked]
>         *Subject:* Re: Device architecture? WAS: RE: [Sipping] Service
>         Identificatio n in SIP
> 
>         Inorder to identify a endpoint that has the capabilities to
>         serve a very specialized functionality, I guess it is simpler to
>         name the functionality. Naming the functionality not only helps
>         in decision making while routing the request to that specific
>         endpoint but also helps the endpoint identify which specialized
>         application on the endpoint can take up the responsibility.
>         Instead of all the routing entities looking into the SDP/message
>         bodies it should be easier/faster if they can look for a
>         specific header.
>         I thought feature tag mechanisms indicated in the RFC3841/3840
>         combination should have sufficed but implementing those RFCs
>         seems to be a overkill for describing/selecting/routing
>         requests to the specific endpoint and also choosing a
>         service/feature/application on the endpoint.
>          
>         -Mallesh
>          
>          
>          
>         On 2/15/07, *Elwell, John* <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Göran,
> 
>              > [mailto:[email-masked]
>             <mailto:[email-masked]>]
>              > Cc: [email-masked] <mailto:[email-masked]>
>              > From: Elwell, John [mailto: [email-masked]
>             <mailto:[email-masked]>]
>             <mailto:[email-masked]>
>              > > From: Henry Sinnreich [mailto:[email-masked]
>             <mailto:[email-masked]>]
>              > > To: [email-masked] <mailto:[email-masked]>
>              > > Sipping mailing list  
>             https://www1.ietf.org/mailman/listinfo/sipping
>             <https://www1.ietf.org/mailman/listinfo/sipping>
>              > > [email-masked]
>             <mailto:[email-masked]> for questions on
>             current sip Use
>              > > [email-masked] <mailto:[email-masked]> for new developments
>             of core SIP
>              > >
>              >
>              > Sipping mailing list  
>             https://www1.ietf.org/mailman/listinfo/sipping
>              > Use [email-masked]
>             <mailto:[email-masked]> for questions on
>             current
>              > sip Use [email-masked] <mailto:[email-masked]> for new
>             developments of core SIP
>              >
> 
>             Sipping mailing list  
>             https://www1.ietf.org/mailman/listinfo/sipping
>             <https://www1.ietf.org/mailman/listinfo/sipping>
>             Use [email-masked]
>             <mailto:[email-masked]>for questions on
>             current sip
>             Use [email-masked] <mailto:[email-masked]> for new developments
>             of core SIP
> 
> 
>     ------------------------------------------------------------------------
>     This transmission (including any attachments) may contain
>     confidential information, privileged material (including material
>     protected by the solicitor-client or other applicable privileges),
>     or constitute non-public information. Any use of this information by
>     anyone other than the intended recipient is prohibited. If you have
>     received this transmission in error, please immediately reply to the
>     sender and delete this information from your system. Use,
>     dissemination, distribution, or reproduction of this transmission by
>     unintended recipients is not authorized and may be unlawful. 
> 
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other than 
> the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and delete 
> this information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> 
> 
> ------------------------------------------------------------------------
>