Re: [Geopriv] New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

On 29 Feb 2012, at 16:39, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

Hi Ray,

 

ports are specified in HELD identity.

Indeed, and it was my idea in the first place.

But I didn't get it right.

 

Since the idea of HELD is to find out where the entity (as described by an IP address, etc.) is I wonder why it would be useful to include the destination address and port number (which is what a flow information adds).

Because on a CGN (and some other NATs) it's possible for the same source IP / port pair to be part of lots of flows at once.

It's only the complete 6-tuple that uniquely identifies the flow, and hence the internal target behind that NAT.

Ray

Re: [Geopriv] Fwd: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

> Since the idea of HELD is to find out where the entity (as described by an IP address, etc.) is I wonder why it would be useful to include the destination address and port number (which is what a flow information adds).

I can name that tune in 3 letters: CGN.

--Ricahrd

>
> Ciao
> Hannes
>
>
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of ext Ray Bellis
> Sent: Wednesday, February 29, 2012 6:29 PM
> To: GEOPRIV WG
> Subject: [Geopriv] Fwd: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt
>
> I've just submitted the draft detailed below, available at:
>
> http://tools.ietf.org/html/draft-bellis-geopriv-flow-identity-00
>
> Textually, it's somewhat rough, but I wanted to get feedback on the general idea (and the validity of the XSD) before spending too much time on the words themselves.
>
> Ray
>
>
> From: <internet-drafts@ietf.org>
> Subject: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt
> Date: 29 February 2012 16:26:12 GMT
> To: <ray.bellis@nominet.org.uk>
>
> A new version of I-D, draft-bellis-geopriv-flow-identity-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository.
>
> Filename: draft-bellis-geopriv-flow-identity
> Revision: 00
> Title: Flow Identity Extension for HELD
> Creation date: 2012-02-29
> WG ID: Individual Submission
> Number of pages: 12
>
> Abstract:
> Identity Extensions using an IP address and port number to request a
> location based on an individual packet flow have been previously
> specified by the GEOPRIV Working Group.
>
> However certain kinds on NAT require that identifiers for both ends
> of the packet flow must be specified in order to unambiguously
> satisfy the location request.
>
> This document specifieds a Flow Identity Extension for the HTTP-
> Enabled Location Delivery (HELD) Protocol to support this
> requirement.
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

On 29 Feb 2012, at 16:29, Ray Bellis wrote:

> Textually, it's somewhat rough

By which I meant to say, there's barely any text at all, yet...

Ray

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Fwd: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

Hi Ray,

 

ports are specified in HELD identity.

 

Since the idea of HELD is to find out where the entity (as described by an IP address, etc.) is I wonder why it would be useful to include the destination address and port number (which is what a flow information adds).

 

Ciao
Hannes

 

 

From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of ext Ray Bellis
Sent: Wednesday, February 29, 2012 6:29 PM
To: GEOPRIV WG
Subject: [Geopriv] Fwd: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

 

I've just submitted the draft detailed below, available at:

 

  http://tools.ietf.org/html/draft-bellis-geopriv-flow-identity-00

 

Textually, it's somewhat rough, but I wanted to get feedback on the general idea (and the validity of the XSD) before spending too much time on the words themselves.

 

Ray

From: <internet-drafts@ietf.org>

Subject: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

Date: 29 February 2012 16:26:12 GMT

To: <ray.bellis@nominet.org.uk>

 

A new version of I-D, draft-bellis-geopriv-flow-identity-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository.

Filename:      draft-bellis-geopriv-flow-identity
Revision:       00
Title:                                   Flow Identity Extension for HELD
Creation date:                     2012-02-29
WG ID:                              Individual Submission
Number of pages: 12

Abstract:
  Identity Extensions using an IP address and port number to request a
  location based on an individual packet flow have been previously
  specified by the GEOPRIV Working Group.

  However certain kinds on NAT require that identifiers for both ends
  of the packet flow must be specified in order to unambiguously
  satisfy the location request.

  This document specifieds a Flow Identity Extension for the HTTP-
  Enabled Location Delivery (HELD) Protocol to support this
  requirement.

 

[Geopriv] Fwd: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

I've just submitted the draft detailed below, available at:

  http://tools.ietf.org/html/draft-bellis-geopriv-flow-identity-00

Textually, it's somewhat rough, but I wanted to get feedback on the general idea (and the validity of the XSD) before spending too much time on the words themselves.

Ray

From: <internet-drafts@ietf.org>

Subject: New Version Notification for draft-bellis-geopriv-flow-identity-00.txt

Date: 29 February 2012 16:26:12 GMT

To: <ray.bellis@nominet.org.uk>

A new version of I-D, draft-bellis-geopriv-flow-identity-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository.

Filename: draft-bellis-geopriv-flow-identity
Revision: 00
Title: Flow Identity Extension for HELD
Creation date: 2012-02-29
WG ID: Individual Submission
Number of pages: 12

Abstract:
  Identity Extensions using an IP address and port number to request a
  location based on an individual packet flow have been previously
  specified by the GEOPRIV Working Group.

  However certain kinds on NAT require that identifiers for both ends
  of the packet flow must be specified in order to unambiguously
  satisfy the location request.

  This document specifieds a Flow Identity Extension for the HTTP-
  Enabled Location Delivery (HELD) Protocol to support this
  requirement.

[Geopriv] FW: New Version Notification for draft-ietf-geopriv-local-civic-03.txt

Hi All,

We have just submitted the updated Local Civic draft. We believe that this version addresses all outstanding issues including the IANA recommendation of modifying the existing CAType repository. If you have any issues please send them to the list.

Cheers
James

A new version of I-D, draft-ietf-geopriv-local-civic-03.txt has been successfully submitted by James Winterbottom and posted to the IETF repository.

Filename: draft-ietf-geopriv-local-civic
Revision: 03
Title: Specifying Civic Address Extensions in PIDF-LO
Creation date: 2012-02-28
WG ID: geopriv
Number of pages: 19

Abstract:
New fields are occasionally added to civic addresses. A backwardly-
compatible mechanism for adding civic address elements to the Geopriv
civic address format is described. A formal mechanism for handling
unsupported extensions when translating between XML and DHCP civic
address forms is defined for entities that need to perform this
translation. Intial extensions for some new elements are also
defined. The LoST protocol mechanism that returns civic address
element names used for validation of location information is
clarified to require a namespace on each element.

The IETF Secretariat
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action: draft-ietf-geopriv-local-civic-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : Specifying Civic Address Extensions in PIDF-LO
Author(s) : James Winterbottom
Martin Thomson
Richard Barnes
Brian Rosen
Robins George
Filename : draft-ietf-geopriv-local-civic-03.txt
Pages : 19
Date : 2012-02-28

New fields are occasionally added to civic addresses. A backwardly-
compatible mechanism for adding civic address elements to the Geopriv
civic address format is described. A formal mechanism for handling
unsupported extensions when translating between XML and DHCP civic
address forms is defined for entities that need to perform this
translation. Intial extensions for some new elements are also
defined. The LoST protocol mechanism that returns civic address
element names used for validation of location information is
clarified to require a namespace on each element.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-local-civic-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-geopriv-local-civic-03.txt

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-25

+1

On Feb 24, 2012, at 10:14 AM, Hannes Tschofenig wrote:

> I think it is ready to go. We have worked on this document far too long.
>
> On Feb 24, 2012, at 4:48 PM, Alissa Cooper wrote:
>
>> Just a reminder to send your WGLC comments on this, even if your only comment is that the document is ready to go.
>>
>> On Feb 13, 2012, at 6:18 PM, Alissa Cooper wrote:
>>
>>> This is a GEOPRIV Working Group Last Call for comments on
>>> draft-ietf-geopriv-policy-25
>>>
>>> Please send your comments to the list by 27 February 2012. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-25

I think it is ready to go. We have worked on this document far too long.

On Feb 24, 2012, at 4:48 PM, Alissa Cooper wrote:

> Just a reminder to send your WGLC comments on this, even if your only comment is that the document is ready to go.
>
> On Feb 13, 2012, at 6:18 PM, Alissa Cooper wrote:
>
>> This is a GEOPRIV Working Group Last Call for comments on
>> draft-ietf-geopriv-policy-25
>>
>> Please send your comments to the list by 27 February 2012. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02

Just a reminder to send your WGLC comments on this, even if your only comment is that the document is ready to go.

On Feb 14, 2012, at 10:20 AM, Alissa Cooper wrote:

> This is a GEOPRIV Working Group Last Call for comments on
> draft-ietf-geopriv-res-gw-lis-discovery-02
>
> Please send your comments to the GEOPRIV list by 27 February 2012. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-25

Just a reminder to send your WGLC comments on this, even if your only comment is that the document is ready to go.

On Feb 13, 2012, at 6:18 PM, Alissa Cooper wrote:

> This is a GEOPRIV Working Group Last Call for comments on
> draft-ietf-geopriv-policy-25
>
> Please send your comments to the list by 27 February 2012. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02

It's probably OK to hold this one back until just before the cutoff.

I've lost a lot of context/data/whatever in my move. Do you have
everything you need in order to refresh the doc?

--Martin

On 23 February 2012 02:51, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:
>
> On 14 Feb 2012, at 17:58, Martin Thomson wrote:
>
>> This is good to go.
>
> +1, but then I would say that :)
>
> I note that -02 is due to expire March 15th, and that the draft cutoff date for updates is March 12th.
>
> Should we rev up to -03 in the meantime just to keep the draft active, or hope that the WGLC concludes before then?
>
> Ray
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02

On 14 Feb 2012, at 17:58, Martin Thomson wrote:

> This is good to go.

+1, but then I would say that :)

I note that -02 is due to expire March 15th, and that the draft cutoff date for updates is March 12th.

Should we rev up to -03 in the meantime just to keep the draft active, or hope that the WGLC concludes before then?

Ray

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Simple] [Geopriv] [RAI] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121)

On 20 February 2012 06:56, Ben Campbell <ben@nostrum.com> wrote:
> 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.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Geopriv] [Simple] [RAI] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121)

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?

On Feb 20, 2012, at 4:39 AM, Saúl Ibarra Corretgé wrote:

> 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
>
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Simple] [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121)

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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121)

Original Message From: "Saúl Ibarra Corretgé"
> On Feb 16, 2012, at 7:26 PM, Hannes Tschofenig wrote:
>>
>> 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.

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

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.

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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

Hi,

On Feb 16, 2012, at 7:26 PM, Hannes Tschofenig wrote:

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

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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

On 16 February 2012 11:49, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> On 2/16/12 1:26 PM, Hannes Tschofenig wrote:
>>
>> I am curious: Why you do schema validation?
>
> 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
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

On 2/16/12 1:26 PM, Hannes Tschofenig wrote:
> 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.

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

> On Feb 16, 2012, at 8:11 PM, Saúl Ibarra Corretgé wrote:
>
>> Hi,
>>
>> On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote:
>>
>>> Naturally, it would make sense to check with current implementers. In
>>> 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
>>
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

On 16 February 2012 09:58, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> Naturally, it would make sense to check with current implementers. In
> 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?
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

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.

On Feb 16, 2012, at 8:11 PM, Saúl Ibarra Corretgé wrote:

> Hi,
>
> On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote:
>
>> Naturally, it would make sense to check with current implementers. In
>> 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
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

Hi,

On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote:

> Naturally, it would make sense to check with current implementers. In
> 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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

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.
>
> That's a backwards compatibility break.
>
> --Martin
>
> On 14 February 2012 14:36, Robert Sparks <rjsparks@nostrum.com
> <mailto:rjsparks@nostrum.com>> wrote:
>
> 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 <rfc-editor@rfc-editor.org>
> <mailto:rfc-editor@rfc-editor.org>
> To: hgs+simple@cs.columbia.edu <mailto:hgs+simple@cs.columbia.edu>,
> vkg@lucent.com <mailto:vkg@lucent.com>, pkyzivat@cisco.com
> <mailto:pkyzivat@cisco.com>, jdrosen@cisco.com
> <mailto:jdrosen@cisco.com>, gonzalo.camarillo@ericsson.com
> <mailto:gonzalo.camarillo@ericsson.com>, rjsparks@nostrum.com
> <mailto:rjsparks@nostrum.com>, ben@nostrum.com
> <mailto:ben@nostrum.com>, hisham.khartabil@gmail.com
> <mailto:hisham.khartabil@gmail.com>
> CC: stpeter@stpeter.im <mailto:stpeter@stpeter.im>, simple@ietf.org
> <mailto:simple@ietf.org>, rfc-editor@rfc-editor.org
> <mailto:rfc-editor@rfc-editor.org>
>
>
>
> 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 <http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121>
>
> --------------------------------------
> Type: Technical
> Reported by: Peter Saint-Andre <stpeter@stpeter.im> <mailto:stpeter@stpeter.im>
>
> 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
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org <mailto:Geopriv@ietf.org>
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

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 <rjsparks@nostrum.com> wrote:

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 <rfc-editor@rfc-editor.org>
To:	hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com
CC:	stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org

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 <stpeter@stpeter.im>  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 

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121)

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 <rfc-editor@rfc-editor.org>
To:	hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com
CC:	stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org

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 <stpeter@stpeter.im>  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 

Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-25

This document is ready to go.

I know this isn't good form, but I have to observe that the document
is a bit of a relic. While there is nothing inherently wrong with it,
I worry about the relevancy of the mechanisms that it is providing,
particularly in light of the location obfuscation conclusions.

On 13 February 2012 15:18, Alissa Cooper <acooper@cdt.org> wrote:
> This is a GEOPRIV Working Group Last Call for comments on
> draft-ietf-geopriv-policy-25
>
> Please send your comments to the list by 27 February 2012.  As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02

This is good to go.

On 14 February 2012 07:20, Alissa Cooper <acooper@cdt.org> wrote:
> This is a GEOPRIV Working Group Last Call for comments on
> draft-ietf-geopriv-res-gw-lis-discovery-02
>
> Please send your comments to the GEOPRIV list by 27 February 2012.  As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02

This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-res-gw-lis-discovery-02

Please send your comments to the GEOPRIV list by 27 February 2012. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] WGLC: draft-ietf-geopriv-policy-25

This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-policy-25

Please send your comments to the list by 27 February 2012. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv