PFIF 1.4 (very) early draft

[Ka-Ping Yee]

Hi folks,

Just to get the ball rolling, I've incorporated some of the feature requests for PFIF 1.4 into an early draft, available at:

    http://zesty.ca/pfif/1.4draft

The proposed changes from PFIF 1.4 are highlighted in the "Changes" section.

These changes are based on the feedback from the Missing Persons Community of Interest group and my recent conversation with Fred Wolens at Facebook.  They don't cover all feature requests, but these are some fairly simple changes that address the low-hanging fruit and allow us to make a little bit of forward movement.  I thought I'd send this out so folks could have a gander before our MPCI conference call tomorrow.  Again, please understand that this is just a draft—I'm sure this will continue to evolve, and your feedback is welcome!

—Ka-Ping Yee
Google Crisis Response

[Mark Prutsalis]

Hey Ping--

Great work on the preliminary 1.4 draft.

Is there a document where we are tracking the requests for changes by priority and feasibility that merges the list initially compiled by Keith of the American Red Cross at/following our face-to-face meeting in NYC with the requirements that came out of your discussion with Fred of Facebook?  I'm not finding the one from Keith from the Summit in my Google Docs repository but I may be missing something.

Best regards,

Mark

[Mark Prutsalis]

============================================

Mark Prutsalis

President & CEO

Sahana Software Foundation

tel +1-860-499-0332

ma...@sahanafoundation.org

http://SahanaFoundation.org

Follow us @sahanafoss and http://Facebook.com/SahanaSoftwareFoundation

* * * * *

The Mission of the Sahana Software Foundation is to help alleviate human suffering by giving emergency managers, disaster response professionals and communities access to the information that they need to better prepare for and respond to disaster through the development and promotion of free and open source software and open standards.

[Tim Schwartz]

Ka-Ping,

Just to bring up one of Glenn's points again: Perhaps it is the right
time to move everything to utf8 unicode instead of 1/2 unicode and 1/2
ascii?

Everyone loves consistency:)

-tim

[Ka-Ping Yee]

On Tue, May 1, 2012 at 10:00, Tim Schwartz <tim.c.s...@gmail.com> wrote:

Ka-Ping,

Just to bring up one of Glenn's points again: Perhaps it is the right
time to move everything to utf8 unicode instead of 1/2 unicode and 1/2
ascii?

Hi Tim and Glenn,

Indeed, I agree consistency is a virtue.  :)  Let me make a pass through the doc to review the types of the string fields.  My recollection is that the fields specified as ASCII are supposed to only be the fields where only ASCII makes sense (e.g. URLs and e-mail addresses have to be ASCII) but it's possible I may have missed some fields.

Thanks,

—Ping

[Ka-Ping Yee]

Hi everyone,

Just following up on the status of PFIF 1.4.  My list of the concerns raised here so far is as follows:

1. Primary/secondary photos:

The concern as I understand it is that there needs to be a way to provide multiple photos while designating one of them as the primary identifying photo.  I think the draft allows for this use case (the photo on the Person record would be primary).  There is also the nice feature that each additional photo, since it's attached to a Note, would come with metadata (the Note's author_name, text, and so on).  This seems like a workable solution to me.

2. Use of Unicode vs. ASCII strings:

I did a scan of the spec and found that it calls for ASCII in this set of fields:

  - Record identifiers (person_record_id, note_record_id, linked_person_record_id)

  - Dates (entry_date, expiry_date, source_date, date_of_birth)

  - E-mail addresses (author_email, email_of_found_person)

  - Telephone numbers (author_phone, phone_of_found_person)

  - URLs (source_url, photo_url, profile_urls)

  - Age as a whole number or age range (age)

  - Standardized alphanumeric codes (home_postal_code, home_country)

  - Values selected from a fixed set (author_made_contact, status, sex)

In all of these fields, only ASCII strings would be valid anyway, due to the other specified constraints on the value.

3. Not wanting to be found:

Alex raised the question of people who don't necessarily want to list where they are or provide photos, in order to protect their safety.  I think we are in an acceptable position on this, since you don't have to fill in all the fields.  It is possible in PFIF to provide just your name (or even just a nickname) and an indication that you are safe, which might be just enough information for someone who knows you to get the message but not for strangers or harassers to be able to find you.

In summary, it seems to me that the PFIF 1.4 draft is in at least a workable state.  Perhaps we are ready to consider freezing it soon, to lock down some progress, and we can continue discussing further new features for 1.5?  Please let me know if I've missed any important concerns that still need to be addressed.

Thanks!

—Ping

[Tim Schwartz]

Ka-Ping,

Thanks for the hard work on this. Overall looks good to me. I think
locking 1.4 and moving to 1.5 seems reasonable at this time. My
Comments in-line below.

On Mon, May 28, 2012 at 1:21 AM, Ka-Ping Yee <k...@google.com> wrote:
> Hi everyone,
>
> Just following up on the status of PFIF 1.4.  My list of the concerns raised
> here so far is as follows:
>
> 1. Primary/secondary photos:
> The concern as I understand it is that there needs to be a way to provide
> multiple photos while designating one of them as the primary identifying
> photo.  I think the draft allows for this use case (the photo on the Person
> record would be primary).  There is also the nice feature that each
> additional photo, since it's attached to a Note, would come with metadata
> (the Note's author_name, text, and so on).  This seems like a workable
> solution to me.

I think this is a fine solution for right now.

>
> 2. Use of Unicode vs. ASCII strings:
> I did a scan of the spec and found that it calls for ASCII in this set of
> fields:
>   - Record identifiers (person_record_id, note_record_id,
> linked_person_record_id)
>   - Dates (entry_date, expiry_date, source_date, date_of_birth)
>   - E-mail addresses (author_email, email_of_found_person)
>   - Telephone numbers (author_phone, phone_of_found_person)
>   - URLs (source_url, photo_url, profile_urls)
>   - Age as a whole number or age range (age)
>   - Standardized alphanumeric codes (home_postal_code, home_country)
>   - Values selected from a fixed set (author_made_contact, status, sex)
> In all of these fields, only ASCII strings would be valid anyway, due to the
> other specified constraints on the value.
>

Agree. As pre the comment about unicode in URLs, it is not allowed
(though people do it and most modern browsers support it) ie...
http://www.faqs.org/rfcs/rfc1738.html

> 3. Not wanting to be found:
> Alex raised the question of people who don't necessarily want to list where
> they are or provide photos, in order to protect their safety.  I think we
> are in an acceptable position on this, since you don't have to fill in all
> the fields.  It is possible in PFIF to provide just your name (or even just
> a nickname) and an indication that you are safe, which might be just enough
> information for someone who knows you to get the message but not for
> strangers or harassers to be able to find you.

I think these items will be dealt with in the implementation of the
spec and in the constraints or standards we as a group put on the
implementation. I don't *believe* that this can be put into the spec,
though, I would be open to the discussion.

>
> In summary, it seems to me that the PFIF 1.4 draft is in at least a workable
> state.  Perhaps we are ready to consider freezing it soon, to lock down some
> progress, and we can continue discussing further new features for 1.5?
>  Please let me know if I've missed any important concerns that still need to
> be addressed.

1.5!!!

>
> Thanks!
>
>
> —Ping
>