Subject: Re: [Ecrit] Additional data

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Oct 2014 14:43:55 -0700

Hi Chris,

Thanks for catching this.  I agree that the 'purpose' attribute is 
not meaningful when passing additional data by reference within 
'provided-by' within a PIDF-LO (both because multiple data blocks may 
be contained in a single 'EmergencyCallDataValue' element (making a 
single 'purpose' attribute confusing) and also because there is no 
reference to be followed; 'purpose' is used when there is a reference 
(either external or internal (CID)).

I'll fix the example.

At 10:40 AM +0000 10/7/14, Chris Santer wrote:

>  Content-Language: en-US
>  Content-Type: multipart/related;
>  	boundary="_004_9e9112b90ae14378b11a868b31bcb773BLUPR07MB020namprd07pro_";
>  	type="multipart/alternative"
>
>  I have a question about implementing the EmergencyCallDataValue 
> element. The schema on [Page 54] is consistent with the example in 
> Figure 14, but does not match the description in section 5.3. We 
> have implemented using the schema and example in Figure 14 and 
> ignored section 5.3 at this time, but would like to know for sure 
> which one is correct. Section 5.3 includes the purpose attribute, 
> which looks more like a carryover from the 
> EmergencyCallDataReference element and does not belong on the 
> EmergencyCallDataValue element (no purpose attribute in the schema 
> or Figure 14).
>
>  Thanks,
>  Chris Santer
>
>  Chris Santer ? Software Development
>  2323 W. Fifth Avenue | Suite 210 | Columbus, OH 43204
>  614.429.3384 ext. 228 | 888.800.4003 | <http://www.ddti.net/>www.DDTi.net
>
>
>
>
>  Content-Type: image/png; name="image001.png"
>  Content-Description: image001.png
>  Content-Disposition: inline; filename="image001.png"; size=8681;
>  	creation-date="Tue, 07 Oct 2014 10:40:47 GMT";
>  	modification-date="Tue, 07 Oct 2014 10:40:47 GMT"
>  Content-ID: <[email-masked]>
>
>  _______________________________________________
>  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: ---------------
There are some micro-organisms that exhibit characteristics of both
plants and animals.  When exposed to light they undergo photosynthesis;
and when the lights go out, they turn into animals.  But then again,
don't we all?

---

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Oct 2014 15:12:23 -0700

Oops, I meant "by value" -- sorry.

At 2:43 PM -0700 10/7/14, Randall Gellens wrote:

> 'provided-by' within a PIDF-LO (both because multiple data blocks 
> may be contained in a single 'EmergencyCallDataValue' element 
> (making a single 'purpose' attribute confusing) and also because 
> there is no reference to be followed; 'purpose' is used when there 
> is a reference (either external or internal (CID)).
>
>  I'll fix the example.
>

-------------- Randomly selected tag: ---------------
1.) If the document should exist, it doesn't.
2.) If the document does exist, it's out of date.
3.) Only documentation for useless programs transcends the first
    two laws.

---

From: Chris Santer <[email-masked]>
Date: Fri, 10 Oct 2014 19:30:31 +0000

Hi Randall,

Thank you!

I did have another item I'd like to bring up.

RFC4119 allows one "provided-by" element, and this belongs in the namespace "urn:ietf:params:xml:ns:pidf:geopriv10".

Additional Data (23) seems to attempt to either move "provided-by" into a different namespace (urn:ietf:params:xml:ns:EmergencyCallData), or add a new "provided-by" element in a different namespace (urn:ietf:params:xml:ns:EmergencyCallData). This seems to be counter to the intent of RFC4119 and the stated goal (section 5.2) of transmitting additional data "within a 'Provided-By' element of a PIDF-LO". 

What the Additional Data (23) document seems to imply, with its schema and examples, is that the following is valid:

<provided-by xmlns="urn:ietf:params:xml:ns:EmergencyCallData">
  <EmergencyCallDataValue>
      <EmergencyCallData.ProviderInfo xmlns="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
                
But I think it should probably be something more like this:

<provided-by xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
  <EmergencyCallDataValue xmlns="urn:ietf:params:xml:ns:EmergencyCallData">
      <EmergencyCallData.ProviderInfo xmlns="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2014 6:12 PM
To: Randall Gellens; Chris Santer; [email-masked]
Subject: Re: [Ecrit] Additional data

At 2:43 PM -0700 10/7/14, Randall Gellens wrote:

>> Figure 14, but does not match the description in section 5.3. We have 
>> implemented using the schema and example in Figure 14 and ignored 
>> section 5.3 at this time, but would like to know for sure which one 
>> is correct. Section 5.3 includes the purpose attribute, which looks 
>> more like a carryover from the EmergencyCallDataReference element and 
>> does not belong on the EmergencyCallDataValue element (no purpose 
>> attribute in the schema or Figure 14).
>>
>>   Thanks,
>>   Chris Santer
>>
>  -------------- Randomly selected tag: ---------------  There are some 
> micro-organisms that exhibit characteristics of both  plants and 
> animals.  When exposed to light they undergo photosynthesis;  and when 
> the lights go out, they turn into animals.  But then again,  don't we 
> all?
>

---

From: James Winterbottom <[email-masked]>
Date: Sat, 11 Oct 2014 06:35:55 +1100

Good catch Chris.
Your correction is correct.

Cheers
James

Sent from my iPhone

> On 11 Oct 2014, at 6:30 am, Chris Santer <[email-masked]> wrote:
> 
> Hi Randall,
> 
> Thank you!
>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 10 Oct 2014 18:35:27 -0700

Thanks, Chris, I've fixed this as well as your previous catch; both 
will be in -24.

At 7:30 PM +0000 10/10/14, Chris Santer wrote:

>  RFC4119 allows one "provided-by" element, and this belongs in the 
> namespace "urn:ietf:params:xml:ns:pidf:geopriv10".
>
>  Additional Data (23) seems to attempt to either move "provided-by" 
> into a different namespace 
> (urn:ietf:params:xml:ns:EmergencyCallData), or add a new 
> "provided-by" element in a different namespace 
> (urn:ietf:params:xml:ns:EmergencyCallData). This seems to be 
> counter to the intent of RFC4119 and the stated goal (section 5.2) 
> of transmitting additional data "within a 'Provided-By' element of 
> a PIDF-LO".
>
>  What the Additional Data (23) document seems to imply, with its 
> schema and examples, is that the following is valid:
>
>        <EmergencyCallData.ProviderInfo 
> xmlns="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
>                 
>        <EmergencyCallData.ProviderInfo 
> xmlns="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
>

-------------- Randomly selected tag: ---------------
When a stupid man is doing something he is ashamed of, he always
declares that it is his duty.              --George Bernard Shaw