catalog profile parameter and rfc 4288

[GoogleCodeExporter]

Shouldn't the section on the Catalog Profile Parameter [1] reference some 
text in the media type registration for application/atom+xml instead of RFC 
4288? All RFC 4288 section 4.3 seems to say is that parameter names are 
defined as part of the registration.

"""
   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.
"""

Is there anything in Atom we can reference for OPDS use of profile? Or are 
we taking the approach that the introduction of 'profile' doesn't change 
existing Atom functionality?

[1] 
http://code.google.com/p/openpub/wiki/CatalogSpecDraft#The_OPDS_Catalog_Pro
file_Parameter

Original issue reported on code.google.com by ed.summers on 24 May 2010 at 9:23

[GoogleCodeExporter]

Original comment by ed.summers on 24 May 2010 at 9:23

• Changed title: catalog profile parameter and rfc 4288

[GoogleCodeExporter]

Original comment by ed.summers on 24 May 2010 at 9:25

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Aside from discussions in the atom-syntax mailing list I'm not aware of 
anything we 
might be able to reference here.

Original comment by hadrien....@gmail.com on 24 May 2010 at 10:53

[GoogleCodeExporter]

A link to said discussion would be helpful I think.

Original comment by ed.summers on 24 May 2010 at 11:07

[GoogleCodeExporter]

Here are some of the discussions: 

  * http://markmail.org/thread/sybmn6byftbnfa7f
  * http://markmail.org/thread/omds3mvvbjnkdwrb
  * http://www.ietf.org/rfc/rfc3236.txt
  * http://intertwingly.net/wiki/pie/PaceProfileAttribute
  * http://buzzword.org.uk/2009/draft-inkster-profile-parameter-00.html

I believe that the syntax in RFC3236 and James' proposal isn't valid against 
§4.3 of RFC4288.

"""
   Parameter names have the syntax as media type names and values:

       parameter-name = reg-name

   Note that this syntax is somewhat more restrictive than what is
   allowed by the ABNF in [RFC2045] and amended by [RFC2231].
"""

I don't understand why a link to these discussions in the specification itself 
would be useful.

Original comment by abdela...@gmail.com on 24 May 2010 at 2:30

[GoogleCodeExporter]

Original comment by abdela...@gmail.com on 25 May 2010 at 5:41

• Added labels: Milestone-Release1.1
• Removed labels: Milestone-Release1.0

[GoogleCodeExporter]

Original comment by abdela...@gmail.com on 25 May 2010 at 5:44

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

I guess we can't really reference anything authoritative for opds' use of the 
profile 
parameter with the application/atom+xml media type. It sounds like various 
people 
have talked about it, but it never ended up in RFC 4287.

Working through this I agree that we are covered by RFC 4288 section 4.3: we 
aren't 
changing the functionality of the application/atom+xml media type in any way, 
we're 
just adding additional information. But it is kind of unfortunate that adding a 
profile parameter means that apps like Firefox, Google Reader, etc are no 
longer able 
to autodiscover a feed. I also noticed that feedbooks doesn't appear to be 
using the 
type and profile parameters in the Content-type response header, was that 
intentionally done because doing so breaks some things?

"""
curl -I http://www.feedbooks.com/books/recent.atom
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Thu, 27 May 2010 06:53:26 GMT
Content-Type: application/atom+xml; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Status: 200 OK
ETag: "d898628705b5777b310923d6fb171b62"
X-Runtime: 62
Cache-Control: private, max-age=0, must-revalidate
Content-Length: 39740
Set-Cookie: 
_sn=BAh7BjoPc2Vzc2lvbl9pZCIlMmRiNDllYTkzYzBkYzE4ZWQzM2I5MjJlMjkxMDZhMjQ%3D--
6e6aacf4fe6faba8649b1fdfc816a384c40595e5; domain=.feedbooks.com; path=/; 
HttpOnly
"""

Original comment by ed.summers on 27 May 2010 at 6:56

[GoogleCodeExporter]

Using the profile parameter in our atom:link would break compatibility with 
existing 
clients for sure. With "Content-Type" I'm not so sure but with dozens of 
thousands of 
people using our feeds on a daily basis, I need to be careful.

Original comment by hadrien....@gmail.com on 27 May 2010 at 11:28

[GoogleCodeExporter]

I believe we've addressed Ed's concerns. Reopen if that isn't true.

Original comment by abdela...@gmail.com on 4 Aug 2010 at 3:30

• Changed state: Done