Subject: [MMUSIC] [Technical Errata Reported] RFC4566 (5595)

From: RFC Errata System <[email-masked]>
Date: Tue, 8 Jan 2019 08:43:21 -0800 (PST)

The following errata report has been submitted for RFC4566,
"SDP: Session Description Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5595

--------------------------------------
Type: Technical
Reported by: Gavin Scallan <[email-masked]>

Section: 5

Original Text
-------------
An example SDP description is:

      v=0
      o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.example.com/seminars/sdp.pdf
      e=[email-masked] (Jane Doe)
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      a=recvonly
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=rtpmap:99 h263-1998/90000

Corrected Text
--------------
An example SDP description is:

      v=0
      o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.example.com/seminars/sdp.pdf
      e=[email-masked] (Jane Doe)
      c=IN IP4 224.2.17.12/127
      a=recvonly
      t=2873397496 2873404696
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=rtpmap:99 h263-1998/90000

Notes
-----
In section 5 it indicates that the SDP lines MUST appear in the exact order given at the top of Page 9.
The order that is shown indicates that the Session Attributes  appear before the Time Description.

However in the example included in this section which explains that Media Attributes have precedence over Session Attributes for a media stream  contradicts the order as the  Session Attribute of sendonly is included below the  Time Description.

Either the example is incorrect, or the normative description is poorly explained and some variability in the order of lines in the SDP is allowed.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4566 (draft-ietf-mmusic-sdp-new-26)
--------------------------------------
Title               : SDP: Session Description Protocol
Publication Date    : July 2006
Author(s)           : M. Handley, V. Jacobson, C. Perkins
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Jan 2019 12:34:30 -0500

This errata is not correct. Also note that RFC4566 is in process of 
being replaced by draft-ietf-mmusic-rfc4566bis-32. The two are 
compatible, and so the bis doesn't impact the issue reported here.

More below.

> "SDP: Session Description Protocol".

Exactly what causes you to reach that conclusion? It doesn't read that 
way to me. The following:

       Session description
          ...
          One or more time descriptions ("t=" and "r=" lines; see below)
          ...
          a=* (zero or more session attribute lines)
          Zero or more media descriptions

shows that t= lines must precede a= lines.

Also, this entire figure is a summary of the syntax included in Section 
9. I encourage you to use the syntax to verify what I'm saying.

Also, see if this is clearer in rfc4566bis. I reworked some of the text 
to make it clearer.

	Thanks,
	Paul

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 08 Jan 2019 21:19:25 -0500

RFC Errata System <[email-masked]> writes:
> [...]  In section 5 it indicates that the SDP lines MUST appear in the
> exact order given at the top of Page 9.  The order that is shown
> indicates that the Session Attributes appear before the Time
> Description. [...]

The example is correct, but there's a subtle point about the text that
makes it vulnerable to misreading.  Viz., section 5 says:

   Some lines in each description are REQUIRED and some are OPTIONAL,
   but all MUST appear in exactly the order given here [...]

Followed by:

      Session description
         v=  (protocol version)
         o=  (originator and session identifier)
         s=  (session name)
         i=* (session information)
         u=* (URI of description)
         e=* (email address)
         p=* (phone number)
         c=* (connection information -- not required if included in
              all media)
         b=* (zero or more bandwidth information lines)
         One or more time descriptions ("t=" and "r=" lines; see below)
         z=* (time zone adjustments)
         k=* (encryption key)
         a=* (zero or more session attribute lines)
         Zero or more media descriptions

      Time description
         t=  (time the session is active)
         r=* (zero or more repeat times)

      Media description, if present
         m=  (media name and transport address)
         i=* (media title)
         c=* (connection information -- optional if included at
              session level)
         b=* (zero or more bandwidth information lines)
         k=* (encryption key)
         a=* (zero or more media attribute lines)

Look back on this and ask yourself, What is "the order given"?

It looks like the order is "session description" followed by "time
description" followed by "media descriptions, if present".  But it's
not.  "The order given" covers only the section titled "Session
description" -- "Time description" is included within it by reference in
the 10th item, and "Media description, if present" is included within it
multiply by reference in the 14th item.  (Compare with the grammar in
section 9.)

In particular, time descriptions come before session attributes.

So it would really help if this text was clarified in 4566bis.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Jan 2019 11:36:01 -0500

> So it would really help if this text was clarified in 4566bis.

4566bis has already been submitted to the iesg, making it harder to 
revise now.

Do you have a thought about how to improve it? As it is, the text reads 
as normative, but the ABNF should really be the formal authority, with 
this being just a summary.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 10 Jan 2019 21:41:16 -0500

> this being just a summary.

I think an adequate fix could be confined to an editorial change:

   Some lines in each description are REQUIRED and some are OPTIONAL,
   but all MUST appear in exactly the order given here (the fixed order
   greatly enhances error detection and allows for a simple parser).  In
   the following overview OPTIONAL items are marked with a "*".  (For
   details, see the formal grammar in Section 9.)

      Session description
         v=  (protocol version)
         o=  (originator and session identifier)
         s=  (session name)
         i=* (session information)
         u=* (URI of description)
         e=* (email address)
         p=* (phone number)
         c=* (connection information -- not required if included in
              all media descriptions)
         b=* (zero or more bandwidth information lines)
         One or more time descriptions:
           ("t=", "r=" and "z=" lines; see below)
         k=* (encryption key)
         a=* (zero or more session attribute lines)
         Zero or more media descriptions

+  The referenced subsections of the description have this structure:

      Time description
         t=  (time the session is active)
         r=* (zero or more repeat times)
         z=* (optional time zone offset line)

Inserting that one sentence tends to terminate the scope of "the
following overview".

Dale

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 11 Jan 2019 09:06:58 -0500

> 4566bis has already been submitted to the iesg, making it harder to 
I'm sure we can find a way of handling that if the WG thinks the change 
is warranted (seems reasonable to me).

-- Flemming
>
> Do you have a thought about how to improve it? As it is, the text 
> reads as normative, but the ABNF should really be the formal 
> authority, with this being just a summary.
>
>     Thanks,
>     Paul
>
> .

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2019 12:04:42 -0500

I like this. If Flemming agrees, I'll await instructions on the 
procedure for making the change.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 11 Jan 2019 13:28:48 -0600

It sounds good to me as well.

I'll note that, while the document has entered "publication requested" 
state, it's still very early on (AD review hasn't even happened yet), so 
making changes to the document should be very easy at this point.

In terms of the errata, I think the proper disposition is "hold for 
update," as it identifies a real issue, even if it calls for an 
incorrect solution.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2019 16:03:58 -0500

> making changes to the document should be very easy at this point.

OK. Shall we simply hold this change till later on?

> update," as it identifies a real issue, even if it calls for an 

Sounds good.

	Thanks,
	Paul

---

From: Keith Drage <[email-masked]>
Date: Wed, 16 Jan 2019 12:13:08 +0000

Paul wrote: "As it is, the text reads as normative, but the ABNF should 
really be the formal authority, with this being just a summary. "

While that might be a convention, formally it only applies if there is a 
statement in the RFC or draft that says it. Otherwise any normative 
statements in the text and the ABNF have to be taken as complementary to 
each other, and equally normative. As far as I am aware, there is no 
generic overarching RFC that states ABNF takes precedence over all other 
material.

Indeed in other RFCs, it has been necessary to enhance the ABNF with 
additional normative text statements, because either it is impossible to 
express the requirement in ABNF, or because the ABNF representation 
would be too complex.

regards

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jan 2019 13:54:04 -0500

> express the requirement in ABNF, or because the ABNF representation 

Fair enough. Since both say they are normative they must be consistent. 
For the most part I think they are. But the (informal) notation in 
section 5 isn't precise enough to capture every nuance. Notably, it 
implies you can have t= followed by z= without an r=. In 4566 the ABNF 
also permitted this. But after considerable discussion we concluded, and 
clarified in text, that z= only affects r= and so is nonsense if r= 
isn't present. So I modified the ABNF to so z= may only appear following 
r=. And that isn't reflected in section 5.

Attempting to fix the figure in section 5 would complicate it. The point 
here is for this to be simple to understand, so IMO that would be 
counterproductive.

Perhaps section 5 needs to be reworded to make clear that it is just an 
approximate overview of the syntax, and the ABNF is normative.

	Thanks,
	Paul