Subject: [Ecrit] HELD Routing summary

From: James Winterbottom <[email-masked]>
Date: Wed, 25 Mar 2015 19:02:57 +1100

Hi All,

As I see it there is one open discussion point and three positions on this point.
The discussion point is whether or not all of the ancillary data that is returned by a LoST findService request should be included in the HELD routing response or not.

The three positions that have been stated are (in no particular order):
1) The definition for this information should be included in the base specification but is optional to send or be acted on.
2) Isn’t required at all, let the current draft stand
3) Add an extension point to the schema in the draft so that the extra can be specified in a different draft and added by something requiring it.

This email makes no claims to preference, but just presents the opinions that have been expressed.

Cheers
James

---

From: <[email-masked]>
Date: Wed, 25 Mar 2015 15:49:35 +0100

Hi James,
 thank you for the summary.
My position is reflected in point 2.

If people want to add something to a mechanism can it not be done only in writing a further draft?
This means also including in such a draft also a extension mechanism.

I think that would be a clear line to satisfy everybody.

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von James Winterbottom
Gesendet: Mittwoch, 25. März 2015 09:03
An: ecrit_ietf.org
Betreff: [Ecrit] HELD Routing summary

Hi All,

Cheers
James

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 25 Mar 2015 15:52:17 +0000

Let’s say that someone comes along and shows a decent use case for including a service boundary.

So they define an extension for it.

That extension may or may not be the same as the service boundary that LoST returns.  An implementation designed to provide world-wide service would have to change.

Returning the boundary is already optional in the LoST schema.

If we used the existing definition:
1. No new document is required
2. Compatibility between this HELD extension and LoST is maintained
3. Systems built to support both models don’t have to change

There is, as far as I can see, no downside to using the existing schema other than making the smallest possible response a bit bigger.   One can always ignore any returned items not needed/wanted, and since they are optional they can’t be assumed to be there.

Option 2 (don’t allow an extension point on the return) makes no sense to me.  I can’t imagine the IETF doing that.  Any extension would then require all existing implementations to be changed.

Brian

> On Mar 25, 2015, at 9:49 AM, [email-masked] wrote:
> 
> Hi James,

---

From: James Winterbottom <[email-masked]>
Date: Thu, 26 Mar 2015 06:17:16 +1100

I support option 3.
This allows people to add extra stuff if they want but it doesn’t require implementers of this draft to understand LoST information, which is what option 1 would do.

Cheers
James

> On 25 Mar 2015, at 7:02 pm, James Winterbottom <[email-masked]> wrote:
> 
> Hi All,
>

---

From: James Winterbottom <[email-masked]>
Date: Thu, 26 Mar 2015 06:21:04 +1100

There is downside to using the existing schema Brian, this is spelt out clearly in the draft. In order to include the fields you want a new element would need to be defined in this draft to support it. I think that that is the wrong way to do it as there has been no expression of need. If a need arrises after this draft is done, then it can be added later. Right now it isn’t needed.

As I said in my preference for option 3, I think that the extension point should be added then anything can be added later if required.

Cheers
James

> On 26 Mar 2015, at 2:52 am, Rosen, Brian <[email-masked]> wrote:
>

---

From: Laura Liess <[email-masked]>
Date: Thu, 26 Mar 2015 14:22:53 +0100

I would prefer 3) and I can live with 2).

I am oposed to 1) because it would delay the draft progress, just to add
features about we don't know if anyone will need them andif so,  what
exactly will be needed. For the work in ETSI on the EC M493 this is clearly
not needed. ETSI needs the draft finished very soon, if we want the final
ETSI specification, targeted for the end of this year, to refer an RFC and
not a draft and the implementations which will come then soon, to be based
an RFC and not on some intermediary version of the draft.

I think 3) is a good solution, flexible enough that everyone could live
with it.

Thank you
Laura

2015-03-25 20:21 GMT+01:00 James Winterbottom <
[email-masked]>:

> There is downside to using the existing schema Brian, this is spelt out
> clearly in the draft. In order to include the fields you want a new element
> would need to be defined in this draft to support it. I think that that is
> the wrong way to do it as there has been no expression of need. If a need
> arrises after this draft is done, then it can be added later. Right now it
> isn't needed.
>
> As I said in my preference for option 3, I think that the extension point
> should be added then anything can be added later if required.
>
> Cheers
> James
>
>
> > Let's say that someone comes along and shows a decent use case for
> including a service boundary.
> >
> > That extension may or may not be the same as the service boundary that
> LoST returns.  An implementation designed to provide world-wide service
> would have to change.
> >
> > 3. Systems built to support both models don't have to change
> >
> > There is, as far as I can see, no downside to using the existing schema
> other than making the smallest possible response a bit bigger.   One can
> always ignore any returned items not needed/wanted, and since they are
> optional they can't be assumed to be there.
> >
> > Option 2 (don't allow an extension point on the return) makes no sense
> to me.  I can't imagine the IETF doing that.  Any extension would then
> require all existing implementations to be changed.
> >
> > Brian
> >
> >> The discussion point is whether or not all of the ancillary data that
> is returned by a LoST findService request should be included in the HELD
> routing response or not.
> >>
> >> 1) The definition for this information should be included in the base
> specification but is optional to send or be acted on.
> >> 2) Isn't required at all, let the current draft stand
> >> 3) Add an extension point to the schema in the draft so that the extra
> can be specified in a different draft and added by something requiring it.
> >>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Mar 2015 14:31:09 +0000

I don’t understand any of this logic.

You import the definition from RFC5222 and refer to it for the meaning of the elements.  Done.  No time delay.  10 minutes of editing.

I want to be able to build systems that work world-wide.  The more commonality of data structures, the better.

You have not shown any harm to re-use of a data structure that was designed for the purpose you have, has had extensive IETF review, implementation, and consensus.  You want to invent something new.  It’s clearly a subset, but it’s not precisely a subset.  That is not a good idea in my opinion.  As the majority of elements in <mapping> are optional, an implementation can choose never to send them (server) or ignore them if received (client).  If you use the extension point (3), and we later decide that most of <mapping> is in fact useful, we would end up different data structures, because the base structure is different.

Brian

On Mar 26, 2015, at 8:22 AM, Laura Liess <[email-masked]<mailto:[email-masked]>> wrote:

I am oposed to 1) because it would delay the draft progress, just to add features about we don't know if anyone will need them andif so,  what exactly will be needed. For the work in ETSI on the EC M493 this is clearly not needed. ETSI needs the draft finished very soon, if we want the final ETSI specification, targeted for the end of this year, to refer an RFC and not a draft and the implementations which will come then soon, to be based an RFC and not on some intermediary version of the draft.

I think 3) is a good solution, flexible enough that everyone could live with it.

Thank you
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Laura

2015-03-25 20:21 GMT+01:00 James Winterbottom <[email-masked]<mailto:[email-masked]>>:
There is downside to using the existing schema Brian, this is spelt out clearly in the draft. In order to include the fields you want a new element would need to be defined in this draft to support it. I think that that is the wrong way to do it as there has been no expression of need. If a need arrises after this draft is done, then it can be added later. Right now it isn’t needed.

Cheers
James

> On 26 Mar 2015, at 2:52 am, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Mar 25, 2015, at 9:49 AM, [email-masked]<mailto:[email-masked]> wrote:
>>
>> Hi James,
>> Von: Ecrit [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von James Winterbottom
>> An: ecrit_ietf.org<http://ecrit_ietf.org/>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: James Winterbottom <[email-masked]>
Date: Fri, 27 Mar 2015 01:35:59 +1100

HUH????

As I have said before and as the draft states, at least of the mandatory mapping elements is not applicable where you don’t LoST, so simply resuming mapping doesn’t work.

If we put the extension point in, and you want to reuse mapping elements in your implementation you can simply reference them in the extension point, no specification required and things that choose not to understand the extension can ignore  them. No extra specification required, no extra work at all required in this specification, not even 10 minutes editing and 4 years of haggling.

Cheers
James

> On 27 Mar 2015, at 1:31 am, Rosen, Brian <[email-masked]> wrote:
> 
>> On Mar 26, 2015, at 8:22 AM, Laura Liess <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 2015-03-25 20:21 GMT+01:00 James Winterbottom <[email-masked] <mailto:[email-masked]>>:
>> > On 26 Mar 2015, at 2:52 am, Rosen, Brian <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> >> On Mar 25, 2015, at 9:49 AM, [email-masked] <mailto:[email-masked]> wrote:
>> >>
>> >> Hi James,
>> >> Von: Ecrit [mailto:[email-masked] <mailto:[email-masked]>] Im Auftrag von James Winterbottom
>> >> An: ecrit_ietf.org <http://ecrit_ietf.org/>
>> >> [email-masked] <mailto:[email-masked]>
>> >> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>> >> [email-masked] <mailto:[email-masked]>
>> >> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>> >
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Mar 2015 15:19:37 +0000

Come on, the mandatory elements are the source, lastUpdated and expires.  The source might be the HELD server, but it might be something else.  If it’s the HELD server, say so.
It is a trivial ask that you include source, lastUpdated and expires in the response, identical to LoST.  It provides a level of compatibility that is useful, and non-intrusive for implementations to accommodate.  It COULD be a fixed string.

You think of implementations as the server has, internally, all the routing information.  That’s one way to do it.  Another way to do it is to have the HELD server consult a LoST server.  Yes, I know you don’t think anyone will implement a LoST server.  I think you are wrong.

I understand that I can incrementally add the mapping components as extensions in a way that is transformable to a “real” <mapping> structure, but the bits on the wire are different.
If you persist, and consensus is to have an extension point and no more, I’ll submit the draft that does it right away.   Does that REALLY make any sense?

Brian

On Mar 26, 2015, at 9:35 AM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

HUH????

Cheers
James

On 27 Mar 2015, at 1:31 am, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Thank you

Cheers
James

---

From: Randall Gellens <[email-masked]>
Date: Thu, 26 Mar 2015 10:10:13 -0700

Brian,

If it's only 10 minutes of editing, then maybe 
you can revise either the XML (and update the 
TXT) or the TXT and show what it would look like 
in the document?  I think perhaps two examples 
would also help: one where the source is a local 
database and the other where the source is a LoST 
server.  We'd then have a concrete proposal in 
front of us and we could ask if we have consensus 
to adopt it and move forward.

James, if Brian does this, can you then look at 
the revisions and see if you still object or if 
you can accept them?

At 3:19 PM +0000 3/26/15, Brian Rosen wrote:

>  Come on, the mandatory elements are the source, 
> lastUpdated and expires.  The source might be 
> the HELD server, but it might be something 
> else.  If it's the HELD server, say so.
>  It is a trivial ask that you include source, 
> lastUpdated and expires in the response, 
> identical to LoST.  It provides a level of 
> compatibility that is useful, and non-intrusive 
> for implementations to accommodate.  It COULD 
> be a fixed string.
>
>  You think of implementations as the server has, 
> internally, all the routing information. 
>  That's one way to do it.  Another way to do it 
> is to have the HELD server consult a LoST 
> server.  Yes, I know you don't think anyone 
> will implement a LoST server.  I think you are 
> wrong.
>
>  I understand that I can incrementally add the 
> mapping components as extensions in a way that 
> is transformable to a "real" <mapping> 
> structure, but the bits on the wire are 
> different.
>  If you persist, and consensus is to have an 
> extension point and no more, I'll submit the 
> draft that does it right away.   Does that 
> REALLY make any sense?
>
>  Brian
>
>>  On Mar 26, 2015, at 9:35 AM, James 
>> Winterbottom 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  HUH????
>>
>>  As I have said before and as the draft states, 
>> at least of the mandatory mapping elements is 
>> not applicable where you don't LoST, so simply 
>> resuming mapping doesn't work.
>>
>>  If we put the extension point in, and you want 
>> to reuse mapping elements in your 
>> implementation you can simply reference them 
>> in the extension point, no specification 
>> required and things that choose not to 
>> understand the extension can ignore  them. No 
>> extra specification required, no extra work at 
>> all required in this specification, not even 
>> 10 minutes editing and 4 years of haggling.
>>
>>  Cheers
>>  James
>>
>>
>>>  On 27 Mar 2015, at 1:31 am, Rosen, Brian 
>>> <<mailto:[email-masked]>[email-masked]> 
>>> wrote:
>>>
>>>  I don't understand any of this logic.
>>>
>>>  You import the definition from RFC5222 and 
>>> refer to it for the meaning of the elements. 
>>>  Done.  No time delay.  10 minutes of editing.
>>>
>>>  I want to be able to build systems that work 
>>> world-wide.  The more commonality of data 
>>> structures, the better.
>>>
>>>  You have not shown any harm to re-use of a 
>>> data structure that was designed for the 
>>> purpose you have, has had extensive IETF 
>>> review, implementation, and consensus.  You 
>>> want to invent something new.  It's clearly a 
>>> subset, but it's not precisely a subset. 
>>>  That is not a good idea in my opinion.  As 
>>> the majority of elements in <mapping> are 
>>> optional, an implementation can choose never 
>>> to send them (server) or ignore them if 
>>> received (client).  If you use the extension 
>>> point (3), and we later decide that most of 
>>> <mapping> is in fact useful, we would end up 
>>> different data structures, because the base 
>>> structure is different.
>>>
>>>  Brian
>>>
>>>>  On Mar 26, 2015, at 8:22 AM, Laura Liess 
>>>> <<mailto:[email-masked]>[email-masked]> 
>>>> wrote:
>>>>
>>>>  I am oposed to 1) because it would delay the 
>>>> draft progress, just to add features about 
>>>> we don't know if anyone will need them andif 
>>>> so,  what exactly will be needed. For the 
>>>> work in ETSI on the EC M493 this is clearly 
>>>> not needed. ETSI needs the draft finished 
>>>> very soon, if we want the final ETSI 
>>>> specification, targeted for the end of this 
>>>> year, to refer an RFC and not a draft and 
>>>> the implementations which will come then 
>>>> soon, to be based an RFC and not on some 
>>>> intermediary version of the draft. 
>>>>
>>>>  2015-03-25 20:21 GMT+01:00 James 
>>>> Winterbottom 
>>>> <<mailto:[email-masked]>[email-masked]>:
>>>>
>>>>  There is downside to using the existing 
>>>> schema Brian, this is spelt out clearly in 
>>>> the draft. In order to include the fields 
>>>> you want a new element would need to be 
>>>> defined in this draft to support it. I think 
>>>> that that is the wrong way to do it as there 
>>>> has been no expression of need. If a need 
>>>> arrises after this draft is done, then it 
>>>> can be added later. Right now it isn't 
>>>> needed.
>>>>
>>>>  As I said in my preference for option 3, I 
>>>> think that the extension point should be 
>>>> added then anything can be added later if 
>>>> required.
>>>>
>>>>  Cheers
>>>>  James
>>>>
>>>>
>>>>
>>>>>  On 26 Mar 2015, at 2:52 am, Rosen, Brian 
>>>>> <<mailto:[email-masked]>[email-masked]> 
>>>>> wrote:
>>>>>
>>>>>  Let's say that someone comes along and 
>>>>> shows a decent use case for including a 
>>>>> service boundary.
>>>>>
>>>>>  That extension may or may not be the same 
>>>>> as the service boundary that LoST returns. 
>>>>> An implementation designed to provide 
>>>>> world-wide service would have to change.
>>>>>
>>>>>  There is, as far as I can see, no downside 
>>>>> to using the existing schema other than 
>>>>> making the smallest possible response a bit 
>>>>> bigger.   One can always ignore any 
>>>>> returned items not needed/wanted, and since 
>>>>> they are optional they can't be assumed to 
>>>>> be there.
>>>>>
>>>>>  Option 2 (don't allow an extension point on 
>>>>> the return) makes no sense to me.  I can't 
>>>>> imagine the IETF doing that.  Any extension 
>>>>> would then require all existing 
>>>>> implementations to be changed.
>>>>>
>>>>>  Brian
>>>>>
>>>>>>  On Mar 25, 2015, at 9:49 AM, 
>>>>>> <mailto:[email-masked]>[email-masked] 
>>>>>> wrote:
>>>>>>
>>>>>>  Hi James,
>>>>>>  If people want to add something to a 
>>>>>> mechanism can it not be done only in 
>>>>>> writing a further draft?
>>>>>>  Von: Ecrit 
>>>>>> [mailto:<mailto:[email-masked]>[email-masked]] 
>>>>>> Im Auftrag von James Winterbottom
>>>>>>  An: <http://ecrit_ietf.org/>ecrit_ietf.org
>>>>>>  The discussion point is whether or not all 
>>>>>> of the ancillary data that is returned by 
>>>>>> a LoST findService request should be 
>>>>>> included in the HELD routing response or 
>>>>>> not.
>>>>>>
>>>>>>  3) Add an extension point to the schema in 
>>>>>> the draft so that the extra can be 
>>>>>> specified in a different draft and added 
>>>>>> by something requiring it.
>>>>>>
>>>>>>  This email makes no claims to preference, 
>>>>>> but just presents the opinions that have 
>>>>>> been expressed.
>>>>>>
>>>>>>  Cheers
>>>>>>  James
>>>>>>
>>>>>>  <mailto:[email-masked]>[email-masked]
>>>>>> 
>>>>>> <https://www.ietf.org/mailman/listinfo/ecrit> 
>>>>>>  <mailto:[email-masked]>[email-masked]
>>>>>> 
>>>>>> <https://www.ietf.org/mailman/listinfo/ecrit> 
>>>>  <mailto:[email-masked]>[email-masked]
>>>> 
>>>> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>
>>>
>>
>>  <mailto:[email-masked]>[email-masked]

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
"If you see me running, try to keep up."

---

From: James Winterbottom <[email-masked]>
Date: Fri, 27 Mar 2015 06:07:17 +1100

Randall,

I don’t agree with Brian’s position on the Source, my reading of LoST is that this can’t be the HELD server because it doesn’t satisfy the description and requirements for the use of that field.

But further to that, the three people in this group that requested this functionality don’t see a need for this stuff. Indeed the only person arguing for it is Brian and he hasn’t provided or demonstrated any need for it. Option 3 on that table allows it be added when needed which is the fastest and easiest approach.

Cheers
James

> On 27 Mar 2015, at 4:10 am, Randall Gellens <[email-masked]> wrote:
> 
> Brian,
> 
> If it's only 10 minutes of editing, then maybe you can revise either the XML (and update the TXT) or the TXT and show what it would look like in the document?  I think perhaps two examples would also help: one where the source is a local database and the other where the source is a LoST server.  We'd then have a concrete proposal in front of us and we could ask if we have consensus to adopt it and move forward.
> 
> James, if Brian does this, can you then look at the revisions and see if you still object or if you can accept them?
> 
>> Come on, the mandatory elements are the source, lastUpdated and expires.  The source might be the HELD server, but it might be something else.  If it's the HELD server, say so.
>> You think of implementations as the server has, internally, all the routing information.  That's one way to do it.  Another way to do it is to have the HELD server consult a LoST server.  Yes, I know you don't think anyone will implement a LoST server.  I think you are wrong.
>> 
>> I understand that I can incrementally add the mapping components as extensions in a way that is transformable to a "real" <mapping> structure, but the bits on the wire are different.
>> If you persist, and consensus is to have an extension point and no more, I'll submit the draft that does it right away.   Does that REALLY make any sense?
>> 
>> Brian
>> 
>>> On Mar 26, 2015, at 9:35 AM, James Winterbottom <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> HUH????
>>> 
>>> As I have said before and as the draft states, at least of the mandatory mapping elements is not applicable where you don't LoST, so simply resuming mapping doesn't work.
>>> 
>>>> On 27 Mar 2015, at 1:31 am, Rosen, Brian <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> You have not shown any harm to re-use of a data structure that was designed for the purpose you have, has had extensive IETF review, implementation, and consensus.  You want to invent something new.  It's clearly a subset, but it's not precisely a subset.  That is not a good idea in my opinion.  As the majority of elements in <mapping> are optional, an implementation can choose never to send them (server) or ignore them if received (client).  If you use the extension point (3), and we later decide that most of <mapping> is in fact useful, we would end up different data structures, because the base structure is different.
>>>> 
>>>> Brian
>>>> 
>>>>> On Mar 26, 2015, at 8:22 AM, Laura Liess <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> 2015-03-25 20:21 GMT+01:00 James Winterbottom <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>>:
>>>>> 
>>>>> There is downside to using the existing schema Brian, this is spelt out clearly in the draft. In order to include the fields you want a new element would need to be defined in this draft to support it. I think that that is the wrong way to do it as there has been no expression of need. If a need arrises after this draft is done, then it can be added later. Right now it isn't needed.
>>>>> 
>>>>>> On 26 Mar 2015, at 2:52 am, Rosen, Brian <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> Let's say that someone comes along and shows a decent use case for including a service boundary.
>>>>>> 
>>>>>> There is, as far as I can see, no downside to using the existing schema other than making the smallest possible response a bit bigger.   One can always ignore any returned items not needed/wanted, and since they are optional they can't be assumed to be there.
>>>>>> 
>>>>>> Option 2 (don't allow an extension point on the return) makes no sense to me.  I can't imagine the IETF doing that. Any extension would then require all existing implementations to be changed.
>>>>>> 
>>>>>> Brian
>>>>>> 
>>>>>>> On Mar 25, 2015, at 9:49 AM, <mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]> wrote:
>>>>>>> 
>>>>>>> Hi James,
>>>>>>> Von: Ecrit [mailto:<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>] Im Auftrag von James Winterbottom
>>>>>>> An: <http://ecrit_ietf.org/ <http://ecrit_ietf.org/>>ecrit_ietf.org
>>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>>>>>>> <https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>>>>>>> <https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>>>>> 
>>>>> 
>>>>> <mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>>>>> <https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>>https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>>>> 
>>>>> 
>>>> 
>>> 
>>> <mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>

---

From: James Winterbottom <[email-masked]>
Date: Fri, 27 Mar 2015 06:17:24 +1100

Brian,

Please read the draft, look at RFC5222 and tell me source can ever be the HELD server with putting  LoST interface on to the HELD server?

I don’t see a need for the information you are requesting.
If you were to provide a draft to add the extension you request then I think you would have to demonstrate a very strong use case for it.  Further, I don’t think it would be unreasonable to request a liaison statement from an SDO indicating that they required it to progress their work.

Cheers
James

> On 27 Mar 2015, at 2:19 am, Rosen, Brian <[email-masked]> wrote:
> 
>> On Mar 26, 2015, at 9:35 AM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> HUH????
>> 
>>> On 27 Mar 2015, at 1:31 am, Rosen, Brian <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 26 Mar 2015 12:26:17 -0700

My impression is that people are talking past 
each other, which is why I thought seeing the 
proposal in the document would help clarify it.

At 6:07 AM +1100 3/27/15, James Winterbottom wrote:

>  Randall,
>
>  I don't agree with Brian's position on the 
> Source, my reading of LoST is that this can't 
> be the HELD server because it doesn't satisfy 
> the description and requirements for the use of 
> that field.
>
>  But further to that, the three people in this 
> group that requested this functionality don't 
> see a need for this stuff. Indeed the only 
> person arguing for it is Brian and he hasn't 
> provided or demonstrated any need for it. 
> Option 3 on that table allows it be added when 
> needed which is the fastest and easiest 
> approach.
>
>
>  Cheers
>  James
>
>>  On 27 Mar 2015, at 4:10 am, Randall Gellens 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  Brian,
>>
>> TXT) or the TXT and show what it would look 
>> like in the document?  I think perhaps two 
>> examples would also help: one where the source 
>> is a local database and the other where the 
>> source is a LoST server.  We'd then have a 
>> concrete proposal in front of us and we could 
>> ask if we have consensus to adopt it and move 
>> forward.
>>
>>  James, if Brian does this, can you then look 
>> at the revisions and see if you still object 
>> or if you can accept them?
>>
>>>  Come on, the mandatory elements are the 
>>> source, lastUpdated and expires.  The source 
>>> might be the HELD server, but it might be 
>>> something else.  If it's the HELD server, say 
>>> so.
>>> compatibility that is useful, and 
>>> non-intrusive for implementations to 
>>> accommodate.  It COULD be a fixed string.
>>>
>>>  You think of implementations as the server 
>>> has, internally, all the routing information. 
>>>  That's one way to do it.  Another way to do 
>>> it is to have the HELD server consult a LoST 
>>> will implement a LoST server.  I think you 
>>> are wrong.
>>>
>>> mapping components as extensions in a way 
>>> that is transformable to a "real" <mapping> 
>>>> <<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]> 
>>>> wrote:
>>>>
>>>>  HUH????
>>>>
>>>>  As I have said before and as the draft 
>>>> states, at least of the mandatory mapping 
>>>> elements is not applicable where you don't 
>>>> LoST, so simply resuming mapping doesn't 
>>>> work.
>>>>
>>>>  If we put the extension point in, and you 
>>>> want to reuse mapping elements in your 
>>>> understand the extension can ignore  them. 
>>>> No extra specification required, no extra 
>>>> work at all required in this specification, 
>>>> not even 10 minutes editing and 4 years of 
>>>> haggling.
>>>>
>>>>  Cheers
>>>>  James
>>>>
>>>>> <<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]> 
>>>>> wrote:
>>>>>
>>>>> refer to it for the meaning of the 
>>>>> elements.  Done.  No time delay.  10 
>>>>> minutes of editing.
>>>>>
>>>>>  I want to be able to build systems that 
>>>>> work world-wide.  The more commonality of 
>>>>> data structures, the better.
>>>>>
>>>>> want to invent something new.  It's clearly 
>>>>> a subset, but it's not precisely a subset. 
>>>>> optional, an implementation can choose 
>>>>> never to send them (server) or ignore them 
>>>>> if received (client).  If you use the 
>>>>> extension point (3), and we later decide 
>>>>> that most of <mapping> is in fact useful, 
>>>>> we would end up different data structures, 
>>>>> because the base structure is different.
>>>>>
>>>>>  Brian
>>>>>
>>>>>> <<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]> 
>>>>>> wrote:
>>>>>>
>>>>>>  I am oposed to 1) because it would delay 
>>>>>> the draft progress, just to add features 
>>>>>> about we don't know if anyone will need 
>>>>>> them andif so,  what exactly will be 
>>>>>> needed. For the work in ETSI on the EC 
>>>>>> M493 this is clearly not needed. ETSI 
>>>>>> needs the draft finished very soon, if we 
>>>>>> want the final ETSI specification, 
>>>>>> targeted for the end of this year, to 
>>>>>> refer an RFC and not a draft and the 
>>>>>> implementations which will come then soon, 
>>>>>> to be based an RFC and not on some 
>>>>>> <<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]>:
>>>>>>
>>>>>> defined in this draft to support it. I 
>>>>>> think that that is the wrong way to do it 
>>>>>> as there has been no expression of need. 
>>>>>> If a need arrises after this draft is 
>>>>>> done, then it can be added later. Right 
>>>>>> now it isn't needed.
>>>>>>
>>>>>>> <<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> as the service boundary that LoST 
>>>>>>> returns. An implementation designed to 
>>>>>>> provide world-wide service would have to 
>>>>>>> change.
>>>>>>>
>>>>>>> other than making the smallest possible 
>>>>>>> response a bit bigger.   One can always 
>>>>>>> ignore any returned items not 
>>>>>>> needed/wanted, and since they are 
>>>>>>>  Option 2 (don't allow an extension point 
>>>>>>> on the return) makes no sense to me.  I 
>>>>>>> can't imagine the IETF doing that. Any 
>>>>>>> extension would then require all existing 
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked] wrote:
>>>>>>>>
>>>>>>>>  Hi James,
>>>>>>>> [mailto:<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]] 
>>>>>>>>  An: <<http://ecrit_ietf.org/>http://ecrit_ietf.org/>ecrit_ietf.org
>>>>>>>>  The discussion point is whether or not 
>>>>>>>> all of the ancillary data that is 
>>>>>>>> returned by a LoST findService request 
>>>>>>>> should be included in the HELD routing 
>>>>>>>> response or not.
>>>>>>>>
>>>>>>>>  3) Add an extension point to the schema 
>>>>>>>> in the draft so that the extra can be 
>>>>>>>>  This email makes no claims to 
>>>>>>>> preference, but just presents the 
>>>>>>>> opinions that have been expressed.
>>>>>>>>
>>>>>>>>  Cheers
>>>>>>>>  James
>>>>>>>>
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>>> 
>>>>>>>> <<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>>> 
>>>>>>>> <<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>> 
>>>>>> <<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit><https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>
>>>>
>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>> 

-------------- Randomly selected tag: ---------------
Skipper:   Mr. Howell, You don't know what it's like out there in
           the ocean, you may be bitten by a shark!
Thurston:  A shark bite a Howell, ha ha he wouldn't dare.
Skipper:   Besides we don't have room enough for your luggage.
Thurston:  Well that's different. If I can't go first class I won't
           go at all.

---

From: James Winterbottom <[email-masked]>
Date: Fri, 27 Mar 2015 06:27:43 +1100

Thanks for talking the position as conciliator Randall.

> On 27 Mar 2015, at 6:26 am, Randall Gellens <[email-masked]> wrote:
> 
>>> <<mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> 
>>> wrote:
>>> 
>>> Brian,
>>> 
>>>>> <<<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> 
>>>>> wrote:
>>>>> 
>>>>> HUH????
>>>>> 
>>>>>> <<<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> <<<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> <<<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>>:
>>>>>>> 
>>>>>>>> <<<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> <<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]> wrote:
>>>>>>>>> 
>>>>>>>>> Hi James,
>>>>>>>>> [mailto:<<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>] 
>>>>>>>>> An: <<http://ecrit_ietf.org/ <http://ecrit_ietf.org/>>http://ecrit_ietf.org/ <http://ecrit_ietf.org/>>ecrit_ietf.org
>>>>>>>>> <<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>>>>>>>>> 
>>>>>>>>> <<https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>>https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>> <https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>>https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>>>>>>>> <<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>>>>>>>>> 
>>>>>>>>> <<https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>>https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>> <https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>>https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> <<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>>>>>>> 
>>>>>>> <<https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>>https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>><https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>>https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> <<mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>>>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Mar 2015 19:44:34 +0000

Replace the last two paragraphs of Section 4 with:

The location response when the HELD sever supports this specification and routing is requested consists of the <mapping> element from RFC5222.  The “source” element shall be the URI of the authoritative generator of the mapping data, which may be the HELD server’s URI.   All other elements of the <mapping> element are as they are described in RFC5222.

If this language is acceptable, I’ll fix the schema in Section 5 and the examples.

Brian

From: James Winterbottom <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 2:27 PM
To: Randall Gellens <[email-masked]<mailto:[email-masked]>>
Cc: Brian Rosen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] HELD Routing summary

On 27 Mar 2015, at 6:26 am, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

Randall,

Cheers
James

On 27 Mar 2015, at 4:10 am, Randall Gellens
<<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
wrote:

Brian,

Brian

On Mar 26, 2015, at 9:35 AM, James
Winterbottom
<<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
wrote:

HUH????

Cheers
James

On 27 Mar 2015, at 1:31 am, Rosen, Brian
<<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
wrote:

Brian

On Mar 26, 2015, at 8:22 AM, Laura Liess
<<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
wrote:

I think 3) is a good solution, flexible
enough that everyone could live with it.

Thank you
 Laura

2015-03-25 20:21 GMT+01:00 James
Winterbottom
<<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>:

Cheers
James

On 26 Mar 2015, at 2:52 am, Rosen, Brian
<<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
wrote:

There is, as far as I can see, no
downside to using the existing schema
other than making the smallest possible
response a bit bigger.   One can always
ignore any returned items not
needed/wanted, and since they are
optional they can't be assumed to be
there.

Brian

On Mar 25, 2015, at 9:49 AM,
<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]> wrote:

Hi James,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit
[mailto:<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]

Hi All,

As I see it there is one open discussion
point and three positions on this point.
The discussion point is whether or not
all of the ancillary data that is
returned by a LoST findService request
should be included in the HELD routing
response or not.

The three positions that have been
stated are (in no particular order):
1) The definition for this information
should be included in the base
specification but is optional to send or
be acted on.
2) Isn't required at all, let the current draft stand
3) Add an extension point to the schema
in the draft so that the extra can be
specified in a different draft and added
by something requiring it.

Cheers
James

<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

_______________________________________________
Ecrit mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

---

From: James Winterbottom <[email-masked]>
Date: Fri, 27 Mar 2015 07:02:00 +1100

I still don’t want the extra stuff as I don’t see a need for it.

However, if we were to proceed down this path then:
This document now normatively updates RFC5222 so I don’t think that the language below is strong enough or clear enough that we are changing the meaning of source from RFC5222. This is because the HELD server may not generate the mapping data, it may simply supply it and a URI for how it obtained it may not exist.
The source in RFC5222 is not a URI, it is a LoST application unique string, I am not sure that making this a HELD application unique string makes sense, so this would require more thought, unless this is also part of the updating to RFC5222 which would also require schema change to support.

These were the problems I look at when I created the specification the way it is, which is why I didn’t use the mapping element. I just don’t think you can use words to explain away the issues and cram the mapping element in, you would need to redefine the mapping element and I see no value in that.

Cheers
James

> On 27 Mar 2015, at 6:44 am, Rosen, Brian <[email-masked]> wrote:
> 
> From: James Winterbottom <[email-masked] <mailto:[email-masked]>>
> To: Randall Gellens <[email-masked] <mailto:[email-masked]>>
> Cc: Brian Rosen <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On 27 Mar 2015, at 6:26 am, Randall Gellens <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>>>>>>> [mailto:< <mailto:<><mailto:[email-masked] <mailto:[email-masked]>>mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>]

---

From: <[email-masked]>
Date: Thu, 26 Mar 2015 22:44:29 +0100

For me it looks like more confusing than only to apply to OPTION 3.
Thus I’m still in favor for Option 3 which need only a small change.
And I think the requirement for extensibility as discussed in the meeting is fulfilled.

In short I support now OPTION 3 as James proposed.

Thank you and Best Regards

Roland

Von: Ecrit [mailto:[email-masked]] Im Auftrag von James Winterbottom
Gesendet: Donnerstag, 26. März 2015 21:02
An: Rosen, Brian
Cc: [email-masked]; Randall Gellens
Betreff: Re: [Ecrit] HELD Routing summary

Cheers
James

On 27 Mar 2015, at 6:44 am, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Randall,

Cheers
James

Brian,

Brian

HUH????

Cheers
James

Brian

Thank you
 Laura

Cheers
James

Brian

Hi James,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit
[mailto:<<mailto:%3c><mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]

Hi All,

Cheers
James

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 26 Mar 2015 21:52:09 +0000

I support option 3 as well

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory Standards
AT&T Standards and
Industry Alliances
+1-609-903-3360
Sent from my iPhone

On Mar 26, 2015, at 5:44 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Roland

Von: Ecrit [mailto:[email-masked]] Im Auftrag von James Winterbottom
Gesendet: Donnerstag, 26. März 2015 21:02
An: Rosen, Brian
Cc: [email-masked]<mailto:[email-masked]>; Randall Gellens
Betreff: Re: [Ecrit] HELD Routing summary

Cheers
James

Brian

Randall,

Cheers
James

Brian,

Brian

HUH????

Cheers
James

Brian

Thank you
 Laura

Cheers
James

Brian

Hi James,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit

Hi All,

Cheers
James