Re: [Ecrit] Additional Data Draft (again)

[James Winterbottom <[e-mail]>]

Point 1 is not a simple IANA change. The schema is in error, we wish to introduce a new IANA token into the registry for use in a way that schema will break validation for. So the registration is fine, using it is another question.

Sent from my iPhone

> On 6 Apr 2016, at 12:05 am, "Drage, Keith (Nokia - GB)" <[e-mail]> wrote:
> 
> I did a quick skim and noted two issues.
>  
> 1)    I see no reason why RFC 5226 needs to be a normative reference. This is a set of instructions that IANA needs to follow, and we do not need to write normative requirements on IANA. This should be moved to the informative references. In any case, the actions of IANA are outside the scope of the document as defined in section 3.
> 2)    Section 3 somehow implies that emergency calls are exempt from privacy considerations. At least from a European viewpoint this is not true. The privacy legislation in Europe makes no specific mention of emergency calls, and therefore it is up to those organizations making use of the data as to whether any of the other exemptions might apply instead. I would suggest that “The data structures defined here are not appropriate to be conveyed in non-emergency calls because they carry sensitive and private data.” is deleted from section 3, and possibly replaced with some statement about taking account of any local regulatory framework on privacy.
>  
> Regards
>  
> Keith
>  
> From: Ecrit [mailto:[e-mail]] On Behalf Of EXT Alissa Cooper
> Sent: 05 April 2016 22:33
> To: Randall Gellens
> Cc: Brian Rosen; [e-mail]
> Subject: Re: [Ecrit] Additional Data Draft (again)
>  
> Thanks Randy.
>  
> We will unstick this in the RFC Editor’s queue on April 15. If anyone has strong objections to the approach in this draft (acknowledging that there is no perfect compromise here and that the schema is non-normative), please send them to the list before then.
>  
> Thanks,
> Alissa
>  
> On Apr 5, 2016, at 6:12 PM, Randall Gellens <[e-mail]> wrote:
>  
> Thanks very much to everyone who helped with this.  Version -38 has been uploaded to the drafts repository.  It fixes all identifies bugs and avoids any substantial changes.
> 
> We decided not to change the namespace, per Dan's warning that this would cause further problems (sorry, James), and the xCard schema is again in Appendix A.  We did not add "x-" and "vnd-" tokens to the xCard schema since these are not used in the draft.
> 
> --Randy
> 
> 
> At 5:05 PM -0700 3/21/16, Randall Gellens wrote:
> 
> 
> So, I think we have three remaining open questions, which are:
> 
> Should we go with -38 as it is (new namespace and schema normative) or
> 
> (1) Revert namespace to original name?
> (2) Revert schema to informative?
> (3) Do we add to the schema "x-" and "vnd-" tokens as well as IANA tokens?
> 
> 
> At 8:31 PM +0100 3/21/16, Hannes Tschofenig wrote:
> 
> 
>  Hi Dan,
> 
>  the situation looks a bit tricky.
> 
>  It seems that accepting the errata wasn't quite the right thing since it
>  changes an XML schema without defining a new namespace and without
>  registering the new schema.
> 
>  In some sense, we could be equally "relaxed" and just change their
>  schema again (without changing the namespace).
> 
>  I believe it ultimately boils down to the question what the value of the
>  XML schema actually is.
> 
>  I see a couple of different usages:
> 
>  a) If someone uses the XML schema to generate code then anything other
>  than defining our own, corrected XML schema will lead to problems
> 
>  b) If the XML schema is only used by an implementer to validate instance
>  documents than defining our own, corrected XML schema will also be needed.
> 
>  c) If the XML schema is, however, only used as a different way of
>  reading the document content then changing the schema within the text
>  (as we had done up to version -37) is fine.
> 
>  I personally think that most developers don't do (a) and (b) and that's
>  why most of the XML schemas in technical specifications are actually
>  broken (not only in the IETF but also elsewhere). The "most developers"
>  is important here since we have found developers, such as Philip, who
>  actually produce code based on the schema (which is why he found problems).
> 
>  However, by making these types of "fixes" we are obviously not going to
>  improve the situation. It is also the question what the IESG and the
>  area directors think about this situation. In some sense it is not only
>  about the use of XML schemas but the issue is a bit more broadly related
>  to the use of formal languages in the IETF in general. There are many
>  other places where we messed things up, such as with ABNF.
> 
>  Ultimately, it fear it will boil down to a different question, namely:
>  What does it mean if the VCard schema in our spec is different from the
>  original VCard schema in terms of re-use with existing software.
> 
>  Ciao
>  Hannes
> 
> 
>  On 03/21/2016 05:20 PM, Dan Banks wrote:
> 
>  I'm not entirely sure this is the right way to go.
> 
>  First, if the values can only come from the registry, that still
>  excludes the x-name values (which seems to me to be nearly as big of
>  an omission as leaving out the iana-token values).
> 
>  Second, is changing the namespace really necessary?  Perhaps I don't
>  understand the errata process correctly, but James' argument that the
>  RFC 6351 schema error requires it does not seem persuasive to me in
>  light of the existing errata already being verified status (as
>  opposed to held for update).  That suggests to me that any RFC 6351
>  implementation should take this errata into account.
> 
>  Changing the namespace also brings new complications: the xCards will
>  not be interoperable with an RFC 6351 implementation (even one that
>  considers the errata), and the Appendix A schema would have to be
>  normative.  This essentially redefines the entire xCard schema with
>  an XML schema when the previous version was a Relax NG schema.  This
>  doesn't seem like a good idea to me.
> 
>  Dan Banks
> 
>  -----Original Message----- From: Hannes Tschofenig
>  [mailto:[e-mail]] Sent: Sunday, March 20, 2016 9:09
>  AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew
>  Newton; [e-mail] Subject: Re: [Ecrit] Additional Data Draft
>  (again)
> 
>  Hi Randy, Hi James,
> 
>  the proposal makes sense to me an I have been working on an update to
>   > reflect these changes.
> 
> 
>  Here is the link to the work in progress document:
> 
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/draft-ietf-ecrit-additional-data-38.txt
> 
>   Ciao Hannes
> 
>  On 03/19/2016 12:20 AM, Randall Gellens wrote:
> 
>  Thanks for listing the steps, James.
> 
>  Hannes, does this sound like the plan to you?
> 
>  Brian, do you concur?
> 
>  Thanks everyone.
> 
>  At 9:05 AM +1100 3/19/16, James Winterbottom wrote:
> 
> 
>  So, just make sure I am clear on what the plan is: 1) Remove the
>  enumeration for the schema so all values now come from the
>  registry only 2) Add main number to the registry 3) Change the
>  namespace 4) Update all examples to use the new namespace 5)
>  register the namespace and schema with IANA
> 
>  Cheers James
> 
> 
> 
>  On 19 Mar 2016, at 8:51 am, Randall Gellens
>  <[e-mail]> wrote:
> 
>  I'm OK with changing the namespace if we need to.
> 
>  At 6:51 PM +1100 3/17/16, James Winterbottom wrote:
> 
> 
>  I think that the general approach is okay, I remain
>  unconvinced that we don't need a new namespace however,
>  because the schema in RFC 6351 is normative and it has an
>  error and our solution requires the error be corrected.
> 
>  Cheers James
> 
> 
> 
>  On 17 Mar 2016, at 5:54 am, Randall Gellens
>  <[e-mail]> wrote:
> 
>  At 3:50 PM +0000 3/16/16, Dan Banks wrote:
> 
> 
>  I am not very familiar with the process around updating
>  documents,  but to me this suggests: - we should not need
>  to do an update to RFC 6351, - we should fix the
>  informative schema in the additional data document to
>  take into account the verified errata (there are
>  several), - we should seek review of "main-number" as an
>  addition to the  registry, and update the additional data
>  draft to formally make  that addition.
> 
>  This sounds reasonable to me.  We also won't need to change
>  the namespace.
> 
>  -- Randall Gellens Opinions are personal;    facts are
>  suspect;    I speak for myself only -------------- Randomly
>  selected tag: ---------------  A list is only as strong as
>  its weakest link.  --Donald Knuth
> 
> 
>  -- Randall Gellens Opinions are personal;    facts are suspect;
>  I speak for myself only -------------- Randomly selected tag:
>  ---------------  640K ought to be enough for anybody.  --Bill
>  Gates, 1981
>  
> 
>  
> 
> 
> 
>  Content-Type: application/pgp-signature; name="signature.asc"
>  Content-Description: OpenPGP digital signature
>  Content-Disposition: attachment; filename="signature.asc"
> 
>  Attachment converted: TiLand:signature 1702.asc (    /    ) (0331F6EF)
> 
> 
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Military justice is to justice what military music is to music.
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Not knowing is much more interesting than believing an answer which
> might be wrong.                              --Richard Feynman
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>  
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit