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

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

FYI

________________________________

Von: ext Lisa Dusseault [mailto:[email-masked]] 
Gesendet: Donnerstag, 21. Februar 2008 18:58
An: Ted Hardie
Cc: [email-masked]; [email-masked];
[email-masked]
Betreff: Re: DISCUSS: draft-ietf-ecrit-lost

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. 

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

		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.

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

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.

		- 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?

		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.  

Lisa

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