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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hannes, Julian,

> >> ...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 ...
> 
> Interesting, looking forward to understand the reasons.
> 
> > Martin, can you provide a bit of background here?
> > ...

I'm impartial on the topic of URI schemes.  The URI scheme was added on request after IESG review.  There were concerns about the loss of contextual information relating to the URI when used in contexts outside the context of the Device-LIS exchange.

Assuming that the URI is necessary...  The reason to go with the full URI on the request line is to ensure that the server is able to distinguish between a held[s]: URI and a matching http[s]: URI.  Without this, the server potentially does not know the difference.

Without the absolute URI, there is the possibility that held: and http: URIs could be considered equivalent.  In fact, there would be no meaningful difference when it comes to the protocol exchange, as you rightly pointed out.  (I'll note that this isn't the only difference that is important, and certainly wasn't a factor in the discussions that lead to the introduction of the new scheme.)

Using an absolute URI is not common practice in HTTP for anything other than requests to proxies.  However, RFC 2616 requires that servers understand and support absolute URIs (Sec. 5.1.2).  In my experience, this is a safe thing to assume; HTTP servers generally treat the URI sensibly.

Cheers,
Martin

------------------------------------------------------------------------------------------------
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]
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]