Thanks, Ben! We will proceed for this then. Richard
On Thu, May 16, 2013 at 5:18 PM, Ben Niven-Jenkins <[email protected]>wrote: > Works for me. Ben > > On 15 May 2013, at 21:40, "Y. Richard Yang" <[email protected]> wrote: > > > > On Wed, May 15, 2013 at 12:49 PM, Richard Alimi <[email protected]>wrote: > >> On Tue, May 14, 2013 at 12:29 PM, Ben Niven-Jenkins < >> [email protected]> wrote: >> >>> I support the change. >>> >>> One thing that might be worth making clear is that the client MUST NOT >>> assume that the media type returned by the ALTO server is the media type >>> advertised in the IRD (i.e. the client must still check the Content-Type >>> header). The expectation is the media type returned should normally be the >>> media type advertised but in some cases it may legitimately not match (e.g. >>> ALTO error). >>> >> > Thanks Ben. Personally, I found this perspective of HTTP confusing. HTTP ( > http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1) also > specified: > > "Any HTTP/1.1 message containing an entity-body SHOULD include a > Content-Type header field defining the media type of that body. If and only > if the media type is not given by a Content-Type field, the recipient MAY > attempt to guess the media type via inspection of its content and/or the > name extension(s) of the URI used to identify the resource. If the media > type remains unknown, the recipient SHOULD treat it as type > "application/octet-stream"." > > One possibility of exact wording can be: > > "An ALTO Client MUST NOT assume that the media type returned by the ALTO > Server for a request to a URI is the media type advertised in the IRD or > specified in its request (i.e., the client must still check the > Content-Type header). The expectation is the media type returned should > normally be the media type advertised and requested but in some cases it > may legitimately not be so (e.g., ALTO error)." > > Note that the preceding wording does not include the guessing part, which > I think is too much. > > What do you think? > > Richard > >> >> Thanks Sabine and Ben for the feedback. >> >> Ben - we'll be sure to make this clear in the draft. >> >> Thanks, >> Rich >> >> >>> >>> Ben >>> >>> On 14 May 2013, at 17:24, Richard Alimi wrote: >>> >>> > When we started specifying the format of the Information Resource >>> Directory (IRD), one concern was the overall size. As such, we designed >>> mechanisms to allowed a single entry in the IRD to specify that it could >>> handle multiple media types (both in the request and could provide >>> multiple media types). Based on some recent (off-list) discussions with >>> Wendy, this may be less of a concern and we may want to go for simplicity. >>> > >>> > Here's an example of one entry we have now: >>> > >>> > { >>> > "uri" : " >>> > http://custom.alto.example.com/maps >>> > ", >>> > "media-types" : [ >>> > "application/alto-networkmap+json", >>> > "application/alto-costmap+json" >>> > ], >>> > "accepts" : [ >>> > "application/alto-networkmapfilter+json", >>> > "application/alto-costmapfilter+json" >>> > ] >>> > } >>> > >>> > >>> > The proposal is to have each entry declare exactly one media-type for >>> the response, and either 0 or 1 media types for the request (e.g., the >>> unfiltered cost map doesn't need anything in the request - it's a simple >>> GET). >>> > >>> > Here's what the corresponding entry from above would look like: >>> > >>> > >>> > { >>> > "uri" : " >>> > http://custom.alto.example.com/maps >>> > ", >>> > "media-type" : "application/alto-networkmap+json", >>> > "accepts" : "application/alto-networkmapfilter+json", >>> > }, >>> > { >>> > "uri" : "http://custom.alto.example.com/maps >>> > ", >>> > "media-types" : "application/alto-costmap+json", >>> > "accepts" : "application/alto-costmapfilter+json", >>> > } >>> > >>> > >>> > >>> > The editors think this is a reasonable change to make. Comments are >>> very welcome. >>> > >>> > >>> > >>> > >>> > Since we are on a tight schedule here, if we don't hear anything >>> within the next week (by May 21st), we will make the corresponding changes >>> to the draft. >>> > >>> > Thanks! >>> > Rich >>> > >>> > >>> > >>> > _______________________________________________ >>> > alto mailing list >>> > [email protected] >>> > https://www.ietf.org/mailman/listinfo/alto >>> >>> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
