Lisa Dusseault wrote:
>>> Can a client modify an entry to contain a link relation element in the
>>> following cases:
>>>
>>> - To point to a resource on a different server entirely?
>>
>> There is no reason to believe that any of these resource are on
>> the same machine to begin with. I could POST to media to machine A
>> and have the MLE could be created on machine B and the editable media
>> resource itself created on machine C.
>
> This requirement has to be stated explicitly, at least as a SHOULD.
Hmm. One particular operation in the APP is defined as creating two
resources; we specify how this is requested and the mechanism by which
the server communicates the URIs that identify the newly-created
resources. It would feel really weird to me to specify anything about
what servers the resources might be on. That's not how URIs work or how
the Web works. You can't tell by looking at a URI what server the
resource is on, anyhow. The URI might not be an HTTP URI. Two URIs that
look very much the same might reference data on different continents.
That's the whole point of how URIs work.
Having said that, Lisa has already pointed out shortcomings in the
number and placement of examples concerning this particular case. I
think it'd be a good idea to have the example showing the Media resource
showing up at http://media.example.com and the MLE showing up at
http://app.example.com.
But I'd be very much against side-tripping the protocol definition into
any discussion of "servers".
>>> Can a server ever ignore part of an edit and successfully process
the rest?
>>>
>>
>> Yes. Think of a client that throws in a slew of random link elements
with
>> relations my server implementation doesn't understand. Same with foreign
>> markup. The server is in charge.
>
> I completely disagree with this. It is way too unpredictable for
clients to deal with.
Well, except there are several examples of APP clients that seem to do
just fine.
Example: After extensive discussion, the WG achieved consensus that APP
servers are *not* required to retain foreign markup.
Example: It is perfectly possible to imagine a server that morphs or
prunes incoming entries for reasons of political censorship, security
policies, markup standards, spelling-correction, automatic translation,
or lots of other things we can't possibly imagine.
Example: my Ape protocol exerciser posts entries with a separate
<content> and <summary> fields. At least one of the servers I've tested
against accepts posts but discards my summary and generates its own,
algorithmically.
The range of things a server can usefully choose to do currently exceeds
our ability to specify or constrain. Fortunately, in HTTP, we have a
protocol the semantics of whose state-changing verbs PUT and POST are
remarkably well-matched for these interactions whereby a client says
"please take this and publish it and tell me what you did" and the
server says "OK, here's what I made of it."
The current WG consensus, way better than "rough", is that this level of
interoperation is useful. That consensus seems to be supported by
implementation experience.
Lisa, perhaps the problem is that I'm reacting to a fairly general
statement of concern. Do you have some specific suggestions as to how
server behavior could be limited or formally described?
-Tim
