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
