Open APIs

 View Only
Expand all | Collapse all

Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

  • 1.  Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted Jan 18, 2022 05:09
    The subject line says it all really.

    TMF632 Party Management defines its' own address format as part of the contactMedium/characteristic block.
    E.g.
    {"street1" : "22 Acacia Rd",
    "street2": "Lower Village",
    "postCode": "IP5 3RE",
    "city": "Upperton",
    "stateOrProvince": "Suffolk"
    Why does it not use (by reference or value) the TMF673 Geographic Address Management format? E.g. same data as above, different format:
    {"streetNr": "22","streetName": "Acacia",
    "streetType": "Road",
    "postcode": "IP5 3RE",
    "locality": "Lower Village",
    "city": "Upperton",
    "stateOrProvince": "Suffolk"}
    If we had an address service (exposed using TMF673) it would be natural to create party records that used to the data from the address service rather than (as the API implies) store separate address values in a separate format.

    Suggestion: align the postal addresses in TMF632 to the Geographic Address schema of TMF673. Allow pass by reference or pass by value semantics.

    ------------------------------
    Alasdair MacLeod
    BT Group plc
    ------------------------------


  • 2.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted Jan 19, 2022 09:40
    Hi Alasdair,

    I agree with your assessment and I support your suggestion.
    It will require also further fixing of other contactmedium aspects such as phone numbers, e-mail addresses and social media references.

    Regards

    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 3.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted Jan 26, 2022 15:55
    Thanks Koen.

    ​​

    ------------------------------
    Alasdair MacLeod
    BT Group plc
    ------------------------------



  • 4.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted Jan 26, 2022 15:58
    @Ludovic Robert is this something that could be considered for a future uplift of the specs? ​​

    ------------------------------
    Alasdair MacLeod
    BT Group plc
    ------------------------------



  • 5.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted Jan 27, 2022 02:44
    Hello Alasdair,

    I think we should raise a jira for this. this is a fair request. Are you able to log a Jira to the API team @Alasdair MacLeod ? or do you want me to it ?

    Thanks
    Ludovic​

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 6.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted Jan 27, 2022 07:03
    Happy to do if you point me in the right direction.

    ------------------------------
    Alasdair MacLeod
    BT Group plc
    ------------------------------



  • 7.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted Feb 02, 2022 08:46
    Hi,

    this will be fixed on v5.0.0, the Jira that is tracking this specific improvement is this one:
    https://projects.tmforum.org/jira/browse/AP-3792

    Best Regards,

    ------------------------------
    Henrique Rodrigues
    TM Forum
    ------------------------------



  • 8.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted 16 days ago
    Hey there,

    Can anyone describe the changes being done for the address entities in v5.0.0?  I looked at the JIRA ticket but there is no description in there and I do not have access to the GitHub branch where the changes were supposed to have been made.  I did notice that Jonathan Goldberg re-opened the ticket a few days ago though, because the changes were not in Git, so if someone has more information about what the plan is for address entities, that would be appreciated.

    Thanks,
    Sean

    ------------------------------
    Sean Garagan
    Bell Canada
    ------------------------------



  • 9.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted 13 days ago
    Hi Sean and all
    I've been working on the v5 upgrade for TMF632. I can tell you that Contact Medium has been refactored in v5 to tease out the different medium types into subclasses, so there is an email contact medium, an address contact medium, etc. Each of these subclasses has the relevant properties for its type.
    What has not been done is to make the address contact medium somehow related to Geographic Address. I need to discuss this point with my peers before going ahead with it. Possible approaches include:
    • replacing the address properties with a GeoAddress refOrValue
    • keeping the properties and adding a GeoAddress ref
    • other
    Watch this space and feel free to make additional suggestions.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 10.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted 12 days ago
    Hi Jonathan,

    My vote definitely goes to replacing the address properties with GeographicAddress refOrValue.
    This approach permits to common approaches to addresses:
    • Strictly managed addresses: This scenario is common for fixed line service providers. Addresses are maintained in an address management application, closely linked to the network. When a party created his address is normalised and looked up in this
    • Loosely managed addresser: This scenario is common for mobile service providers. Addresses are created as part of the data entry for a party. They are not really validated against a reference.
    Regards

    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 11.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted 11 days ago
    We've discussed this in the Open API team. The general feeling is to go for the second option (sorry Koen), adding a reference to GeoAddress.
    This means that the operative fielded address in PostalAddressContactMedium (the new subclass) will stay as-is, but if an implementation wants to relate the contact medium to a verified GIS address (for example) it can do that with the reference.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 12.  RE: Why does TMF632 Party Management have its' own address format rather than use TMF673 Geopgraphic Address Management?

    TM Forum Member
    Posted 11 days ago
    Hey Jonathan,

    Thanks for taking this up and helping to deal with the ambiguities between ContactMedium addresses and GeographicAddress.  Just to make sure I am clear, we can regard the GeographicAddress spec relating to a physical address, as in your example of a verified GIS address.  The new PostalAddressContactMedium is meant for addresses that may not actually be related to a service address, for example, if a customer has a PO Box for postal communications.

    One thing, will there be a way to add data to the new contact medium entities without having to further extend them, such as having characteristics or something along those lines?  My original question came out of discussions we have had around PO Box addresses or rural route (RR) addresses and where that information should go in the existing entities.  If there was a way to add this without having to extend the entities, this could make things more extensible without having to change the data model if new items arise for addressing

    Thanks,
    Sean

    ------------------------------
    Sean Garagan
    Bell Canada
    ------------------------------