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

[Paul Kyzivat <[e-mail]>]

On 5/10/20 1:57 PM, Christer Holmberg wrote:

>  >>>1. Should the draft say that it updates RFC 4975?
>  >>>The msrps scheme is also IANA-registered in RFC 4975 section 15.5.2.
>  >>>Please check if that registration need update because of the reuse 
> of the msrps scheme.
>  >>
>  >>Thanks for bringing this back. WG was asked for feedback about 
> updating IANA registry or
>  >>keeping as it is, with the argument that data channel uses DTLS so it 
> would conform
>  >>original “msrps” requirement, that refers to TLS. There was no clear 
> outcome.
>  >>
>  >>If there are no comments opposing this, I would follow your comment 
> and add it to IANA updates section
> 
>  >Good.
> 
>  >Would it also be suitable to say that the draft updates RFC 4975, 
> because of this?
> 
> 
> I agree that a reference to the document should be added to the IANA 
> registry for the "msrps" scheme.
> 
> 
> And, if people think 4975 should be updated, I guess we could say 
> something like:
> 
> 
> "This document RFC 4975, by allowing the usage of the "msrps" scheme 
> when the underlying connection is protected with DTLS."

The key is ensuring that the required usage is clear and unambiguous. 
Specifically, ISTM that a "msrps" URI together with a "dc" parameter 
implies that connecting to this requires use of a data channel over a 
DTLS association established using the address in the URI.

Following up on that, a question about the example in 4.8:

The path attribute includes:

    msrps://bob.example.com:54111/si438dsaodes;dc

but the corresponding c= is:

    c=IN IP4 198.51.100.79

Am I to infer that =IN IP4 198.51.100.79 is the resolution of 
bob.example.com:54111? If so, why doesn't the c= reference 
bob.example.com:54111?

	Thanks,
	Paul