Re: [drinks] Change proposal

[Dean Willis <[e-mail]>]

I think the current "optional key" model is complicated.

If we need the functionality, there are alternative structures that could
provide it with fewer headaches.

If we don't need the functionality, then Mickael's modification makes the
structure simpler and easier to understand.

And I think "simpler and easier to understand" is a good selling point for
wider adoption of the protocol.

So: first question: Do we need the functionality?


On Mon, May 13, 2013 at 8:55 AM, Mickael Marrache <[e-mail]
> wrote:

> Hi,
>
> - Exclude the Destination Group's name from the Public Identifier key in
> section 5.2.2 of the framework document. Note that I don't mean to exclude
> the DG name from the PI type.
> - Update section 6.2 and 12 of the framework document accordingly. It
> consist of adding a maxOccurs attribute to the dgName element with the
> value unbounded. This way, it will be possible to associate the PI with
> multiple DGs. After the change, the PubIdType would look like:
>
> <complexType name="PubIdType" abstract="true">
>     <complexContent>
>      <extension base="sppfb:BasicObjType">
>       <sequence>
>        <element name="dgName" type="sppfb:ObjNameType" minOccurs="0" maxOccurs="unbounded"/>
>       </sequence>
>      </extension>
>     </complexContent>
> </complexType>
>
> Since we agreed the COR is intrinsic to the PI (i.e. it doesn't depend on
> the association with a particular DG), this element should stay in the
> derived types of PubIdType.
>
> - Update sections 7.1.2 and 9 of the SOAP document.
>
> *Pros:*
> -For REST, the API is more intuitive since a single URI template is
> defined for PIs while two URI templates are defined with the current model
> (i.e. one for in-DG PIs and another for standalone PIs).
> -Less duplication of data when PIs are manipulated. For example, in order
> to associate the number 12345 to 4 DGs with the current model, 4 ADD
> requests are sent. These requests contain the same data except the dgName
> element. With the proposed changes, only 1 ADD request is sent.
> -With the current model, different COR may be provided for the number
> 12345 and it is an error as we discussed. With the proposed changes, for a
> given PI, the COR is defined only once so this unexpected scenario cannot
> happen.
> -Also concerning COR, with the current model, if the registry is
> authoritative, a registrant would have to set the same COR for a telephone
> number when it associates it to multiple DGssince a registrant must set the
> COR when it associates
>
> *Cons:*
> -Lack of flexibility. If flexibility means the ability to populate
> different information for the "same" PI depending on which DG it is
> associated to, I think the right way to do is to use a dedicated type for
> the association as it is done for the SED Group-SED Record association. The
> only thing I see behind the term flexibility is the fact that the current
> model is better suited for data distribution where for example, multiple
> PIs representing the same telephone number are stored at different places.
> But, I think this concept is irrelevant at the provisioning protocol level.
> -Need to make some modifications to both documents while they are closed
> to become RFCs. The changes are not big and I can allocate time to write
> them.
>
> *Another related point:*
>
> Currently, there are no additional elements that describe the PI-DG
> association (as for example, the priority element in the SED Group-SED
> Record association). Therefore, the association is represented by a list of
> ObjNameType (i.e. simple string). With the current model, this is enough
> since a new PI instance is created for each PI-DG association. With the
> proposed changes, it would be better to follow the same model as for the
> SED Group-SED Record association (i.e. using a new type, for example,
> DestGrpRefType) so that additional attributes may be added to the
> association in the future.
>
> Mickael
>
> _______________________________________________
> drinks mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/drinks
>
>