emergency-if — archive

[Rex Brooks]

Thanks Don, I think that it will be easier to reference later if I include my response to this in a message which I was planning to send out later anyway. It will have the Subject Line: ValueListURN/URI Proposal. However, since I'm in another meeting, it may be a while before I can get it out. So I will say this much in this message, I think that we need both and I agree flexibility is key. What is needed is a way to consensus. One camp saying it isn't convinced or doesn't think that the other camp has made its point doesn't mean that consensus has been reached. I think that being rigorous about establishing requirements in a formal, accountable representation will be a help, will keep us on track and I don't think that there is any acceptable alternative to that. Yet I also think that we are actually on the verge of having an acceptable resolution that allows both as needed whether that need is in the perception of the user or not. However, I will discuss that in the proposal message. Sorry to be a tease, but I have another discussion going on in my ear and I have to pay attention to it now. More later, Rex 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