[drinks] Change proposal

[Mickael Marrache <[e-mail]>]

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