Subject: [Simple] [Technical Errata Reported] RFC4480 (3121)

From: RFC Errata System <[email-masked]>
Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)

The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre <[email-masked]>

Section: 7.2

Original Text
-------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Corrected Text
--------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="lunch"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Notes
-----
Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Feb 2012 16:36:05 -0600

This erratum will change the schema for RPID registered with IANA.
(I've confirmed with IANA that they can handle a change made this way).

There have been discussions in several groups about registry maintenance 
with some
confusion about whether changes can be made to an existing schema. Our 
XML experts
(Peter in this case) assure us that schema changes are OK.

In most cases, I would ask that a change to a registration like this be 
done with a document.
That's definitely required if we're doing anything more than correcting 
an obvious mistake.
In this case, however, it is obvious that these values were intended to 
be included in the
affected list from the beginning.

I plan to approve this erratum a week from today. If you believe this is 
not the right thing to do,
please speak now.

RjS

-------- Original Message --------
Subject: 	[Technical Errata Reported] RFC4480 (3121)
Date: 	Tue, 14 Feb 2012 13:54:39 -0800 (PST)
From: 	RFC Errata System <[email-masked]>
To: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
CC: 	[email-masked], [email-masked], [email-masked]

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre<[email-masked]>

Section: 7.2

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: Ben Campbell <[email-masked]>
Date: Tue, 14 Feb 2012 16:38:50 -0600

On Feb 14, 2012, at 4:36 PM, Robert Sparks wrote:

> There have been discussions in several groups about registry maintenance with some
> confusion about whether changes can be made to an existing schema. Our XML experts
> In most cases, I would ask that a change to a registration like this be done with a document.
> That's definitely required if we're doing anything more than correcting an obvious mistake.
> In this case, however, it is obvious that these values were intended to be included in the 
> I plan to approve this erratum a week from today. If you believe this is not the right thing to do,
> please speak now.
> 

While you didn't ask for concurring opinions: I concur with the approach.

> To:	[email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> <Attached Message Part.txt>_______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Feb 2012 15:08:50 -0800

Since the extension point in the existing schema is marked ##other and lax,
a processor with an old schema will reject an instance document that
contains the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch element.

That's a backwards compatibility break.

--Martin

On 14 February 2012 14:36, Robert Sparks <[email-masked]> wrote:

> -------- Original Message --------  Subject: [Technical Errata Reported]
> RFC4480 (3121)  Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)  From: RFC
> Errata System <[email-masked]> <[email-masked]>  To:
> [email-masked], [email-masked], [email-masked],
> [email-masked], [email-masked]  CC: [email-masked],
> [email-masked], [email-masked]
>
> You may review the report below and at:http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121
>
> Reported by: Peter Saint-Andre <[email-masked]> <[email-masked]>
>
> Section: 7.2
>
> Original Text
> -------------
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Feb 2012 10:58:24 -0700

Naturally, it would make sense to check with current implementers. In
particular, is anyone doing schema validation?

On 2/14/12 4:08 PM, Martin Thomson wrote:
> Since the extension point in the existing schema is marked ##other and
> lax, a processor with an old schema will reject an instance document
> that contains the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch
> element.
> 
> On 14 February 2012 14:36, Robert Sparks <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     <mailto:[email-masked]>
>     To: 	[email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>
>     CC: 	[email-masked] <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>
> 
> 
> 
>     http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121 <http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121>
> 
>     Reported by: Peter Saint-Andre <[email-masked]> <mailto:[email-masked]>
> 
>     Section: 7.2
> 
>     Original Text
>     -------------
>     [email-masked] <mailto:[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 16 Feb 2012 19:11:44 +0100

Hi,

> particular, is anyone doing schema validation?

We are currently doing schema validation both on the server side (OpenXCAP, for pidf-manipulation) and client side (SIPSIMPLE SDK).

I didn't check the details of the errata, but if it's reasonable I guess we could see if we can workaround it for a while and make the switch after a reasonable amount of time.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Feb 2012 20:26:17 +0200

I am curious: Why you do schema validation?

When you receive a PIDF document in a SIP message then you will have to parse it. Since we put any namespace="##other" statements in nearly all our schema files I am curious what you actually going to learn from the validation since almost everything validates without error.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Feb 2012 11:38:54 -0800

> particular, is anyone doing schema validation?

...and who is using RPID?  The intersection of those sets is probably
small, possibly empty.  And you want empty (or to exclude those who
are willing to make a minor patch).

I know that schema validation was the default mode of operation where
I used to work.  RPID was not.

Sounds like more than an erratum's worth of work to me.  Do you have a
problem with noting the existence of the problem without specifying a
remedy?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Feb 2012 14:49:17 -0500

> When you receive a PIDF document in a SIP message then you will have to parse it. Since we put any namespace="##other" statements in nearly all our schema files I am curious what you actually going…

Uhhh - to detect changes like this one? :-)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Feb 2012 13:29:03 -0800

> Uhhh - to detect changes like this one? :-)

Or to detect random, valid gibberish in the stream.  Unknown elements
and attributes; bad cardinality; invalid lexical representations of
text; etc...

--Martin

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 20 Feb 2012 10:07:49 +0100

Hi,

> When you receive a PIDF document in a SIP message then you will have to parse it. Since we put any namespace="##other" statements in nearly all our schema files I am curious what you actually going…

Well, I like to do schema validation to al least know that the document doesn't violate the specified structure. Yes, you may put whatever you want in ##other, but PIDF does define certain elements, and those will not fall in the ##other bucket, so those should be validated.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 20 Feb 2012 11:39:42 +0100

Hi Pete,

> 
> I don't know anything about PIDF, but I know a bit about XML Schema and I
> think there might be some mis-understanding of what <xs:any
> namespace="##other"> does.
> 
> If you have a schema fragment like:
> 
>    <xs:element name="activities">
>      <xs:complexType>
>              <xs:choice>
>                <xs:element name="breakfast"
>                  type="empty" />
>                <xs:element name="dinner"
>                  type="empty" />
>                <xs:element name="meal"
>                  type="empty" />
>                <xs:any namespace="##other"
>                  maxOccurs="unbounded" processContents="lax"/>
>              </xs:choice>
>      </xs:complexType>
>    </xs:element>
> 
> Then the following would _violate_ the schema:
> 
> <activities><lunch/></activities>
> 
> The reason is that the <xs:any> element is specifying that the extension
> must be in an-other namespace, not the namespace specified by the schema.
> 
> Something like the following would be OK:
> 
> <activities>
>   <xmlns:v2="urn:ietf:params:xml:ns:pidf:rpid:v2" v2:lunch/>
> </activities>
> 
> So as I understand it, I believe this change could
> break existing implementations that choose to use schema
> validation.  Whether, given the state of current implementation, that is a issue in practice is a matter for the group.
> 

You are right, this was what was pointed out, that the change would make validating the current schema erroneous.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 20 Feb 2012 10:36:03 -0000

Original Message From: "Saúl Ibarra Corretgé"
>> When you receive a PIDF document in a SIP message then you will have to
>> parse it. Since we put any namespace="##other" statements in nearly all
>> our schema files I am curious what you actually going to learn from the
>> validation since almost everything validates without error.

> Well, I like to do schema validation to al least know that the document
> doesn't violate the specified structure. Yes, you may put whatever you
> want
> in ##other, but PIDF does define certain elements, and those will not fall
> in the ##other bucket, so those should be validated.

<activities>

So as I understand it, I believe this change could
break existing implementations that choose to use schema
validation.  Whether, given the state of current implementation, that is a 
issue in practice is a matter for the group.

HTH,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Feb 2012 08:56:42 -0600

Taking this back to the original question:

It looks like we have a rough consensus that the proposed change is not backward's compatible for devices that validate schemas. Does anyone disagree at this point? 

What does that mean for the question of fixing the schema via an erratum?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Feb 2012 10:41:05 -0800

> What does that mean for the question of fixing the schema via an erratum?

Add a note to the erratum: The "lunch" element cannot be used without
risk of the document being rejected.

--Martin

p.s. Non-existence of a midday meal is consistent with some workplace
policies.  However, in some jurisdictions such a policy may be
considered illegal according to workplace legislation.