Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

[Christer Holmberg <[e-mail]>]

One more thing: if you by "destination" mean the IP address and port of the remote peer, you get that from the c/m- line.

Regards,

Christer

On 13/05/2020, 20.18, "mmusic on behalf of Christer Holmberg" <[e-mail] on behalf of christer.holmberg=[e-mail]> wrote:

    Hi,

        >>>>>- Added text to make more clear the scope of path and MSRP URI:
        >>>>
        >>>>>Data channels are negotiated independently of the value of the "path"
        >>>> attribute. This means that when MSRP messages are transported on a data
        >>>> channel, the "path" attribute
        >>>>
        >>>>>is not used for transport negotiation or routing of the messages. MSRP
        >>>> endpoints using data channels can set the value of the "path" attribute,
        >>>> including the MSRP URI, and use it as described in RFC4975
        >>>>
        >>>> I think we need to be a little more explicit, so I suggest something like:
        >>>>
        >>>> "When MSRP messages are transported on a data channel, the "path"
        >>>> attribute is not used for routing of the messages. The MSRP data channel
        >>>> is established using the SDP offer/answer procedures defined in
        >>>> [I-D.ietf-rtcweb-data-channel], and the MSRP messages are then
        >>>> transported on that data channel. Because of that an MSRP endpoint can
        >>>> set the MSRP-URI authority value of the "path" attribute at its own
        >>>> discretion, following the syntax and rules in [RFC4975]."
        >>>
        >>> I'm concerned that this might imply that an msrp(s) URI is not
        >>> sufficient information to establish communication. (That some additional
        >>> information, received out-of-band, might be a prerequisite.)
        >>>
        >>> Do you intend that to be a possible situation?
        >>>
        >>> I would hope that it is not - that an msrp(s) URI is sufficient. In that
        >>> case, both the transport setup and the path attribute would be derived
        >>> from the same source.
        >> 
        >>      I am not sure I understand....
        >> 
        >>      The MSRP URI is *not* enough to establish the SCTP association and the data channel. The procedures
        >>      for establishing a data channel are defined in [I-D.ietf-rtcweb-data-channel], and then each usage have some specific attribute values etc.
        >> 
        >>     We are not modifying the procedures how to establish a data channel - we are defining how to send MSRP messages over a data channel.
        >
        > [I-D.ietf-rtcweb-data-channel] defines *procedures* for establishing a 
        > data channel, just as SIP provides procedures for establishing a sip 
        > session. In both cases, those procedures must be parameterized. In the 
        > case of SIP a sip URI is generally sufficient. (In some environments you 
        > might need some extra environmental information, such as how to get 
        > yourself registered first and the need to use an access proxy.)
        >
        > In this case, the msrp(s) uri should provide all the parameterizing 
        > information I need to send msrp messages to this destination, over and 
        > above info about my environment and basic standards. The "dc" parameter 
        > in the URI tells me that I need use a data channel.
        >
        > I shouldn't need to supply any extra information *about the destination*.

        You know that you are going to send the MSRP message on the data channel - that's all you need to know.

        Regards,

        Christer


    _______________________________________________
    mmusic mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/mmusic