Subject: [Ecrit] draft-ietf-ecrit-additional-data-14: Naming consistency of various parameters / namespaces

From: Matt Serra <[email-masked]>
Date: Wed, 23 Oct 2013 10:33:48 -0500

In reviewing the latest additional data draft (v14) - I noticed that there are a few inconsistencies that should be addressed.  Issues and thoughts are below.  

I ask that whatever is decided recognize that other forms of additional data will be defined (Additional Caller and Additional Location data), so we should pick names that don't limit our options when those are introduced.

1) Section 9.2 - The purpose parameter in the table should read as 'emergencyCallData' per the section title.

2) Section 9.4 - We may want to reconsider renaming the MIME registrations to match the purpose parameter name.  Section 9.4 calls for a pattern of 'emergencyCallData.<block>+xml'

3) Section 9.5: the various URN Sub-Namespace registrations are named inconsistently.  We should iron this out:

- urn:ietf:params:xml:ns:emergencyCallAddlData
- urn:ietf:params:xml:ns:emergencyCallProviderInfo
- urn:ietf:params:xml:ns:emergencyCall.SvcInfo
- urn:ietf:params:xml:ns:emergencyCall.DevInfo
- urn:ietf:params:xml:ns:emergencyCall.SubInfo
- urn:ietf:params:xml:ns:emergencyCall.Comment

4) The schema registries in section 9.6 are different still from section 9.5. These should agree, no?

Thanks,

Matthew A. Serra, ENP
Sr. Director, Product Management 
Rave Mobile Safety | Smart911
Mobile:  201.245.1557
[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Oct 2013 14:03:03 +0200

Hi Matt,

thanks for the detailed review and for spotting these inconsistencies.

On 10/23/2013 05:33 PM, Matt Serra wrote:
> In reviewing the latest additional data draft (v14) - I noticed that
> there are a few inconsistencies that should be addressed.  Issues and
> thoughts are below.
>
> I ask that whatever is decided recognize that other forms of
> additional data will be defined (Additional Caller and Additional
> Location data), so we should pick names that don't limit our options
> when those are introduced.
>
> 1) Section 9.2 - The purpose parameter in the table should read as
> 'emergencyCallData' per the section title.
>

Fixed.

> 2) Section 9.4 - We may want to reconsider renaming the MIME
> registrations to match the purpose parameter name.  Section 9.4 calls
> for a pattern of 'emergencyCallData.<block>+xml'

Makes sense.

> - urn:ietf:params:xml:ns:emergencyCallAddlData -
> urn:ietf:params:xml:ns:emergencyCallProviderInfo -
> urn:ietf:params:xml:ns:emergencyCall.SvcInfo -
> urn:ietf:params:xml:ns:emergencyCall.DevInfo -
> urn:ietf:params:xml:ns:emergencyCall.SubInfo -
> urn:ietf:params:xml:ns:emergencyCall.Comment

I changed it to

urn:ietf:params:xml:ns:emergencycalldata:<block>

> section 9.5. These should agree, no?

They should be aligned for better readability.

Thanks a lot for the review.

I am working on the updated version and will post a link to the new 
document to the list. Might take a little while since I have to fix 
examples and schemas as well.

Ciao
Hannes

>
> Thanks,
>
> Matthew A. Serra, ENP Sr. Director, Product Management Rave Mobile
> Safety | Smart911 Mobile:  201.245.1557 [email-masked]
>
>
> _______________________________________________ Ecrit mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ecrit
>