Subscription Identifier overwriting rule

[Takatoshi Kondo <redboltz@gmail.com>]

Hi,

According to the MQTT v5.0 spec,
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901170

> 3.8.4 SUBSCRIBE Actions
>
> The Subscription Identifiers are part of the Session State in the Server and are returned to the Client receiving a matching PUBLISH packet. They are removed from the Serverâs Session State when the Server receives an UNSUBSCRIBE packet, when the Server receives a SUBSCRIBE packet from the Client for the same Topic Filter but with a different Subscription Identifier or with no Subscription Identifier, or when the Server sends Session Present 0 in a CONNACK packet.

Consider the following scenario:

1.SUBSCRIBE a/topic1 Subscription Identifier:1
2.SUBSCRIBE a/topic1 Subscription Identifier:2

After the step1, a map of topic and Topic Identifier is a/topic1 - 1.
After the step2, the map of topic and Topic Identifier is a/topic1 - 2.

Because "the Server receives a SUBSCRIBE packet from the Client for
the same Topic Filter but with a different Subscription Identifier".

So far, so good.

However, how about following scenario ?

1.SUBSCRIBE a/topic1 Subscription Identifier:1
2.SUBSCRIBE a/# Subscription Identifier:2

After the step1, the map of topic and Topic Identifier is a/topic1 - 1.
What happens after the step2 ?

I considered two candidates.

A. The map of topic and Topic Identifier is a/topic1 - 2.
B. The map of topic and Topic Identifier is a/topic1 - 1 and a/topic1 - 2.

I think that A is appropriate behavior.
The point is the Topic FIlter "a/topic1" is NOT the same as "a/#" but
the Topic Filter "a/#" matches "a/topic1".

I think that the wording "the Server receives a SUBSCRIBE packet from
the Client for the same Topic Filter but with a different Subscription
Identifier". should be something like "when the Server receives a
SUBSCRIBE packet from the Client for the Topic Filter that matches the
existing subscription but with a different Subscription Identifier".

----
Thanks,
Takatoshi