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

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: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
> Brian Rosen
> Sent: 15 July 2013 20:14
> To: Hannes Tschofenig
> Cc: ecrit@ietf.org 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 <Hannes.Tschofenig@gmx.net>
> 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
> > Ecrit@ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit