search

annando / salmon-protocol

Automatically exported from code.google.com/p/salmon-protocol
0 stars 0 forks source link

Salmon Endpoint #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
In Section 2. Definitions
Consider changing "endpoint" to "Salmon endpoint" to match
the wording used in sections 3.1 and 3.2 and elsewhere.

In Section 5. Reply Endpoint Semantics
MUST a Salmon endpoint accept POSTs with
Content-Type: application/magic-envelope+xml
as shown in the example POST in
Section 4. Replies Protocol Flow?

SHOULD or MAY a Salmon endpoint accept other Content-Types?

Original issue reported on code.google.com by mail.ton...@gmail.com on 26 Feb 2010 at 3:07

GoogleCodeExporter commented 9 years ago 
Yes , specifically, is an application/atom+xml entry with <me:provenance> 
acceptable?

Original comment by wal...@gmail.com on 26 Feb 2010 at 5:40

GoogleCodeExporter commented 9 years ago 
Wording: Agreed, will update to indicate "salmon endpoint".

POST type:  Probably.  Is it helpful to do this?  Note that we're dealing here 
with a 
client and endpoint which both understand Magic Signatures so there's no legacy 
format issue.  The magic envelope is the smallest / most lightweight way of 
sending 
the data.  And, if the endpoint accepts an Atom entry w/provenance, it'll just 
throw 
away the entry and use the provenance information (it has to).  So it's really 
a 
question of whether we make the clients do this (if they are using an Atom 
entry 
internally) or the server.   I definitely want to make the magic envelope be 
the 
preferred mechanism for the reasons above.

Original comment by jpanzer@google.com on 26 Feb 2010 at 5:58

GoogleCodeExporter commented 9 years ago 
Added "Salmon endpoint" where it seemed ambiguous (many places already had a 
more 
specific rel value qualifier, e.g, salmon signing endpoint).

Holding off on changing the reply endpoint to REQUIRE it to accept 
application/atom+xml.  It's already implicitly a MAY of course (servers can 
accept any 
additional types they want) the question is whether it would be useful for 
clients to 
be able to rely on this generically.

Original comment by jpanzer@google.com on 1 Mar 2010 at 9:23

GoogleCodeExporter commented 9 years ago

Original comment by jpanzer@google.com on 1 Mar 2010 at 9:30

GoogleCodeExporter commented 9 years ago 
I don't think servers should be REQUIREd to accept application/atom+xml though 
of course they can for either 
debugging or alternative auth scenarios.  So I'm closing this out -- anyone who 
feels this is the wrong 
decision please yell.

Original comment by jpanzer@google.com on 6 Apr 2010 at 10:03