AppEphemeral struct and description is inconsistent

[franziskuskiefer]

Unless I misunderstand something here, the text and proposal struct don't work together here.

The text first says

mls-extensions/draft-ietf-mls-extensions.md

Lines 549 to 550 in 099b42e

	The content of an AppEphemeral proposal is the same as an `app_data_dictionary`
	extension. The proposal type is set in {{iana-considerations}}.

but then defines the proposal as

mls-extensions/draft-ietf-mls-extensions.md

Lines 553 to 556 in 099b42e

	struct {
	ComponentID component_id;
	opaque data<V>;
	} AppEphemeral;

It then goes on to talk about ComponentData and app_data_dictionary.

mls-extensions/draft-ietf-mls-extensions.md

Lines 559 to 562 in 099b42e

	An AppEphemeral proposal is invalid if it contains a `component_id` that is
	unknown to the application, or if the `app_data_dictionary` field contains any
	`ComponentData` entry whose `data` field is considered invalid by the
	application logic registered to the indicated `component_id`.

Is the intention that

1. the proposal really is equivalent to the AppDataDictionary struct? Then the AppEphemeral struct needs to be changed to this.
2. or is the AppEphemeral struct correct, and the text should get updated?

Either would be fine, but option 2 makes more sense to me.

[raphaelrobert]

Can you please file a PR for this?

[rohanmahy]

As I recall, it made more sense to have multiple AppEphemeral Proposals, one per component, since this isn't keeping state like GC, GI, KP, or LN "extensions". I'll take this one and write a short PR to update the text.

[franziskuskiefer]

Thanks (sorry I didn't get around to it yet). Happy to review.

[rohanmahy]

OK, I submitted PR #82 just now.

The text in the draft still requires that every client understands any component present in AppEphemeral (not a change). If not you could send total garbage and clients that understand wouldn't be able to reject it.