[e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/
John Day
day at std.com
Sun Jul 13 19:32:01 PDT 2008
Remember ICMP is a kludge. Work through how it should be done and
you will have a cleaner solution.
I am being dense. How do you find TCBs with no source address? The
TCP connection-identifier is only unique within the scope of the
(source-address, destination-address) pair. Once you do something
dumb like overload the connection-id to identify applications, i.e.
well-known ports, so that half the connection-id is the same for a
large number of connections and take away the source address, you are
left with (source-port-id, destination-address) needing to be unique,
which is pretty unlikely.
What did I miss?
Take care,
John
At 9:10 -0700 2008/07/11, Joe Touch wrote:
>Jon,
>
>Jon Crowcroft wrote:
>...
>>I simplify the design of ip to get these properties
>>properly, at the cost of complex icmp but icmp is slow path/control
>>plane so that tradeoff is to MY benefit.
>>
>>putting information for forwarding (as opposed to for end system)
>>into the TCP header would require ip forwarding to look there - on
>>the fast path which is clearly a Bad Idea not just in relegious
>>sense, but also in an engienering sense.
>
>I agree that shifting things around to make forwarding faster would
>be beneficial. However, I disagree that putting things in the
>transport header is a reasonable solution - whether ICMP is slow
>path or not, you're requiring routers to parse transport header,
>which is also a bad engineering idea.
>
>>ICMP communicates largely information for transport
>>(i.e. its a middle box function) so as i have said several times, it is
>>completely within scope to consider making this communication more
>>fit for purpose (indeed, more in keeping with the end to end
>>argument)
>
>ICMP is useful for network (e.g., routing) as well as transport.
>Even when considering just their transport use, however, they are
>generated as network signals to the source transport.
>
>Again, I appreciate the desire for more space for realms, etc., but
>there is no case here for using space in the transport header for
>the source ID or any other network layer information.
>
>>end of argument
>
>I agree; we have each come to our conclusions.
>
>Joe
>
>>In missive <48778010.102 at isi.edu>, Joe Touch typed:
>>
>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>> >>--------------enigF1C37DEE2E67C3C7E2C863DF
>> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >>Content-Transfer-Encoding: quoted-printable
>> >>
>> >>
>> >>
>> >>Jon Crowcroft wrote:
>> >>> you say i should put the realm info as a tcp option and then say there=
>> >> isnt
>> >>> much space for tcp options.
>> >>
>> >>You do put something as a TCP option - the source ID. I'm saying that it =
>> >>
>> >>is just as useful (or problematic) to put the realm there, and that TCP=20
>> >>lacks space in general for either.
>> >>
>> >>> i say sna does it in a way that is more flexible, doesnt need a lot of =
>> >>routers to
>> >>> change just yet,=20
>> >>
>> >>All routers on a path need to change to find the SNA ID to send return=20
>> >>ICMP errors.
>> >>
>> >> > and provides a lot of what people have done in mobile ipv6 (with
>> >>> route optimisation) without the pain of turning on full internet wide v=
>> >>6 routing.
>> >>> admittedly there's a little tweaking of some icmp code - this is not pe=
>> >>rformance
>> >>> critical and one could easily (as per shim6) do the transport/icmp inte=
>> >>rworking
>> >>> cleanly across all transports
>> >>
>> >>If this is done as a shim on IP, then it's just an IP option=20
>> >>(implemented a different way), in which case you haven't removed the=20
>> >>source address so much as shifted it.
>> >>
>> >>If this is done as a common transport option, you're pinning transport=20
>> >>protocols into a structure in order to support a network layer=20
>> >>capability, which violates layering.
>> >>
>> >>> hosts already peak into ICMP errors to see for what Transport they migh=
>> >>t be useful;=20
>> >>
>> >>That's not peeking; that's receiving an ICMP message and parsing it as=20
>> >>indicated.
>> >>
>> >>> i dont see why ICMP looking in transport to figure out=20
>> >>> whether its useful to send something at all and to whome is any differe=
>> >>nt=20
>> >>> in terms of religions like "layer violation" and its a whole lot more e=
>> >>fficient
>> >>
>> >>It's not a religious issue; I'm noting that source IDs/addresses aren't
>> >>only transport-layer info, and that's why ICMP needs access to them.
>> >>
>> >>Overall:
>> >>
>> >>- your proposal doesn't get rid of the source addr, it just moves it
>> >> e.g., because packets without source addrs can be silently
>> >> dropped without signaling the source, as you note,
>> >> and apps sending packets without sources should expect this
>> >>
>> >>- moving the source address doesn't accomplish anything
>> >> you want extra space for realms; that's fine, but taking
>> >> that space from IP and putting the info in TCP isn't
>> >> a win; it complicates ICMP design at routers. it's
>> >> just as useful to put realms in the TCP header,
>> >> or to put it in an IP option; there may be utility
>> >> in that, but this has nothing to do with getting rid
>> >> of a source address
>> >>
>> >>Joe
>> >>
>> >>
>> >>> In missive <487777D1.6090001 at isi.edu>, Joe Touch typed:
>> >>>=20
>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>> >>> >>--------------enigD0DFC0254F721440EFF890E4
>> >>> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>> >>> >>Content-Transfer-Encoding: quoted-printable
>> >>> >>
>> >>> >>Jon (et al.),
>> >>> >>
>> >>> >>Jon Crowcroft wrote:
>> >>> >>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed:
>> >>> >>>=3D20
>> >>> >>> >>Consider a packet whose transport lacks a destination address
>> >>> >>> >>altogether, as you note should be possible. Receivers of those =
>> >>packe=3D
>> >>> >>ts
>> >>> >>> >>have no way to turn them around.
>> >>> >>> =3D20
>> >>> >>> >>> icmp errors can be sent, but icmp in routers would have to pa=
>> >>rse t=3D
>> >>> >>he TCP sna option
>> >>> >>>=3D20
>> >>> >>> >>So basically the need for the *network* layer to signal the sou=
>> >>rce i=3D
>> >>> >>s
>> >>> >>> >>accommodated in packets using the TCP sna option by layer viola=
>> >>tion.=3D
>> >>> >>
>> >>> >>>=3D20
>> >>> >>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is no=
>> >>t a l=3D
>> >>> >>ayer
>> >>> >>> violation.
>> >>> >>
>> >>> >>If you call ICMP a transport layer (fair enough), you haven't explai=
>> >>ned=3D20
>> >>> >>why one transport should peek into the headers of another. ICMP can =
>> >>talk =3D
>> >>> >>
>> >>> >>to TCP, but having ICMP parse TCP headers would be layer violation I=
>> >>MO.
>> >>> >>
>> >>> >>> by the way, i dont put an _address_ in the transport - i put an id=
>> >>entif=3D
>> >>> >>ier - this
>> >>> >>> is then used receivers to lookup an address to the originator. i _=
>> >>might=3D
>> >>> >>_ put a
>> >>> >>> routing hint (e.g. a care of adddress) in the transport too - this=
>> >> is =3D
>> >>> >>
>> >>> >>> not the same as putting in an actual address (which i am getting r=
>> >>id of=3D
>> >>> >> as it is
>> >>> >>> invalid MOST of the time...
>> >>> >>
>> >>> >>Understood. That difference isn't key to my responses, so
>>I've just=3D=
>> >>20
>> >>> >>referred to it as an address, but didn't mean to confuse that issue.=
>> >>
>> >>> >>
>> >>> >>> >>Moving the source address in that case didn't make it go away, =
>> >>so th=3D
>> >>> >>at's
>> >>> >>> >>just shuffling the deck chairs. If you wanted more space for IP=
>> >>, it'=3D
>> >>> >>s
>> >>> >>> >>just as logical to leave the current IP header alone and place =
>> >>the e=3D
>> >>> >>xtra=3D20
>> >>> >>> >>forwarding info in the TCP header - if you're violating layers =
>> >>for I=3D
>> >>> >>CMP, =3D3D
>> >>> >>>=3D20
>> >>> >>> this is either a semantic quibble or confusing.
>> >>> >>>=3D20
>> >>> >>> 1. i havnt changed the IP header ast aal - i 've changed the meani=
>> >>ng of=3D
>> >>> >> a field -
>> >>> >>> thishas some very nice legacy interworking properties (as noted in=
>> >> my n=3D
>> >>> >>ote)
>> >>> >>
>> >>> >>Changing the meaning of a field changes the header. I.e., you can't =
>> >>pass =3D
>> >>> >>
>> >>> >>that packet through a legacy router usefully - it could generate ICM=
>> >>Ps=3D20
>> >>> >>to the wrong place, and won't interpret the source address field as =
>> >>an=3D20
>> >>> >>extension of the destination address.
>> >>> >>
>> >>> >>My view is that:
>> >>> >> change IP src address to mean destination realm
>> >>> >> add source identifier to TCP header (e.g., as an option)
>> >>> >>is just as usefully accomplished as:
>> >>> >> leave IP as-is
>> >>> >> add destination realm to the TCP header (as an option)
>> >>> >>
>> >>> >>(the only remaining difference is that your source identifier isn't =
>> >>the=3D20
>> >>> >>same as IP's source address; I could just as easily put the source I=
>> >>D in =3D
>> >>> >>
>> >>> >>the TCP header too if you prefer).
>> >>> >>
>> >>> >>Further, your paper and emails have not addressed the fact
>>that TCP=3D=
>> >>20
>> >>> >>headers don't exactly have lots of space - especially the SYN packet=
>> >>,=3D20
>> >>> >>which is where the source identifier for a connection would need to =
>> >>be=3D20
>> >>> >>established.
>> >>> >>
>> >>> >>=3D2E..
>> >>> >>> >>why not for forwarding?
>> >>> >>> >>> since most of these ICMP response are meant as a response to=
>> >> a tr=3D
>> >>> >>anspo=3D3D
>> >>> >>> >>rt entity,
>> >>> >>> >>> this is semantically reasoanble.
>> >>> >>> >>
>> >>> >>> >>Your system posits transports might not ever need source addres=
>> >>ses.
>> >>> >>> >>Those transports no longer benefit from ICMP information from t=
>> >>he ne=3D
>> >>> >>twork=3D3D
>> >>> >>>
>> >>> >>> indeed since there is no information theoretic or control theoerti=
>> >>c rea=3D
>> >>> >>son they
>> >>> >>> should want fedback from the net if thewy didnt want it from the e=
>> >>nd. -=3D
>> >>> >> i am just=3D20
>> >>> >>> bringing some consistency to a design error of the internet.
>> >>> >>
>> >>> >>I agree that unidirectional packets don't necessarily need
>>network=3D=
>> >>20
>> >>> >>feedback. That implies:
>> >>> >>
>> >>> >>1. that your entire supposition that the IP packet doesn't need a so=
>> >>urce =3D
>> >>> >>
>> >>> >>address because the transport layer is unacknowledged may be true, b=
>> >>ut=3D20
>> >>> >>actually implies that all transport layers should be
>>bidirectional=3D=
>> >>20
>> >>> >>(rather than implying that you don't need a source address).
>> >>> >>
>> >>> >>2. bidirectional packets need network address info in the network=3D=
>> >>20
>> >>> >>header, because the network needs to respond to that information. if=
>> >> I=3D20
>> >>> >>leave this to the transport layer, then every time I deploy a new=3D=
>> >>20
>> >>> >>transport protocol (SCTP, DCCP, etc.), I need to recode all my route=
>> >>rs=3D20
>> >>> >>to know where to peek to get information for ICMP to respond to.
>> >>> >>
>> >>> >>Again, as noted, many ICMP messages originate from the network, not =
>> >>the=3D20
>> >>> >>end host. The need for source addresses in the header in the Interne=
>> >>t is =3D
>> >>> >>
>> >>> >>to enable network-based error indicators. It's not clear at all why =
>> >>that =3D
>> >>> >>
>> >>> >>is something we can/should want to get rid of entirely.
>> >>> >>
>> >>> >>Joe
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>> >>
>> >>> >>> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed:
>> >>> >>> >>>=3D3D20
>> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)=
>> >>
>> >>> >>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126
>> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3Dwindows-1252; form=
>> >>at=3D3D3D=3D
>> >>> >>flowed
>> >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable
>> >>> >>> >>> >>
>> >>> >>> >>> >>Jon,
>> >>> >>> >>> >>
>> >>> >>> >>> >>You asked why the Internet had source addresses. I provide=
>> >>d an =3D
>> >>> >>answe=3D3D
>> >>> >>> >>r,=3D3D20
>> >>> >>> >>> >>based on my understanding of the historical context for th=
>> >>e dec=3D
>> >>> >>ision=3D3D
>> >>> >>> >>=3D3D2E I=3D3D20
>> >>> >>> >>> >>apologize for being too terse for that to be clear, or for=
>> >> bein=3D
>> >>> >>g too=3D3D
>> >>> >>> >>=3D3D20
>> >>> >>> >>> >>glib to belie a thoughful consideration of the contents of=
>> >> your=3D
>> >>> >> pape=3D3D
>> >>> >>> >>r.
>> >>> >>> >>> >>
>> >>> >>> >>> >>That, however, does not mean that I did not read your pape=
>> >>r.
>> >>> >>> >>> >>
>> >>> >>> >>> >>My response of your (IMO, historical) question has nothing=
>> >> to d=3D
>> >>> >>o wit=3D3D
>> >>> >>> >>h=3D3D20
>> >>> >>> >>> >>your proposal for removing them, as is discussed below.
>> >>> >>> >>> >>
>> >>> >>> >>> >>Jon Crowcroft wrote:
>> >>> >>> >>> >> > a perfect example of people responding to email that th=
>> >>ey ha=3D
>> >>> >>ven't=3D3D
>> >>> >>> >>
>> >>> >>> >>> >> > actually read properly
>> >>> >>> >>> >>
>> >>> >>> >>> >>I urge posters to read the mail they *write* as well as th=
>> >>ose o=3D
>> >>> >>thers=3D3D
>> >>> >>> >>=3D3D20
>> >>> >>> >>> >>post. ;-) Please read my more detailed note below before =
>> >>concl=3D
>> >>> >>uding=3D3D
>> >>> >>> >> how=3D3D20
>> >>> >>> >>> >>properly I've read your work.
>> >>> >>> >>> =3D3D20
>> >>> >>> >>> >>
>> >>> >>> >>> >>--
>> >>> >>> >>> >>
>> >>> >>> >>> >>You assert that:
>> >>> >>> >>> >>
>> >>> >>> >>> >>> Remember this (RFC 791)? Let=3D3D3D92s think about the l=
>> >>ine mar=3D
>> >>> >>ked
>> >>> >>> >>> >>> by Xs. So why is there a source address there? The naive=
>> >> answ=3D
>> >>> >>er
>> >>> >>> >>> >>> is that some receivers might want to reply.
>> >>> >>> >>> >>
>> >>> >>> >>> >>That is a historically consistent answer.
>> >>> >>> >>> >>
>> >>> >>> >>> >>> It;s a Datagram,
>> >>> >>> >>> >>> Stupid. Not all higher layers want to send something bac=
>> >>k! Th=3D
>> >>> >>e
>> >>> >>> >>> >>> end-to-end argument says that we do not put a function i=
>> >>n a l=3D
>> >>> >>ower
>> >>> >>> >>> >>> layer, unless it is required by the majority of upper la=
>> >>yer u=3D
>> >>> >>sers
>> >>> >>> >>> >>
>> >>> >>> >>> >>E2E argument allows designers to "put things in a layer th=
>> >>at TH=3D
>> >>> >>AT la=3D3D
>> >>> >>> >>yer
>> >>> >>> >>> >>actually needs".
>> >>> >>> >>> >>
>> >>> >>> >>> >>Later, your doc says that:
>> >>> >>> >>> >>
>> >>> >>> >>> >>> a better place to send advisory
>> >>> >>> >>> >>> information in the future Internet is onwards to the rec=
>> >>eiver=3D
>> >>> >>, not=3D3D
>> >>> >>> >>
>> >>> >>> >>> >>> backwards to the sender. Obviously the unreachable cases=
>> >> need=3D
>> >>> >>
>> >>> >>> >>> >>> to be considered more carefully, although if an end syst=
>> >>em is=3D
>> >>> >> not
>> >>> >>> >>> >>> reachable, a SNA-RK might be still reachable.
>> >>> >>> >>> >>
>> >>> >>> >>> >>Host and net unreachables can't be fixed at all, as you no=
>> >>te la=3D
>> >>> >>ter. =3D3D
>> >>> >>> >>
>> >>> >>> >>> >>Other messages require the receiver know the source, which=
>> >> - if=3D
>> >>> >> this=3D3D
>> >>> >>> >> is=3D3D20
>> >>> >>> >>> >>one of those higher layers that doesn't want to send somet=
>> >>hing =3D
>> >>> >>back =3D3D
>> >>> >>> >>-=3D3D20
>> >>> >>> >>> >>won't happen either.
>> >>> >>> >>> >>
>> >>> >>> >>> >>The fact that further discussion asserts that error notifi=
>> >>catio=3D
>> >>> >>ns we=3D3D
>> >>> >>> >>re=3D3D20
>> >>> >>> >>> >>always a bad idea I find naive as well. And MTU discovery =
>> >>will =3D
>> >>> >>NEVER=3D3D
>> >>> >>> >>=3D3D20
>> >>> >>> >>> >>happen if the receiver has no notion of who the sender is.=
>> >>
>> >>> >>> >>> >>
>> >>> >>> >>> >>---
>> >>> >>> >>> >>
>> >>> >>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed:
>> >>> >>> >>> >>>=3D3D20
>> >>> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and =
>> >>3156)=3D
>> >>> >>
>> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF
>> >>> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3D3DISO-8859-1;=
>> >> format=3D
>> >>> >>=3D3D3D3Dfl=3D3D
>> >>> >>> >>owed
>> >>> >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>Jon Crowcroft wrote:
>> >>> >>> >>> >>> >>> speaking of sacred cows,
>> >>> >>> >>> >>> >>> why are their source addresses in IP Packets?
>> >>> >>> >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>The same reason letters have return addresses; for er=
>> >>rors =3D
>> >>> >>(e.g.=3D3D
>> >>> >>> >>, ICM=3D3D3D
>> >>> >>> >>> >>Ps). =3D3D3D3D
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >> Not all errors signal the transport layer; some sig=
>> >>nal t=3D
>> >>> >>he ne=3D3D
>> >>> >>> >>twork=3D3D3D
>> >>> >>> >>> >>=3D3D3D3D20
>> >>> >>> >>> >>> >>layer (e.g., too-big, redirect, etc.)
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>PS - burying them in the TCP header eats option space=
>> >> from=3D
>> >>> >> TCP,=3D3D
>> >>> >>> >> whic=3D3D3D
>> >>> >>> >>> >>h=3D3D3D3D20
>> >>> >>> >>> >>> >>isn't exactly in abundance either ;-)
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>Joe
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF
>> >>> >>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D3=
>> >>D"signa=3D
>> >>> >>ture.as=3D3D
>> >>> >>> >>c"
>> >>> >>> >>> >>> >>Content-Description: OpenPGP digital signature
>> >>> >>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D3D"si=
>> >>gnature=3D
>> >>> >>=3D2Easc"
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>-----BEGIN PGP SIGNATURE-----
>> >>> >>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32)
>> >>> >>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.m=
>> >>ozdev=3D
>> >>> >>=3D2Eorg
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTE=
>> >>sWdYQ=3D
>> >>> >>CdF9O=3D3D
>> >>> >>> >>k
>> >>> >>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D3D
>> >>> >>> >>> >>> >>=3D3D3D3Do5Lq
>> >>> >>> >>> >>> >>-----END PGP SIGNATURE-----
>> >>> >>> >>> >>> >>
>> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF--
>> >>> >>> >>> >>>=3D3D20
>> >>> >>> >>> >>> cheers
>> >>> >>> >>
>> >>> >>> >>
>> >>> >>> >>--------------enig841B4237908E688C7D411F39
>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D"signature.as=
>> >>c"
>> >>> >>> >>Content-Description: OpenPGP digital signature
>> >>> >>> >>Content-Disposition: attachment; filename=3D3D"signature.asc"
>> >>> >>> >>
>> >>> >>> >>-----BEGIN PGP SIGNATURE-----
>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32)
>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> >>> >>> >>
>> >>> >>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8=
>> >>Y
>> >>> >>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D3D
>> >>> >>> >>=3D3DxV8K
>> >>> >>> >>-----END PGP SIGNATURE-----
>> >>> >>> >>
>> >>> >>> >>--------------enig841B4237908E688C7D411F39--
>> >>> >>>=3D20
>> >>> >>> cheers
>> >>> >>>=3D20
>> >>> >>> jon
>> >>> >>
>> >>> >>
>> >>> >>--------------enigD0DFC0254F721440EFF890E4
>> >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc"
>> >>> >>Content-Description: OpenPGP digital signature
>> >>> >>Content-Disposition: attachment; filename=3D"signature.asc"
>> >>> >>
>> >>> >>-----BEGIN PGP SIGNATURE-----
>> >>> >>Version: GnuPG v1.4.7 (MingW32)
>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> >>> >>
>> >>> >>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE
>> >>> >>J6vm6gE7ZeA+AeVBsDHv/t8=3D
>> >>> >>=3DSAYu
>> >>> >>-----END PGP SIGNATURE-----
>> >>> >>
>> >>> >>--------------enigD0DFC0254F721440EFF890E4--
>> >>>=20
>> >>> cheers
>> >>>=20
>> >>> jon
>> >>
>> >>
>> >>--------------enigF1C37DEE2E67C3C7E2C863DF
>> >>Content-Type: application/pgp-signature; name="signature.asc"
>> >>Content-Description: OpenPGP digital signature
>> >>Content-Disposition: attachment; filename="signature.asc"
>> >>
>> >>-----BEGIN PGP SIGNATURE-----
>> >>Version: GnuPG v1.4.7 (MingW32)
>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> >>
>> >>iD8DBQFId4AQE5f5cImnZrsRAiVYAJ9gkJxsv7y+UqJlnkhe2xEQGB06OgCeMWQ0
>> >>/q2ZOYRu0DHrMLUzzZC1Q9s=
>> >>=YQ+E
>> >>-----END PGP SIGNATURE-----
>> >>
>> >>--------------enigF1C37DEE2E67C3C7E2C863DF--
>>
>> cheers
>>
>> jon
>
>
>
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: OpenPGP digital signature
>Content-Disposition: attachment; filename="signature.asc"
>
>Attachment converted: Macintosh HD:signature 16.asc ( / ) (00396180)
More information about the end2end-interest
mailing list