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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Jul 2013 19:43:50 +0200

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Jul 2013 15:13:41 -0400

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 <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi all, 
> 
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Jul 2013 10:19:01 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Rosen
> Sent: 15 July 2013 20:14
> To: Hannes Tschofenig
> Cc: [email-masked] WG
> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10
> 
> 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
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Jul 2013 09:52:03 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jul 2013 12:57:33 -0400

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

	Thanks,
	Paul