I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-siprec-architect
greement. I think that more diversity in
>>>> IETF would help minimize the risk that some interests were
>>>> shortchanged, but I certainly agree that another factor is a lack of
>>>> understanding of, and respect for, the effect of certain changes on
>>&
he risk that some interests were
>>> shortchanged, but I certainly agree that another factor is a lack of
>>> understanding of, and respect for, the effect of certain changes on
>>> the Internet architecture.
>> Interesting... that could be the case.
>>
>&
a lack of understanding of, and respect
for, the effect of certain changes on the Internet architecture.
Interesting... that could be the case.
Have we even tried to identify and advertise those architectural principles
since the early days?
It may no longer be achievable, as pressure from v
> respect for, the effect of certain changes on the Internet architecture.
Interesting... that could be the case.
> Have we even tried to identify and advertise those architectural principles
> since the early days?
It may no longer be achievable, as pressure from vendors for new
On 03/22/2013 09:50 AM, John Curran wrote:
On Mar 21, 2013, at 8:58 AM, Keith Moore wrote:
...
Another result is that the Internet architecture has gone to hell, and we're
now spending a huge amount of effort building kludges to fix the problems
associated with other kludges and th
On Mar 21, 2013, at 8:58 AM, Keith Moore wrote:
> ...
> Another result is that the Internet architecture has gone to hell, and we're
> now spending a huge amount of effort building kludges to fix the problems
> associated with other kludges and the new kludges will
ZOOM://IETF.Fact.Check
IETF.Fact.Check on the ZOOM:// Scheme and ZOOM://BOX Architecture
ZOOM:// is a Scheme not a Protocol
The ZOOM://BOX Architecture as No Back-Haul connection to the Legacy Inter.NET
When you deploy your free open-source ZOOM://BOX and invite wireless
users they connect to
I was appointed to review this document from an OPS-DIR point of
vie, i,e, to check for operational or management aspects.
This are is not my space of expertise, so don't rely too much on my
report.
I think that there might be some operational aspects in the sense that
sometimes secure/encrypted
esign.
In addition to being an architecture, it is also a set of requirements for the
protocol design. It describes a protocol that is consistent with, and meets the
goals of, the WG charter. I raise two minor issues which folks might want to
consider but in my opinion it would be fine to publish
> From: Dave Cridland
> So currently, a NAT provides:
> - A degree of de-facto firewalling for everyone.
> - An immunity to renumbering for enterprises.
> - Fully automated network routing for ISPs.
> If technologies could be introduced to tackle especially the last two,
ram networks, with packet-level routing, are a
> failure at scale and that we should be going back to an essentially
> connection-oriented design at the network level.
I (perhaps obviously) think that's a rash conclusion: the circa 1975 Internet
architecture was never intended to grow
hi
I am a research scolar working in cross layer architecture for heterogeneous
network. I would like to contribute some work to draft a RFC for cross layer
architecture.
1. is there any IETF mail group / work group for Cross layer architecture of
wireless network. Kindly inform me.
2. If not
Support
> -Original Message-
> From: ietf-announce-boun...@ietf.org
> [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG
> Sent: Tuesday, June 02, 2009 10:01 PM
> To: IETF-Announce
> Cc: p...@ietf.org
> Subject: Last Call: draft-ietf-pwe3-ms-pw-arch (A
On 5/16/09 5:28 PM, SM wrote:
If you want to provide the historical chain of development, you'll
have to start with RFC 1341 for MIME. Mail routing is covered in RFC
974. There's also RFC 1123 which updates or annotates portions of RFC
821 to conform to current usage (at that time). RFC 1123
> --On Saturday, May 16, 2009 07:23 -0700 Ned Freed
> wrote:
> >> Comment on new text introduced into -13. The text in a new
> >> bullet in 6.3 says
> >
> >> > o MIME's [RFC2045] and [RFC2046] allow for the transport of
> >> > true multimedia material, which has obvious applicability
> >> > to
--On Saturday, May 16, 2009 07:23 -0700 Ned Freed
wrote:
>> Comment on new text introduced into -13. The text in a new
>> bullet in 6.3 says
>
>> > o MIME's [RFC2045] and [RFC2046] allow for the transport of
>> > true multimedia material, which has obvious applicability
>> > to internationali
One of the key points behind a layered architecture like this is
that these higher-level, logical, end-to-end relationships are
primary. Author and Recipient perceive themselves as sending to
each other. They mostly don't perceive all the underlying mechanism.
The paragraph is about the basic
> Comment on new text introduced into -13. The text in a new
> bullet in 6.3 says
> > o MIME's [RFC2045] and [RFC2046] allow for the transport of
> > true multimedia material, which has obvious applicability
> > to internationalization.
> It is not obvious at all.
Excuse me? If it isn't obvious
John C Klensin wrote:
Hi.
This is a tiny nit, but, since -13 has not yet been posted...
A few of the references list organizations and not authors as
authors and should probably be fixed.[RFC5335] sort of leapt
out at me. A quick scan also turned up [RFC1652], but I have
not done a compre
Comment on new text introduced into -13. The text in a new
bullet in 6.3 says
> o MIME's [RFC2045] and [RFC2046] allow for the transport of
> true multimedia material, which has obvious applicability
> to internationalization.
It is not obvious at all. MIME does three things:
(i) It ch
13
Title: Internet Mail Architecture
Creation_date: 2009-05-15
WG ID: Independent Submission
Number_of_pages: 54
Abstract:
Over its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a global
infrastructure service.
John C Klensin wrote:
This is a tiny nit, but, since -13 has not yet been posted...
Thanks.
Since the latest draft has been modified to respond to your recent observations
about internationalization and the role of an architecture document I'm glad to
see that your concerns are re
Hi.
This is a tiny nit, but, since -13 has not yet been posted...
A few of the references list organizations and not authors as
authors and should probably be fixed.[RFC5335] sort of leapt
out at me. A quick scan also turned up [RFC1652], but I have
not done a comprehensive check for others.
re 2, there really is a logical connection between Author and Recipient.
Referring to the use of that connection as sending to a Recipient.
One of the key points behind a layered architecture like this is that these
higher-level, logical, end-to-end relationships are primary. Author and
Re
At 05:27 13-04-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on t
I support this version of the document.
Tony Hansen
t...@att.com
The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Internet Mail Architecture '
> as a Proposed Standard
>
Ned Freed writes:
But that's the problem - this is not what RFC 5321 says.
It's not what 3501 says either ;) More of a one-sentence simplification
than a full and exact description.
...
SMTP server do stuff like expand lists all the time. For those tests
to be done competently some amount
s...@resistor.net writes:
> If there isn't an authoritative reference and there are differences in
> semantics or syntax between the draft and RFC5321/5322 or future
> revisions of these documents, it can lead to serious issues.
> Standards Track documents are around years. The documents may be
s...@resistor.net writes:
If there isn't an authoritative reference and there are differences in
semantics or syntax between the draft and RFC5321/5322 or future
revisions of these documents, it can lead to serious issues.
Standards Track documents are around years. The documents may be
edit
At 07:49 02-03-2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
There are several possible answers:
1. The author of the draft chooses the email-arch draft
2. The author of the draft chooses RFC 5321 and RFC 5332
3. Have the peopl
On Mon Mar 2 16:05:16 2009, Dave CROCKER wrote:
Dave Cridland wrote:
On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one
is authoritative?
>
Whichever is cited by the document referencing the content, of
course.
That sounds p
ned+ietf-s...@mrochek.com wrote:
At 20:21 01-03-2009, Dave CROCKER wrote:
>What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
"The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmittin
Maybe Dave you should add an Updates tag to your draft?
Eliot
On 3/2/09 5:26 PM, ned+i...@mauve.mrochek.com wrote:
At 20:21 01-03-2009, Dave CROCKER wrote:
>What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
"The Relay performs MHS-level tra
At 20:21 01-03-2009, Dave CROCKER wrote:
>What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
"The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting the message to its
Recipients.
At 20:21 01-03-2009, Dave CROCKER wrote:
What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
"The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting the message to its
Recipients. The
Dave Cridland wrote:
On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
>
Whichever is cited by the document referencing the content, of course.
That sounds pretty unstable, since it produces context-dependent
On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
Whichever is cited by the document referencing the content, of course.
Alternately, we could have a public food fight between Klensin,
Resnick, and Crocker. I
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
d/
SM wrote:
At 20:21 01-03-2009, Dave CROCKER wrote:
As this draft is being considered as a Proposed Standard, will it be
authoritative instead of RFC 5821/5322?
This presumes that there are different semant
At 20:21 01-03-2009, Dave CROCKER wrote:
As this draft is being considered as a Proposed Standard, will it
be authoritative instead of RFC 5821/5322?
This presumes that there are different semantics or syntax offered by them.
I'm replying to this point separately so that it does not get
conf
r side of not having to make
changes when there's a new RFC is not being sure whether the meaning has
changed...
In the Security Considerations Section (6.1):
"As mentioned in Section 4.1.4, it is common practice for components of this
architecture to use the [RFC0791].SourceAddr to
At 10:10 26-02-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on t
there.
That might start with a trimming and reworking of the IMC
document (see Paul's "should not be referenced in a modern
architecture document" comment -- one of the few I18N-related
areas in which the two of us are in agreement). Much of the
material there is good. Some can just be lef
John C Klensin wrote:
What specific changes are you proposing?
Really, John, whatever folks agree on is more than fine with me. However, I
also note that some other experienced IETFers have indicated that they consider
it acceptable to leave the text as-is.
Please note that besides the
http://www.imc.org/mail-i18n.html>.) For those of you checking your
chronometers, that means it predates IDNs, much less EAI.
It should not be referenced in a modern architecture document.
--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing lis
ntexts;
internationalization is not further discussed in this document".
Personally, I would object less to your saying nothing (or to
saying the above, which is equivalent) than to your hand waving
and then pointing off to a decade old non-consensus document
that is outdated in several areas.
parts of the architecture or at of least the
relevant protocols. As suggested above, one is that the content
matter is settled and that UTF-8 is the winner in the character
set wars (although other things are certainly around). Another
is that work on i18n of email headers and addresses is
progressing
challenge") seems dubious and
probably inappropriate.
(3) There are some useful things that can be said that are, at
this point, settled parts of the architecture or at of least the
relevant protocols. As suggested above, one is that the content
matter is settled and that UTF-8 is the winner
ocument has from the community. This requires
affirmative postings from the community.
However verbose or terse, positive or negative, it will aid the IESG's
assessment to see postings from you about whether to make "Internet Mail
Architecture" an IETF standard. In par
-- Forwarded message --
From: The IESG
Date: Thu, Feb 26, 2009 at 10:10 AM
Subject: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard
To: IETF-Announce
The IESG has received a request from an individual submitter to
consider
the following
Tony Hansen wrote:
Should it be using RFC5321/RFC5322 instead of RFC2821/RFC2822, such as
RFC5322.From instead of RFC2822.From?
yes.
current draft came out just before the latest RFCs were published.
final publication will be revised (and nits fixed -- thanks for the close read.)
d/
--
The IESG wrote:
> The IESG has received a request from an individual submitter to
> consider the following document:
>
> - 'Internet Mail Architecture '
> as a Proposed Standard
+1 for publication.
Should it be using RFC5321/RFC5322 instead of RFC2821/RFC2822, such a
The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Internet Mail Architecture '
>as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>fina
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. P
Hi all,
There are still some places in in draft-ietf-pcn-architecture-09 where the
"ingress/ingress-node" might be misused. Clarification or editorial changes
are required in those places. Please see the detailed comments below.
6.2. Flow termination : "In one approach the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Tony" == Tony Finch writes:
>>> Most networkable consumer electronics ships with at least two
>>> network interfaces. Host multihoming is only rare because it
>>> doesn't work.
>> Why do you say it doesn't work ?
Tony> Th
I spent several years trying to discern what the IETF's Internet
Architecture became when we abandoned our historic architecture and
started growing the middle of the hour glass through middleboxes and
telephony-originated techniques. For several years in the early 2000s I
became convinced th
Hello,all
We have setup an mailing list to discuss the host which would like to use
multiple interfaces.
several issues has been identified based on problem statement.
http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00.txt
Please be awared that it is different from multi
Tony Finch - le (m/j/a) 1/1/09 10:01 PM:
But what we need is an addressing architecture that allows us to tell the
difference between a hostname that has multiple addresses because they are
required for application addressing, or because the destination has
multiple points of connection
On Thu, 1 Jan 2009, John Leslie wrote:
>
>I'm not at all clear what "support" of "multihoming" Tony is asking
> for...
I'm not clear either, because I don't know what mechanisms could make it
work, especially not mechanisms that are deployable.
Bu
w in private email to clarify what I
mean, so this is going to turn into a massive rant about how
the current Internet architecture - as it is deployed, and as
it seems to be developing - has a completely broken idea of
how to address endpoints. The multiple meanings of the word
"multihoming&q
> I've been asked twice now in private email to clarify what I mean, so this
> is going to turn into a massive rant about how the current Internet
> architecture - as it is deployed, and as it seems to be developing - has a
> completely broken idea of how to address endpoi
on source address is a dangerous practice, even when the
source address is trusted.
> The Internet's idea of multihoming as supported by the architecture is
> NOT what I consider to be multihoming. (The lack of support for my
> idea of multihoming makes Internet connections klunky, frag
ltiple IP
addresses on the same link is a serious problem with practical
consequences.
I've been asked twice now in private email to clarify what I mean, so this
is going to turn into a massive rant about how the current Internet
architecture - as it is deployed, and as it seems to be devel
Am 24.12.2008 um 19:50 schrieb Bryan Ford:
So in effect we've gotten ourselves in a situation where IP
addresses are too topology-independent to provide good scalability,
but too topology-dependent to provide real location-independence at
least for individual devices, because of equally s
On Mon, 29 Dec 2008, Marshall Eubanks wrote:
> On Dec 29, 2008, at 10:02 PM, Tony Finch wrote:
>> On Mon, 29 Dec 2008, Noel Chiappa wrote:
>>>
>>> I have been thinking this for some time too, and it's especially
>>> true/clear when the multi-homing in question is site multi-homing,
>>> and not host
On Dec 29, 2008, at 10:02 PM, Tony Finch wrote:
On Mon, 29 Dec 2008, Noel Chiappa wrote:
I have been thinking this for some time too, and it's especially
true/clear when the multi-homing in question is site multi-homing,
and
not host-multihoming (which is much rarer, is my impression).
M
On Mon, 29 Dec 2008, Noel Chiappa wrote:
>
> I have been thinking this for some time too, and it's especially
> true/clear when the multi-homing in question is site multi-homing, and
> not host-multihoming (which is much rarer, is my impression).
Most networkable consumer electronics ships with at
> >> It ought to be, but unfortunately we have confounded the transport
> >> entity
> >> namespace with the network entity namespace with the point of
> attachment
> >> namespace.
> >
> > Not really. Many applications are actively managing their network
> connections, and for a good reason. A netwo
Hi Christian,
On 2008-12-30 11:55, Christian Huitema wrote:
>>> I would agree with this, except I defer to the 'get down off an
>> elephant'
>>> principle. If both points of attachment are bound to a single
>> transport level
>>> entity, then it ought to be relatively easy, and not involve the
>>
Short version: Please contribute to the IRTF Routing Research Group
discussions on how to devise a new Internet
architecture (including by adding to the current
architecture) to solve the routing scaling problem.
Hi John and All,
This
> > I would agree with this, except I defer to the 'get down off an
> elephant'
> > principle. If both points of attachment are bound to a single
> transport level
> > entity, then it ought to be relatively easy, and not involve the
> routing at
> > all, to detect that both points of attachment lea
John Day wrote:
> At 11:34 -0500 2008/12/29, John Leslie wrote:
>>
>> I accept "reliability and flow control" as the transport layer's
>> primary function, but denying it access to multiple interfaces cripples
>> its ability to perform those functions in a mobility environment.
>
> Transport has
Noel,
On 2008-12-30 05:28, Noel Chiappa wrote:
> > From: John Day
>
> > Multihoming is fundamentally a routing problem.
(snip)
> > It is a problem of routing not be able to recognize that two points of
> > attachment go to the same place. Portraying it as anything else is just
Hi -
> From: "John Day"
> To: "Rémi Després" ; "John C Klensin"
>
> Cc: "Bryan Ford" ;
> Sent: Monday, December 29, 2008 7:24 AM
> Subject: Re: The internet architecture
>
> No it isn't Transport's job. Transport
At 11:34 -0500 2008/12/29, John Leslie wrote:
John Day wrote:
At 14:22 +0100 2008/12/29, R?mi Despr?s wrote:
To pick a local interface for an outgoing connection[,]
isn't the transport layer, e.g. SCTP, well placed to do the job
(or some intermediate layer function like Shim6)?
No it i
ink the only way to resolve the question is to publish an Internet
architecture description in today's context, that explains what the
Internet architecture is, what it isn't, and why it has succeeded in
being what it is. At the same time, one could point to other work
outside
the IETF
At 17:04 +0100 2008/12/29, Rémi Després wrote:
John Day - le (m/j/a) 12/29/08 4:24 PM:
Re: The internet architecture
No it isn't Transport's job. Transport has one
and only one purpose: end-to-end reliability
and flow control.
"Managing" the resources of the network is
John Day wrote:
> At 14:22 +0100 2008/12/29, R?mi Despr?s wrote:
>>
>> To pick a local interface for an outgoing connection[,]
>> isn't the transport layer, e.g. SCTP, well placed to do the job
>> (or some intermediate layer function like Shim6)?
>
> No it isn't Transport's job. Transport has on
ly have
two alternative paths to the destination, and have to pick.
Which raises the question of 'why not have the routing do it', and that's a
very valid question. In a routing architecture which had better - read
non-manually configured - _scopes_ for routing information, and more
Title: Re: The internet architecture
John Day - le (m/j/a) 12/29/08 4:24 PM:
No it isn't Transport's job. Transport has one and only one
purpose: end-to-end reliability and flow control.
"Managing" the resources of the network is the network
layer
work).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name. One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as
esses, and, at least as we do things today and without other
changes in the architecture, only one name. One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is mo
consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name. One could change
the latter, but ha
onsider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name. One could change
the latter, but hav
ihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name. One could change
the latter, but having the typical application
s, clearly some level of
aggregation is essential but it is equally clear that 100% clean
aggregation is never going to be achievable either. The longer a
block is in service the more it gets 'bashed about'. Entropy
increases.
At the moment the Internet architecture has a built in
of
trust anchor.
When we did the Controlling access patent, this was part of the control
and reporting model we built for it.
At the moment the Internet architecture has a built in assumption that
the system is going to grow. And that keeps the chaos factor in check
because the new bl
achievable either. The longer a block is in service the more it gets 'bashed
about'. Entropy increases.
At the moment the Internet architecture has a built in assumption that the
system is going to grow. And that keeps the chaos factor in check because the
new blocks are a significant
On Dec 22, 2008, at 10:51 PM, macbroadcast wrote:
IP does not presume hierarchical addresses and worked quite well
without it for nearly 20 years.
IP addresses are topologically independent. Although since CIDR,
there has been an attempt to make them align with aspects of the
graph.
Ford's
hello,
thanks for your reply, i prefer answering questions to the list, hope
thats ok for you.
Let me try to answer your question with one sentence:
i believe that "Kademlia " [ 1 ] for example and the technologies
mentioned in the linked paper [ 2 ]
would fit the needs and requirem
-
related
functions to stop depending on location-dependent tokens, i.e.
locators.
Once that's done, they can use anything they like -- and they do :-).
Agreed. They do.
That does not mean that identity should not be an important part of
the internet architecture.
Note also that the pa
-dependent tokens, i.e.
locators.
Once that's done, they can use anything they like -- and they do :-).
Agreed. They do.
That does not mean that identity should not be an important part of
the internet architecture.
Note also that the paper above mixes identity with identifiers. They
a
Mark Seery allegedly wrote on 11/30/08 10:38 AM:
> Some questions have also risen WRT identity:
>
> http://www.potaroo.net/presentations/2006-11-30-whoareyou.pdf
>
> Is identity a network level thing or an application level thing?
Whatever. All of the above. There are many possible ways to use
Hallam-Baker, Phillip wrote:
10.1.2.3 is simply a string litteral that may be used in place of a
DNS name. In neither case should the application require knowledge of
the IP address itself. In fact you don't want that as at some point in
the distant future, 10.1.2.3 is actually going to map to
Ken Raeburn wrote:
> On Dec 17, 2008, at 11:01, Keith Moore wrote:
>>> One could possibly extend getaddrinfo() or make something a bit similar.
>>> getaddrinfo() is perhaps already becoming too complex though. A neat
>>> thing with extending getaddrinfo() could be to make existing code use
>>> SRV
On Dec 17, 2008, at 11:01, Keith Moore wrote:
One could possibly extend getaddrinfo() or make something a bit
similar.
getaddrinfo() is perhaps already becoming too complex though. A neat
thing with extending getaddrinfo() could be to make existing code use
SRV without changes. Not exactly sure
Stig Venaas wrote:
> I would have liked some standard API for looking up SRV records. It's
> hard to use SRV in portable applications.
In general there is a need for a standard, general purpose API for DNS
queries - one that lets you query for arbitrary record types. It also
needs to be thread s
Rémi Després wrote:
> Christian Vogt - le (m/j/a) 12/4/08 10:26 AM:
>> In any case, your comment is useful input, as it shows that calling the
>> proposed stack architecture in [1] "hostname-oriented" may be wrong.
>> Calling it "service-name-oriented"
was Re: The internet architecture)
Hallam-Baker, Phillip wrote:
> 10.1.2.3 is simply a string litteral that may be used in place of a
> DNS name. In neither case should the application require knowledge of
> the IP address itself. In fact you don't want that as at some point in
> the dista
1 - 100 of 307 matches
Mail list logo
