Subject: [Ecrit] Additional Data Draft (again)

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 9 Mar 2016 16:05:08 +0100

Hi all,

James has been working in EENA on extensions for the additional data
draft and has also been playing around with code. As part of that
exercise he discovered bugs, which I like to bring to your attention.

As a high-level summary, we believe the following changes are needed
based on the bugs he discovered:
 * fixes to examples,
 * normative changes to the vcard XML schema found in the appendix, and
 * addition of a new IANA registry.

Here are the details:

-- Issue #1: James discovered a bug in Figure 17 of version -37 with
regard to the xc namespace prefix. Here is the snippet:

   <pi:DataProviderContact
   xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">

This is a copy-and-paste error since the referenced schemas at
http://ip-emergency.net/additional-data.zip contain the correct instance
documents.

-- Issue #2: James noticed a problem with the value 'main-number' used
in the following example:

      <tel>
            <parameters>
               <type>
                  <text>work</text>
                  <text>voice</text>
                  <text>*main-number*</text>
               </type>
            </parameters>
            <uri>sips:[email-masked] <http://example.com></uri>
      </tel>

main-number is not a valid type according the schema from Section 6.4.1
of RFC 6351. RFC 6351 lists the valid types as:

  * “work"
  * “home"
  * “text"
  * “voice"
  * “fax"
  * “cell"
  * “video"
  * ”pager"
  * "textphone"

This looks like a minor issue since we already state in the text that
'main-number' is a new value this draft introduces. However, the way the
XML schema in RFC 6351 is defined you cannot just add values since it
contains an enumeration with a fixed list of values.

The reason we have not noticed this earlier is because the example in
Figure 17 the content of the zip file is again out of sync with what is
in the draft. The example in the zip file does not contain the text
main-number and hence no error shows up. Of course, if I use the
main-number (as shown in the body of the draft) then an error is thrown.

Needless to say that this is a problem.

What can we do about this?

Currently, the XML schema in Appendix A is informative and the Relax NG
schema in RFC 6351 is normative.

We can make the XSD schema currently found in Appendix A normative and,
at least, add this new value (main-number). Then,
there is the question whether this will be the only value ever added. If
so, then it is fine to add it to the enumeration. If it is not then we
need to go a different path, namely to just declare it as a string and
register the values with IANA.

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!

Ciao
Hannes

---

From: James Winterbottom <[email-masked]>
Date: Thu, 10 Mar 2016 07:45:34 +1100

It is also worth noting that we will require a new namespace for the cad schema if we make it normative and update the examples accordingly.

Cheers
James

Sent from my iPhone

> On 10 Mar 2016, at 2:05 am, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Randall Gellens <[email-masked]>
Date: Wed, 9 Mar 2016 16:35:31 -0800

At 4:05 PM +0100 3/9/16, Hannes Tschofenig wrote:

>    * "work"
>    * "home"
>    * "text"
>    * "voice"
>    * "fax"
>    * "cell"
>    * "video"
>    * "pager"

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
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
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: Thu, 10 Mar 2016 12:23:05 +1100

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Mar 2016 13:55:40 +1100

James is right here.  An implementation of RFC 6351 will choke on this
new value.

The correct way to address this is to make a new schema that patches
the RFC 6351 schema.  In relax NG that's easy [1], because you only
have to redefine "property-tel".  But you do need to give it a new
namespace.  An XML schema is tough.

[1] http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html

On 10 March 2016 at 12:23, 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
>
>
>
>
> 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

---

From: Randall Gellens <[email-masked]>
Date: Fri, 11 Mar 2016 12:31:17 -0800

At 12:23 PM +1100 3/10/16, James Winterbottom 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.

I never said to publish a document with defects.  I was proposing one 
approach to solve the defects without opening up a lot of new work.

>
>  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.

So we also need to add a new namespace for the corrected 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.

I said that was the cleaner approach, and one I'd take with a new 
document.  I just don't think we need to do all those steps now.

>>  On 10 Mar 2016, at 11:35 am, Randall Gellens 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>> 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
>> 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: ---------------
One might say that the right's approach is to release the dogs of the
market, throwing all traditional values into disarray; and then, in
this tumult of insecurity, offer themselves up as the last bastion of
order and hierarchy, the stalwart defenders of the authority of
churches and fathers against the barbarians they have themselves
unleashed.  A scam it may be, but it is a remarkably effective one;
and one result is that the right ends up seeming to have a monopoly on
value.  --David Graeber, "Army of Altruists", Harper's, January 2007.

---

From: James Winterbottom <[email-masked]>
Date: Sun, 13 Mar 2016 14:33:46 +1100

> On 12 Mar 2016, at 7:31 am, Randall Gellens <[email-masked]> wrote:
> 

[AJW] I am afraid that we do and this means that we should probably normatively update RFC 6351

> document.  I just don't think we need to do all those steps now.

[AJW] I don’t think that it is a question of “need to do all those steps now”. If we don’t do them, then they are not done. This isn’t something that we are going to go and clean up later. We aren’t going to change the structure, or even make other corrections that I would dearly love to see. We are just going to change the name space, change an enumeration into a token that is filled from a repository, and make the schema normative. Small changes, but will allow the document to move forward in a clean fashion.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 15 Mar 2016 15:56:42 -0400

> of RFC 6351. RFC 6351 lists the valid types as:

Is there a reason why something new is being invented instead of using
the parameter preference feature built into xCard/vCard/jCard ?

Also, the URI element above is broken. The angle bracket(s) of the
embedded URI need to be escaped.

-andy

---

From: James Winterbottom <[email-masked]>
Date: Wed, 16 Mar 2016 07:04:40 +1100

Given that the it is inside the <tel> section, I am not convinced that it makes sense to have the http URI in there anyway… *8)

> On 16 Mar 2016, at 6:56 am, Andrew Newton <[email-masked]> wrote:
>

---

From: Dan Banks <[email-masked]>
Date: Wed, 16 Mar 2016 15:50:40 +0000

When looking at this issue, I discovered a couple things that may be helpful.  xCard is intended to allow a 1:1 mapping to vCard (according to the statement in the RFC 6351 intro).  So I went back to RFC 6350, and it seems the type parameter is intended to both be extensible via the use of a registry, and with unregistered values (typically for experimentation or private use):
type-param-tel = "text" / "voice" / "fax" / "cell" / "video"
                    / "pager" / "textphone" / iana-token / x-name

The registry is at http://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml and per section 10.2.1, updates requires expert review and an RFC.

RFC 6351 does not appear to accommodate this in the schema it provides, and that seems to be contrary to the intent of a 1:1 mapping.  Sure enough, this has already been discovered, reported, and verified as errata 3047:

-----------------
Section Appendix A. says:

# 6.4.1
property-tel = element tel {
    element parameters {
      param-altid,
      param-pid,
      param-pref,
      element type {
        element text { "work" | "home" | "text" | "voice"
                     | "fax" | "cell" | "video" | "pager"
                     | "textphone" }+
      }?,
      param-mediatype
    }?,
    (value-text | value-uri)
  }

It should say:

# 6.4.1
property-tel = element tel {
    element parameters {
      param-altid,
      param-pid,
      param-pref,
      element type {
        element text { "work" | "home" | "text" | "voice"
                     | "fax" | "cell" | "video" | "pager"
                     | "textphone" | x-name | iana-token }+
      }?,
      param-mediatype
    }?,
    (value-text | value-uri)
  }
--------------------

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.

Dan Banks

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of James Winterbottom
Sent: Tuesday, March 15, 2016 4:05 PM
To: Andrew Newton
Cc: [email-masked]
Subject: Re: [Ecrit] Additional Data Draft (again)

>> -- Issue #2: James noticed a problem with the value 'main-number' 
>> used in the following example:
>> 
>>      <tel>
>>            <parameters>
>>               <type>
>>                  <text>work</text>
>>                  <text>voice</text>
>> main-number is not a valid type according the schema from Section 
>> 6.4.1 of RFC 6351. RFC 6351 lists the valid types as:
>> 
>>  * “work"
>>  * “home"
>>  * “text"
>>  * “voice"
>>  * “fax"
>>  * “cell"
>>  * “video"
>>  * ”pager"
>>  * "textphone"
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 Mar 2016 11:54:06 -0700

At 3:50 PM +0000 3/16/16, Dan Banks wrote:

>  	- 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.

-------------- Randomly selected tag: ---------------
A list is only as strong as its weakest link.  --Donald Knuth

---

From: James Winterbottom <[email-masked]>
Date: Thu, 17 Mar 2016 18:51:48 +1100

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:
>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 18 Mar 2016 14:51:25 -0700

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
>
>
>

-------------- Randomly selected tag: ---------------
640K ought to be enough for anybody.  --Bill Gates, 1981

---

From: James Winterbottom <[email-masked]>
Date: Sat, 19 Mar 2016 09:05:30 +1100

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:
>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 18 Mar 2016 16:20:36 -0700

Thanks for listing the steps, James.

Hannes, does this sound like the plan to you?

Brian, do you concur?

Thanks everyone.

-------------- Randomly selected tag: ---------------
Conscience is the inner voice that warns us somebody is looking
                                                --H. L. Mencken

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Mar 2016 13:26:23 +0100

Hi Dan,

thanks a lot for your feedback. I did not check the errata and therefore
failed to notice that this issue already surfaced earlier.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Mar 2016 14:09:21 +0100

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

---

From: Dan Banks <[email-masked]>
Date: Mon, 21 Mar 2016 16:20:22 +0000

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.

Ciao
Hannes

On 03/19/2016 12:20 AM, Randall Gellens wrote:
>>>>>>     - we should seek review of "main-number" as an addition to 
>>>>>> the  registry, and update the additional data draft to formally 
>>>>>> make  that addition.
>>>>>
>>>>>  -------------- Randomly selected tag: ---------------  A list is 
>>>>> only as strong as its weakest link.  --Donald Knuth
>>>
>>>
>>>  --
>>>  Randall Gellens
>>>  -------------- Randomly selected tag: ---------------  640K ought 
>>> to be enough for anybody.  --Bill Gates, 1981
> 
>

---

From: James Winterbottom <[email-masked]>
Date: Tue, 22 Mar 2016 04:13:24 +1100

Hi Dan,

The “held for update” status is used for issues found that are not necessary for an update to the RFC, so “verified” is the only status available that fits the problem. It isn’t clear to me that this means that it is okay to make changes to the schema in a registered namespace, it just says that the errata should be available to implementors. That is to say does the errata say “be aware” of the limitation that shouldn’t be there or fix the schema in the current namespace and move on? I think that the Errata status definitions could be more clear on this. I am not keen in just changing bits of a registered schema because there are errors and leaving it in the same namespace, this will certainly lead to implementation errors.

In the changes that have just gone in, the XML has moved to being normative and it spells out that it is for additional-data, so while x-names might be useful in a straight vCard, I question their applicability to the additional-data work.

To my mind the approach we have taken is unambiguous, where suppositions about what the errata actual means could lead to problems.

Cheers
James

> On 22 Mar 2016, at 3:20 am, Dan Banks <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2016 20:31:15 +0100

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:
> 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,
> 
>  Ciao Hannes
>>> 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
>>> 
>>> 
>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> 
>>>>>>> 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.
>>>>>> 
>>>>>> -- 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
>> 
>> 
>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Mar 2016 17:05:59 -0700

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:

>  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)

-------------- Randomly selected tag: ---------------
Military justice is to justice what military music is to music.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 26 Mar 2016 14:58:43 +0100

Hi Randy,

I believe we should reach out to the IESG and ask them a question about
their approach regarding formal languages and the use of data definition
languages in particular.

It seems that we are not particularly lucky in the IETF with the use of
formal languages for describing protocol exchanges. While we excessively
use them we often get them wrong for a number of reasons.

In this specific case it seems that the authors of the XML xcard spec
got it wrong and fixed the bug in a way that is also violating the way
how these formal language is supposed to work. The correct way IMHO
would have been to issue a new schema (+ new namespace + new schema
registration). For whatever reason they haven't gone that route.

Now, for us the question is why cannot we cheat here as well?
Or, to phrase it differently, does anyone even care about these data
definition languages at all in IETF documents.

Ciao
Hannes

---

From: Randall Gellens <[email-masked]>
Date: Sat, 26 Mar 2016 12:31:20 -0700

Hi Hannes,

I agree with you that formal languages have been a problem in our 
documents for decades.  In the particular case of additional-data and 
xCard, you are right that we already have two schemas using the same 
namespace, so the question is, should we do one more, or not?  I 
believe Dan has said he sees more problems if we define a new 
namespace then if we don't, but James disagrees.

At 2:58 PM +0100 3/26/16, Hannes Tschofenig wrote:

>  Attachment converted: TiLand:signature 1719.asc (    /    ) (0336FF14)

-------------- Randomly selected tag: ---------------
Do not condemn the judgement of another because it differs from your
own.  You may both be wrong.                              --Dandemis