Subject: [Ecrit] WG: DISCUSS: draft-ietf-ecrit-lost

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 21 Feb 2008 08:26:06 +0100

FYI 

-----Ursprüngliche Nachricht-----
Von: ext Ted Hardie [mailto:[email-masked]] 
Gesendet: Donnerstag, 21. Februar 2008 00:56
An: Lisa Dusseault; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: DISCUSS: draft-ietf-ecrit-lost

At 1:49 PM -0800 2/20/08, Lisa Dusseault wrote:
>Discuss:
>
>1. Redirects
>
>The section on redirect (13.3) is shockingly short.   Are redirects permanent or temporary?  Should other servers change their listings when seeing a redirect?  Redirects have caused interoperability problems in HTTP; perhaps a little deeper review of the need for the functionality would help here.

Redirects at the LoST layer are responses to a specific query.  Once an answer
has been received from the server to which the query was redirected, it will
have an "expires" attribute.  The same query can be retried after that point to
the original server.  Other queries may be sent to the LoST redirecting server
at any point; they may also be redirected, but since the LoST client will not
know what application logic is being applied for the LoST redirection, this is
the correct behavior for a LoST server that has followed its normal process
for identifying which LoST server to talk to for that service.

The current text in 13.3 is:

   A LoST server can respond indicating that the querier should redirect
   the query to another server, using the <redirect> element.  The
   element includes a 'target' attribute indicating the LoST application
   unique string (see Section 4) that the client SHOULD be contacting
   next, as well as the 'source' attribute indicating the server that
   generated the redirect response and a 'message' attribute explaining
   the reason for the redirect response.  During a recursive query, a
   server receiving a <redirect> response can decide whether it wants to
   follow the redirection or simply return the response to its upstream
   querier.

Would adding the following change meet the need:

   A LoST server can respond indicating that the querier should redirect
   the query to another server, using the <redirect> element.  The
   element includes a 'target' attribute indicating the LoST application
   unique string (see Section 4) that the client SHOULD be contacting
   next, as well as the 'source' attribute indicating the server that
   generated the redirect response and a 'message' attribute explaining
   the reason for the redirect response.  During a recursive query, a
   server receiving a <redirect> response can decide whether it wants to
   follow the redirection or simply return the response to its upstream
   querier.  The "expires" value in the response returned by the server
   handling the redirected query indicates the earliest time at which
   a new query might be needed (see section 5.2).  The same query
   SHOULD NOT be directed to the server which gave redirect prior to
   that time.

If a redirect is intend to move the entire service, rather than be limited to
queries (moving all response formerly served from lost.example.com
to lost.example.net), then the HTTP-level redirects should be used and the
permanent 301 code should be used.

>I'm inferring from section 14. that HTTP redirects MUST be supported by clients as well as LoST redirects.  Can that be made a normative requirement?

The document refers to RFC 2616, which gives these as SHOULD requirements in
10.3.X.  I do not believe it is appropriate to shift the requirement from the SHOULD
in HTTP to a MUST here.  Can you describe any reason why this should be stronger?

>2a.  Open-ended URI types
>I'd like to see more guidance on what URIs are returned.  The risk that the LoST server will return a URI that can't be used by the seeker is a bad risk to take when it comes to emergency services.

I think we have to be careful about this.  The base aim here is to make sure that the
contact URIs returned are those provisioned by those responsible for the jurisdiction.
We can provide advice on that, but it is ultimately up to those with the legal
responsibility to provide the records.  The working group chose to split the
advice (which is in draft-ietf-ecrit-phonebcp) from the protocol semantics exactly
because some jurisdiction may choose to use URIs that are specific to their
conditions.  Mailto may be reasonable in the eyes of some jurisdiction, in other
words, and the protocol should not eliminate it as a possibility. 

> - Add "tel" URI examples to the examples; Explain that in the worst case of not being able to use the URI types presented, seekers that have user interfaces should present the telephone number to the user; recommend that phone numbers be provided this way as fallbacks for emergency services

This is the serviceNumber element; please see Section 5.7.

> - limit the types used: no data or mailto URIs; better yet have a registry of types that *can* be used
> - In the case of SIP URIs, what kind of contact can be made?  Can this URI get a human voice, a voice mailbox, a presentity or other?

Can you rephrase this question?  I do not understand how the URI will determine
the method, which it sounds like is the root of the question.  Can you give a
further example here?

> - Differentiate between contact and resource URIs?  A resource URI obtains something static, a contact URI may be able to begin a conversation...

This service returns contact URIs, as the abstract and Overview of Protocol usage
(section 3) make clear. 

>I'd like a little discussion of the requirement that each URI scheme may appear only once.  That seems to prevent some fairly common use cases like providing one number for voice mail and one number to reach an operator.  The proliferation of http URIs makes this even worse -- many different kinds of services can be hosted on http URIs.  The Atom link rel provides an example of how one might deal with this problem.

This was discussed extensively in the working group.  The aim here is to avoid the
end user having to select among choices which are equivalent at the protocol level
while they have an emergency.  If the system returns 5 sip contact URIs, the user
should not have to select among them while simultaneously beating back the
flames in their car.  If a jurisdiction needs to arrange failover, it should do that
using a URI to a system capable of dispatch or failover (the NENA and ETSI folks
have a whole set of models of how that works using Emergency Service Routing
Proxies (ESRPs) )

>2b. IRIs
>
>Is support for IRIs explicitly not desired?

As the Internationalization Considerations notes, this is primarily intended
for machine-to-machine communications.  The URI form of IRIs is preferred
for this purpose in general, and it specifically preferred.  We did include
complex types for displayName and message, since those are not
machine-to-machine.

>2c. URI security/privacy
>
>I assume both LoST URIs (found in NAPTR) and service URIs can contain anything allowed by the URI scheme; long paths, query elements, anchor points. I can see a slight privacy issue here, because the URIs can contain tokens allowing communication from the LoST server that provided the URI to the service hosting that URI.

This question is not clear to me.  There are no tokens that allow communication from
the LoST server; there are tokens like the "sourceId", which identifies a particular
mapping?  Are you concerned that the requirement that it be unique has
some privacy consequence?  The current text there is:

The 'sourceId' attribute identifies a particular mapping and contains
   an opaque token that MUST be unique among all different mappings
   maintained by the authoritative source for that particular service.
   For example, a Universally Unique Identifier (UUID) is a suitable
   format.

Do you wish to suggest additional text here?

>This document doesn't talk about preserving URIs end-to-end.  What if a LoST resolver were to "helpfully" try to change URIs before passing them on to seekers?  Is there some other document that covers this?

The LoST resolver returns whatever was provisioned; if it changes the URIs that
were provisioned, it is not behaving according to the spec.

>
>3.  Overlooked HTTP features.
>
>A number of features that are commonly overlooked when using HTTP this way are not mentioned.  I like that HTTP caching is disabled but it looks like there's a cut-and-paste error in that part of the spec:
>
>  The HTTP request MUST use the Cache-Control response
>   directive "no-cache" to HTTP-level "caching even by caches that have
>   been configured to return stale responses to client requests."

You are right; sorry about the error.  I suggest the following RFC Editor note:

OLD
The HTTP request MUST use the Cache-Control response
   directive "no-cache" to HTTP-level "caching even by caches that have
   been configured to return stale responses to client requests."

NEW

The HTTP request MUST use the Cache-Control response
   directive "no-cache" to disable HTTP-level caching even by caches that have
   been configured to return stale responses to client requests.

>For the rest I suggest adding:
>
>"LoST servers MUST handle the Expect header, conditional headers and Content-* headers on requests according to HTTP requirements (possibly by failing the request).  They MUST also handle OPTIONS and HEAD and GET requests even if it's by responding with canned 200 responses.
>
>"LoST clients MUST include a Host header and MUST handle all possible HTTP response codes.
>
>"Both LoST clients and servers MUST handle chunked transfer-encoded message bodies."

My personal preference is to retain the reference to 2616 and assume that the LoST
server and client will use the available HTTP servers and clients as sources.  My concern
is that buy calling out these, the casual reader may assume that other HTTP
requirements do not apply.

I would be more supportive of language like "Client and server developers
are reminded that full support of RFC 2616 HTTP facilities is expected.  Among
those commonly missed are X, Y, Z.  If LoST Client or Servers re-implement
HTTP, rather using available servers or client code as a base, careful attention
must be paid to full interoperability".

Would that work for you?

Thanks for the review,
				Ted

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