Subject: Re: [Ecrit] Additional Data Draft (again)

From: Randall Gellens <[email-masked]>
Date: Tue, 5 Apr 2016 14:12:08 -0700

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:[email-masked]] Sent: Sunday, March 20, 2016 9:09
>>>   AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew
>>>   Newton; [email-masked] 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
>>>>>>   <[email-masked]> 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
>>>>>>>>   <[email-masked]> 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
>  [email-masked]
>  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

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 5 Apr 2016 18:32:48 -0300

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 <[email-masked]> 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
> 
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
> 
> 
> -- 
> Randall Gellens
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: James Winterbottom <[email-masked]>
Date: Tue, 5 Apr 2016 23:15:29 +0200

I am not in favour of this decision.
Multiple different schemas with same namespace is bad practice.

Cheers
James

Sent from my iPhone

> On 5 Apr 2016, at 11:12 pm, Randall Gellens <[email-masked]> wrote:
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 5 Apr 2016 22:05:56 +0000

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:[email-masked]] On Behalf Of EXT Alissa Cooper
Sent: 05 April 2016 22:33
To: Randall Gellens
Cc: Brian Rosen; [email-masked]
Subject: Re: [Ecrit] Additional Data Draft (again)

Thanks Randy.

Thanks,
Alissa

On Apr 5, 2016, at 6:12 PM, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

--Randy

 Hi Dan,

 Ciao
 Hannes

 Dan Banks

 -----Original Message----- From: Hannes Tschofenig
 [mailto:[email-masked]] Sent: Sunday, March 20, 2016 9:09
 AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew
 Newton; [email-masked]<mailto:[email-masked]> Subject: Re: [Ecrit] Additional Data Draft
 (again)

 Hi Randy, Hi James,

  Ciao Hannes

 Brian, do you concur?

 Thanks everyone.

 Cheers James

 On 19 Mar 2016, at 8:51 am, Randall Gellens
 <[email-masked]<mailto:[email-masked]>> wrote:

 Cheers James

 On 17 Mar 2016, at 5:54 am, Randall Gellens
 <[email-masked]<mailto:[email-masked]>> wrote:

-------------- Randomly selected tag: ---------------

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

-------------- Randomly selected tag: ---------------

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Randall Gellens <[email-masked]>
Date: Tue, 5 Apr 2016 15:09:15 -0700

Hi James,

I know you are not happy about this.  Unfortunately, there was no 
ideal answer, so we went with what seems the least bad approach.

--Randy

At 11:15 PM +0200 4/5/16, James Winterbottom 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
>>
>>

-------------- Randomly selected tag: ---------------
If we do not change our direction we are likely to end up where we are
headed.

---

From: James Winterbottom <[email-masked]>
Date: Wed, 6 Apr 2016 03:13:23 +0200

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

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 6 Apr 2016 01:36:19 +0000

I do not believe you are correct.

IANA works as a subcontractor for IETF in maintaining a set of registries. Putting something into the registry does not change anything in the protocol, it merely ensures that no one else tries to use that value for something else, and provides an informative pointer as to which documents the real allocation may be found in. We do not need normative text to get IANA to do something, in the same way as we don’t need a normative statement to ensure the RFC editor edits the document in accordance with the IETF drafting rules.

Ensuring that the schema does not break validation is the responsibility of the text in the RFC, not the registry.

Keith

From: EXT James Winterbottom [mailto:[email-masked]]
Sent: 06 April 2016 02:13
To: Drage, Keith (Nokia - GB)
Cc: EXT Alissa Cooper; Randall Gellens; Brian Rosen; [email-masked]
Subject: Re: [Ecrit] Additional Data Draft (again)

Sent from my iPhone

On 6 Apr 2016, at 12:05 am, "Drage, Keith (Nokia - GB)" <[email-masked]<mailto:[email-masked]>> wrote:
I did a quick skim and noted two issues.

Regards

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Alissa Cooper
Sent: 05 April 2016 22:33
To: Randall Gellens
Cc: Brian Rosen; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] Additional Data Draft (again)

Thanks Randy.

Thanks,
Alissa

--Randy

 Hi Dan,

 Ciao
 Hannes

 Dan Banks

 Hi Randy, Hi James,

  Ciao Hannes

 Brian, do you concur?

 Thanks everyone.

 Cheers James

 Cheers James

---

From: James Winterbottom <[email-masked]>
Date: Wed, 6 Apr 2016 11:37:59 +1000

So just to make sure I get this right.
You believe that text in the RFC can update the schema, without having to republish the schema?

> On 6 Apr 2016, at 11:36 am, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
> On 6 Apr 2016, at 12:05 am, "Drage, Keith (Nokia - GB)" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Ecrit [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of EXT Alissa Cooper
> Cc: Brian Rosen; [email-masked] <mailto:[email-masked]>
> On Apr 5, 2016, at 6:12 PM, Randall Gellens <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  [mailto:[email-masked] <mailto:[email-masked]>] Sent: Sunday, March 20, 2016 9:09
>  Newton; [email-masked] <mailto:[email-masked]> Subject: Re: [Ecrit] Additional Data Draft
>  (again)
> 
>  Hi Randy, Hi James,
> 
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/draft-ietf-ecrit-additional-data-38.txt <https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/draft-ietf-ecrit-additional-data-38.txt>
> 
>   Ciao Hannes
> 
>  <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 6 Apr 2016 01:40:02 +0000

The schema is in the RFC. That is the normative version.

Keith

Sent: 06 April 2016 02:38

On 6 Apr 2016, at 11:36 am, Drage, Keith (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

Keith

Cc: EXT Alissa Cooper; Randall Gellens; Brian Rosen; [email-masked]<mailto:[email-masked]>

Sent from my iPhone

Regards

Keith

Thanks Randy.

Thanks,
Alissa

--Randy

 Hi Dan,

 Ciao
 Hannes

 Dan Banks

 Hi Randy, Hi James,

  Ciao Hannes

 Brian, do you concur?

 Thanks everyone.

 Cheers James

 Cheers James

---

From: James Winterbottom <[email-masked]>
Date: Wed, 6 Apr 2016 11:41:07 +1000

Yes, and, as specified, it cannot use the new token we are introducing.

> On 6 Apr 2016, at 11:40 am, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
> On 6 Apr 2016, at 11:36 am, Drage, Keith (Nokia - GB) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: EXT James Winterbottom [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: EXT Alissa Cooper; Randall Gellens; Brian Rosen; [email-masked] <mailto:[email-masked]>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 6 Apr 2016 11:32:20 +0000

But that is nothing to do with IANA.

I am not an XML expert, but a schema is defined by an RFC. If another RFC needs to change it, it needs a point of extension somewhere in the original schema, and then the new RFC needs to proposal that extension.

Otherwise the new RFC needs to do a delete all and replace on the old RFC.

Regards

Keith

Sent: 06 April 2016 02:41

On 6 Apr 2016, at 11:40 am, Drage, Keith (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

Keith

Keith

Sent from my iPhone

Regards

Keith

Thanks Randy.

Thanks,
Alissa

--Randy

 Hi Dan,

 Ciao
 Hannes

 Dan Banks

 Hi Randy, Hi James,

  Ciao Hannes

 Brian, do you concur?

 Thanks everyone.

 Cheers James

 Cheers James

---

From: James Winterbottom <[email-masked]>
Date: Wed, 6 Apr 2016 13:45:22 +0200

Thank you Keith that is my point exactly, but that is NOT what is being done.

Sent from my iPhone

> On 6 Apr 2016, at 1:32 pm, "Drage, Keith (Nokia - GB)" <[email-masked]> wrote:
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 6 Apr 2016 11:48:27 +0000

Right, so my point 1 is therefore fine from your perspective.

I am not going to take sides on whether the extra indication is required, but I would not that any coding (in this case a schema) should indicate how it is extensible and apparently this one does not.

Otherwise the fundamental aspects of forward compatibility have not been dealt with.

Regards

Keith

Sent: 06 April 2016 12:45

Sent from my iPhone

On 6 Apr 2016, at 1:32 pm, "Drage, Keith (Nokia - GB)" <[email-masked]<mailto:[email-masked]>> wrote:
But that is nothing to do with IANA.

Regards

Keith

Keith

Keith

Sent from my iPhone

Regards

Keith

Thanks Randy.

Thanks,
Alissa

--Randy

 Hi Dan,

 Ciao
 Hannes

 Dan Banks

 Hi Randy, Hi James,

  Ciao Hannes

 Brian, do you concur?

 Thanks everyone.

 Cheers James

 Cheers James

---

From: James Winterbottom <[email-masked]>
Date: Wed, 6 Apr 2016 22:08:32 +1000

Point 1 is from registering an entity in an IANA registry.

My issue, as you say, is that the schema can’t handle it and saying “just use it anyway” in the additional-data draft is not a reasonable solution.

Cheers
James

> On 6 Apr 2016, at 9:48 pm, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
> On 6 Apr 2016, at 1:32 pm, "Drage, Keith (Nokia - GB)" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 6 Apr 2016, at 11:40 am, Drage, Keith (Nokia - GB) <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Randall Gellens (IETF)" <[email-masked]>
Date: Wed, 6 Apr 2016 10:26:06 -0300

We did modify the schema; it contains an IANAtoken value. 

Sent from my iPad

> On Mar 9, 2016, at 10:23 PM, James Winterbottom <[email-masked]> wrote:
> 
> I totally disagree with this approach and the argument that the document is far progressed not a reasonable excuse for publishing a document that has clear issues.
> 
> The approach below results in two different schemas with the same namespace one of which is considered normative and the other informative yet the additional-data specification will require use of the informative schema.
> 
> What is the issue with altering the schema to accommodate what we want, move the undesirable token sets into a repository, change the namespace and making it normative?
> This ensures integrity of namespaces, it doesn’t really structurally change the document, but it does result in a much better outcome.
> 
> Cheers
> James
> 
> 
> 
> 
>> On 10 Mar 2016, at 11:35 am, Randall Gellens <[email-masked]> wrote:
>> 
>> At 4:05 PM +0100 3/9/16, Hannes Tschofenig wrote:
>> 
>>> 
>>> Because of this normative change we need to reach out to you. If you
>>> have other suggestions on what we should do please let us know!
>> 
>> The solution detailed by Hannes is a fine one, and is the approach I'd recommend if the draft was earlier in the process.  Given the late stage, my preference is to make minimal changes to the draft. The minimalist approach would be the following:
>> 
>>   (1) fix the example to use 'main-number'
>>   (2) fix the xCard schema in Appendix A to add 'main-number' to the list of values
>>   (3) in the text in Section 4 that normatively adds 'main-number' to xCard, add an explanatory note that this new value is added in the xCard schema in the document but does not appear in RFC 6351, and note that should additional values be needed in the future, a new IANA registry of the values is recommended
>>   (4) in Appendix A, add a note that the schema is a simplified version of RFC 6351 with the addition of 'main-number'
>> 
>> These changes are a way to fix the document with the least impact. There is no requirement that XML schemas in RFCs be normative since the text is always normative.  There is no requirement to add an IANA registry when a list of strings is expanded.  In new documents, it is cleaner and better to do both, but to fix late-stage bugs we can skip both.
>> 
>> -- 
>> Randall Gellens
>> The great Chinese philosopher Confucius wrote, "When words lose their
>> meaning, the universe crumbles."  Theologically and cosmologically, I'm
>> not sure about that.  I am sure that when our government is
>> characterized as "amoral, godless and secularist," our public schools
>> as "failures" and our judges as "tyrants," simplistic solutions
>> promoted by demagogues will seem appropriate.
>> -- Barry Lynn,
>>  Executive Director of
>>  Americans United for Separation of Church and State
>>

---

From: James Winterbottom <[email-masked]>
Date: Wed, 6 Apr 2016 15:33:15 +0200

But it has kept the same namespace which is a clash.

Sent from my iPhone

> On 6 Apr 2016, at 3:26 pm, "Randall Gellens (IETF)" <[email-masked]> wrote:
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 6 Apr 2016 15:47:44 +0000

I do not think this an appropriate manner of extending a coding.

Regards

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of EXT James Winterbottom
Sent: 06 April 2016 14:33
To: Randall Gellens (IETF)
Cc: [email-masked]
Subject: Re: [Ecrit] Additional Data Draft (again)

Sent from my iPhone

On 6 Apr 2016, at 3:26 pm, "Randall Gellens (IETF)" <[email-masked]<mailto:[email-masked]>> wrote:
We did modify the schema; it contains an IANAtoken value.

Sent from my iPad

On Mar 9, 2016, at 10:23 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:
I totally disagree with this approach and the argument that the document is far progressed not a reasonable excuse for publishing a document that has clear issues.

Cheers
James

On 10 Mar 2016, at 11:35 am, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Randall Gellens <[email-masked]>
Date: Wed, 6 Apr 2016 08:52:07 -0700

We were faced with a dilemma without an ideal solution: as Dan Banks 
pointed out, the schema already changed without changing the 
namespace, so if we'd have incompatibilities if we changed the 
namespace as well as if we didn't.  Given that the schema is 
informative, with the text being normative, we went with not changing 
the namespace.  People are supposed to implement based on the 
normative text, not the schema (just as they aren't supposed to 
implement to examples).

At 3:47 PM +0000 4/6/16, Keith (Nokia - GB) Drage wrote:

>  On 6 Apr 2016, at 3:26 pm, "Randall Gellens (IETF)" 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
>  On Mar 9, 2016, at 10:23 PM, James Winterbottom 
> <<mailto:[email-masked]>[email-masked]> 
> wrote:
>
>  I totally disagree with this approach and the argument that the 
> document is far progressed not a reasonable excuse for publishing a 
> document that has clear issues.
>
>  The approach below results in two different schemas with the same 
> namespace one of which is considered normative and the other 
> informative yet the additional-data specification will require use 
> of the informative schema.
>
>  What is the issue with altering the schema to accommodate what we 
> want, move the undesirable token sets into a repository, change the 
> namespace and making it normative?
>  This ensures integrity of namespaces, it doesn't really 
> structurally change the document, but it does result in a much 
> better outcome.
>
>  Cheers
>  James
>
>
>
>
>
>  On 10 Mar 2016, at 11:35 am, Randall Gellens 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
>  The solution detailed by Hannes is a fine one, and is the approach 
> I'd recommend if the draft was earlier in the process.  Given the 
> late stage, my preference is to make minimal changes to the draft. 
> The minimalist approach would be the following:
>
>    (3) in the text in Section 4 that normatively adds 'main-number' 
> to xCard, add an explanatory note that this new value is added in 
> the xCard schema in the document but does not appear in RFC 6351, 
> and note that should additional values be needed in the future, a 
> new IANA registry of the values is recommended
>    (4) in Appendix A, add a note that the schema is a simplified 
> version of RFC 6351 with the addition of 'main-number'
>
>  These changes are a way to fix the document with the least impact. 
> There is no requirement that XML schemas in RFCs be normative since 
> the text is always normative.  There is no requirement to add an 
> IANA registry when a list of strings is expanded.  In new 
> documents, it is cleaner and better to do both, but to fix 
> late-stage bugs we can skip both.
>
>  -- 
>  Randall Gellens
>  <mailto:[email-masked]>[email-masked]
> 
> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>
>

-------------- Randomly selected tag: ---------------
Those who can make you believe absurdities can make you commit
atrocities.                                         --Voltaire

---

From: James Winterbottom <[email-masked]>
Date: Wed, 6 Apr 2016 17:56:22 +0200

As I said, the errata simply brings the error to the attention of implementors, it doesn't change the schema. Changes to the schema require a specification.

Sent from my iPhone

> On 6 Apr 2016, at 5:52 pm, Randall Gellens <[email-masked]> wrote:
> 
> We were faced with a dilemma without an ideal solution: as Dan Banks pointed out, the schema already changed without changing the namespace, so if we'd have incompatibilities if we changed the namespace as well as if we didn't.  Given that the schema is informative, with the text being normative, we went with not changing the namespace.  People are supposed to implement based on the normative text, not the schema (just as they aren't supposed to implement to examples).
> 
>> On 6 Apr 2016, at 3:26 pm, "Randall Gellens (IETF)" <<mailto:[email-masked]>[email-masked]> wrote:
>> 
>> On Mar 9, 2016, at 10:23 PM, James Winterbottom <<mailto:[email-masked]>[email-masked]> wrote:
>> 
>> This ensures integrity of namespaces, it doesn't really structurally change the document, but it does result in a much better outcome.
>> 
>> Cheers
>> James
>> 
>> 
>> 
>> 
>> 
>> On 10 Mar 2016, at 11:35 am, Randall Gellens <<mailto:[email-masked]>[email-masked]> wrote:
>> 
>> --  Randall Gellens

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Apr 2016 11:04:09 -0300

On 6 April 2016 at 12:52, Randall Gellens <[email-masked]> wrote:
> We were faced with a dilemma without an ideal solution: as Dan Banks pointed
> out, the schema already changed without changing the namespace, so if we'd
> have incompatibilities if we changed the namespace as well as if we didn't.
> Given that the schema is informative, with the text being normative, we went
> with not changing the namespace.  People are supposed to implement based on
> the normative text, not the schema (just as they aren't supposed to
> implement to examples).

The problem in this case is that the xCard specification IS the schema.

Let us not double-down on that error.  Yes, James is technically
right, but he is advocating log-jam.  Let's do as Randall says, but
ALSO take responsibility for our actions and commit to fixing xCard.

Caveat: If someone has an existing xCard implementation that would be
adversely affected by this, then that would invalidate this position.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 7 Apr 2016 08:41:20 -0700

>  adversely affected by this, then that would invalidate this position.

The additional-data draft has limited scope, so I think its schema 
and changes only affect implementations conformant to this document.

-------------- Randomly selected tag: ---------------
A truly happy person is one who can enjoy the scenery on a detour.

---

From: James Winterbottom <[email-masked]>
Date: Fri, 8 Apr 2016 01:50:13 +1000

I concede.

> On 8 Apr 2016, at 1:41 am, Randall Gellens <[email-masked]> wrote:
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 18 Apr 2016 10:06:52 -0700

Based on this list discussion the document has been unstuck in the RFC Editor’s queue.

Thanks all.

Alissa

> On Apr 7, 2016, at 8:50 AM, James Winterbottom <[email-masked]> wrote:
> 
> I concede.
>