RE: [emergency-if] ValueListURN/URI Proposal

["McGarry, Donald P." <dmcgarry@mitre.org>]

Rex-
I appreciate what you are saying, but that proposition limits my system's use of the DE.  My system shouldn't have to inspect each of the valuelists of the content objects to do routing and exposure.
You did bring up a few points that I would like to bring out:
1. Scalability - this is tossed around a lot.  Pub/sub doesn't scale big naturally.   Your view is that the DE will provide a mechanism for a pub/sub system to scale, which I agree with.  Requiring a URN in one of the list values, has nothing to do with scalability.  If you think I'm wrong...show me an architectural sketch of a system that uses urn's where just any old unique string wouldn't work.
2. Security - Proponents of the URN only solution argue that it is more secure.  Besides doubting that fact, I would like to point out that not every Emergency Management system HAS to be at a DNDO level of security.  Again I make the point that you will have to parse that string one way or another at your router.  Right now it is just a string, so you have to parse it anyway...Once again show me a system diagram of what requires URN versus unique string.

If you are the super-secure system just copy paste this code:

if (!ValueListURN.StartsWith("URN", true, new System.Globalization.CultureInfo("en-us")))
DropMessage();

My point is that I can hand-draw the 10,000 foot view of my system on my whiteboard and snap a picture with it to email out which makes my case for what I want to do.  I made a lame attempt at putting together those visio things (which was about 15min of effort) to make my case, but I've gotten no solid technical evidence to support the claims of the URN camp.  I understand the technical issues thoroughly that are made as claims for a URN only solution, however the idea that these technical issues dictate a URN-only solution just aren't there.


I'll propose a different solution:
1.
Move the following into its own "routing" sub-element of the DE which would be optional: - this would allow the super-secret routing systems to go right here for all their goods.  The rest of us could just ignore this structure when we parse the DOM.
Senderrole
Recipientrole
Keyword
Distributionreference
explicitaddress

2.
Add a generic structure in the root DE element that would allow me to:
Have a unique name (String)
Have values for that (String)
Specify What I'm talking about (String)

This solution:
1. Would allow us lesser folks to do all the stuff in the routing sub-element on a small scale.
2. Wouldn't increase the size of the root de element (actually it would reduce it).  
3. Still allow the URN camp to lock down the routing portion of the DE

One other alternative is just leave it as a string, the way the 1.0 committee had it.  Ironically the first example in the DE 1.0 document uses a URL in the ValueListURN item.  I'll just plug whatever I want in there and be done with it.  Then we'll have a bunch of super-brittle systems out there.  That will really help those of us actually building systems for First Responders.

-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 2:29 PM
To: emergency-if@lists.oasis-open.org; emergency-rim@lists.oasis-open.org
Subject: [emergency-if] ValueListURN/URI Proposal

Hi Everyone,

I won't have time to go into the details due to some unexpected tasks reviewing the SOA End-to-End-Resource-Planning specifications, but I want to at least get the basic proposal out today.

I propose we specify the ValueListURN specifically for EDXL-DE so that policy-and-content-based routing can be robustly supported with the kind of scalability and security required for national and state level confidence and reliability. I don't have the time to get into the details of why this is necessary. I will return to this with more specific requirements.

I also propose we specify a new element, the ValueListURI which can take a URL for EDXL-RM, HAVE, SitRep and TEP terminological disambiguation and ease of reference where it will not choke distribution because the ValueListURIs apply within the content of the message and need not be parsed for distribution.

I will stop at this point with a word about requirements. I intend to specify Use-Cases for each of these elements and to derive requirements from those Use Cases, including the one currently being developed for the ValueListURN in the RIM SC. I think we need to be rigorous about requirements and Use Cases. This is something that needs to be discussed in more detail as well.

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