Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APPAD)

[Vincent Chen <[e-mail]>]

Hi Luzango,


On Mon, Aug 11, 2014 at 5:50 AM, Luzango Mfupe <[e-mail]> wrote:

>  Hi Vince, Folks,
>
> It seems the issue of adding the single-resolution bandwidth
> example slipped off the cracks some how as it was supposed to be included
> in the current draft.
>

Please see the first example in Section 5.11, which was added based on your
suggestion.


>
> Today I am presenting another burning issue relevant to the following
> Sections:
>
> SECTION 5.5 DeviceOwner
> SECTION 6.4 Example Encoding Device Owner vCard
>
> Can you please elaborate how the device owner jcard/vCard fragments should
> be handled within the JSON registration request message body; what
> primitive type(s) should be applied( i.e, String, int etc...). Apparently
> there is already a great deal of confusion in this area as some would
> thinks the card fragments should just be sent as-it-is in an array
> format with the rest of the JSON registration request body
>
> To the best of my understanding jcards are supposed to be written as
> String primitive types this allows to preserve the formatting when they are
> parse/read by the spectrum database/server or any other application
> that would wish to extract the contact information in a standardised
> format.
>
> Section 5.5 is silent on the definition of vCard data type(s), while the
> example provided in Section 6.4 shows the vCard in an array.
>
> May I suggest that we should also explicitly state the data type of jcard
> similar to the way we have defined data types for other aspects throughout
> the document (e.g., In Section 5.2 Device Descriptor)...In doing so this
> will clear any future confusions in the implementation of our standard.
>

Actually, Section 6.4 is the jCard representation and was intended to
provide the clarification you're asking for.
Perhaps it needs a better intro sentence?

Since Sections 4 and 5 define new data models for PAWS, we provide a
mapping from those data models to JSON.
On the other hand, we are not redefining vCard and jCard, so it seemed
redundant to repeat their definitions.

-vince


>
> Kind Regards,
> Luzango.
>
>
> >>> Vincent Chen <[e-mail]> 28/07/2014 18:54 >>>
> Hi Luzango,
>
> Thanks for your suggestions.
>
>
> On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe <[e-mail]> wrote:
>
>> Hi Vince, Folks,
>>
>> I am glad to see things are moving to the right direction and hopefully
>> soon we will finalise this work.
>>
>> I just found some few not very critical issues that needs some fixing in
>> in my opinion:
>>
>>  *5.11. Spectrum*
>>
>>
>> Here the document talk about the FCC and OFCOM/ETSI spectral profile
>> presentation requirements (i.e, power levels over a set of frequency
>> ranges. However, there is only one type of example (OFCOM/ETSI specific)
>> that is provided throughout the document. I think we need to add another
>> set of example that is FCC specific.
>>
>>
>> Would something like this below suffice for the FCC specific example?
>>
>> “resolutionBwHz”: 1e5,
>>
>> “profiles”: [
>>
>> {
>>
>> "Hz": 5.18e8,
>>
>> "Hz": 5.24e8,
>>
>> “dbm”: 24
>>
>> ] },
>>
>>
>>
>>
> Ah. I see. We can add a single resolution-bandwidth example for
> completeness.
>
>   --
>> This message is subject to the CSIR's copyright terms and conditions,
>> e-mail legal notice, and implemented Open Document Format (ODF) standard.
>> The full disclaimer details can be found at
>> http://www.csir.co.za/disclaimer.html.
>>
>
> This message has been scanned for viruses and dangerous content by
> *MailScanner* <http://www.mailscanner.info/>,
> and is believed to be clean.
>
>
> Please consider the environment before printing this email.
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
>
> This message has been scanned for viruses and dangerous content by
> *MailScanner* <http://www.mailscanner.info/>,
> and is believed to be clean.
>
>
> Please consider the environment before printing this email.
>
>


-- 
-vince