Subject: [alto] Number of media types per resource

From: Richard Alimi <[email-masked]>
Date: Tue, 14 May 2013 09:24:46 -0700

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

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 14 May 2013 17:06:48 +0000

Hi all,

Fine with me. It definitely makes transactions clearer and simpler. Another advantage is that in case or errors at the client or server side, the consequences are limited  to a smaller set of requested objects.
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de Richard Alimi
Envoyé : mardi 14 mai 2013 18:25
À : [email-masked]
Objet : [alto] Number of media types per resource

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.

       {

         "media-types" : [

         ],

         "accepts" : [

         ]

       }

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).

       {

       },  {

       }

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 14 May 2013 20:29:15 +0100

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).

Ben

On 14 May 2013, at 17:24, Richard Alimi wrote:

>          "uri" : "
> http://custom.alto.example.com/maps
> ",
>          "media-types" : [
>          "uri" : "
> http://custom.alto.example.com/maps
> ",
>        }, 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Wed, 15 May 2013 09:49:51 -0700

On Tue, May 14, 2013 at 12:29 PM, Ben Niven-Jenkins <[email-masked]
> 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 Sabine and Ben for the feedback.

Ben - we'll be sure to make this clear in the draft.

Thanks,
Rich

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

---

From: Richard Alimi <[email-masked]>
Date: Wed, 15 May 2013 09:53:27 -0700

One clarification to this.

Along with this change, in order to retain the ability for an ALTO Server
referring to a set of resources in another IRD, we would also like to allow
an IRD entry to point directly to another iRD.  This would basically mean
that there would be entries specifying the media type
of "application/alto-directory+json".  Without this, it would force an ALTO
Server to explicitly list all resources at the other server, and we thought
that would be coupling them too tightly.

Thanks,
Rich

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 15 May 2013 16:40:57 -0400

On Wed, May 15, 2013 at 12:49 PM, Richard Alimi <[email-masked]> wrote:

> On Tue, May 14, 2013 at 12:29 PM, Ben Niven-Jenkins <
> [email-masked]> wrote:
>
>> I support the change.
>>
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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 May 2013 22:17:25 +0100

I'd always assumed that was allowed already :-) so making it explicit in the spec is fine with me. Ben

On 15 May 2013, at 17:53, Richard Alimi <[email-masked]> wrote:

> Along with this change, in order to retain the ability for an ALTO Server referring to a set of resources in another IRD, we would also like to allow an IRD entry to point directly to another iRD.  This would basically mean that there would be entries specifying the media type of "application/alto-directory+json".  Without this, it would force an ALTO Server to explicitly list all resources at the other server, and we thought that would be coupling them too tightly.
> 
> Thanks,
> Rich
> 
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 May 2013 22:18:24 +0100

Works for me. Ben

On 15 May 2013, at 21:40, "Y. Richard Yang" <[email-masked]> wrote:

>> On Tue, May 14, 2013 at 12:29 PM, Ben Niven-Jenkins <[email-masked]> wrote:
>>> I support the change.
>>> 
> 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"."
> 
> "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 
>> 
>>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 17 May 2013 13:57:45 -0400

Thanks, Ben! We will proceed for this then.

Richard

On Thu, May 16, 2013 at 5:18 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> On Wed, May 15, 2013 at 12:49 PM, Richard Alimi <[email-masked]>wrote:
>
>>> > 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
>>> >
>>> >
>>> >