Subject: RE: [Ecrit] Proposed Requirement

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 20 Sep 2005 18:17:40 -0500

I could not disagree more with this requirement!

The Mapping service by its very virtue of providing destination routing
information based on location grants it the very trust that is being
argued below that it does not have. Further to this, the mapping
functions are in most cases likely to be in the best position to have
this trust placed on them. I see the argument raised for having this
requirement as being moot.

A mapping function MUST be able to accept either a location-by-reference
(preferred in the mobile case), or alternatively by-value, preferably if
the source can be verified.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Tom-PT Taylor
> Sent: Tuesday, 20 September 2005 12:06 AM
> To: Marc Linsner
> Cc: [email-masked]
> Subject: Re: [Ecrit] Proposed Requirement
> 
> I like it.
> 
> Marc Linsner wrote:
> > A proposed new requirement for the 'almost finished' req. draft.....
> >
> > Requirement: The ecrit mechanism will only deal with location data
in
> value
> > form, any location by-reference or location-key MUST be resolved to
a
> > location by-value prior to query submission to the mapping database.
> >
> > Motivation: It cannot be expected that the entities considered to be
> 'the
> > mapping database' (accepting the queries and returning a resolution)
of
> the
> > location mapping-to-uri function be part of any trust or
authentication
> > mechanism that may be required to resolve location
> > by-reference/location-key.
> >
> >
> > This requirement spurs the need to define location by-reference,
> > location-key and location by-value in section 2 - Terminology.
> Hence....
> >
> > Location by-reference: A URI that when accessed by an authorized
entity
> will
> > yield the location of the end-point to which the reference is
> associated.
> >
> > Location-Key: A mechanism used to provide a reference to a location.
> This
> > may be a URI, a URL or some other kind of identifier.
> >
> > Location by-value: The location data in it's native form (see
location).
> >
> >
> > Fire-away,
> >
> > -Marc-
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 20 Sep 2005 19:29:48 -0400

What you're saying is that you don't want us to force the mapping client 
to be the fetcher of location.  You want the mapping server to have to 
do this.  You are imposing an additional interface on that equipment as 
a result.  Is this reasonable?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 21 Sep 2005 09:24:41 -0400

The problem is that there is an unbounded number of de-referencing  
mechanisms for by-reference mechanisms (any URL, essentially), while  
the protocol format clearly limits what's legal in by-value. Given  
the hierarchical nature of mapping, these references would also be  
passed around, with unknown access characteristics. Thus, without  
serious constraints on protocol mechanisms, this is a recipe for  
mapping failures. The security issues are even hairier.