[Issue 12] Explaining "profile" concept

["Wachob, Gabe" <gwachob@visa.com>]

Its become clear that this concept (that Mike has referred to already at [1]) is causing some confusion.

The intent for the concept of "profile" (and this is a bad name, we need to think of another) is that some features expressed in syntactical structures are interesting to some applications or users but not all users and applications. Furthermore, for some of these features, they can be safely ignored by the common infrastructure supporting the wide interoperability of identifiers (which is primarily the resolution infrastructure). 

Thus, it would be a big win if some features could be declared in a way that infrastructure (resolvers, parsers, etc) could safely ignore the syntactic structures corresponding to the feature in question. Such features would then exist as a "profile" (which is a bad term). This means, in part, that *implementation* of code which treats these syntactic structures specially would be *optional*. System components would still function (albeit with dimished semantic functionality) even if they didn't understand all the structure and semantics of identifiers using the "profiled" features. 

An example would be helpful. Lets say we could declare "versioning" as a "profiled" (optional?) feature. This means that the stuff in between [] (using our current versioning proposal) would have no special meaning to components that didn't care about versioning. In this case, the versioning part of the identifier would simply be more characters. 

Take the example XRI xri://xrifoo.org/charter[:1.2]

To a component that understood versioining, it would parse this into (xrifoo.org, charter, [:1.2]) components. That component would understand that we are referring to a version of a resource and may want to attempt behavior that only makes sense with a versioned resource (like retrieving previous versions) 

A version-ignorant component, on the other hand, would parse this into (xrifoo.org, charter[:1.2]) and would not understand any relationship to other resources which may be different "versions" of the same thing. This sort of behavior is entirely reasonable for resolvers, for example, who are unconcerned with anything but the naming authority part (xrifoo.org).

Other candidates for "profiling" (again, yechy term) are any sort of specification which structures the stuff to the right of the 3rd '/' (ie the "local part" of the XRI). By definition, this stuff doesn't affect resolution. You could have profiles wihch *restrict* or *give special meaning* to otherwise legal naming authority identifiers, etc. 

To be clear, by saying "non-core" Mike doesn't neccesarily mean "not in the adressing and resolution spec", but rather he means "defined as a 'profile' - something which needs only to be optionally implemented in components". 

	-Gabe


[1] http://lists.oasis-open.org/archives/xri/200304/msg00036.html