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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 22 Feb 2008 08:01:52 +0100

FYI 

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

At 8:57 AM -0800 2/21/08, Lisa Dusseault wrote:
>On Feb 20, 2008, at 2:56 PM, Ted Hardie wrote:
>
>>At 1:49 PM -0800 2/20/08, Lisa Dusseault wrote:
>>
>>>Discuss:
>>>
>>>1. Redirects
>>>
>>...
>>
>>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.
>>
>
>Referring to the "expires" value here is most helpful.  I forgot about that attribute when I read this section.
>
>I'm still confused about the way this is a redirect "for a specific query".  Until I saw that phrase elsewhere in your response, I missed the specificity: I thought that the agent (isn't it a client, not necessarily a server) receiving a <redirect> response would send all queries to the new redirected server.

No, it is specific to a particular query.  Take the case where a jurisdiction
is having a major event like the Olympics in a specific area.  During the
course of that event, the jurisdiction may redirect certain services  (like the
top level sos,  police or ambulance services) to special LoST servers when the query is
from the area of the event.  Other services, like sos.gas, sos.physician
or sos.poison, might not be redirected. 

>The text has "the query" and "the same query" but this doesn't say what should be done about other queries. 

Here's a full, proposed RFC editor note:

OLD
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.

NEW
   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
   the response would need to be refreshed (see section 5.2).  A query
   for the same tuple of  location and service SHOULD NOT be directed to
   the server which gave redirect prior to that time.

>
>>
>>>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?
>>
>
>Fair enough.  It's been my experience (e.g. in WebDAV interop tests) that some servers fully expect all clients to handle these, and treat these as if they were a MUST, when in fact clients can choose not to follow them.
>
>>
>>>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.
>>
>
>You've definitely thought about this in the WG but a new reader of the document has to work to figure out where responsibility for being able to interconnect with the service URI might lie, and whether interoperability problems with certain URI types is likely.  Is there something about this in another document? 
>
>A non-normative note on "Interoperability Concerns with Service URIs" would be very good here if it's not elsewhere, containing just the kind of information on how URIs are provisioned and how one might try to ensure lowest-common-denominator interoperability.

I propose to add this to the end of Section 3.  Here is a proposed RFC Editor's
note:

OLD:

   A service-specific Best Current Practice (BCP) document, such as
   [20], governs whether a client is expected to invoke the mapping
   service just before needing the service or whether to rely on cached
   answers.  Cache entries expire at their expiration time (see
   Section 5.2), or they become invalid if the caller's device moves
   beyond the boundaries of the service region.

NEW:

  A service-specific Best Current Practice (BCP) document, such as
   [20], governs whether a client is expected to invoke the mapping
   service just before needing the service or whether to rely on cached
   answers.  Cache entries expire at their expiration time (see
   Section 5.2), or they become invalid if the caller's device moves
   beyond the boundaries of the service region.  Service-specific
   Best Curent Practice documents may also provide guidance on the
   contact URI schemes most appropriate to the service.  As a general
   set of guidelines, URI schemes that do not provide mechanisms
   for actually initiating a contact method should be avoided (e.g. data, info,
    cid, tag) as transforming those references into contact mechanisms
    requires a layer of indirection that makes the overall mechanism more
    fragile.  Provisionally registered URI schemes should also be
   carefully considered before use, because they are subject to change in
   core semantics.

>The non-normative note could also mention the <serviceNumber> element and how to use it as a backup to ensure the end-user can reach the service.
>
>
>There's also an opportunity, not ruled out by your response, to require LoST clients to handle certain URIs.  Since SIP URIs appear in all the examples, one might require or strongly recommend LoST clients should be able to handle all types of SIP URIs.  In the long run, it would be good to spread awareness about what types of URIs are most commonly supported and used by clients.  An IANA registry may be too much for that purpose, but there ought to be something ecrit can do...

There is certainly a strong expectation in the working group that SIP will
be common.  But what a LoST client can do to "handle" SIP URIs is limited.
It must be able to handle the full URI syntax and thus any URI scheme or
production returned.  But once that URI has been returned, it is up to other
code to invoke SIP (or XMPP or any other protocol). 

We also cannot require, at a protocol level, that a LoST client should always
have access to a SIP stack.  There are valid deployment scenarios here that
have nothing but Tel URIs/serviceNumbers.  For non-emergency uses of
LoST the appropriate URIs may also be completely different.

>I still disagree about certain URIs.  You may be right about mailto: but that's stretching it; the data: URI is really harmful, not just "likely useless".  I won't insist on this however.

I hope the text proposed above handles this issue for you.

>
>>
>>
>>>- 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?
>>
>
>In theory the URI does not determine whether you'll get a human operator or a voice mailbox or a presentity; in practice, however, services often define different URIs for these things or have available specific URIs as well as generic ones. 
>
>The information about what the URI is likely to get you would have to be provided by the jurisdiction providing the service, along with the URI.
>
>Here's one thing I imagined might be done to address this issue:
>
>	<uri rel="operator">sip://switchboard.police.muenchen.de</uri>
>	<uri rel="text">sip://deafservice.police.muenchen.de</uri>
>
>
>
>>
>>
>>>- 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.
>>
>
>Yes, and that's all right as far as it goes.  I note that's descriptive text, not normative or even guidance text.
>
>>
>>>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) )
>>
>
>That's an excellent goal and one I didn't think of when reading the document.
>
>Perhaps instead of annotating URIs with what kind of link they are (as in my example above), better guidance would be for jurisdictions to provide a small number of general-purpose URIs ?  Can one hope to provide a single SIP URI for both voice and text, and allow the user agent to automatically bring the caller to the correct service version?

I believe any guidance to jurisdictions on this point should be in phonebcp.

>>
>>>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?
>>
>
>No, I thought about this one overnight and I realized that this situation is just what it is; URIs (particularly HTTP URIs) can contain all kinds of used and unused parameters and tokens, and they will be supported, and any possible fallout from that is already a concern.
>
>>
>>>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.
>>
>
>I agree that's correct, I'm not sure it's required by the spec.  I may be too paranoid here.
>
>>
>>
>>>
>>>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?
>>
>
>That would work for me very nicely, thanks -- a definite improvement.  A minor nit is that one of the reasons these are commonly overlooked is not because the software is re-implementing HTTP, but because the software uses a library or extension mechanism that encourages the service to ignore these required features because that's the default. 

Proposed RFC Editor Note:

In Section 14.
OLD:
  LoST needs an underlying protocol transport mechanisms to carry
   requests and responses.  This document defines the use of LoST over
   HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future
   documents.  The available transport mechanisms are determined through
   the use of the LoST U-NAPTR application.  In protocols that support
   content type indication, LoST uses the media type application/
   lost+xml.

NEW:
  LoST needs an underlying protocol transport mechanisms to carry
   requests and responses.  This document defines the use of LoST over
   HTTP and LoST over HTTP-over-TLS.  Client and server developers
are reminded that full support of RFC 2616 HTTP facilities is
expected.  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.  Other
transport mechanisms are left to future documents.  The available transport mechanisms
are determined through the use of the LoST U-NAPTR application.  In protocols that support
content type indication, LoST uses the media type application/lost+xml.

Thanks for  your review,
				Ted

>Lisa

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