Subject: RE: [Ecrit] Review of draft-ietf-ecrit-requirements-08.txt

From: "Stastny Richard" <[email-masked]>
Date: Sat, 6 May 2006 19:09:08 +0200

IMHO there is a contradiction, (espeially between Ma6 and  Ma17) or at least
this is very confusing. I do not know now if multiple URIs for the same contact
protocol are allowed or not)
 
In one requirement  the client needs to the select among differnt protocols, in the other not
 
Richard
 
Ma4.  Multiple response URIs: The mapping protocol MUST support the
      possible inclusion of multiple URIs in a mapping response.
      Motivation: Multiple URIs may be available from the mapping
      server.
 
   Ma5.  URI alternate contact: In addition to returning a primary
      contact, the mapping protocol MUST support the return of a URI or
      contact method explicitly marked as an alternate contact.
      Motivation: In response to a mapping request, the mapping server
      may return an alternate URI.  Implementation details to be
      described within an operational document.
 
   Ma6.  URL properties: The mapping protocol MUST support the ability
      to provide ancillary information about a contact or URI that
      allows the mapping client to determine relevant properties of the
      URL.
      Motivation: In some cases, the same geographic area is served by
      several PSAPs, for example, a corporate campus might be served by
      both a corporate security department and the municipal PSAP.  The
      mapping protocol should then return URLs for both, with
      information allowing the querying entity to choose one or the
      other.  This determination could be made by either an ESRP, based
      on local policy, or by direct user choice, in the case of caller-
      based methods.

   Ma17.  Single URI per contact protocol: Though the mapping protocol
      supports the return of multiple URIs, it SHOULD return only one
      URI per contact protocol, so that clients are not required to
      select among different targets for the same contact protocol.
      Motivation: There may be two or more URIs returned when multiple
      contact protocols are available (e.g., SIP and SMS).  The client
      may select among multiple contact protocols based on its
      capabilities, preference settings, or availability.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Ted Hardie <[email-masked]>
Date: Sat, 6 May 2006 12:14:08 -0700

>In one requirement  the client needs to the select among differnt protocols, in the other not

I agree that this is a bit confusing, largely because Ma17 occurs after the
others.  I think if we moved it forward, it would make more sense, as it
would then imply that the multiple URIs  in Ma4 were each from a different
scheme.

The reason we did not want to return multiple contact URIs for a single scheme
in a standard response was that we didn't want the client to have to worry
about which of the returned URIs to pick (e.g., if I gave you six SIP URIs,
which one should be selected?). 

The alternate contact field allowed you to handle the need for explicit
indication of a fallback, but with the understanding that the client didn't
need to determine an ordering in the response--the fallback was there only
when the first contact was not available.

That's my memory of how we got there.   To make that clear, I suggest
we move Ma17 up to be before Ma4, and we change "URI alternate
contact" to say "explicitly marked as an alternate contact for use when
a fallback contact is needed".
			regards,
				Ted