Re: [Ecrit] draft-ietf-ecrit-additional-data-10

[Paul Kyzivat <[e-mail]>]

Clearly this is a sipcore issue.
I have to think more about it before I take a position.

	Thanks,
	Paul

On 7/17/13 9:52 AM, Brian Rosen wrote:
> Looking at the registry, there are only two parameters that have more than 3 values, purpose and "handling" parameter of Content-Disposition.  When we're finished, we're going to have six in purpose, and NENA wants to register two more.  I think that justifies a separate sub registry, I don't think it would affect other parameters, and I think this parameter ought to have a more lax registration mechanism than IETF consensus.
>
> I'll fix the other things you noted.
>
> Brian
>
> On Jul 16, 2013, at 6:19 AM, "DRAGE, Keith (Keith)" <[e-mail]> wrote:
>
>> The relevant document that defines the policy here is RFC 3968:
>>
>>    Some SIP header field parameters only accept a set of predefined
>>    parameter values.  For example, a parameter indicating the transport
>>    protocol in use may only accept the predefined tokens TCP, UDP, and
>>    SCTP as valid values.  Registering all parameter values for all SIP
>>    header field parameters of this type would require a large number of
>>    subregistries.  Instead, we have chosen to register parameter values
>>    by reference.  That is, the entry in the parameter registry for a
>>    given header field parameter contains references to the RFCs defining
>>    new values of the parameter.  References to RFCs defining parameter
>>    values appear in double brackets in the registry.
>>
>>    So, the header field parameter registry contains a column that
>>    indicates whether or not each parameter only accepts a set of
>>    predefined values.  Implementers of parameters with a "yes" in that
>>    column need to find all the valid parameter values in the RFCs
>>    provided as references.
>>
>> So given an explicit approved statement I think you should come up with better arguments for a separate registry, rather than "I think we should fix this". I'm not saying you may not be able to justify it, rather that if we follow your policy without control we will be adding dozens of extra tables to the registries, and noone will be able to find anything.
>>
>> Whatever the WG decides, you still need to amend the header field parameters table and this document currently does not fulfil that function.
>>
>> Additional comments I spotted while looking at this:
>>
>> I'd note that it is the
>>
>> "purpose" header field parameter [of the Call Info header field]
>>
>> Rather than the
>>
>> 'purpose' parameter.
>>
>> And on 9.1.1:
>>
>> " As defined in [RFC5226], this registry operates
>>    under "Expert Review" rules."
>>
>> RFC 5226 does not define how this registry operates. What you want to say is that the expert review rules are defined in RFC 5226.
>>
>>
>>
>> Keith
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Brian Rosen
>>> Sent: 15 July 2013 20:14
>>> To: Hannes Tschofenig
>>> Cc: [e-mail] WG
>>> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10
>>>
>>> Commenting on a draft of which I am an author :)
>>>
>>> The IANA considerations, in section 9.1.7.  Additional Data Blocks
>>> Registry
>>> says:
>>>
>>>    This document creates a new sub-registry called 'Additional Data
>>>    Blocks' in the purpose registry established by RFC 3261 [RFC3261].
>>>
>>> Unfortunately, there is no "purpose" registry.  There is only a list of
>>> references in the Header parameters table that refer to RFCs that define
>>> new purpose values.
>>> I think we should fix this and have "Additional Data" create the purpose
>>> registry, adding one new value and the sub registry.
>>>
>>> Brian
>>>
>>> On Jul 15, 2013, at 1:43 PM, Hannes Tschofenig <[e-mail]>
>>> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>
>>>> Hi all,
>>>>
>>>> I have just uploaded a new version of the additional data draft.
>>>>
>>>> The following changes have been made:
>>>> * Editorial changes throughout the document to improve readability
>>>> * James joined us as a co-author for his contributions to the document
>>>> * Section about the Content-Disposition Parameter added (as discussed
>>> on the list)
>>>> * Updated examples
>>>> * Included an additional example illustrating the provided-by element
>>>> * Fixed provided by schema. This caused changes to other schemas as
>>> well
>>>> * Re-wrote the privacy consideration section
>>>>
>>>> Here is the document:
>>>> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-10
>>>>
>>>> The diff can be found here:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-10
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>>>> Comment: GPGTools - http://gpgtools.org
>>>>
>>>> iQEcBAEBCgAGBQJR5DTXAAoJEGhJURNOOiAtT9MH/jnxPS0xShhw/OoYJP3HbWn2
>>>> gZTpxcEgW/iaR8nqgH7nydruzihDZhWB+rhy744JzKQuQGMFY1tbqwoBtsjcN8eZ
>>>> KihFwXxGYYYpLT3KOG0MNVim/kEFW+yURBAo2nhivF51t5rqJM76VRTUXjk94dgy
>>>> dFysUhx041OT6NsGuxGIcsW5X1snFgHhvims+P7NJt93cqmaPOoYHYkparcJEsqw
>>>> w4RcUUHWRGPUJ4e0wt45CdmYgz9CpR8wJcYHQbxhjB/K7ZlQXhJ1bNQ4njWep2F7
>>>> 4omKn7osh8JqcxPYb21gAmdo0oLglrNwW++Z8g3DIhRXp6pH8NGDiiWt0XF2ri8=
>>>> =Txce
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>