RE: Past LC comments on draft-ietf-geopriv-http-location-delivery-08

["Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig at nsn.com>]

Hi Julian, 

thanks for the extremely quick response: 

>Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> ...
>>> 1) URI schemes
>>>
>>> From the draft, it's totally unclear what the URI schemes 
>are needed 
>>> for. For instance, the registrations do not mention what the URIs 
>>> actually identity, and how to resolve them.
>> 
>> Well. Initially, we wanted to use HTTP URI scheme but we were told 
>> that we shouldn't do that. Based on the advice we got we 
>created a new 
>> URI scheme.
>> ...
>
>I think that's bad advice.
>
>Either this decision should be reversed, or the specification 
>needs to be updated so that it acFrom ietf-bounces at ietf.org  Sun Aug  3 23:51:30 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 133CF3A6AF0;
	Sun,  3 Aug 2008 23:51:30 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D22C43A6B35
	for <ietf at core3.amsl.com>; Sun,  3 Aug 2008 23:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5
	tests=[AWL=-2.001, BAYES_00=-2.599, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id TMX2yApI-iZ9 for <ietf at core3.amsl.com>;
	Sun,  3 Aug 2008 23:51:28 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net
	[217.115.75.234])
	by core3.amsl.com (Postfix) with ESMTP id B678C3A6AF0
	for <ietf at ietf.org>; Sun,  3 Aug 2008 23:51:27 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55])
	by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id
	m746pJZU003067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 4 Aug 2008 08:51:19 +0200
Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35])
	by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP
	id m746pJIo015925; Mon, 4 Aug 2008 08:51:19 +0200
Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by
	demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 4 Aug 2008 08:51:19 +0200
Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by
	demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 4 Aug 2008 08:51:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Past LC comments on draft-ietf-geopriv-http-location-delivery-08
Date: Mon, 4 Aug 2008 09:51:16 +0300
Message-ID: <C41BFCED3C088E40A8510B57B165C16241632A at FIESEXC007.nsn-intra.net>
In-Reply-To: <4896A57D.30005 at gmx.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Past LC comments on draft-ietf-geopriv-http-location-delivery-08
Thread-Index: Acj1/bCPv2kFTMJrSvesctXNQevHhAAACNkQ
References: <4895D549.9060807 at gmx.de>
	<C41BFCED3C088E40A8510B57B165C1624162FA at FIESEXC007.nsn-intra.net>
	<4896A57D.30005 at gmx.de>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig at nsn.com>
To: "ext Julian Reschke" <julian.reschke at gmx.de>
X-OriginalArrivalTime: 04 Aug 2008 06:51:18.0955 (UTC)
	FILETIME=[7F7E6FB0:01C8F5FE]
Cc: IETF Discussion <ietf at ietf.org>, "ext Thomson,
	Martin" <Martin.Thomson at andrew.com>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

Hi Julian, 

thanks for the extremely quick response: 

>Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> ...
>>> 1) URI schemes
>>>
>>> From the draft, it's totally unclear what the URI schemes 
>are needed 
>>> for. For instance, the registrations do not mention what the URIs 
>>> actually identity, and how to resolve them.
>> 
>> Well. Initially, we wanted to use HTTP URI scheme but we were told 
>> that we shouldn't do that. Based on the advice we got we 
>created a new 
>> URI scheme.
>> ...
>
>I think that's bad advice.
>
>Either this decision should be reversed, or the specification 
>needs to be updated so that it actually *tually *defines* the URI scheme.
>

Like with many other areas, you ask 5 persons and get 7 opinions. 
How should a working group soliciting advice make an informed decisions?



>> ...
>>> 2) HTTP examples
>>>
>>> As far as I can tell, the examples in Section 11.1 are not really 
>>> HTTP, or I'm missing explanations that would be needed to 
>understand 
>>> this.
>>>
>>> For instance, they use heldref URIs in the Request-Line of the 
>>> request.
>>> Also, there's an example where a response uses the HTTP version 
>>> number "HTTP/1.x".
>> 
>> 
>> How would the examples have to look like so that they are correct?
>
>As far as I can tell,
>
>          GET heldrefs://lis.example.com:49152/location HTTP/1.1
>          Accept:application/held+xml,
>              application/xml;q=0.8,
>              text/xml;q=0.7
>          Accept-Charset: UTF-8,*
>
>needs to be:
>
>          GET /location HTTP/1.1
>          Host: lis.example.com:49152
>          Accept:application/held+xml,
>              application/xml;q=0.8,
>              text/xml;q=0.7
>          Accept-Charset: UTF-8,*
>
>...which of course makes it obvious that the new URI scheme is 
>totally pointless.

We just recently updated our examples from the lower one to the upper
one. Martin Thomson might provide you more background on this issue
since he also told me to update other drafts ... 

Martin, can you provide a bit of background here? 

>
>>> 3) Usage of HTTP
>>>
>>> The protocol tunnels over HTTP instead of using HTTP, probably 
>>> because it tries to be transport-agnostic. This makes only sense if 
>>> there are other transports. Are there?
>> 
>> The idea was to make it protocol agnostic and at least one other 
>> transport has been published. Currently, the group tries to finish 
>> some other work before these issues may be brought up again.
>> 
>>> Even if the answer to that is "yes", HTTP semantics should 
>be obeyed; 
>>> if the response to a request is an error message, it shouldn't be 
>>> returned with status code 200. There's no problem using a 4xx class 
>>> status code and returning a custom body (as we do in WebDAV).
>> 
>> We copied this from other documents that went through the 
>IETF process. 
>> We got told that returning a 200 OK is fine when the problem that 
>> caused the error message happens to be at a different layer. So far, 
>> that seemed to me like a pretty good answer and seems to be inline 
>> with the semantic of protocol layering.
>> ...
>
>Is that discussion archived somewhere? Where did it happen?

I have to search through the ECRIT and GEOPRIV mailing list -- 2 lists
with a lot of mail.

Ciao
Hannes


>
>BR, Julian
>
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


defines* the URI scheme.
>

Like with many other areas, you ask 5 persons and get 7 opinions. 
How should a working group soliciting advice make an informed decisions?



>> ...
>>> 2) HTTP examples
>>>
>>> As far as I can tell, the examples in Section 11.1 are not really 
>>> HTTP, or I'm missing explanations that would be needed to 
>understand 
>>> this.
>>>
>>> For instance, they use heldref URIs in the Request-Line of the 
>>> request.
>>> Also, there's an example where a response uses the HTTP version 
>>> number "HTTP/1.x".
>> 
>> 
>> How would the examples have to look like so that they are correct?
>
>As far as I can tell,
>
>          GET heldrefs://lis.example.com:49152/location HTTP/1.1
>          Accept:application/held+xml,
>              application/xml;q=0.8,
>              text/xml;q=0.7
>          Accept-Charset: UTF-8,*
>
>needs to be:
>
>          GET /location HTTP/1.1
>          Host: lis.example.com:49152
>          Accept:application/held+xml,
>              application/xml;q=0.8,
>              text/xml;q=0.7
>          Accept-Charset: UTF-8,*
>
>...which of course makes it obvious that the new URI scheme is 
>totally pointless.

We just recently updated our examples from the lower one to the upper
one. Martin Thomson might provide you more background on this issue
since he also told me to update other drafts ... 

Martin, can you provide a bit of background here? 

>
>>> 3) Usage of HTTP
>>>
>>> The protocol tunnels over HTTP instead of using HTTP, probably 
>>> because it tries to be transport-agnostic. This makes only sense if 
>>> there are other transports. Are there?
>> 
>> The idea was to make it protocol agnostic and at least one other 
>> transport has been published. Currently, the group tries to finish 
>> some other work before these issues may be brought up again.
>> 
>>> Even if the answer to that is "yes", HTTP semantics should 
>be obeyed; 
>>> if the response to a request is an error message, it shouldn't be 
>>> returned with status code 200. There's no problem using a 4xx class 
>>> status code and returning a custom body (as we do in WebDAV).
>> 
>> We copied this from other documents that went through the 
>IETF process. 
>> We got told that returning a 200 OK is fine when the problem that 
>> caused the error message happens to be at a different layer. So far, 
>> that seemed to me like a pretty good answer and seems to be inline 
>> with the semantic of protocol layering.
>> ...
>
>Is that discussion archived somewhere? Where did it happen?

I have to search through the ECRIT and GEOPRIV mailing list -- 2 lists
with a lot of mail.

Ciao
Hannes


>
>BR, Julian
>
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf