Subject: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value

From: Brett Tate <[email-masked]>
Date: Tue, 5 Aug 2014 10:12:52 -0400

Hi,

Draft-ietf-mmusic-rfc4566bis-10 section 5.13 discusses two formats of
attribute fields.  However, it doesn't appear to clearly indicate the
validity/invalidity of colon without a value.

Is an attribute such as "a=rtcp-xr:" valid?  For instance, RFC 3611
indicates that it is valid; however errata 3795 indicates that it
potentially shouldn't be valid.

Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify
the topic?

Thanks,
Brett

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 5 Aug 2014 14:41:48 +0000

> validity/invalidity of colon without a value.

It says there are two forms. since "a=<attribute>:" is not listed as a form, I guess it simply means it is not valid usage.

> 
> Is an attribute such as "a=rtcp-xr:" valid?  

Not based on my knowledge.

> For instance, RFC 3611

I am not sure why that errate is not verified. To me, 3611 has an abnf syntax error that should be fixed.

> Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify

We can add a sentence to ban such a usage but now I wonder whether they have been attributes defined in that form in the past. Is anyone aware of any?

-acbegen

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2014 11:12:36 -0400

> Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify

Yes, it probably should.

Given how established SDP is, I think we need to be careful about *how* 
we clarify it, to minimize compatibility issues.

The referenced erratum says that for one particular attribute the colon 
is required even if there is no value after it. And the proposed fix is 
to only permit the colon if there is a value.

Another possibility would be to make the colon optional if there is no 
value.

I am inclined to think that the *generic* syntax for attributes ought to 
work that way, in order to be most forgiving. The current syntax is:

    attribute =           (att-field ":" att-value) / att-field

    att-field =           token

    att-value =           byte-string

    byte-string =         1*(%x01-09/%x0B-0C/%x0E-FF)
                          ;any byte except NUL, CR, or LF

I think we should at least *consider* changing it to:

    attribute =           att-field [ ":" [att-value] ]

It would be good to hear from anybody who thinks this change would be 
troublesome.

Possibly the syntax of individual attributes can continue to be more 
restrictive. That will certainly be the case until/unless they are all 
updated.

In principle we need to confront *that* for each of the attributes 
defined in 4566 if we are going to give ABNF for each of them. But it is 
only of concern for an attribute where the value is optional. I don't 
think that is the case for any attributes defined in 4566.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 5 Aug 2014 13:04:28 -0400

Thanks for the response.  I agree with your RFC 4566 interpretation.  RFC
3211 did not conform to RFC 2327 (or RFC 4566) when introducing the
rtcp-xr attribute.  Thus I guess that it is just a matter of deciding how
best to remedy the situation.  Since the rfc4566bis ABNF is explicit, one
option is potentially to recommend that errata 3795 be accepted and leave
rfc4566bis as-is.

RFC 4566:

attribute-fields =    *(%x61 "=" attribute CRLF)
   attribute =           (att-field ":" att-value) / att-field
   att-field =           token
   att-value =           byte-string
   token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                         / %x41-5A / %x5E-7E
   token =               1*(token-char)
   byte-string =         1*(%x01-09/%x0B-0C/%x0E-FF)
                         ;any byte except NUL, CR, or LF

RFC 2327:

attribute-fields =    *("a=" attribute CRLF)
   attribute =           (att-field ":" att-value) | att-field
   att-field =           1*(alpha-numeric)
   att-value =           byte-string
   byte-string =         1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
                         ;any byte except NUL, CR or LF

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Ali C. Begen
(abegen)
Sent: Tuesday, August 05, 2014 10:42 AM
To: Brett Tate
Cc: [email-masked]
Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have
a null value

> validity/invalidity of colon without a value.

It says there are two forms. since "a=<attribute>:" is not listed as a
form, I guess it simply means it is not valid usage.

> potentially shouldn't be valid.

I am not sure why that errate is not verified. To me, 3611 has an abnf
syntax error that should be fixed.

>
> Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to
> clarify the topic?

We can add a sentence to ban such a usage but now I wonder whether they
have been attributes defined in that form in the past. Is anyone aware of
any?

-acbegen

---

From: Brett Tate <[email-masked]>
Date: Tue, 5 Aug 2014 13:54:38 -0400

> Given how established SDP is, I think we need to be careful about
> *how* we clarify it, to minimize compatibility issues.

I agree.  One option is potentially to keep it invalid.  A comment
potentially could be added indicating that RFC 3611 is a reason to
accommodate the unexpected ABNF expansion (i.e. sender not updated to
comply with the errata).

> The referenced erratum says that for one particular attribute the
> colon is required even if there is no value after it. And the proposed
> fix is to only permit the colon if there is a value.

Errata 3795's proposed fix to RFC 3611 would allow the ABNF to comply with
RFC 4566.

> It would be good to hear from anybody who thinks this change
> would be troublesome.

It would cause the rfc4566bis attribute ABNF to not be backward compatible
with RFC 4566 devices.

This could cause issues with some RFC 4566 devices; however some already
accommodate it for interoperability reasons.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2014 14:06:10 -0400

> accommodate it for interoperability reasons.

In practice this is only an issue for attributes that are specified to 
be meaningful both with and without a value. We could investigate the 
current population to see how many fit into that category. I suspect it 
is very few.

My thought in proposing the change was to encourage those ignoring 
attributes they don't understand to also ignore those with a colon and 
no value. But we don't want to encourage people to do that. If we only 
have one case that called for this usage, then maybe we just deal with 
it there.

	Thanks,
	Paula

	Thanks,
	Paul

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Aug 2014 07:44:10 +0000

On Aug 5, 2014, at 9:06 PM, Paul Kyzivat <[email-masked]> wrote:

> In practice this is only an issue for attributes that are specified to be meaningful both with and without a value. We could investigate the current population to see how many fit into that category. I suspect it is very few.
> 
> My thought in proposing the change was to encourage those ignoring attributes they don't understand to also ignore those with a colon and no value. But we don't want to encourage people to do that. If we only have one case that called for this usage, then maybe we just deal with it there.

I think errata 3795 should be accepted and we just make the clarification in the bis document (i.e., say "dont use just a column").

What is the process for reviving errata 3795?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Aug 2014 09:42:55 -0400

> I think errata 3795 should be accepted and we just make the clarification in the bis document (i.e., say "dont use just a column").

OK.

> What is the process for reviving errata 3795?

I don't know.

---

From: Brett Tate <[email-masked]>
Date: Wed, 6 Aug 2014 10:26:58 -0400

> > What is the process for reviving errata 3795?

The status is Reported which means "reported but is unverified".

http://www.rfc-editor.org/status_type_desc.html

I sent an email to the avt list to attempt to initiate discussion.

http://www.ietf.org/mail-archive/web/avt/current/msg16320.html

I'm not sure if any off list discussion has occurred concerning RFC 3611
errata 3795.  Stephan might know.

Thanks,
Brett