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

[Vincent Chen <[e-mail]>]

Hi Luzango,

Please see Section 9.1.2.1 for additional requirements on the DeviceOwner
fields for FCC rules. There's a table that describes the required fields
that must appear for "owner" and "operator".

We did not want to make any restrictions in the core PAWS spec.

Also, RFC 6350 defines what the types are for each field, e.g., "fn" is "a
single text value" (Section 6.2.1) and "adr" is a structured text value of
7 components (Section 6.3.1).


-vince


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

>  Hi Vince,
>
> Thanks for prompt clarifications however, my suggestion is that the data
> type of vCard fragments (the device owner part and the device operator
> part) as a whole should be explicitly stated in section 5.5. Here I am not
> talking about the data types of individual parameters inside the vCard
> itself. This will indeed help to preserve the integrity of card formatting
> when they are being parsed by different applications as well as promote
> uniformity in different PAWS implementations.
>
> Kind Regards,
> Luzango.
>
> >>> Vincent Chen <[e-mail]> 11/08/2014 16:42 >>>
> 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
>
> --
> 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