Re: [RAI] Conference Focus Indicating CCMP Support draft

[Paul Kyzivat <[e-mail]>]

On 4/11/13 2:38 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> 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

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

> Regards,
>   Rifaat
>
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Paul Kyzivat
>> Sent: Thursday, April 11, 2013 11:52 AM
>> To: [e-mail]
>> Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft
>>
>> On 4/11/13 1:50 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
>>> 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
>>
>>> 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:[e-mail]]
>>>> Sent: Wednesday, April 10, 2013 1:29 PM
>>>> To: Shekh-Yusef, Rifaat (Rifaat)
>>>> Cc: Gonzalo Camarillo; [e-mail]; 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 [e-mail].
>>>>
>>>> RjS
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>     Rifaat
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Robert Sparks [mailto:[e-mail]]
>>>>>> Sent: Wednesday, April 10, 2013 10:35 AM
>>>>>> To: Gonzalo Camarillo
>>>>>> Cc: Shekh-Yusef, Rifaat (Rifaat); [e-mail]; 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>> _______________________________________________
>>> RAI mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rai
>>>
>>
>> _______________________________________________
>> RAI mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rai
>