"Mike Schinkel" <mikeschinkel@...> writes:

> Stefan Tilkov wrote:
>>> Mike Schinkel wrote:
>>> > So my question was really "How to you programmatically
>>> > update the DNS?"
>>> You don't need to, as I've tried to point out.
>
> Thanks.  I was so wrapped up on what I already "knew" to be true about DNS
> that I wasn't even able to even hear you. That is until just now when I went
> to prove you wrong and found out that you were right! ;-)  Here is my test.
>
>  Microsoft Windows XP [Version 5.1.2600]
>  (C) Copyright 1985-2001 Microsoft Corp.
>
>  C:\Documents and Settings\mikes>nslookup
>  Default Server:  dns.guidesinc.local
>  Address:  192.168.0.143
>
>  > guidesinc.com
>  Server:  dns.guidesinc.local
>  Address:  192.168.0.143
>
>  Name:    guidesinc.com
>  Address:  208.101.32.104
>
>  > notthere.guidesinc.com
>  Server:  dns.guidesinc.local
>  Address:  192.168.0.143
>
>  Name:    notthere.guidesinc.com
>  Address:  208.101.32.104
>
> This is totally awesome! I had no idea this was possible and have always
> wanted to implement subdomains in that fashion (Damn, ignorance sux!) This
> opens up a whole world for me! Thank you.

Note that this is a feature of the DNS configuration. It's not always
the case.


--
Nic Ferrier
http://www.tapsellferrier.co.uk   for all your tapsell ferrier needs

Yeah, POST is the protocol equivalent pointing at something and grunting
at someone. Who knows what will happen in that language game [1]. What
you do know is the success criteria are undefined - unlike PUT and
DELETE, POST is degenerate.

As for APP, the most important contraints its adding aren't around POST;
they're around semantically relating resources to each other (either via
collections or media links). It's subtle but it's a big deal.

cheers
Bill

[1] http://www-csli.stanford.edu/~john/APA/apa/node2.html

Walden Mathews wrote:
>
>
>
> ----- Original Message -----
> From: "algermissen1971" <algermissen1971@...
> <mailto:algermissen1971%40mac.com>>
> :
> : Actually, I wonder if actions that are performed through 'process
> this'-POST (and not
> : through manipulation of resuorce state) aren't in fact hidden RPC anyhow
> and thus are
> : against REST's architectural principles.
>
> I don't think so.
>
> 'process this'-POST can be thought of as "implicit invocation". Another
> way of thinking of it is event delivery. In RPC, the client requests a
> remote
> method invocation. In Implicit Invocation (event delivery), the server
> decides what internal method, if any, to apply in response to the delivered
> event.
>
> Note the loose coupling of the II style. :-)
>
> Walden
>
>

Walden Mathews wrote:
>
>
> The side effects are not part of what the client intends.
>
> For example, PUTting to resource X may cause resource
> Y to cease to have a representation, but this outcome cannot be
> something the client intends; it's just server autonomy.

See my point elsewhere about APP. It introduces these kinds of
side-effects, but in a predictable fashion. You can't always work with a
collection/iterator or what is collected without inducing a side-effect.

cheers
Bill

: Yeah, POST is the protocol equivalent pointing at something and grunting
: at someone.

Except for the grunting part, yes.  The entity in a POST can be
a lot more elaborate and formal (and therefore more expressive)
than a grunt, though.  However, from the client POV, it may be
utterly meaningless.

: Who knows what will happen in that language game [1].

Fine, fine question if taken at face value.  So, what is the answer?

: What
: you do know is the success criteria are undefined

The server will respond with a status code indicating the level
of success, so how is it undefined?

: - unlike PUT and
: DELETE, POST is degenerate.

Or misunderstood.

--Walden

Walden Mathews wrote:
> : Yeah, POST is the protocol equivalent pointing at something and grunting
> : at someone.
>
> Except for the grunting part, yes.  The entity in a POST can be
> a lot more elaborate and formal (and therefore more expressive)
> than a grunt, though.  However, from the client POV, it may be
> utterly meaningless.

It's still grunting. Elaborate here would means two fingers.

> : Who knows what will happen in that language game [1].
>
> Fine, fine question if taken at face value.  So, what is the answer?

Apply Grice's maxims. Don't grunt when you have a better way of saying
things.

> : What
> : you do know is the success criteria are undefined
>
> The server will respond with a status code indicating the level
> of success, so how is it undefined?

What were we trying to do?

> : - unlike PUT and
> : DELETE, POST is degenerate.
>
> Or misunderstood.

Nope. POST is different.

cheers
Bill

On 11/29/06, Walden Mathews <waldenm@...> wrote:
> Well, y'all are making it sound like "loose coupling" is the
> only design quality we design for.  But what about scaleability,
> performance, security, transactional stuff (atomicity, integrity,
> durability, etc.)?

The hypothesis is that all constraints are expressible as a separation
of concerns, and therefore that all architectural properties derive
from some form of loose coupling.

> And in terms of tradeoffs, you may see constraints intended
> to induce some of the latter (above) interfering with the former,
> right?  Think of schema denormalization, for example.

Sure.  Any constraint has tradeoffs, just as any separation of concerns does.

Mark.

Mike Schinkel wrote:

> Now Bill, no need to get defensive on REST's account. [..]
>
> It certainly is not a deliberate debating tactic, it is me trying to make
> sense of things and to also figure out why the state of REST has been
> bugging me so much. But I've been doing a lot of reading and work offline
> and I think I'm getting a handle on what's been bugging me and how to
> resolve it.
>
>>> http://www.mikeschinkel.com/blog/WhatIsARESTafarian.aspx
>>> from where I'm standing people are doing their level best here
>>> to answer your questions. That doesn't help, at all.
>
> I'm not sure where you are going with this. I do appreciate all the help,
> and I am here with the best of intentions, I can assure you of that.

When I read that blog post about RESTafarians, and when you start this
response with "now Bill, no need to get defensive", I'm not sure what to
think about your assurances.

Confusing HTTP and REST results technical gibberish, it's not something
to encourage or equivocate about. If you were on comp.lang.object and
mixed up a JVM  implementation detail and object oriention, or confusing
Xerces bug with XML on xml-dev, it would hardly be reasonable to
describe a clarification as "defensive".

cheers
Bill

: The hypothesis is that all constraints are expressible as a separation
: of concerns

Referring to the dissertation, I see Roy identifies separation of
concerns as the principle behind the client-server constraint.  How
would you express the Stateless constraint as separation of
concerns...without undue contrivance?

How about Cache?

Walden

Hi,

as a clarification: I only meant to talk about application layer constraints -
sorry if that was unclear.

Jan

On Friday, December 01, 2006, at 06:00PM, "Nick Gall" <nick.gall@...>
wrote:
>--- In rest-discuss@yahoogroups.com, "Mark Baker" <distobj@...> wrote:
>>
>> Fascinating question!
>>
>> conjecture.  Can anybody think of one; a constraint on the
>> relationship of architectural elements which does *not* separate any
>> concerns?
>
>Fascinating indeed. Here's a potential counterexample: a latency
>constraint. Suppose a protocol coupling two components imposes a
>severe latency constraint, eg a reply must be received within 50ms.
>This is more constrained than a protocol without a latency constraint,
>but the components are now more tightly coupled, eg they must be
>spatially closer.
>
>More generally I have problems with the assertion that more
>constraints on a protocol means looser coupling of the components
>coupled by the protocol. If this were true, wouldn't the massive
>number of constraints imposed by CORBA and DCOM mean that the
>components coupled by these architectures were the MOST loosely
>coupled? Yet no one thinks of such components as loosely coupled.
>
>I think the invalid step in Jan's logic is in assuming that highly
>constrained protocols can be pervasive. Here's how I see his logic
>
>1. The more components that share common semantics in the protocol
>that interfaces among them, the more loosely coupled the component are
>("because coupling between components is induced by non-pervasive
>semantics shared between components"). [This I agree with.]
>
>2. Therefore, push as much (unshared) component semantics into the
>(shared) protocol as possible. [The problem with this strategy is that
>the very act of pushing more semantics into the protocol makes the
>protocol less generic (aka general purpose), which means that fewer
>components will use it, which means the shared semantics are now not
>very pervasive.]
>
>In general, I think loose coupling is an incredibly subtle concept,
>which unfortunately can not be reduced to something as simplistic as
>"maximize shared constraints". There is much more of a "balance"
>required between the degree of constraint and the pervasiveness of
>such constraints.
>
>A concept from economics seems relevant in this context -- Stigler's
>general specialties (now known as General Purpose Technologies):
>
>"This coupling of specialization of function with generalization of
>capabilities recalls the generalist merchants of the early republic.
>It is in fact a typical feature of the Smithian process. In his famous
>analysis of that process, George Stigler (1951, p. 192) referred to
>what he called 'general specialties.' He had in mind activities like
>railroads, shipping, and banking that can benefit a variety of
>industries; but contract suppliers are clearly examples in the small ?
>microcosmic instances of what economists now call general-purpose
>technologies (Helpman 1998)." "The Vanishing Hand"
>http://www.sp.uconn.edu/~langlois/Vanishing.html.
>
>See Wikipedia for a (too) short entry on GPTs:
>http://en.wikipedia.org/wiki/General_Purpose_Technology .
>
>Thus I would change Jan's conjecture to: "The more a system is general
>purpose and broadly adopted, the more the components are loosely coupled."
>How many constraints a purpose system should have will be more subtle
>balance than "as many as possible", since too many constraints will
>cause it to be less general and therefore less broadly adopted. The
>80/20 rule is appropriate here: design protocols in which a small number of
>constraints can address a large (and diverse) set of needs.
>
>My favorite example of the relaxation of constraints causing even looser
>coupling (besides the Internet and the Web protocols) is the invention of
>the intermodal shipping container. See
>http://en.wikipedia.org/wiki/Containerization ("Containerization has
>revolutionized cargo shipping.")
>
>-- Nick
>
>--
>Nick Gall
>Phone: +1.781.608.5871
>AOL IM: Nicholas Gall
>Yahoo IM: nick_gall_1117
>MSN IM: (same as email)
>Google Talk: (same as email)
>Email: nick.gall AT-SIGN gmail DOT com
>Weblog: http://ironick.typepad.com/ironick/
>Furl: http://www.furl.net/members/ngall
>

On 12/1/06, Walden Mathews <waldenm@...> wrote:
> : The hypothesis is that all constraints are expressible as a separation
> : of concerns
>
> Referring to the dissertation, I see Roy identifies separation of
> concerns as the principle behind the client-server constraint.  How
> would you express the Stateless constraint as separation of
> concerns...without undue contrivance?

Statelessness separates message semantics from server state.

> How about Cache?

You stumped me.  Come to think of it, even self-description in general
isn't expressible as a separation of concerns, though some of the
subordinate constraints are (uniform interface, statelessness).  Oh
well, I think you have your answer, Jan. 8-)

Still, the hypothesis had longer legs than I expected.  That might
make it useful as a tool for describing some aspects of software
architecture to those that aren't familiar with what's described in
chapter 1 of Roy's dissertation, but are familiar with the concept of
"loose coupling".

Mark.

On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
> Hi,
>
> as a clarification: I only meant to talk about application layer constraints -
sorry if that was unclear.

What do you mean by "application layer constraint", Jan?

Mark.

On Dec 1, 2006, at 8:43 PM, Mark Baker wrote:

> On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
> > Hi,
> >
> > as a clarification: I only meant to talk about application layer
> constraints - sorry if that was unclear.
>
> What do you mean by "application layer constraint", Jan?

Hmm....I had no idea that phrase did not exist already...felt so
natural. Sorry.

I mean a constraint that applies to the application semantics of a
system. A uniform API
is such a constraint, pervasively understood media types would be
another.

Thinking about it, in terms of REST I should maybe have said
'interface constraint' and
'data element constraint'?

This was partially inspired by your 'axiom blog posting'[1]; it
suddenly struck me that what
distiguishes REST from SOA the most is that REST includes
'application layer axioms' and
SOA does not.

IOW, I wanted to point out that constraints that apply to the
application semantic are fundamentally
different from other constraints.

Jan


>
> Mark.
>
>

(sorry, forgot the reference)

[...] This was partially inspired by your 'axiom blog posting'[1]; [...]

Jan

[1] http://www.markbaker.ca/blog/2006/07/19/standards-as-axioms/





>
> Mark.
>
>

On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
>
> On Dec 1, 2006, at 8:43 PM, Mark Baker wrote:
>
> > On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
> > > Hi,
> > >
> > > as a clarification: I only meant to talk about application layer
> > constraints - sorry if that was unclear.
> >
> > What do you mean by "application layer constraint", Jan?
>
> Hmm....I had no idea that phrase did not exist already...felt so
> natural. Sorry.
>
> I mean a constraint that applies to the application semantics of a
> system. A uniform API
> is such a constraint, pervasively understood media types would be
> another.

Hmm, I'm not sure that term makes sense.  Constraints are on data,
components, and connectors, which are all "application layer" AFAICT.

Can you give an example of a constraint that isn't application layer?

Mark.

On Dec 1, 2006, at 9:38 PM, Mark Baker wrote:

> On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
>>
>>
>> I mean a constraint that applies to the application semantics of a
>> system. A uniform API
>> is such a constraint, pervasively understood media types would be
>> another.
>
> Hmm, I'm not sure that term makes sense.  Constraints are on data,
> components, and connectors, which are all "application layer" AFAICT.
>
> Can you give an example of a constraint that isn't application layer?

Sockets. They enable communication to happen, but do not affect
(constrain) the
application layer.

Maybe 'constraint' is the wrong word?

>
> Mark.

Bill,

I once had an unaltered tomcat as a pet who hunted quite well
and on more than one occasion POSTed a dead rabbit on my
back doorstep.  He didn't use HTTP, but I recognize the POST
method nonetheless.

Had he been required to issue the correct command, I'm
sure communication would have broken down.  He knew I
would know how best to dispose of the rabbit.  More
accurately, and more importantly, he knew no such thing, and
yet his POST action was still the right one.

Pet lesson in interop #1.

Walden

----- Original Message -----
From: "Bill de hOra" <bill@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, December 01, 2006 9:21 AM
Subject: Re: [rest-discuss] Atom, 'process-this'-POST and rockets


: Walden Mathews wrote:
: > : Yeah, POST is the protocol equivalent pointing at something and
grunting
: > : at someone.
: >
: > Except for the grunting part, yes.  The entity in a POST can be
: > a lot more elaborate and formal (and therefore more expressive)
: > than a grunt, though.  However, from the client POV, it may be
: > utterly meaningless.
:
: It's still grunting. Elaborate here would means two fingers.
:
: > : Who knows what will happen in that language game [1].
: >
: > Fine, fine question if taken at face value.  So, what is the answer?
:
: Apply Grice's maxims. Don't grunt when you have a better way of saying
: things.
:
: > : What
: > : you do know is the success criteria are undefined
: >
: > The server will respond with a status code indicating the level
: > of success, so how is it undefined?
:
: What were we trying to do?
:
: > : - unlike PUT and
: > : DELETE, POST is degenerate.
: >
: > Or misunderstood.
:
: Nope. POST is different.
:
: cheers
: Bill
:
:
:
: __________ NOD32 1895 (20061201) Information __________
:
: This message was checked by NOD32 antivirus system.
: http://www.eset.com
:
:

On Dec 1, 2006, at 10:00 PM, Mark Baker wrote:

> On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
>> > Can you give an example of a constraint that isn't application
>> layer?
>>
>> Sockets. They enable communication to happen, but do not affect
>> (constrain) the
>> application layer.
>>
>> Maybe 'constraint' is the wrong word?
>
> I think so.  Sockets aren't a constraint.  They're not even a
> connector (just a part of one).

Ok, seems like I was trying to point out a distinction that inherently
has been made already by focusing on connector, component and data.

So, using your term 'axiom': would you agree that SOA/WS-* does not
use *any* axiom?


Thanks,

Jan




>
> Mark.

On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
> > Can you give an example of a constraint that isn't application layer?
>
> Sockets. They enable communication to happen, but do not affect
> (constrain) the
> application layer.
>
> Maybe 'constraint' is the wrong word?

I think so.  Sockets aren't a constraint.  They're not even a
connector (just a part of one).

Mark.

On Dec 1, 2006, at 9:38 PM, Mark Baker wrote:
>
>
> Hmm, I'm not sure that term makes sense. Constraints are on data,
> components, and connectors, which are all "application layer" AFAICT.
Let's try the other way round: does SOA (or WS-*) use any constraint on
any of those three?

I'd say 'no'.

Does WS-*'s constraining the data to SOAP count as a constraint on
data in the software architectural sense? IMHO it does not, because it
is just transport (below the application layer).

But maybe we are talking past each other. Will check back with Roy's
disertation (though not today).

Jan




>
> Can you give an example of a constraint that isn't application layer?
>
> Mark.
>
>

On Dec 1, 2006, at 10:09 PM, Nick Gall wrote:

> "The more a system is constrained [without limiting the generality
> of the system], the more loosely coupled are the components."
>
> A good example of this ATOM/GData, which constrains "ad hoc REST",
> but is effectively just as general purpose.

This sounds like what I was trying to say, but let's check: what do
you mean by

'ad hoc REST'

and in what way do you think Atom constrains it?


Jan

On 12/1/06, Jan Algermissen <algermissen1971@...> wrote:
>
> On Dec 1, 2006, at 9:38 PM, Mark Baker wrote:
> >
> >
> > Hmm, I'm not sure that term makes sense. Constraints are on data,
> > components, and connectors, which are all "application layer" AFAICT.
> Let's try the other way round: does SOA (or WS-*) use any constraint on
> any of those three?
>
> I'd say 'no'.

It's hard to tell for certain of course, since SOA isn't defined.  But
if you look at what people are doing in its name, you can pick out at
least a couple of constraints; client/server, and layered (just as
with REST).

> Does WS-*'s constraining the data to SOAP count as a constraint on
> data in the software architectural sense? IMHO it does not, because it
> is just transport (below the application layer).

WS-* might be SOAP-specific, but we're talking about the architectural
style which is (so I'm told) SOA.  SOA does not require SOAP, nor
should it if it's an architectural style.

> But maybe we are talking past each other. Will check back with Roy's
> disertation (though not today).

Good idea.

Mark.

Nice try. The rabbit's not a communication act, it's an indexical - you
infer in passing the tomcat left the rabbit - it's not as though the
tomcat told you it left a rabbit. But until I see computers with the
capabilities of tomcats, this will not matter either way.

cheers
Bill

Walden Mathews wrote:
> Bill,
>
> I once had an unaltered tomcat as a pet who hunted quite well
> and on more than one occasion POSTed a dead rabbit on my
> back doorstep.  He didn't use HTTP, but I recognize the POST
> method nonetheless.
>
> Had he been required to issue the correct command, I'm
> sure communication would have broken down.  He knew I
> would know how best to dispose of the rabbit.  More
> accurately, and more importantly, he knew no such thing, and
> yet his POST action was still the right one.
>
> Pet lesson in interop #1.
>
> Walden
>
> ----- Original Message -----
> From: "Bill de hOra" <bill@...>
> To: <rest-discuss@yahoogroups.com>
> Sent: Friday, December 01, 2006 9:21 AM
> Subject: Re: [rest-discuss] Atom, 'process-this'-POST and rockets
>
>
> : Walden Mathews wrote:
> : > : Yeah, POST is the protocol equivalent pointing at something and
> grunting
> : > : at someone.
> : >
> : > Except for the grunting part, yes.  The entity in a POST can be
> : > a lot more elaborate and formal (and therefore more expressive)
> : > than a grunt, though.  However, from the client POV, it may be
> : > utterly meaningless.
> :
> : It's still grunting. Elaborate here would means two fingers.
> :
> : > : Who knows what will happen in that language game [1].
> : >
> : > Fine, fine question if taken at face value.  So, what is the answer?
> :
> : Apply Grice's maxims. Don't grunt when you have a better way of saying
> : things.
> :
> : > : What
> : > : you do know is the success criteria are undefined
> : >
> : > The server will respond with a status code indicating the level
> : > of success, so how is it undefined?
> :
> : What were we trying to do?
> :
> : > : - unlike PUT and
> : > : DELETE, POST is degenerate.
> : >
> : > Or misunderstood.
> :
> : Nope. POST is different.
> :
> : cheers
> : Bill
> :
> :
> :
> : __________ NOD32 1895 (20061201) Information __________
> :
> : This message was checked by NOD32 antivirus system.
> : http://www.eset.com
> :
> :
>

Of course not, the rabbit is the entity.

But I can see this is going nowhere.  Did you have a point to make
about POST being degenerate (whatever you mean by that)?  Is
this something we need to care about?

Walden

----- Original Message -----
From: "Bill de hOra" <bill@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, December 01, 2006 8:35 PM
Subject: Re: [rest-discuss] Atom, 'process-this'-POST and rockets


:
: Nice try. The rabbit's not a communication act, it's an indexical - you
: infer in passing the tomcat left the rabbit - it's not as though the
: tomcat told you it left a rabbit. But until I see computers with the
: capabilities of tomcats, this will not matter either way.
:
: cheers
: Bill
:
: Walden Mathews wrote:
: > Bill,
: >
: > I once had an unaltered tomcat as a pet who hunted quite well
: > and on more than one occasion POSTed a dead rabbit on my
: > back doorstep.  He didn't use HTTP, but I recognize the POST
: > method nonetheless.
: >
: > Had he been required to issue the correct command, I'm
: > sure communication would have broken down.  He knew I
: > would know how best to dispose of the rabbit.  More
: > accurately, and more importantly, he knew no such thing, and
: > yet his POST action was still the right one.
: >
: > Pet lesson in interop #1.
: >
: > Walden
: >
: > ----- Original Message -----
: > From: "Bill de hOra" <bill@...>
: > To: <rest-discuss@yahoogroups.com>
: > Sent: Friday, December 01, 2006 9:21 AM
: > Subject: Re: [rest-discuss] Atom, 'process-this'-POST and rockets
: >
: >
: > : Walden Mathews wrote:
: > : > : Yeah, POST is the protocol equivalent pointing at something and
: > grunting
: > : > : at someone.
: > : >
: > : > Except for the grunting part, yes.  The entity in a POST can be
: > : > a lot more elaborate and formal (and therefore more expressive)
: > : > than a grunt, though.  However, from the client POV, it may be
: > : > utterly meaningless.
: > :
: > : It's still grunting. Elaborate here would means two fingers.
: > :
: > : > : Who knows what will happen in that language game [1].
: > : >
: > : > Fine, fine question if taken at face value.  So, what is the answer?
: > :
: > : Apply Grice's maxims. Don't grunt when you have a better way of saying
: > : things.
: > :
: > : > : What
: > : > : you do know is the success criteria are undefined
: > : >
: > : > The server will respond with a status code indicating the level
: > : > of success, so how is it undefined?
: > :
: > : What were we trying to do?
: > :
: > : > : - unlike PUT and
: > : > : DELETE, POST is degenerate.
: > : >
: > : > Or misunderstood.
: > :
: > : Nope. POST is different.
: > :
: > : cheers
: > : Bill
: > :
: > :
: > :
: > : __________ NOD32 1895 (20061201) Information __________
: > :
: > : This message was checked by NOD32 antivirus system.
: > : http://www.eset.com
: > :
: > :
: >
:
:
:
: __________ NOD32 1897 (20061201) Information __________
:
: This message was checked by NOD32 antivirus system.
: http://www.eset.com
:
:

Nic James Ferrier wrote:
>> Note that this is a feature of the DNS configuration. It's not always the
case.

What would be the DNS configuration option that would disable this, and can
it be controlled by the authoritative DNS?  Also, is the existence of said
configuration option specific to DNS server or a general capability of DNS?

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/

Bill de HOra:

>> it would hardly be reasonable to
>> describe a clarification as "defensive".

I was commenting on your tone, not the clarification.

I come in peace.  Honest.

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/

"Mike Schinkel" <mikeschinkel@...> writes:

> Nic James Ferrier wrote:
>>> Note that this is a feature of the DNS configuration. It's not always the
> case.
>
> What would be the DNS configuration option that would disable this, and can
> it be controlled by the authoritative DNS?

Depends on the server of course.

It's about how the names are resolved... not the policy of the zone.


> Also, is the existence of said
> configuration option specific to DNS server or a general capability
> of DNS?

I don't think a server is required to implement this
behaviour. Indeed, it might not work all the time in certain
situations. If you were behind (in terms of DNS queries) a very
restrictive DNS cache you might not be able to do dynamic names.

--
Nic Ferrier
http://www.tapsellferrier.co.uk   for all your tapsell ferrier needs

Walden Mathews wrote:
>
>
> Of course not, the rabbit is the entity.
>
> But I can see this is going nowhere. Did you have a point to make
> about POST being degenerate (whatever you mean by that)? Is
> this something we need to care about?

I think it is. HTTP without POST is an interesting gedanken experiment.
It's like having English without "just do it".

POST is uniformly devoid of meaning; anything will fit into it, which is
why it's degenerate (aka grunting) compared to the other methods. Which
is why approaches from html forms to WS to MEST like using it, they can
defer protocol decision making, or make point to point decisions that
don't have to be globally consistent.

In a two verb web with that kind of thinking, all GET provides over POST
is a switch for caches and form handlers.

cheers
Bill