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
