On Windows Phone the permission required to access NFC is ID_CAP_PROXIMITY.
The ID_REQ_NFC restricts the application to running on only devices that
have NFC.
This would be equivalent to setting android:required to true for a feature
<uses-feature android:name="android.hardware.nfc"
android:required="true" />
AFAIK android:required="true" only effects Google Play listings.
Plugman should set the features and permissions. I think adding hardware
restrictions is a decision that needs to be made by the app developer.
On Wed, Apr 17, 2013 at 3:41 PM, Jesse <purplecabb...@gmail.com> wrote:
> I could, or it could just be an ignored tag for other platforms. It will
> sit inside the platform tag anyway.
> could also just add an optional attrib to the permission tag :
> <permission type='requirement' name='ID_REQ_NFC' />
>
> The names already do contain enough info to easily parse, ID_CAP_* ID_REQ_*
> not to mention ID_RESOLUTION_*
>
> I am down with whatever.
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Apr 17, 2013 at 12:24 PM, Filip Maj <f...@adobe.com> wrote:
>
> > Hmm, this could be an implementation detail for windows phone.
> >
> > Requirement vs permission isn't syntactically different. Could we
> > encapsulate Windows Phone requirements as <permission> elements in
> > plugin.xml, and have tooling be smart enough to parse wp7 + wp8
> <platform>
> > <permission> elements and drop them into the Windows Phone manifest as
> > whatever elements they need to be?
> >
> > On 4/17/13 12:16 PM, "Jesse" <purplecabb...@gmail.com> wrote:
> >
> > >While we are there, we may want to add an optional requirements tag.
> > >Requirements let the app specify what device features it must have, for
> > >example NFC. [1]
> > >Logically this would just fall right under platform, and be optional :
> > >
> > > <platform name="wp8">
> > > <requirement name="ID_REQ_NFC" />
> > > </platform>
> > >
> > >Does it make sense for us to group these?
> > >ie.
> > >
> > ><platform>
> > > <permissions>
> > > <permission/>
> > > ...
> > > </permissions>
> > > <requirements>
> > > <requirement/>
> > > ...
> > > </requirements>
> > ></platform>
> > >
> > >
> > >
> > >
> > >[1]
> > >
> >
> http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/04/17/defining
> > >-your-app-s-requirements-for-a-great-customer-experience.aspx
> > >
> > >
> > >
> > >@purplecabbage
> > >risingj.com
> > >
> > >
> > >On Wed, Apr 17, 2013 at 12:04 PM, Filip Maj <f...@adobe.com> wrote:
> > >
> > >> Good call, sound rule of thumb
> > >>
> > >> On 4/17/13 12:03 PM, "Jesse" <purplecabb...@gmail.com> wrote:
> > >>
> > >> >RE: the permission element
> > >> >Looks good for wp7 + wp8
> > >> >I assume if some platform requires extra data in the permission tag
> it
> > >>can
> > >> >have it, the same way that the blackberry version has the system
> > >> >attribute.
> > >> >
> > >> >@purplecabbage
> > >> >risingj.com
> > >> >
> > >> >
> > >> >On Wed, Apr 17, 2013 at 11:48 AM, Jeffrey Heifetz
> > >> ><jheif...@blackberry.com>wrote:
> > >> >
> > >> >> Makes sense to me.
> > >> >>
> > >> >> Sent from my BlackBerry 10 smartphone on the Rogers network.
> > >> >> From: Filip Maj
> > >> >> Sent: Wednesday, April 17, 2013 2:43 PM
> > >> >> To: dev@cordova.apache.org
> > >> >> Reply To: dev@cordova.apache.org
> > >> >> Subject: Re: plugman + plugin spec final q's
> > >> >>
> > >> >>
> > >> >> K one more update: <permission> element that will be a child of
> > >> >><platform>
> > >> >> elements.
> > >> >>
> > >> >> Examples:
> > >> >> <platform name="android">
> > >> >> <permission name="android.permission.INTERNET" />
> > >> >> </platform>
> > >> >> <platform name="blackberry">
> > >> >> <permission name="_sys_use_consumer_push" system="true" />
> > >> >> </platform>
> > >> >> <platform name="wp7">
> > >> >> <permission name="ID_CAP_CONTACTS" />
> > >> >> </platform>
> > >> >>
> > >> >>
> > >> >> `name` attribute is mandatory, mapping to native strings
> representing
> > >> >> specific features/permissions.
> > >> >>
> > >> >> `system` attribute is optional and false by default. Only used by
> > >> >> BlackBerry for certain system-level permissions.
> > >> >>
> > >> >> I think this satisfies our use cases.
> > >> >>
> > >> >> Thoughts/comments welcome.
> > >> >>
> > >> >>
> > >> >>
> > >> >> On 4/17/13 11:07 AM, "Jeffrey Heifetz" <jheif...@blackberry.com>
> > >>wrote:
> > >> >>
> > >> >> >I was thinking exactly along the same lines as Braden. Whatever
> > >> >>universe
> > >> >> >the cordova core plugins live in will likely be default, with the
> > >>wild
> > >> >> >west following it. SO long as plugman is explicit about where it
> is
> > >> >> >fetching from, a dev shouldn't have to find the URL and hope it
> > >>never
> > >> >> >changes.
> > >> >> >
> > >> >> >On 13-04-17 2:01 PM, "Braden Shepherdson" <bra...@chromium.org>
> > >>wrote:
> > >> >> >
> > >> >> >>I think there will be a common repo, where the Cordova core
> plugins
> > >> >>and
> > >> >> >>some others live. See the spec for the remotes.js file; I think
> it
> > >> >>should
> > >> >> >>search for plugins with the given name in each of those
> universes.
> > >> >> >>Specifying a url in the <dependency> would then only be necessary
> > >>for
> > >> >> >>other
> > >> >> >>universes.
> > >> >> >>
> > >> >> >>Braden
> > >> >> >>
> > >> >> >>
> > >> >> >>On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj <f...@adobe.com>
> wrote:
> > >> >> >>
> > >> >> >>> But then we'd need to be able to discover the different
> > >>universes..
> > >> >> >>>Unless
> > >> >> >>> we all agree on a "default", don't think this is optional..
> > >> >> >>>
> > >> >> >>> On 4/17/13 10:53 AM, "Jeffrey Heifetz" <
> jheif...@blackberry.com>
> > >> >> wrote:
> > >> >> >>>
> > >> >> >>> >Coming back to Braden's suggestion of specifying a url and id
> > >>for
> > >> >> >>>plugin
> > >> >> >>> >dependency, I think this is the correct route, and would go
> > >> >>further to
> > >> >> >>> >suggest the url is optional. I do not believe we should
> > >>inherently
> > >> >>tie
> > >> >> >>> >plugin dependency to the exact source. Thats why we have a
> > >> >>discovery
> > >> >> >>> >system and multiple places to get a plugin from.
> > >> >> >>> >
> > >> >> >>> >On 13-04-17 1:37 PM, "Filip Maj" <f...@adobe.com> wrote:
> > >> >> >>> >
> > >> >> >>> >>Braden and I had a little chat on IRC about install/uninstall
> > >>and
> > >> >> >>>calling
> > >> >> >>> >>prepare. We've agreed that having prepare as a separate
> > >>command is
> > >> >> >>>useful
> > >> >> >>> >>(you tweak some plugin JS files, add more JS files, and want
> > >>that
> > >> >> >>> >>reflected in your app), but also calling prepare
> automatically
> > >> >>after
> > >> >> >>>an
> > >> >> >>> >>install and uninstall makes sense too (otherwise people using
> > >> >>plugman
> > >> >> >>> >>will
> > >> >> >>> >>have to call prepare manually after calling install or
> > >>uninstall).
> > >> >> >>> >>
> > >> >> >>> >>FTR, --prepare composes the cordova_plugins.json object that
> is
> > >> >>read
> > >> >> >>>by
> > >> >> >>> >>cordova.js and handles injecting plugin JS into the app. It
> > >>will
> > >> >>also
> > >> >> >>>be
> > >> >> >>> >>responsible for handling permissions that plugins require and
> > >> >>setting
> > >> >> >>>up
> > >> >> >>> >>platform manifests appropriately based on all installed
> > >>plugins.
> > >> >> >>> >>
> > >> >> >>> >>On 4/17/13 10:25 AM, "Brian LeRoux" <b...@brian.io> wrote:
> > >> >> >>> >>
> > >> >> >>> >>>Braden: you thinking that the config is canonical and then
> > >> >>prepare
> > >> >> >>> >>>quietly
> > >> >> >>> >>>does the right thing based on that?
> > >> >> >>> >>>
> > >> >> >>> >>>(Agree less steps is exactly what we're going for here.)
> > >> >> >>> >>>
> > >> >> >>> >>>
> > >> >> >>> >>>On Wed, Apr 17, 2013 at 10:16 AM, Braden Shepherdson
> > >> >> >>> >>><bra...@chromium.org>wrote:
> > >> >> >>> >>>
> > >> >> >>> >>>> Re: --install calling --prepare: no. It could, though, I
> > >> >>suppose.
> > >> >> >>> >>>>
> > >> >> >>> >>>> Why not have --prepare handle the plugins rather than
> > >> >> >>>install/remove.
> > >> >> >>> >>>>We're
> > >> >> >>> >>>> trying to make less, not more, happen at install time.
> > >>Someday
> > >> >>I
> > >> >> >>>hope
> > >> >> >>> >>>> --install ceases to exist.
> > >> >> >>> >>>>
> > >> >> >>> >>>>
> > >> >> >>> >>>> On Wed, Apr 17, 2013 at 12:59 PM, Filip Maj <
> f...@adobe.com>
> > >> >> wrote:
> > >> >> >>> >>>>
> > >> >> >>> >>>> > Max, yeah, at the top of the plugman readme (in both
> > >>future
> > >> >>and
> > >> >> >>> >>>>master I
> > >> >> >>> >>>> > believe), the usage docs don't specify --install or
> > >> >>--uninstall
> > >> >> >>>as
> > >> >> >>> >>>>an
> > >> >> >>> >>>> > available command, but those commands are referenced
> right
> > >> >>after
> > >> >> >>>the
> > >> >> >>> >>>> usage
> > >> >> >>> >>>> > section. I'd be in favor of using --fetch for the
> > >>RETRIEVAL
> > >> >>of
> > >> >> >>> >>>>plugins,
> > >> >> >>> >>>> > --remove for the removal of plugins from the local
> plugins
> > >> >> >>>cache,
> > >> >> >>> >>>>and
> > >> >> >>> >>>> > --install and --uninstall for the relevant actions.
> > >> >> >>> >>>> >
> > >> >> >>> >>>> > Max, re (2): correct.
> > >> >> >>> >>>> >
> > >> >> >>> >>>> > To Braden's points:
> > >> >> >>> >>>> >
> > >> >> >>> >>>> > - I'm fine with url + name attributes for <dependency>
> > >> >> >>>elements.
> > >> >> >>> >>>>Will
> > >> >> >>> >>>> > update the spec/README shortly.
> > >> >> >>> >>>> > - Re <clobbers> I will add a note about that to the spec
> > >>as
> > >> >> >>>well.
> > >> >> >>> >>>> > - Re parsing package Ids, fair enough.
> > >> >> >>> >>>> > - About "namespacing" iOS source files, this sounds
> like a
> > >> >>good
> > >> >> >>> >>>>idea.
> > >> >> >>> >>>> > This is something that plugman can handle as well, yes?
> > >>That
> > >> >>is,
> > >> >> >>> >>>> > management of the plist and pointing to the right
> > >>location.
> > >> >> >>> >>>> > - Re config munging and permissions. I vote in favor of
> > >> >> >>>removing
> > >> >> >>> >>>>all
> > >> >> >>> >>>> > permissions and re-adding all of them with every change
> in
> > >> >> >>>plugins
> > >> >> >>> >>>>(add
> > >> >> >>> >>>> or
> > >> >> >>> >>>> > remove), with a de-duping pass. Brute force approach but
> > >> >>it'll
> > >> >> >>>work
> > >> >> >>> >>>>and
> > >> >> >>> >>>> is
> > >> >> >>> >>>> > simple. However spec wise we need a separate element for
> > >>this
> > >> >> >>>ya?
> > >> >> >>> >>>> > <permission> or something? Then based on what <platform>
> > >>tag
> > >> >> >>>houses
> > >> >> >>> >>>>a
> > >> >> >>> >>>> > <permissions> tag we can deduce where and how to set up
> > >>the
> > >> >> >>> >>>>appropriate
> > >> >> >>> >>>> > native permissions.
> > >> >> >>> >>>> > - Re the different <*-file> elements. I believe behavior
> > >>in
> > >> >>how
> > >> >> >>> >>>>header
> > >> >> >>> >>>> > and source files are handled on iOS are identical, so
> > >> >> >>>consolidating
> > >> >> >>> >>>>those
> > >> >> >>> >>>> > is an easy simplification. I will update the spec with
> > >>that.
> > >> >> >>>I'll
> > >> >> >>> >>>>leave
> > >> >> >>> >>>> > resource-file in there for now.
> > >> >> >>> >>>> >
> > >> >> >>> >>>> > One more question that came up: does a plugman --install
> > >>call
> > >> >> >>> >>>>implicitly
> > >> >> >>> >>>> > call plugman --prepare ?
> > >> >> >>> >>>> >
> > >> >> >>> >>>> > On 4/17/13 9:31 AM, "Max Woghiren" <m...@chromium.org>
> > >> wrote:
> > >> >> >>> >>>> >
> > >> >> >>> >>>> > >(1) On line 25 of the cordova-plugman readme, is the
> > >>command
> > >> >> >>> >>>>missing
> > >> >> >>> >>>> (ie.
> > >> >> >>> >>>> > >--add or --install or whatever)?
> > >> >> >>> >>>> > >
> > >> >> >>> >>>> > >(2) Though two versions of a plugin are not allowed, I
> > >>just
> > >> >> >>>want to
> > >> >> >>> >>>>make
> > >> >> >>> >>>> > >sure: there will be some kind of detection that it's
> > >>okay if
> > >> >> >>>the
> > >> >> >>> >>>> > >*same*version of a plugin has already been installed
> by a
> > >> >> >>>previous
> > >> >> >>> >>>> > >dependency,
> > >> >> >>> >>>> > >right? (For example, plugins A and B both depend on C
> > >>v1.0,
> > >> >>so
> > >> >> >>> >>>>plugman
> > >> >> >>> >>>> > >will determine that this is okay, whereas if A depends
> > >>on C
> > >> >> >>>v1.0
> > >> >> >>> >>>>and
> > >> >> >>> >>>>B
> > >> >> >>> >>>> > >depends on C v1.1, there'll be an error).
> > >> >> >>> >>>> > >
> > >> >> >>> >>>> > >
> > >> >> >>> >>>> > >On Wed, Apr 17, 2013 at 3:08 AM, Filip Maj
> > >><f...@adobe.com>
> > >> >> >>>wrote:
> > >> >> >>> >>>> > >
> > >> >> >>> >>>> > >> Hey all,
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> I've done a review of the spec and updated it. Check
> it
> > >> >>out
> > >> >> >>>at
> > >> >> >>> >>>>the
> > >> >> >>> >>>> > >>README
> > >> >> >>> >>>> > >> in the plugman repo's future branch [1]. I've added
> the
> > >> >>last
> > >> >> >>>bit
> > >> >> >>> >>>>to
> > >> >> >>> >>>> it:
> > >> >> >>> >>>> > >> <dependencies> and <dependency> elements. Here is an
> > >> >>example:
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> <dependencies>
> > >> >> >>> >>>> > >> <dependency
> > >> >> >>> >>>> > >>
> > >> >> >>>url="http://plugins.cordova.io/com.facebook.plugin/plugin.xml";
> > >> >> >>> />
> > >> >> >>> >>>> > >> <dependency
> > >> >> >>> >>>> > >>
> > >> >> >>>url="http://plugins.phonegap.com/com.adobe.omniture/plugin.xml";
> > >> >> >>> >>>> > >> version="1.0.0" />
> > >> >> >>> >>>> > >> </dependencies>
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> Dependencies are specified by providing a url and
> > >> >>optionally
> > >> >> >>>some
> > >> >> >>> >>>>way
> > >> >> >>> >>>> of
> > >> >> >>> >>>> > >> describing what version of the plugin you want. The
> > >>only
> > >> >> >>> >>>>constraint
> > >> >> >>> >>>> > >> imposed on plugin dependencies right now is only a
> > >>single
> > >> >> >>>version
> > >> >> >>> >>>>of a
> > >> >> >>> >>>> > >> plugin can be installed in an app at the same time. I
> > >> >>think
> > >> >> >>>this
> > >> >> >>> >>>>is
> > >> >> >>> >>>> good
> > >> >> >>> >>>> > >> enough, but wanted to let everyone know and give
> people
> > >> >>time
> > >> >> >>>to
> > >> >> >>> >>>> comment.
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> Also did a bunch of updates/tweaks to the plugin.xml
> > >>spec,
> > >> >> >>>made
> > >> >> >>> >>>> explicit
> > >> >> >>> >>>> > >> some failures (if there are file conflicts, error
> > >>noisily,
> > >> >> >>>that
> > >> >> >>> >>>>kind
> > >> >> >>> >>>> of
> > >> >> >>> >>>> > >> stuff). I have a PluginTooling [2] wiki article up
> > >>where
> > >> >>I am
> > >> >> >>> >>>>doing my
> > >> >> >>> >>>> > >> best to summarize these various reqs/use cases
> floating
> > >> >> >>>around
> > >> >> >>> >>>>the
> > >> >> >>> >>>> list,
> > >> >> >>> >>>> > >> IRC, hangout discussions regarding plugin tooling
> > >> >> >>>development. If
> > >> >> >>> >>>>you
> > >> >> >>> >>>> > >>have
> > >> >> >>> >>>> > >> anything to add there please do so!
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> Next, I have a few questions came up when I was going
> > >> >>through
> > >> >> >>>the
> > >> >> >>> >>>> spec:
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> - does <clobbers> and <merges> (specified in the JS
> > >>symbol
> > >> >> >>> >>>>mapping
> > >> >> >>> >>>> > >> section of the plugin spec) create the objects on
> > >>window
> > >> >>if
> > >> >> >>>they
> > >> >> >>> >>>>do
> > >> >> >>> >>>> not
> > >> >> >>> >>>> > >> exist? I suppose this is more of a cordova.js
> question
> > >> >>than a
> > >> >> >>> >>>>spec
> > >> >> >>> >>>> > >> question, but that behavior should be explicit in the
> > >> >>spec.
> > >> >> >>> >>>> > >> - native code <source-file> elements have a `target`
> > >> >> >>>attribute
> > >> >> >>> >>>>where
> > >> >> >>> >>>> > >>you
> > >> >> >>> >>>> > >> specify where within the native project the native
> code
> > >> >> >>>should be
> > >> >> >>> >>>> copied
> > >> >> >>> >>>> > >> into. Is this necessary? For Java files, we could
> look
> > >>at
> > >> >>the
> > >> >> >>> >>>>package
> > >> >> >>> >>>> > >> declaration at the top to determine where to put it.
> If
> > >> >>I'm
> > >> >> >>>not
> > >> >> >>> >>>> > >>mistaken,
> > >> >> >>> >>>> > >> on iOS it doesn't matter where within the directory
> > >> >>structure
> > >> >> >>>of
> > >> >> >>> >>>>a
> > >> >> >>> >>>> > >> cordova-ios project you put native code in. What is
> the
> > >> >> >>>situation
> > >> >> >>> >>>>for
> > >> >> >>> >>>> > >>the
> > >> >> >>> >>>> > >> Windows (Phone) platforms, and for cordova-osx?
> > >> >> >>> >>>> > >> - the spec currently only accounts for appending XML
> to
> > >> >> >>>specific
> > >> >> >>> >>>> parts
> > >> >> >>> >>>> > >>of
> > >> >> >>> >>>> > >> XML-based configuration documents. Does anyone
> foresee
> > >>an
> > >> >> >>> >>>>instance
> > >> >> >>> >>>> where
> > >> >> >>> >>>> > >> some manner of native or cordova-specific config
> > >>munging
> > >> >> >>>OTHER
> > >> >> >>> >>>>than
> > >> >> >>> >>>> > >> appending would be necessary? Removal/modification of
> > >> >> >>>existing
> > >> >> >>> >>>> elements?
> > >> >> >>> >>>> > >> - iOS specific: Do we need separate elements for
> > >> >> >>><source-file>,
> > >> >> >>> >>>> > >> <resource-file> and <header-file>? Can we consolidate
> > >>into
> > >> >> >>>one?
> > >> >> >>> >>>>The
> > >> >> >>> >>>> > >> current draft of the spec mentions that this may be
> an
> > >> >> >>> >>>>implementation
> > >> >> >>> >>>> > >> detail.
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> Finally, I have two questions/concerns about the
> > >>command
> > >> >>line
> > >> >> >>> >>>> interface
> > >> >> >>> >>>> > >> for plugman.
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> 1. The --fetch operation seems to need a redundant
> > >> >>--plugin
> > >> >> >>>flag,
> > >> >> >>> >>>>e.g.
> > >> >> >>> >>>> > >> plugman --fetch --plugin <url>. Shouldn't we just axe
> > >> >> >>>--plugin in
> > >> >> >>> >>>>this
> > >> >> >>> >>>> > >> case?
> > >> >> >>> >>>> > >> 2. The API readme mentions --install and --uninstall
> > >>flags
> > >> >> >>>but
> > >> >> >>> >>>>the
> > >> >> >>> >>>> docs
> > >> >> >>> >>>> > >> only show --fetch and --remove. Can we clarify this?
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> Thanks for everyone's input. I feel we're getting
> > >>closer
> > >> >>to
> > >> >> >>> >>>>shipping
> > >> >> >>> >>>> > >>this
> > >> >> >>> >>>> > >> thing!
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >> [1]
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>>
> > >> >> >>> >>>>
> > >> >> >>>
> > >> >>
> > >>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlo
> > >> >> >>> >>>>g
> > >> >> >>> >>>> > ;
> > >> >> >>> >>>> > >>h=
> > >> >> >>> >>>> > >> refs/heads/future
> > >> >> >>> >>>> > >> [2] http://wiki.apache.org/cordova/PluginTooling
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> > >>
> > >> >> >>> >>>> >
> > >> >> >>> >>>> >
> > >> >> >>> >>>>
> > >> >> >>> >>
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>>
> > >>
> >>>---------------------------------------------------------------------
> > >> >> >>> >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.
> > >> >>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> 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.
> > >> >>
> > >>
> > >>
> >
> >
>
