Typed Spans: Create RFC from current WIP proposal.

[z1c0]

Since the "work in progress" folder is about to get removed from the repository (open-telemetry/opentelemetry-specification#225), the proposal concerning "typed spans" will be moved from there into the RFC repo.

See original discussion: open-telemetry/opentelemetry-specification#14

[yurishkuro]

I would really like to see an actual proposal of the API for doing this. Especially if it was already POCed in Node, what's preventing it from becoming a part of this RFC? Without the API proposal this current document provides little value, since it's not directly usable.

[AloisReitbauer]

Should we make language-specific RFCs? Not all languages support the same capabilities which makes writing specs for APIs a challenge. We can, however, link to the language spec files or should we rather use same pseudo code?

[AloisReitbauer]

Beyond the discussion above we should move these files over. This is just an administrative task rather than any substantial change to the spec. @tedsuo and @bogdandrutu can you please approve.

[lizthegrey]

I think this proposal is missing an important element: declaring which parts of the attribute namespace are "reserved" for typed span data, which are for user attributes, etc. (e.g. can we declare that regardless of the type of the span, that most application data should be, for instance, prefixed with app.[appname].?

[tedsuo]

In subsequent conversations, we've moved from a single span type to composing semantic conventions as a mechanism for recording this information.

As requested, I'm approving this so that we can record it as proposed so that we can move it from the spec repo.

[discostu105]

I believe this PR is a little bit ambiguous as it is. IMHO, it should be split into multiple standalone-pieces:

1. Propose canonical type (with some concrete type-names)
2. Semantic conventions per canonical type (these already exist, but maybe could use some refinements, better documenation, connection to concrete canonical types)
3. Actual typed span APIs to help create spans that with proper attributes, that match semantic conventions for specific types.
4. Fix "component" field inconsistency, because it partially overlaps with the "canonical type"
   • For HTTP, the definition is component:http, whereas for Database component:<name-of-db)
   • could also be part of 1.

[z1c0]

Closing this PR after some discussion.

• We probably won't need a canonical type (we will check presence of attributes and apply a fixed resolution for multiple type spans, e.g. DB wins over HTTP).
• Semantic conventions are discussed separately in the Data Formats meeting.
• We should make a new OTEP/push for typed span APIs.