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

[Christer Holmberg <[e-mail]>]

Hi,

    >> 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.
    >
    > And where does *the* m line get the fqdn/ip from???
    >
    > Assume you gave me your msrp address once, and I have it in my address 
    > book. Today I decide I want to chat with you. I need to set up a session 
    > with you, and your msrp url is what I have to work with.
    >
    > Because the URL has the "dc" parameter I can infer that I will need a 
    > data channel. I must set up the the DTLS session and then create a data 
    > channel to do that. How do I know what to put into the c/m- line? Are 
    > you saying that I need some *other* information about you before I can 
    > do that? Or can I derive the c/m- line data from it?

    I don't think an MSRP-URI is something you would put in your address book. If you use SIP to negotiate the MSRP session, then you would have a SIP-URI in your address book, and you would use that to establish a SIP session in order to negotiate the MSRP session.

    Even in RFC 4975, you use SIP and offer/answer to negotiate the MSRP session. You don't just start sending MSRP messages without exchanging the MSPR session parameters (including path) first.

     But, maybe I completely misunderstand your issue. 

     Please suggest some text that you would to be included, if that perhaps helps me understand.

     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
    > 
    > _______________________________________________
    > mmusic mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/mmusic
    > 

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