Subject: [Ecrit] Comments re: draft-ietf-additional-data-28

From: Dan Banks <[email-masked]>
Date: Mon, 2 Mar 2015 16:42:10 +0000

While working through draft-ietf-additional-data-28, I noted a few issues:

1)
The text states in section 4.1.6 that the <language> element in ProviderInfo uses ISO 639-1:2002 codes, which seems appropriate.  However, the schema (section 7.1) uses the name "iso3166a2" as the type name.  It would be better if the type name in the schema reflected the actual standard uses for the element.  Additionally, the type definition indicates uppercase letters (which is typical for ISO 3166 codes), but it is recommended that language codes be expressed in lower case (see http://www.loc.gov/standards/iso639-2/faq.html#21).

I suggest that the schema be updated by renaming the "iso3166a2" type and changing the pattern to lowercase, and that all examples be updated accordingly.

2)
Section 4.2.1 states that the <ServiceEnvironment> element is "Optional when a 'ServiceType' value is 'wireless'; required otherwise."  However, the schema in section 7.2 shows the ServiceEnvironment element as minOccurrs="1".

3)
In section 7.6, the "provided-by" element is defined, but I'm not sure if it is correct the way it is written since the "provided-by" element itself is defined elsewhere for PIDF-LO, and I don't believe that there is a use described for a "provided-by" element with the urn:ietf:params:xml:ns:EmergencyCallData namespace.

4)
For the XML fragments given as examples in sections 5.2 and 5.3, I think it would be more clear if the applicable namespaces were spelled out instead of using prefixes that aren't declared in that particular fragment (but are used for examples elsewhere).

5)
In the example on page 39 (section 6) and other places, the DataProviderContact element is written in the xCard namespace, which appears to be incorrect.  That element is in the EmergencyCallData:ProviderInfo namespace in the schema.

6)
Looking at the ProviderInfoType definition (section 7.1), it appears that the DataProviderContact element is required, but can be empty.  Section 4.1.7, however, states that the use of the element is optional.  Am I interpreting the schema correctly, and is that the intended definition?

Dan Banks

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 11:34:56 +0100

Hi Dan,

thanks for this very good review.

On 03/02/2015 05:42 PM, Dan Banks wrote:
> The text states in section 4.1.6 that the <language> element in
> ProviderInfo uses ISO 639-1:2002 codes, which seems appropriate. 
> However, the schema (section 7.1) uses the name “iso3166a2” as the type
> name.  It would be better if the type name in the schema reflected the
> actual standard uses for the element.  Additionally, the type definition
> indicates uppercase letters (which is typical for ISO 3166 codes), but
> it is recommended that language codes be expressed in lower case (see
> http://www.loc.gov/standards/iso639-2/faq.html#21).
> 
>  
> 
> I suggest that the schema be updated by renaming the “iso3166a2” type
> and changing the pattern to lowercase, and that all examples be updated
> accordingly.
> 

Good catch.

I believe I have two choices:

Option #1: I could now reference ISO.3166-1 and adjust the definition of
the type in the XML schema to allow both lower case and upper case
characters.

Option #2: I could instead reference the IANA language tags registry (as
defined in [RFC5646]):
http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

I prefer option#2.

Would this be OK for you?

>  
> 
> 2)
> 
> Section 4.2.1 states that the <ServiceEnvironment> element is “Optional
> when a 'ServiceType' value is 'wireless'; required otherwise.”  However,
> the schema in section 7.2 shows the ServiceEnvironment element as
> minOccurrs=”1”.
> 

Fixed.

>  
> 
> 3)
> 
> In section 7.6, the “provided-by” element is defined, but I’m not sure
> if it is correct the way it is written since the “provided-by” element
> itself is defined elsewhere for PIDF-LO, and I don’t believe that there
> is a use described for a “provided-by” element with the
> urn:ietf:params:xml:ns:EmergencyCallData namespace.
> 
The <provided-by> element is defined in [RFC4119] and we use it to
convey the additional data structures, as described in Section 5.

>  
> 
> 4)
> 
> For the XML fragments given as examples in sections 5.2 and 5.3, I think
> it would be more clear if the applicable namespaces were spelled out
> instead of using prefixes that aren’t declared in that particular
> fragment (but are used for examples elsewhere).
> 

I agree that this makes things clearer. I updated the examples.

>  
> 
> 5)
> 
> In the example on page 39 (section 6) and other places, the
> DataProviderContact element is written in the xCard namespace, which
> appears to be incorrect.  That element is in the
> EmergencyCallData:ProviderInfo namespace in the schema.
> 
> 
Again a good catch. Fixed.

> 
> 6)
> 
> Looking at the ProviderInfoType definition (section 7.1), it appears
> that the DataProviderContact element is required, but can be empty. 
> Section 4.1.7, however, states that the use of the element is optional. 
> Am I interpreting the schema correctly, and is that the intended definition?
> 
>  
Declared DataProviderContact as optional in the XML.

 <xs:element name="DataProviderContact"
                    minOccurs="0" maxOccurs="1">
                  <xs:complexType>
                     <xs:sequence>
                       <xs:element minOccurs="0"
                           maxOccurs="unbounded" ref="xc:vcard"/>
                     </xs:sequence>
                  </xs:complexType>
                </xs:element>

I noticed that the data provider contact is optional itself and so I
explicitly declared the structure as

  <xs:element
        name="EmergencyCallData.ProviderInfo"
        type="pi:ProviderInfoType"
        minOccurs="0" maxOccurs="1"/>

Thanks again for your detailed review.

Ciao
Hannes

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

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 05 Mar 2015 12:15:14 +0100

For 1) the language tags, I agree that option #2 seems to be the proper 
one to use.

Regards
/Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Dan Banks <[email-masked]>
Date: Thu, 5 Mar 2015 20:50:14 +0000

I agree, I think that option #2 is best.

Dan

From: Gunnar Hellström [mailto:[email-masked]]
Sent: Thursday, March 05, 2015 6:15 AM
To: Hannes Tschofenig; Dan Banks; [email-masked]
Subject: Re: [Ecrit] Comments re: draft-ietf-additional-data-28

For 1) the language tags, I agree that option #2 seems to be the proper one to use.

Regards
/Gunnar

Hi Dan,

1)

However, the schema (section 7.1) uses the name "iso3166a2" as the type

I suggest that the schema be updated by renaming the "iso3166a2" type

accordingly.

Good catch.

characters.

defined in [RFC5646]):

I prefer option#2.

2)

Section 4.2.1 states that the <ServiceEnvironment> element is "Optional

when a 'ServiceType' value is 'wireless'; required otherwise."  However,

minOccurrs="1".

Fixed.

3)

In section 7.6, the "provided-by" element is defined, but I'm not sure

if it is correct the way it is written since the "provided-by" element

itself is defined elsewhere for PIDF-LO, and I don't believe that there

is a use described for a "provided-by" element with the

4)

instead of using prefixes that aren't declared in that particular

5)

6)

                  <xs:complexType>

                     <xs:sequence>

                     </xs:sequence>

                  </xs:complexType>

                </xs:element>

  <xs:element

Ciao

Hannes

Dan Banks

Ecrit mailing list

[email-masked]<mailto:[email-masked]>

Ecrit mailing list

[email-masked]<mailto:[email-masked]>

--

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

---

From: Randall Gellens <[email-masked]>
Date: Fri, 6 Mar 2015 16:24:10 -0800

> http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

This seems the best choice.  As an example, 
draft-gellens-slim-negotiating-human-language uses the wording "a 
single [RFC3066] language tag in US-ASCII [RFC3066]".

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Change is inevitable, except from a vending machine.