Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 10 Apr 2013 17:50:50 +0000

Adding the RAI distribution to this discussion per Robert's request.

Thanks Robert,

> That _redefines_ Call-Info even if it leaves the syntax the same.
> The definition for the header would be in _this_ document, not in 3261
> if you leave the ABNF like this.

I now understand your concern.
I would like to go with the option of removing the ABNF and just define the new value.

Do others see value with the second option:

> But if you do mess with the ABNF, make this change:
> 
> info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / generic-param
> info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token
> 
> so that  the _next_ draft that comes along that wants to add a purpose
> choice can simply say
> info-purpose-choices =/ "foo"
> 
> If you go down this path, you should also check with the community
> whether we should
> create an IANA registry for these choices. I don't think it's worth it,
> but there have been
> similar conversations where the rough consensus was to create one.

Thanks,
 Rifaat

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2013 1:29 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: Gonzalo Camarillo; [email-masked]; Mary Barnes; Alan Johnston
> Subject: Re: Conference Focus Indicating CCMP Support draft
> 
> On 4/10/13 12:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> > Hi Robert,
> >
> > Thanks for your feedback.
> >
> >> The one thing that sticks out is the complete redefinition of the
> >> Call-Info header syntax just to add a parameter
> >> to info-param.
> > The draft is not changing the syntax of the Call-Info header; the
> absoluteURI will be an XCON-URI and we are defining a new "ccmp" token
> to indicate that the URI supports ccmp.
> > Where do you see that we are redefining the syntax?
> The draft contains this:
> 
>     The following is the updated ABNF for the Call-Info header:
> 
>        Call-Info   =  "Call-Info" HCOLON info *(COMMA info)
>        info        =  LAQUOT absoluteURI RAQUOT *( SEMI info-param)
>        info-param  =  ( "purpose" EQUAL ( "icon" / "info"
>                       / "card" / "ccmp" / token ) ) / generic-param
> 
> That _redefines_ Call-Info even if it leaves the syntax the same.
> The definition for the header would be in _this_ document, not in 3261
> if you leave the ABNF like this.
> 
> At the very least, don't restate Call-Info and info. Redefine only
> info-param.
> 
> You could just define the value and not mess with the ABNF. That is the
> avenue I would recommend.
> 
> But if you do mess with the ABNF, make this change:
> 
> info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / generic-param
> info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token
> 
> so that  the _next_ draft that comes along that wants to add a purpose
> choice can simply say
> info-purpose-choices =/ "foo"
> 
> If you go down this path, you should also check with the community
> whether we should
> create an IANA registry for these choices. I don't think it's worth it,
> but there have been
> similar conversations where the rough consensus was to create one.
> 
> Also, it's unfortunate that this conversation isn't on a list. If we
> continue, please add a list to the distribution.
> I suggest [email-masked].
> 
> RjS
> 
> 
> 
> >
> > Regards,
> >   Rifaat
> >
> >
> >> -----Original Message-----
> >> From: Robert Sparks [mailto:[email-masked]]
> >> Sent: Wednesday, April 10, 2013 10:35 AM
> >> To: Gonzalo Camarillo
> >> Cc: Shekh-Yusef, Rifaat (Rifaat); [email-masked]; Mary Barnes; Alan
> Johnston
> >> Subject: Re: Conference Focus Indicating CCMP Support draft
> >>
> >> We had not yet started. The next step is for the authors to request
> >> publication (when they believe it is ready),
> >> and you or Richard can start fresh with an initial AD review.
> >>
> >> I skimmed the version of the draft linked to below - I still don't
> >> expect controversy or much in the way of changes.
> >> The one thing that sticks out is the complete redefinition of the
> >> Call-Info header syntax just to add a parameter
> >> to info-param. It would be much better to find a way to use the
> >> Incremental Alternative (=/) production rule.
> >> If that's not possible the way Call-Info is currently defined, we
> should
> >> redefine it _once_ to make it possible.
> >> IIRC there are other things in flight that are touching Call-Info -
> you
> >> should make sure they're aligned.
> >>
> >> RjS
> >>
> >> On 4/10/13 3:01 AM, Gonzalo Camarillo wrote:
> >>> Hi Robert,
> >>>
> >>> the authors of the draft below just sent us the email below. They
> >>> mention you had agreed to AD sponsor it. What is the next step here
> so
> >>> that Richard or I can take this over?
> >>>
> >>> Thanks,
> >>>
> >>> Gonzalo
> >>>
> >>> On 09/04/2013 9:47 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> >>>> Gonzalo, Richard,
> >>>>
> >>>>
> >>>>
> >>>> Mary and I have been working on the following "Conference Focus
> >>>> Indicating CCMP Support" draft, which Robert agreed to AD sponsor a
> >>>> while back.
> >>>>
> >>>> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-
> >> indication/?include_text=1
> >>>>
> >>>>
> >>>> The draft is simple and straightforward which was discussed on the
> >>>> DISPATCH mailing list.
> >>>>
> >>>> Robert Sparks, Alan Johnston, Cullen Jennings, and Adam Roach all
> >>>> reviewed it and provided feedback which was incorporated into the
> >> latest
> >>>> version of the draft.
> >>>>
> >>>> Alan Johnston is the document shepherd and he worked on the writeup
> >> for
> >>>> this draft.
> >>>>
> >>>>
> >>>>
> >>>> Now that Robert is no longer an AD, can one of you please sponsor
> >> this
> >>>> draft instead?
> >>>>
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Rifaat
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 11 Apr 2013 01:26:36 +0000

I prefer the approach to that defines the ABNF in a way that allows it to be extended with 

in a future specification or other document.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shekh-Yusef, Rifaat (Rifaat)
> Sent: 10 April 2013 18:51
> To: Robert Sparks
> Cc: [email-masked]
> Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft
> 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Apr 2013 23:52:13 +0800

> Adding the RAI distribution to this discussion per Robert's request.

IMO RAI isn't the best place for this discussion.
I fear that some people who care won't see this.
The right place to have the discussion of restructuring the ABNF for the 
info-param is sipcore. But I don't want to cross post, so lets reach 
some conclusion to this thread, and then if it becomes a sipcore concern 
we can post the conclusion there for confirmation.

I see three ways to handle this, two of which have already been mentioned:

1) revise the ABNF so in the future it can be extended without
    further redefinition:

    info-param = info-purpose-param / generic-param
    info-purpose-param = "purpose" EQUAL info-purpose-choices
    info-purpose-choices = "icon" / "info" / "card" / token
    info-purpose-choices =/ "ccmp"

2) revise the ANBF to just have the choices be just "token"
    and add an IANA registry for values.

3) just work around the existing ABNF in a cleaner way:

    info-param =/ "purpose" EQUAL "ccmp"

Which to do depends on how much work we want to go through now and how 
many new values we anticipate in the future. In this case, where the 
syntax isn't too complex and the number of new values is likely to be 
small I think (3) may be the simplest.

The choice between (1) and (2) depends on whether we want to spend 
cycles deciding what the criteria ought to be for adding new values in 
the future.

	Thanks,
	Paul

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 11 Apr 2013 18:38:14 +0000

I think that if we are to revise the ABNF, then we need a separate document for that. If there is enough interest, I would be willing to work on that document.
For this document, I prefer to go with option 3.

Regarding the IANA registry, we had a similar discussion on the DISPATCH mailing list in the context of the XMPP work, and the conclusion was that we did not need a registry:
http://www.ietf.org/mail-archive/web/dispatch/current/msg04628.html

Are you saying that we need a registry *if* we revise the ABNF?

Regards,
 Rifaat

> Paul Kyzivat
> Sent: Thursday, April 11, 2013 11:52 AM
> To: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Apr 2013 16:44:43 -0400

> http://www.ietf.org/mail-archive/web/dispatch/current/msg04628.html

You are right - we have been down this path before, several times, 
including recently. The sip parameters registry, introduced with 
RFC3968, already lists parameters and the header fields they may be used 
with, and cross references the documents that define the values of the 
parameter.

That registry already references two additional specs that define new 
values for 'purpose', and we know there is another one in the pipeline 
that will define another.

As a result, the ABNF in 3261 is no longer an exhaustive source for the 
values of the purpose parameter.

RFC3968 says that new parameter values must be defined in an RFC. It 
does not say that they must extend the syntax of 3261 to to so. The 
things that have been added to the table since 3968 have not provided 
ABNF definitions for the new values they define.

Using ABNF =/ to define new values as an extension to the 3261 ABNF is 
certainly *possible*, but it might just be confusing. Doing that would 
at least imply that the RFC doing so should be marked as revising 3261. 
But one purpose of creating the registry is to avoid having to update 
3261 each time a new parameter value is defined.

So, I take back all of (1)-(3).

Instead, I think you must do as draft-ietf-bliss-call-completion-19 
does: Define the specific value, and its meaning, in text in your draft, 
and add an IANA considerations section that adds a reference to your 
draft to the "Header Field Parameters and Parameter Values" sub-table of 
the IANA "Session Initiation Protocol (SIP) Parameters" registry.

> Are you saying that we need a registry *if* we revise the ABNF?

No.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 11 Apr 2013 19:07:32 -0400 (EDT)

> From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
> 

In abstract, I think I prefer the "second option".  But it would take
more bureaucratic work to implement it.

However, draft-yusef-dispatch-ccmp-indication-02, proposes creating a
registry for the predefined values of the purpose parameter of
Call-Info.  I'm not sure it's needed, as there are currently only 4
RFCs/drafts that are relevant.  But if a new registry is defined, the
document that defines it must initialize the registry with all of the
currently defined values, and the current section 4.2 only lists the
value "ccmp".  And it would need to update the row for "Call-Info" in 
"Header Field Parameters and Parameter Values" to reference the new
registry, rather than the collection of RFCs.

Dale

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Fri, 12 Apr 2013 13:01:27 +0000

Hi Dale,

As Paul suggested in a previous email, I will follow what you did with your draft-ietf-bliss-call-completion.

Regards,
 Rifaat

> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Thursday, April 11, 2013 7:08 PM
> Cc: [email-masked]; [email-masked]

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 14 Apr 2013 13:51:45 +0000

I have submitted a new version that removed the ABNF and changed the IANA section to address both the Call-Info and the URI registration.
http://tools.ietf.org/html/draft-yusef-dispatch-ccmp-indication-03

Please, take a look and let me know if you have any comments.

Thanks,
 Rifaat

> Sent: Friday, April 12, 2013 9:01 AM
> To: Dale R. Worley
> Cc: [email-masked]
> > > > info-param = ( "purpose" EQUAL ( info-purpose-choices) ) /
> generic-
> > param

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Apr 2013 11:56:24 -0400

WFM