[art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization

[Guntur Wiseno Putra <[e-mail]>]

Dear architecture-discuss,

Such co-presences of which architecture is part of: if we attempt to think
of its relation with other human experiences on poetry, on poetics, on a
spirit invoked to make comprehensible a poetic fact, to get toward an
understanding of cyberspace architecture, of "Liquid Architecture in
Cyberspace" (Marcos Novak, 1991)

I suggested as a reading to [e-mail] at which
there is the web-address to the Novak's work (posted at 12 May 2019):

http://www.w3.org/mid/[e-mail];list=public-informationarchitecture
Regard,

Guntur Wiseno Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <[e-mail]> menulis:

> Dear architecture-discuss,
> & John,
>
> To share what might be inspiring...
>
> In order to propose what should be understood as "concept", "percept" &
> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is
> Philosophy?") mentioned architecture as the first art as art begins with
> house: that of which "the most scientific architecture continually produces
> and unifies planes and sections... it could be defined as "frame" with a
> connection among various frames oriented differently, applied to other
> arts...(There is) a composite system consisting of points and
> counterpoints... (there is) a matter of sensations (percepts and affects)
> combined... (While) the system still needs a composition plane run
> "deframing" opening ways from house territory to city-cosmos, the system in
> which there are cosmic forces to create new affects...".
>
> There is "asthetic composition" as the working of sensation which is, so
> they said, the definition of art...
>
> Regard,
> Guntur Wiseno Putra
>
> Pada Selasa, 23 Juli 2019, Adam Roach <[e-mail]> menulis:
>
>> John --
>>
>> It's going to take a while for me to formulate my thoughts around what
>> you say below. To make sure I understand the class of constraints you're
>> concerned about below, can you clarify whether you think they apply to:
>>
>>    - Documents like BCP 200, RFC 2804, and BCP 188?
>>    - Documents like BCP 9 and BCP 92?
>>    - Documents like BCP 25, BCP 54, and BCP 83?
>>
>> You might see an unstated agenda in the categories of documents I list
>> above, so I'll state it explicitly: in the general case, one person's
>> important protections against a tragedy of the commons is another person's
>> annoying impediment to be ignored and defeated. I get that not all of the
>> above read on protocol design; but they do share the common feature that
>> they've gone through the IETF consensus process (at least to the degree
>> that such a process existed at the time of their respective publications).
>> If we're going to carefully parse out the meanings of some of them as the
>> will of the community while treating others as light guidelines to be
>> ignored when they become cumbersome, we're going to need to agree on a
>> pretty bright line that divides those categories.
>>
>> /a
>>
>> On 7/23/19 08:37, John C Klensin wrote:
>>
>> (copying architecture-discuss because the comment I'm about to
>> make is an architectural issue and because
>> draft-nottingham-for-the-users is under discussion there.)
>>
>>
>> A late colleague, much loved by some of us, used to claim (much
>> more elegantly than I can manage) that one of the reasons the
>> ARPANET and then the Internet protocols had succeeded and much
>> of what was seen as competitive alternatives had not, was that
>> our efforts focused on pragmatic, working protocols and
>> implementations.
>>
>> The other folks had developed a culture of formalisms, models,
>> and stated design principles.  They then tried to develop
>> protocols that fit into the boxes and categories of those
>> formalisms, models, and design principles.    When they
>> discovered that something didn't fit, they needed to either
>> invent kludges or other ways of getting square pegs into round
>> holes, go back and revise models and guidance before moving
>> forward, or consider and make exceptions (which often required
>> first figuring out how to make an exception and developing
>> procedures for that).
>>
>> One difficulty is that the above can waste a lot of time.
>> Another is that it can distort protocol design, if only because
>> forcing square pegs into round holes tends to be hard on both
>> the pegs and the holes.
>>
>> In many or most fields of application, the nature of engineering
>> involves seeing and understanding a range of tradeoffs and then
>> doing design work that reflects a carefully-chosen balance among
>> them.  Give design elegance absolute priority over structural
>> issues and buildings and bridges fall down.  IMO, we need to
>> think, and keep thinking, about systems and tradeoffs.  That, in
>> turn, means that statements like these that can be interpreted
>> in absolute terms, even if we mostly agree with them, should be
>> packaged as general guidelines and not BCPs to which everything
>> done in the future is required to either conform or to try to
>> figure out how to appeal to a higher authority.
>>
>> I'm not at all convinced that the proposal that was summarized
>> an ARTAREA yesterday and that is seen as requiring an exception
>> to BCP 190 is a good idea.  But I think our time would be better
>> spent, and the Internet more efficiently made better, discussing
>> the strengths, weaknesses, and alternatives to that idea rather
>> than debating the reach and appropriateness of BCP 190 under
>> various circumstances.   Long term and more generally, I think
>> that suggests seeing BCP 190 not as a particular set of
>> principles and rules but as an example of something we don't
>> want to do to ourselves again as a BCP (or as something that
>> gets enough of an IAB stamp of approval that people will later
>> argue MUST (or SHOULD) be conformed to.  Again, restated as
>> general guidance with the assumption that there will be
>> exceptions and cases not considered, I don't have much of a
>> problem.    If that shoe fits  draft-nottingham-for-the-users,
>> so be it.
>>
>>    john
>>
>> p.s. I don't mean to pick on Mark here.   While these two
>> documents coming up at the same time was handy, I think the
>> problem is general and that there are far worse examples
>> (examples of which he is not an author) than either of them.
>>
>> _______________________________________________
>> art mailing [e-mail]://www.ietf.org/mailman/listinfo/art
>>
>>
>>