Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-rfc4566bis-35: (with COMMENT)

[Paul Kyzivat <[e-mail]>]

Ben,

Just responding to a few points below. I think we are good now.

On 6/3/19 6:17 PM, Benjamin Kaduk wrote:

>>> I reviewed the diff from RFC 4566 but didn't make it quite all the way
>>> through the full document itself.  What I did find in that partial read
>>> suggests that a full read-through by the authors may find some lingering
>>> stale language or minor internal inconsistencies.
>>
>> There really hasn't been an attempt to thoroughly remove stale (dated)
>> language. Fundamentally this is a 21 year old document that has been tidied
>> up a bit. Anyone that started over today to define something new for the
>> same purpose would surely define something very different. We've only been
>> trying to fix areas where there has been confusion or ambiguity has been
>> found, or where new concerns (e.g., security) have needed to be addressed.
> 
> I think the RFC Editor is still going to be reviewing the whole thing for
> consistency with the current style/practices, so getting a headstart now
> would probably be more effective and save some time overall.

I prefer to wait and see. Doing this preemptively seems like a time sink.

>>> Section 4.3
>>>
>>> The usual security considerations about (potentially) referencing remote
>>> content would seem to apply.  Perhaps a RFC 3986 reference (or more)
>>> would be appropriate.
>>
>> Will adding a reference to [RFC3986] be sufficient?
> 
> I would prefer a note about "Use of URIs to indicate remote resources
> is subject to the security considerations from [RFC3986]", but just the
> reference would be okay.

OK, I'll do the long form.

>>> Section 5.x
>>>
>>> It's interesting to note that while the SDP attributes (Sections 6.x)
>>> got ABNF constructions for their values, the type descriptions here
>>> are still presented in a somewhat informal syntax (that, e.g., relies on
>>> implicitly stating that fields are whitespace-separated).
>>
>> It is an interesting point. The best rationale I can give is that *not*
>> having ABNF got to be a serious problem for attributes, because there are a
>> lot of them, and new ones get defined regularly (with complex syntax) and
>> the syntax was often recognized as being ambiguous. So we wanted to demand
>> ABNF for future extensions, and felt we should make the ones defined in this
>> document comply with that.
>>
>> OTOH, the other fields are revised/extended much more rarely, so it hasn't
>> been a problem. And so there is much less motivation to "rock the boat" by
>> changing the manner of defining them.
> 
> Indeed.  Changing this seems like more effort than it's worth, at this point
> in the process.  (But can I have whitespace in a comma-separated list?  I
> assume "no", but have been wrong on many occasions...)

In general whitespace is only allowed where *specifically* permitted.
  	Thanks,
	Paul