OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-if message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency] RE: [emergency-rim] RE: [emergency-if] RE:[emergency-rim] Questions & Observations #1: Don's IF SC Use Cases


Lee-
I agree that the mobility issue will most likely need to be tackled by some sort of profiling.  I don't think there is any way around it.  However I think the profile bit will be mainly on that edge device front, and not on the federation of multiple instances of my nodes (or your nodes) with each other.  Then we shouldn't restrict things down, because we'll end up having to not have live interop without figuring out our profiles ahead of time.  I think the idea of having the flexibility to have hosted lists for value lists, with the opportunity to have some implementation-specific push/poll is really what I'm looking for to make this happen.  Hence the need for just a generic unique string, URL, or custom internal URI.  I like the SMS concept that you have a lot, and it's nice to know there is already a solution out there!  Would be really interesting to patch our capabilities together and see how they could work off of each other's ICS "context"...that could make a real spiffy interop demo!

--Don

Office: 315-838-2669

Cell: 315-383-1197

dmcgarry@mitre.org


From: Lee Tincher [ltincher@evotecinc.com]
Sent: Saturday, April 03, 2010 9:56 AM
To: McGarry, Donald P.; 'Gary Ham'
Cc: rexb@starbourne.com; 'Hans Jespersen'; emergency-if@lists.oasis-open.org; emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
Subject: RE: [emergency] RE: [emergency-rim] RE: [emergency-if] RE: [emergency-rim] Questions & Observations #1: Don's IF SC Use Cases

The strange part about your list is that we accomplish this via
implementation (ICS model as well) - we have mobile tools that automatically
report the command structure and creates SMS groups based on ICS when an
Emergency responder enters a disaster/incident area - this is all routed via
DE.....I agree it could be better - but its beauty (for me) is it's
flexibility and its ease of use - I just wonder if some of the things you
are striving for could be implementation issues.  I also wonder how far we
go with "Profiles" -  a lot of what you desire could be achieved via a more
restrictive profile....

Good string of emails though - I am on board with having these discussions!

Thanks,
Lee

The aim of education should be to teach us rather how to think, than what to
think - rather to improve our minds, so as to enable us to think for
ourselves, than to load the memory with thoughts of other men.  ~Bill
Beattie

-----Original Message-----
From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: Friday, April 02, 2010 11:59 PM
To: Gary Ham; Lee Tincher
Cc: <rexb@starbourne.com>; Hans Jespersen;
<emergency-if@lists.oasis-open.org>; <emergency-rim@lists.oasis-open.org>;
<emergency@lists.oasis-open.org>
Subject: RE: [emergency] RE: [emergency-rim] RE: [emergency-if] RE:
[emergency-rim] Questions & Observations #1: Don's IF SC Use Cases

Lee/Gary/Others:  My apologies....That did not come out as it was
represented in my head as intended in the email.  My point was not to say
that folks were not using it at all, nor to say that it was only for point
to point non-redistribution.  I was speaking more of the "advanced" routing
component that Dave is speaking of.  Bottom line is I want this thing to
flourish and grow its adoption base beyond where we are now.  I don't think
our concern or focus can be on specific large-scale systems with
requirements without technical details to support their needed requirements.

My use case is this:
1. Field paramedic sends a message to an exposure system with his sender
role and keywords describing message content, which includes multiple
payloads.  Field paramedic doesn't know the state of the command structure
for multiple reasons: bandwidth of always pushing around the state of
command; changing people in roles; explicit addressing locks down adding
unintended producers / consumers of data, which is bad in some cases.
2. Message system routes and exposes data based on current state of ICS /
command model.   This is based on predefined valuelists for terminology,
roles, and keywords that can hosted at destination URI's, but can also be
pushed to endpoint nodes; the <string> only represents a structured RESTful
or other URI that gives context to a unique name.  However a URI gives you
the ability to pull this data later if needed.
3. Data gets to intended folks.

System Requirements:
1. Easy / clear to implement
2. Lightweight processing footprint
3. Can be carried on low bandwidth / intermittent connections
4. Implementable by local government
5. Ability to use own terminology
6. Does not require "custom" hardware/software solutions - (i.e. COTS
product where I can just install it and use it)
7. Ability to report unit information, situational information, hospital
status, emergency patient information
8. Ability to carry field sensor data
9. Ability to describe information carried in multiple payloads without
inspecting the data itself
10. Only need to use the sender information and keywords to send the
message.  Field paramedics don't need to know what explicitaddresses to send
to.  That's for the messaging infrastructure to figure out.
11. Ability to host / poll lists of data terminology used in value lists in
a standard way; not required for all DE implementations, but an option
chosen by this one.

Basic Architecture drilldown:
1. Field provider's edge device wraps up content objects with
contentkeywords.  Keywords may be copied to DE Keywords header.  This is
then wrapped in DE with various sender roles filled in from a managed list
for their sender roles...i.e. paramedic mcgarry, gbac 2, ALS ambulance,
treatment sector officer, etc.
2. Message published to RESTful web service.  Message transport changed to
async pub/sub or push.  Message transitioned to routing service.  All async
cross-machine operations are mediated through DTC's.
3. Routing service ingests message, preforms xpath queries on DE header.  If
keywords are marked for internal processing, redistributes to multiple
services.  Messages can also be passed to other DE ingestors.
4. Service operations include caching for archival, querying of model to
determine exposure/delivery, querying of weighted tree for detail level
exposure determination, translation of content formats to vis formats
(GeoRSS/KML,etc),etc.
5. Processed / transformed content objects pass around the infrastructure
via the routing service, which can be dynamically updated with explicit
rules, however the goal of this research is to leave the heavy lifting up to
the standard models, because I think we can easily become rapidly bogged
down with explicit routing rules at the operational level.

The analytic basis for making a routing sub-element has value.  Separate
this obvious point of contention so those folks that want to build a large
grid system would have an area to focus their development and theoretical
efforts, and those of us who want to build "lesser" systems can just move
on.  I'm advocating for leaving the flexibility in, while adding clarifying
documentation on its use.  You are advocating to lock down this part of the
standard without presenting clear technical evidence that a URN is necessary
as opposed to any unique string that can hold contextual information (which
could be a URI).  Since you are advocating for a more restrictive case I
think you should have to really prove your case as well.  I'll be happy to
elaborate on any of the above to make mine.  I'll also be more than happy to
share all my library source code and point folks to a real implementation of
this on the public internet once my new server goes up on the DMZ in the
next month and my code clears public release.  My thoughts on moving the
routing information to a sub-element would be to lighten up the root de
element, add a generic valuelist component that DE-light systems can use,
and allow the hardcore routing folks to keep their routing component locked
down to URN only.  As a member of this TC I would like to see the use cases
and architectural requirements that would drive a URN-only solution in DE
2.0.

As an OASIS TC member are you suggesting that I just go use other non-EDXL
standards in lieu of using the DE?  An unfortunate truth here is that we
require that all our other standards be carried in the DE.  UCORE doesn't
provide a standard mechanism to represent roles, and is much too large to
have a lightweight XML processor, and can't make it over low bandwidth
links.  UICDS from my impression isn't a standard.  It's a redistribution
model comparable to a controlled UDP broadcast that it web based.  That
doesn't provide any extendibility to do model based routing / exposure based
on command structure.

I don't really think the whole <string> thing in the ValueListURN element is
an inconsistency.  It's in the documentation and the schema.  A URL is used
in the first example.  That seems pretty consistent to me.

1. If you want this process to be requirements driven where are your
requirements?
2. I will consider any routing architecture brought to the table.  It needs
to be an architecture though.
3. Once again, please don't minimize my implementation because it's not
yours or doesn't fit into your vision for how pub/sub will "scale" for
SOA...My project is trying to deliver the interoperability vision to
day-to-day boots on the ground First Responders (as are a lot of others
here); a large scale model doesn't apply to this application.
"The primary purpose of the Distribution Element is to facilitate the
routing of any properly formatted XML emergency message to recipients. The
Distribution Element may be thought of as a "container". It provides the
information to route "payload" message sets (such as Alerts or Resource
Messages), by including key routing information such as distribution type,
geography, incident, and sender/recipient IDs."

That's from the DE spec.  That's our requirements.  In fact in the
requirements for Design section of the spec there is no mention of specific
system implementations, non-repudiation, secure policy oriented routing,
etc.  On my side there's no talk of command models, low bandwidth links,
edge devices, CAD systems, etc.  These are implementation issues.  There is
however a lot of talk about business process driven flexibility for
terminology, interoperable exchanging of various payloads, and an open
container model.  I'm more than willing to play ball on coming to a
compromise about this routing stuff, but outside of your personal take on
what the DE is, we don't have any solid technical requirements or
architectural comments to support your needs.


-Don
Office: 315-838-2669
Cell: 315-383-1197
dmcgarry@mitre.org


-----Original Message-----
From: Gary Ham [mailto:gham@grandpaham.com]
Sent: Friday, April 02, 2010 8:32 PM
To: Lee Tincher
Cc: McGarry, Donald P.; <rexb@starbourne.com>; Hans Jespersen;
<emergency-if@lists.oasis-open.org>; <emergency-rim@lists.oasis-open.org>;
<emergency@lists.oasis-open.org>
Subject: Re: [emergency] RE: [emergency-rim] RE: [emergency-if] RE:
[emergency-rim] Questions & Observations #1: Don's IF SC Use Cases

Not to mention the TEP interoperability work going on this month. De
wrapping - multiple applications. And (of course since it is me
writing this) the expanded capability of dm-open 2.0 when it comes
availabe.

Sent from my iPhone

On Apr 2, 2010, at 7:08 PM, "Lee Tincher" <ltincher@evotecinc.com>
wrote:

> Don,
>
> I respectfully disagree on one point in this...not only does DNDO
> use the DE
> for virtually every message exchange - I personally have it as the
> main
> focus of our commercial product that does a whole lot more than
> point to
> point exchanges...I even use it to carry multiple CAP messages as
> payloads
> for routing distribution down the pipe...it carries HAVE and SiTRep
> reports
> as well as Justice defined NIEM IEP's...I rely heavily on it as do
> all of
> the recipient and "re-distributors" that use our product....
>
> Thanks,
> Lee
>
> The aim of education should be to teach us rather how to think, than
> what to
> think - rather to improve our minds, so as to enable us to think for
> ourselves, than to load the memory with thoughts of other men.  ~Bill
> Beattie
>
>
> -----Original Message-----
> From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
> Sent: Friday, April 02, 2010 4:11 PM
> To: rexb@starbourne.com; Hans Jespersen
> Cc: Gary Ham; emergency-if@lists.oasis-open.org;
> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
> Subject: [emergency-rim] RE: [emergency-if] RE: [emergency-rim]
> Questions &
> Observations #1: Don's IF SC Use Cases
>
> All-
> 1. My feeling is that if it doesn't stand the test of time we can
> change it.
> Frankly I don't see how changing one character in the name of one
> element
> will cause any harm.  In fact we really aren't changing anything
> outside the
> name since once again I point out it is typed as <string>.  I still
> like my
> idea of moving all of the URN stuff into a routing sub-element and
> putting a
> generic ValueList component in the root.
> 2. Our method for people not mucking it up now seems to be no one
> using it
> at all, beyond just passing point to point data.  I'd rather have
> people
> start using it and have them grow with the standard rather that have
> the
> "perfect standard" that is so theoretically wonderful that no one
> uses it.
> 3. I fail to see how preforming an unintended DoS attack on an
> improperly
> tuned webserver applies to this, but point taken that people can and
> will
> mess anything up.
> 4. I'm still waiting for what "should" be a simple answer to my
> questions...What does limiting our spec to a URN buy us?  If it was so
> important why was it completely overlooked in 1.0?  What is the
> architecture
> that disproves a unique string (which could be a URI) can't do the
> same job.
>
> If we are willing to agree to compromise and move on, so be it.  I
> would
> suggest that given this outcome, that all non-constructive criticism
> also go
> with it.  As a researcher who's completing my dissertation in this
> stuff I'm
> more than happy to accommodate anyone who can present legitimate
> technical
> contributions that will point out oversights in my (or any other OASIS
> member's) product or work.  However, opinion, undocumented claims,
> etc. are
> starting to wear very thin and are without merit.  I'm sure I speak
> for many
> folks on these committees when I ask that that comments, opinions, and
> criticisms be brought out only when there is solid technical
> evidence to
> support the counterpoint.  I think this is in both the true spirit of
> industry, academia, and general to overall productivity.
>
> -Don
> Office: 315-838-2669
> Cell: 315-383-1197
> dmcgarry@mitre.org
>
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Friday, April 02, 2010 2:31 PM
> To: Hans Jespersen
> Cc: Gary Ham; McGarry, Donald P.; emergency-if@lists.oasis-open.org;
> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
> Subject: Re: [emergency-if] RE: [emergency-rim] Questions &
> Observations #1:
> Don's IF SC Use Cases
>
> My intention to reply in depth to Don's post has managed to get pushed
> farther and farther down my priority list, especially since Gary's
> proposed compromise, which I indicated I could live with, and today
> has
> been particularly difficult in that regard, so I must, in essence,
> throw
> in the towel with a couple of comments only.
>
> While I can live with Gary's compromise, I don't think it will stand
> the
> test of time, but we'll see about that. That's just my opinion. Having
> weighed the opposition, I decided that fighting it didn't make sense
> and
> was wasting precious time. I don't like it, but that's happened before
> and it hasn't proved fatal to me personally, and not as far as I
> know to
> anyone else, yet.
>
> The problem with the compromise is that no matter how well we caveat
> it,
> people will find a way to muck it up. Hopefully we can catch as much
> of
> that as possible in testing. Case in point, when we initially finished
> CAP one of our three letter agencies decided to use it and promptly
> caused its network to crash because so many of their systems went out
> over the web at the same time to get the schema and validate it. I
> would
> never have guessed that folks with that much experience and
> intelligence
> would not actually cache the schema locally, but they didn't.
>
> Stuff happens.
>
> I will ask that we carefully and accurately document our requirements
> and our caveats. I think it would be especially helpful if we
> carefully
> delineate where users can safely use <explicitAddress>. Where URNs are
> required for policy, we will need to ask that those networks make that
> clear so that we minimize inadvertent mismatches.
>
> Cheers,
> Rex
>
> Hans Jespersen wrote:
>> Comments inline denoted [hj]
>>
>> -hans
>>
>> -----Original Message-----
>> From: Gary Ham [mailto:gham@grandpaham.com]
>> Sent: Wednesday, March 31, 2010 8:56 AM
>> To: McGarry, Donald P.
>> Cc: rexb@starbourne.com; emergency-if@lists.oasis-open.org;
>> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
>> Subject: Re: [emergency-if] RE: [emergency-rim] Questions &
>> Observations
>> #1: Don's IF SC Use Cases
>>
>> Sounds to me like network rules related to ValueList elements
>> 1. Parse them.
>>
>> [hj]or not as the case may be. Not every ValueList element MUST be
>> used
>> by every DE implementation.
>>
>> 2. If your network does not find a URN it needs for distribution,
>> refuse
>> it, or do not redistribute.
>>
>> [hj] or add one so that downstream nodes know more about the
>> message and
>> can treat it accordingly.
>>
>> 3. Any URI would be acceptable in the schema, but only those with
>> formal
>> URNs might be used on some networks.
>>
>> [hj] Seems fine to me as long as everyone understands that any URI
>> can
>> be in these fields and they should not fail to parse, choke, or drop
>> messages if it's a URN and not a URL (i.e the opposite of #2 should
>> not
>> happen).
>>
>> Adds the need to parse to all push redistributors.   But it would
>> seem
>> to me that they would need to do that anyway.
>>
>> The rules need to be put into the DE documentation so that it is not
>> ambiguous. I.e,"Warning: If you do not use a formal URN, some of the
>> more security conscious networks will not be able to use your
>> document."
>> But you can use other URI's for categorization, filtering, etc.
>> Seems to be a reasonable compromise to me.
>>
>>
>> R/s
>>
>> Gary
>>
>>
>> On Mar 31, 2010, at 11:42 AM, McGarry, Donald P. wrote:
>>
>>
>>> Rex-
>>> Agree with your in-band / out-of-band assessment; however I think we
>>>
>> are getting to bogged down in some implementation details...
>>
>>> 1. Proponents of the URN feel that it is required to adequately
>>>
>> extract authority context from its structure to do secure routing.
>>
>>> 2. Proponents of the URI feel that:
>>>     a. URIs/URNs/URLs are just structured strings.  Although URNs
>>>
>> imply a unique name; newer principles of REST state that URLs (or
>> more
>> generally URIs) also can act unique names for resources - including a
>> name of a list
>>
>>>     b. Although URNs can be registered at an authoritative source
>>>
>> (IANA or your own infrastructure), at some point someone needs to
>> go and
>> verify that unique    name from the authoritative source.  This can
>> be
>> done in-band, out-of-band, or periodically; but it still has to be
>> done
>> and has a host of security issues, not completely dis-similar from
>> verifying a certificate chain in a registered uri/url
>>
>>>     c. If you want to add a dynamic component to your lists; URNs
>>>
>> require that you have a custom URN resolution software to resolve the
>> URN to a location to pull the list from; If you do an out of band
>> push,
>> you still need to resolve /authorize the entity pushing the update.
>> Again, not completely dis-similar from pulling list data from a url
>> location and authenticating the server through CAS
>>
>>> 3. The valuelist concept is about flexibility.  Everytime we want to
>>>
>> allow implementers to use their own terminology we plug this thing
>> in.
>> That's to provide flexibility.
>>
>>> 4. The DE is about distributing data.
>>> 5. Since the purpose of the URN/URI is to identify the referenced
>>> list
>>>
>> and the authority context associated with it in a "secure" system, if
>> you only want to work with URN's drop the message when you the first
>> characters != 'urn'...You need to parse the string anyway...if
>> there are
>> no 'urn' identified list in the DE...then your system shouldn't be
>> getting it anyway...
>>
>>> I think pushing this back to the subcommittee is a bad idea.  To
>>> date,
>>>
>> we've been discussing this over and over, yet there exists no
>> architecture diagram coupled with a use case to refute this point.
>> If
>> this was so important in the DE 1.0, why was it typed as <string>?  I
>> don't think we should have to hold back the DE 2.0 to further
>> "discuss"
>> this.  Given the perceived "importance" of this structure I would
>> think
>> that there could be a clear use case and architecture to support the
>> claims of the URN camp available now.  I think that we are continuing
>> down the path we have already been down and that we'll end up in the
>> same spot that we are at right now next quarter if we don't change
>> our
>> approach to this.
>>
>>> -Don
>>> Office: 315-838-2669
>>> Cell: 315-383-1197
>>> dmcgarry@mitre.org
>>>
>>> -----Original Message-----
>>> From: Rex Brooks [mailto:rexb@starbourne.com]
>>> Sent: Wednesday, March 31, 2010 10:32 AM
>>> To: emergency-if@lists.oasis-open.org;
>>>
>> emergency-rim@lists.oasis-open.org
>>
>>> Subject: [emergency-rim] Questions & Observations #1: Don's IF SC
>>> Use
>>>
>> Cases
>>
>>> Hi Everyone,
>>>
>>> Don McGarry produced a pdf of a set of Visio files as Use Cases and
>>>
>> uploaded them 2 March 2010.
>>
>>>
>> http://www.oasis-open.org/apps/org/workgroup/emergency-if/download.php/3
>> 6650/Visio-DE_IF_Use_Cases_v1.vsd.pdf
>>
>>> I happened to be out of pocket at the NCOIC March Plenary at the
>>> time
>>>
>> and didn't notice this until it was pointed out to me yesterday in a
>> call with Dave Ellis. If I had been here I would certainly have
>> asked a
>> number of questions and made a few observations about these
>> diagrammatic
>> illustrations. However, I found myself at a loss when asked how I
>> could
>> support something I had never seen, to which I said I couldn't and it
>> was at this point that Dave pointed me to this file.
>>
>>> So this sets up an interesting set of disconnects for me wrt how I
>>>
>> want to respond to this as it relates to the ValueListURx
>> discussions in
>> both the Infrastructure Framework and the Reference Information Model
>> SCs. I assume we all know what ASSUME stands for? All puns intended.
>>
>>> Now, it looks to me like we have had dueling assumptions, and both
>>>
>> sets of assumptions appear to have been asserted and defended without
>> giving the opposing set of assumptions the benefit of the doubt, and
>> both have been argued out of context, in my opinion.
>>
>>> For now, in this particular message, I'm going to stick with just
>>>
>> asking my questions about this set of Use Cases. I will be
>> composing and
>> sending out a couple or a few more messages where I hope to focus on
>> different specific aspects of this discussion.
>>
>>> I will give them separate Subject Lines so, hopefully, we can
>>> harvest
>>>
>> any further discussions more easily. I've tried this before and it
>> usually breaks down because people ignore Subject Lines which would
>> otherwise serve to collect related discussions in an easily
>> referenced
>> way and react only to specific comments within a message. I don't
>> expect
>> this to be any different, but I keep trying in the hope that one fine
>> day, it will "take."
>>
>>> Question #1: What list is it that the user wants to update?
>>>
>>> This makes an incredible difference since, (in my opinion) IF it
>>>
>> relates to the user's social structure; e.g. a change in the
>> permissions
>>
>>> (policy) assigned to a given role (job description and title) for a
>>>
>> position in Mitre or OASIS or Foo or Bar or The Dept of Redundancy
>> Dept;
>> THEN (In my opinion and in any repeatable Service Oriented pattern I
>> work on) it definitely should not be submitted to the List Server
>> or the
>> Https Server or the Router through any external network In-Band.
>>
>>> My opinion (with the understanding that this Infrastructure is only
>>>
>> now beginning to be implemented):
>>
>>> It should be submitted through the social structure's duly
>>> authorized
>>>
>> method to a Third Party Registry (possibly a public-private shared
>>
>>> resource) or Broker Service where it can be separately validated,
>>>
>> authorized and authenticated before being propagated to the network
>> routers where it would be updated system-wide just like DNS. I could
>> argue that no significant change should be submitted In-Band, but I
>> think that for the next few years we can probably allow simple
>> changes
>> in the kind of ValueLists which are aimed solely to document a given
>> jurisdiction's facilities, terminologies and equipment names to
>> simply
>> be published separately and shared among the partners with whom the
>> jurisdiction has mutual aid or other service level agreements. I
>> would
>> envision those lists being shared by municipalities and counties in
>> shared DBs once we educate them to the value of such datasharing.
>>
>>> I recognize that this seems like a more heavyweight process than may
>>>
>> seem needed, but I think that there is more than sufficient need for
>> verifiable security, financial liability assurance, audit trails and
>> confidence, as well as scalability. Once it is done a few times, we
>> can
>> learn how to streamline the process, and once in place, maintenance
>> should be much easier than most people think. However, it does
>> require
>> practice and making that maintenance a regular SOP. We need to set up
>>
>>> 24/7 365 testbeds anyway, so this should help take the sting out of
>>>
>> the learning curve, especially if we can use students to do the
>> initial
>> documentation.
>>
>>> Cheers,
>>> Rex
>>>
>>>
>>>
>>> --
>>> Rex Brooks
>>> President, CEO
>>> Starbourne Communications Design
>>> GeoAddress: 1361-A Addison
>>> Berkeley, CA 94702
>>> Tel: 510-898-0670
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>
>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>>
>>
>> Gary Ham
>> http://grandpaham.com
>> 703-899-6241
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/
>> my_workgroups.php
>>
>>
>>
>>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]