Subject: [MMUSIC] Changes for draft-ietf-mmusic-trickle-ice-sip-14 - ABNF

From: Thomas Stach <[email-masked]>
Date: Sun, 6 May 2018 20:31:20 +0200

All,

during IESG review we got the below proposal by Adam for changing the 
ABNF to allow for more encoding flexibility.

Unless somebody objects, I'd provide the proposed change by end of the week.

It would affect the "session-level-fields" as proposed below and in a 
similar way the  "pseudo-media-descriptions" and
"trickle-ice-attribute-fields"

Excerpt from Adam'S IESG review:

§9.2:

The syntax for "session-level-fields", "pseudo-media-descriptions", and
"trickle-ice-attribute-fields" include extremely strict rules around 
ordering of
fields (e.g., including ice-ufrag before ice-pwd would be syntactically
invalid). That level of strictness seems unlikely to lead to interoperable
implementations.

If the intention is to be rigid in this fashion, please add prominent prose
that warns implementors that fields MUST appear in the order specified, and
that all other orders are invalid and MUST be rejected.

If that's *not* your intention (and I suspect it isn't), then please fix 
the
syntax definition to allow for arbitrary ordering of attributes in the 
same way
as SDP does. For example:

      session-level-fields = *(session-level-field CRLF)

      session-level-field = bundle-group-attribute /
                            ice-lite-attribute /
                            ice-pwd-attribute /
                            ice-ufrag-attribute /
                            ice-options-attribute /
                            ice-pacing-attribute /
                            end-of-candidates-attribute /
                            extension-attribute-fields
                                   ; for future extensions

Regards

Thomas

---

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

Hi,

I am ok with the change.

However, I think there are some issue with the ABNF (not related to Adam¹s
issue).

For example, the syntax says:

   ice-pwd-attribute      = %s"a" "=" ice-pwd-att

Then the draft says:

   with ice-pwd-attribute from [I-D.ietf-mmusic-ice-sip-sdp],

In my reading, this would result in:

   a=a=ice-pwd:asd88fgpdd777uzjYhagZg

Is this what you want?

If you want to use the syntax of draft-ietf-mmusic-ice-sip-sdp, why not do
it directly? Something like:

 session-level-field = ice-pwd-att /
                       Š
                       Š

 ;ice-pwd-att as defined in [I-D.ietf-mmusic-ice-sip-sdp]

Or, have I missed something?

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Mon, 7 May 2018 20:22:02 +0200

Christer,

thanks for the comments.

replies inline

>     with ice-pwd-attribute from [I-D.ietf-mmusic-ice-sip-sdp],
which says

ice-pwd-att           = "ice-pwd:" password
i.e. doesn't introduce a second a=

>     a=a=ice-pwd:asd88fgpdd777uzjYhagZg
No, and with the above syntax we do not get the a=a=

> Or, have I missed something?
The trickle-ice-sdpfrag syntax uses just a subset of SDP attributes and 
isn't  build as open as  the SDP syntax , the above doesn't work.

Kind Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 May 2018 19:41:19 +0000

Hi Thomas,

I hope Paul can jump in on this one too, since it’s ABNF related :)

> i.e. doesn't introduce a second a=

First, I think the structure in draft-ice-sip-sdp is wrong. It shall be something like:

      Attribute Name: ice-pwd

      Attribute Value: ice-pwd-att

      Usage Level: media

      Charset Dependent: No

      Mux Category: TBD

    The Augmented BNF syntax [RFC5234] for the attribute is:

      ice-pwd-att = password
      password = blah blah...

Now, whether we should use that syntax also in trickle-ice I don't know. I would like to hear Paul's opinion.

> The trickle-ice-sdpfrag syntax uses just a subset of SDP attributes and isn't  build as open as  the SDP syntax , the above doesn't work.

I am not suggesting an open SDP syntax - I am suggesting the reference the specific syntax for the ice-pwd attribute.

Regards,

Christer

All,

Unless somebody objects, I'd provide the proposed change by end of the
week.

§9.2:

If the intention is to be rigid in this fashion, please add prominent
prose
that warns implementors that fields MUST appear in the order specified,
and
that all other orders are invalid and MUST be rejected.

Regards

Thomas

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 7 May 2018 13:57:21 -0600

On 5/7/18 1:41 PM, Christer Holmberg wrote:
> Now, whether we should use that syntax also in trickle-ice I don't know.

Do you mean in draft-ietf-mmusic-trickle-ice-sip or in
draft-ietf-ice-trickle? The latter document contains no ABNF definitions.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 May 2018 21:20:16 +0000

Hi,

>>>> However, I think there are some issue with the ABNF (not related to 
>>>> Adam¹s issue).
>>>>
> Do you mean in draft-ietf-mmusic-trickle-ice-sip or in draft-ietf-ice-trickle? The latter document contains no ABNF definitions.

I mean draft-ietf-mmusic-trickle-ice-sip.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 May 2018 10:03:10 -0400

> I hope Paul can jump in on this one too, since it’s ABNF related :)

I've been doing my best to ignore these drafts. :-)

I'll have to do some reading for context. Just looking at this thread in 
isolation my first thought is that this seems to be defining a new 
attribute with the definition including the "a=" which we are really 
trying to avoid.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 May 2018 07:37:28 +0000

Hi,

>attribute with the definition including the "a=" which we are really

It is not defining a new attribute per se, but it is defining the usage of
the attribute within the ‘application/trickle-sdp-sdpfrag’ message body.

Regards,

Christer

>>>>Adam¹s
>> Now, whether we should use that syntax also in trickle-ice I don't
>>know. I would like to hear Paul's opinion.
>> 
>>> The trickle-ice-sdpfrag syntax uses just a subset of SDP attributes
>>>and isn't  build as open as  the SDP syntax , the above doesn't work.
>> 
>> I am not suggesting an open SDP syntax - I am suggesting the reference
>>the specific syntax for the ice-pwd attribute.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>

---

From: Thomas Stach <[email-masked]>
Date: Wed, 9 May 2018 20:13:26 +0200

Christer,

> Now, whether we should use that syntax also in trickle-ice I don't know. I would like to hear Paul's opinion.
You are mixing up the ABNF syntax and the IANA registration template.

The ABNF syntax in section 5.4 of draft-ietf-mmusic-ice-sip-sdp-16 and 
also section 15.4 of RFC 5245
both define the ABNF grammar as

   ice-pwd-att           = "ice-pwd" ":" password

I don't think it is a good idea to re-define the ice-pwd-att token as
  ice-pwd-att = password
  
If you want to add text to the IANA section it MUST read

     The Augmented BNF syntax [RFC5234] for the attribute is:
	  ice-pwd-att           = "ice-pwd" ":" password

The ABNF in draft-ietf-mmusic-trickle-ice-sip-14 is correct wrt usage of ice-pwd-att

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 May 2018 20:57:12 +0000

Hi,

Hi Thomas,

issue).

Then the draft says:

which says

      Attribute Name: ice-pwd

      Usage Level: media

      Charset Dependent: No

      Mux Category: TBD

      ice-pwd-att = password

      password = blah blah...

The ABNF syntax in section 5.4 of draft-ietf-mmusic-ice-sip-sdp-16 and also section 15.4 of RFC 5245
both define the ABNF grammar as

That is the “old” way of defining attributes. My example above is according to the “new” way, that has been used lately (and, no, I didn’t mix up the ABNF syntax and the IANA reg).

Another example is in section 6 of draft-bundle (with the corresponding IANA reg in section 16.3).

Regards,

Christer

 ice-pwd-att = password

Regards

Thomas

Is this what you want?

                      Š

                      Š

Regards,

Christer

On 06/05/18 21:31, "Thomas Stach" <[email-masked]><mailto:[email-masked]> wrote:

All,

week.

§9.2:

ordering of

implementations.

prose

and

the

same way

                           ice-lite-attribute /

                           ice-pwd-attribute /

                           ice-ufrag-attribute /

                           ice-options-attribute /

                           ice-pacing-attribute /

                                  ; for future extensions

Regards

Thomas

---

From: Thomas Stach <[email-masked]>
Date: Thu, 10 May 2018 13:21:00 +0200

Christer,

On 2018-05-09 22:57, Christer Holmberg wrote:
> That is the “old” way of defining attributes. My example above is 
> according to the “new” way, that has been used lately (and, no, I 
> didn’t mix up the ABNF syntax and the IANA reg).
That's a bad example since a=bundle-only doesn't have a value.
I'd rather prefer ( just personal preference ) the style of 
https://tools.ietf.org/html/draft-ietf-mmusic-rid-14, where the 
registration in section 11 refers to the grammar in section 10.

Nevertheless, the only thing I care about is that we don't confuse the 
reader by having two conflicting definitions of the token ice-pwd-att in 
RFC5245 and draft-ietf-mmusic-ice-sip-sdp. If you want to do changes in 
the grammar, use a distinct token.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 May 2018 16:59:15 +0000

Hi,

Hi Thomas,

I hope Paul can jump in on this one too, since it's ABNF related :)

issue).

Then the draft says:

which says

      Attribute Name: ice-pwd

      Usage Level: media

      Charset Dependent: No

      Mux Category: TBD

      ice-pwd-att = password

      password = blah blah...

That is the "old" way of defining attributes. My example above is according to the "new" way, that has been used lately (and, no, I didn't mix up the ABNF syntax and the IANA reg).

A better example is the tls-id attribute, defined in Section 4 of https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-32.txt.

I'd rather prefer ( just personal preference ) the style of https://tools.ietf.org/html/draft-ietf-mmusic-rid-14, where the registration in section 11 refers to the grammar in section 10.

The ABNF is not according to the new style.

And, just to clarify, my comments are not based on my personal preference, but on my understanding of how SDP attributes are to be defined nowadays.

Nevertheless, the only thing I care about is that we don't confuse the reader by having two conflicting definitions of the token ice-pwd-att in RFC5245 and draft-ietf-mmusic-ice-sip-sdp. If you want to do changes in the grammar, use a distinct token.

No matter how the grammar in draft-ietf-mmusic-ice-sip-sdp eventually will look like (that discussion anyway doesn't belong to this thread), I still think we should just reference it from this draft.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 May 2018 13:37:30 -0400

> I hope Paul can jump in on this one too, since it’s ABNF related :)

OK. I have taken a brief look at the full syntax in the draft.

It is a challenge to find a way to reference the definitions you need 
without duplication!

If this is truly to define a fragment, so that any valid SDP, after 
stripping out the stuff you don't want to include, is a valie fragment, 
then you must allow any ordering of the relevant attribute fields. At 
the moment you mandate a particular ordering.

Also at the moment you indicate some attributes as required and some 
optional. I see no practical way to (in ABNF) distinguish between 
optional and required while allowing arbitrary ordering.

There is also a question about how to handle extension attributes. You 
currently handle this by referencing the generic syntax of an attribute 
from rfc4566. But of course this doesn't have a way to restrict to 
ice-relevant attributes.

This can all be addressed by making the syntax "looser" and then 
restricting it further via normative text.

But this all needs more discussion. So lets discuss this more before 
deciding.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 May 2018 13:40:50 -0400

On 5/10/18 12:59 PM, Christer Holmberg wrote:

> A better example is the tls-id attribute, defined in Section 4 of 
> https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-32.txt.
> 
> 
> And, just to clarify, my comments are not based on my personal 
> preference, but on my understanding of how SDP attributes are to be 
> defined nowadays.

I've been finding that the "new" style that I have been trying to get 
institutionalized isn't well enough specified. I'm thinking that we need 
to firm it up, and preferably get that written down in 4566bis.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 13 May 2018 08:47:30 +0000

Hi,

My suggestion would be to simply reference the syntax. Something like:

trickle-ice-sdpfrag =   session-level-fields
                                      pseudo-media-descriptions
session-level-fields = bundle-group-attribute CRLF          \
                                      ice-lite-attribute CRLF                      \
                                      ice-pwd-attribute CRLF                     \
                                      ice-ufrag-attribute CRLF                    \
                                      ice-options-attribute CRLF                \
                                      ice-pacing-attribute CRLF                  \
                                      end-of-candidates-attribute CRLF   \
                                      extension-attribute-fields

The attribute fields follow the generic syntax for SDP attributes [RFCXXXX]. The list below reference the specific syntax for each attribute field.

ice-lite-attribute              ; as ice-lite defined in [RFCXXXX]
ice-pwd-attribute            ...
ice-ufrag-attribute           ...
ice-pacing-attribute         ...
ice-options-attribute       ....

Then we don't need to worry about "new" and "old" in this draft. We simply define the high-level syntax for the sdpfrag message body, and reference the appropriate specifications for the attributes etc.

In addition, I think it would be useful to say that in order to use an extension attribute, there needs to be a specification for how that attribute is used within a sdpfrag message body. Otherwise someone could include any SDP attribute just like that.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 12 May 2018 19:41
To: [email-masked]
Subject: [MMUSIC] "New" style for defining SDP attributes

> preference, but on my understanding of how SDP attributes are to be 

I've been finding that the "new" style that I have been trying to get institutionalized isn't well enough specified. I'm thinking that we need to firm it up, and preferably get that written down in 4566bis.

	Thanks,
	Paul

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

---

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

Christer,

Note that I changed the subject line here. My intent was to start a 
different discussion that isn't specifically related to trickle-ice-sip. 
The intent instead is to discuss if we should change 4566bis to be more 
explicit about how to define attributes.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 May 2018 18:02:52 +0000

Hi,

>Note that I changed the subject line here. My intent was to start a different discussion that >isn't specifically related to trickle-ice-sip. 
>The intent instead is to discuss if we should change 4566bis to be more explicit about how >to define attributes.

Sure. 

But, at the same time we'd like to move trickle-ice-sip forward, and I think my suggestion below allows us to do that while any possible change to 4566bis is discussed.

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Sat, 19 May 2018 18:43:47 +0200

Hi,

the proposal works for me.
However, as long a we don't have definitions for ice-lite-attribute and 
the other stuff,
I can't reference it and have to keep the constructions and references 
that I currently have.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 May 2018 17:19:57 +0000

Hi,

>However, as long a we don't have definitions for ice-lite-attribute and the other stuff, I can't >reference it and have to keep the constructions and references that I currently have.

Not sure I follow.

The definitions are in draft-ietf-mmusic-ice-sip-sdp. Yes, we may have to change those to the "new" style, but that should not affect the trickle draft.

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Tue, 22 May 2018 21:32:27 +0200

Christer,

On 2018-05-19 19:19, Christer Holmberg wrote:
> The definitions are in draft-ietf-mmusic-ice-sip-sdp.
I couldn't find ABNF for ice-lite-attribute, pwd-attribute, 
ice-ufrag-attribute, ...
Once it's there I'll take it.

For the time being I stick with the ABNF that current is in 
draft-ietf-mmusic-trickle-ice-sip, i.e,

          ice-lite-attribute     = %s"a" "=" ice-lite
          ice-pwd-attribute      = %s"a" "=" ice-pwd-att
          ice-ufrag-attribute    = %s"a" "=" ice-ufrag-att
          ice-pacing-attribute   = %s"a" "=" ice-pacing-att

>   Yes, we may have to change those to the "new" style,
yes

Regards
Thomas
> but that should not affect the trickle draft.
>
> Regards,
>
> Christer
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 May 2018 06:37:26 +0000

Hi,

>I couldn't find ABNF for ice-lite-attribute, pwd-attribute, ice-ufrag-attribute, ...

Section 4.

You don’t need the “a=” part, because that is implicit for attributes.

Regards,

Christer

Hi,

Sure.

Regards,

Christer

Hi,

                                        ice-pwd-attribute CRLF                     \

ice-pwd-attribute            ...

ice-ufrag-attribute           ...

ice-pacing-attribute         ...

Regards,

Christer

-----Original Message-----

From: mmusic [mailto:[email-masked]] On Behalf Of Paul

Kyzivat

Sent: 12 May 2018 19:41

To: [email-masked]<mailto:[email-masked]>

defined nowadays.

     Thanks,

     Paul

mmusic mailing list

[email-masked]<mailto:[email-masked]>

mmusic mailing list

[email-masked]<mailto:[email-masked]>