Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-26.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 May 2018 17:14:22 -0400

I just submitted draft-ietf-mmusic-rfc4566bis-26.txt. I believe this 
addresses all of the issues raised in the meeting minutes, with the 
exception of #9 on bwtype.

Please check and see if this does the job.

I'll post another message regarding bwtype and a broader issue that I 
think it raises.

	Thanks,
	Paul

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-26.txt
Date: Tue, 01 May 2018 14:08:21 -0700
From: [email-masked]
To: Colin Perkins <[email-masked]>, Mark Handley 
<[email-masked]>, Paul Kyzivat <[email-masked]>, Ali 
Begen <[email-masked]>

A new version of I-D, draft-ietf-mmusic-rfc4566bis-26.txt
has been successfully submitted by Paul Kyzivat and posted to the
IETF repository.

Name:		draft-ietf-mmusic-rfc4566bis
Revision:	26
Title:		SDP: Session Description Protocol
Document date:	2018-04-30
Group:		mmusic
Pages:		58
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-26.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-26
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-26

Abstract:
    This memo defines the Session Description Protocol (SDP).  SDP is
    intended for describing multimedia sessions for the purposes of
    session announcement, session invitation, and other forms of
    multimedia session initiation.  This document obsoletes RFC 4566.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 May 2018 07:35:02 +0000

Hi,

The document looks good to me. Just a couple of issues:

GENERIC:

Q1:
===

There seem to be a different meaning for "field" and "sub-field".

Sometimes individual parts (e.g., the proto part of an m- line) of an SDP
element is referred to as "field", while in other cases it is referred to
as "sub-field".

Related to that, in the case of the m- line, "field" seems to refer to the
whole m- line. There are also 3 instances of "media field" that I think we
could remove, and replace with something else (e.g., m= line).

I do understand the usage of "field" in the ABNF, but my issue is on the
normative text.

SPECIFICS:

Q2 (related to Q1):
===================

Section 5 says:

"SDP field names"

What exactly are you referring to here?

Q3 (related to Q1):
===================

Section 5 says:

   "attribute names"

Šwhile Section 8.2.4.1 says:

   "Attribute field names"

What is the difference?

Q4:
===

Section 5.14 says:

    "A session description may contain a number of media descriptions.
     Each media description starts with an "m=" line (media field) and is
     terminated by either the next "m=" line or by the end of the session
     description." 

Section 5.13 says:

    "A media description may have any number of attributes ("a=" lines)
     that are media description specific.  These are referred to as
     "media-level" attributes and add information about the media
     description." 

Unless I¹ve missed it, apart from the ABNF, I don¹t think it is anywhere
indicated that attributes are placed below the m= line they are associated
with. 

I think it would be good to indicate in the normative text that an m= line
can be followed by attributes, and whatever other SDP elements that can be
associated with a media description.

Regards,

Christer

On 02/05/18 00:14, "mmusic on behalf of Paul Kyzivat"
<[email-masked] on behalf of [email-masked]> wrote:

>https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-26
>Htmlized: 
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 May 2018 16:39:39 -0400

> I'll post another message regarding bwtype and a broader issue that I 

 From the London meeting there was an issue (#9) around bwtype. It 
wasn't very clear to me, but it was raised by Ben and so I followed up 
with him. He responded to me:

> It’s been a while, but I think my comment was about 8.2.2 and 8.2.3 
> saying that things SHOULD be registered with IANA. Given that this 
> leaves the possibility of people using things without registering, I 
> think it would be good to make that a MUST, or to add some guidance 
> about when it might make sense to use an unregistered parameter.

I agree with this, but think think that such a change deserves wg 
discussion before doing it.

I think this issue is broader than just bwtype - there is a similar 
issue with proto values for m-lines - it is currently SHOULD register. 
IMO it also should be MUST.

Does anybody object to making these changes?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 May 2018 17:13:55 -0400

Christer,

> I do understand the usage of "field" in the ABNF, but my issue is on the

I just scanned the whole document for "field" and sized up how it is 
used. It is not pretty!

'field' is not defined in the ABNF, but there are a lot of 'foo-field' 
things defined.

For the most part, each line of SDP gets a name of the form 'foo-field'. 
And for the most part there aren't names for constructions consisting of 
more than one line.

One exception is media-description, which includes more than one line. 
Each of the things it can contain is a field.

The other exception is time-field, which optionally contains 
repeat-fields and zone-adjustments, which each are separate lines.

The predominate terminology for portions of a field (line) is sub-field. 
But there are many cases that use 'field' for this where sub-field would 
be more appropriate.

There are also plenty of places that use 'field' more generically. Those 
can generally be understood as different based on context.

So, what do we want to do about this?

My inclination is to "fix" it within limits, without going crazy. I 
suggest the following:

- change all the places that use 'field' to reference a portion of a 
line to use 'sub-field' instead.

- redefine time-field as time-description, in a manner analogous to 
media-description. The name 'time-field' would then refer only to the 
t-line itself. Of course then change any text necessary to agree with this.

Leave generic usage of 'field' unchanged.

> Q2 (related to Q1):

I presume this refers to the portion of a line preceding the first "=".

> Q3 (related to Q1):

I think none.

> associated with a media description.

It is pretty clear from the ABNF, but I agree it would be food to make 
it clear in the text as well.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 May 2018 11:57:34 +0000

Hi Paul,

>line to use 'sub-field' instead.

I think most SDP extension specifications use ‘part’, or something
similar, but I am ok if we don’t want to change that.

>Leave generic usage of 'field' unchanged.

Yes, but I think the text shall be consistent when we talk about complete
SDP elements/SDP fields: we either say ‘x- line’ or ‘x- field’.

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 9 May 2018 11:52:54 -0400

> Does anybody object to making these changes?
Sounds good to me

Thanks

-- Flemming (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 May 2018 13:31:33 -0400

> similar, but I am ok if we don’t want to change that.

ISTM that sub-field is more precise than part, and there is already 
precedent for its use in this document, so I'm inclined to stick with 
that unless there is some strong reason to do otherwise.

> SDP elements/SDP fields: we either say ‘x- line’ or ‘x- field’.

It seems that the existing usage is consistently x-field. I find no 
occurrences of "-line" or "- line" in the document.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 May 2018 17:56:38 -0400

> occurrences of "-line" or "- line" in the document.

Its easy to miss stuff when only looking using search. :-(

There is extremely widespread usage of '"X=" line' (for almost every 
value of X) in the document.

I started changing some of these to 'X-field ("X=" line)', but after 
looking at the results I am doubting that this is an improvement.

I hesitate to diverge too much from the established style, though that 
is certainly an option.

I am thinking about changing the first occurrence to '"X=" line 
(X-field)' to establish the linkage to the ABNF. And then otherwise 
leave the usage as just '"X=" line'.

That at least establishes that they may be used as synonyms.

I'm about ready to publish a version with all the "field" changes, but 
I'd like to get feedback on this first.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 May 2018 14:59:25 -0400

[Resending due to the outage on the ietf mail server]

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 21 May 2018 09:14:33 -0400

> I'd like to get feedback on this first.
I *think* your suggestion above sound reasonable, but it's easier to 
judge when seeing the actual text. If you have an updated draft with the 
changes ready anyway, I'd suggest publishing that and get feedback on it 
- we can always revert to the older version again if necessary.

Thanks

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2018 10:20:53 -0400

> - we can always revert to the older version again if necessary.

I don't have a version with the changes the way I describe. I *started* 
changing a different way and pulled back when it started to look ugly to me.

But I can go ahead and make the changes I've described and then publish 
it for review. There is a fine line here between making gratuitous 
changes and making the document clearer. I'm trying to find that line.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 21 May 2018 11:00:30 -0400

On 5/21/18 10:20 AM, Paul Kyzivat wrote:
>> judge when seeing the actual text. If you have an updated draft with 
>> the changes ready anyway, I'd suggest publishing that and get 
>> feedback on it - we can always revert to the older version again if 
>> necessary.
>
> I don't have a version with the changes the way I describe. I 
> *started* changing a different way and pulled back when it started to 
> look ugly to me.
>
> But I can go ahead and make the changes I've described and then 
> publish it for review. There is a fine line here between making 
> gratuitous changes and making the document clearer. I'm trying to find 
> that line.
>
Agreed. If the changes can be done without too much work, then I'd 
suggest trying to publish a version that shows them.

Thanks

-- Flemming

> .