Subject: Re: [Insipid] publishing draft-kaplan session-id as historic

From: James Polk <[email-masked]>
Date: Tue, 06 Aug 2013 14:13:48 -0500

Hadriel

https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/ 
shows an intended status of "informational", not "historic" as you 
agreed. I believe that needs to be corrected.

James

At 03:36 PM 3/13/2013, Hadriel Kaplan wrote:
> From today's meeting action I took... below was the email.
>The difference between draft-kaplan-dispatch-session-id-03 and 02 
>can be seen here:
>
>http://tools.ietf.org/rfcdiff?url2=draft-kaplan-dispatch-session-id-03.txt
>
>It did not change the ABNF nor protocol rules.  Therefore I propose 
>to submit 03 as independent submission to the RFC Editor, for 
>'Historic' status.  Or 'Epic' status if they have that. :)
>
>-hadriel
>
>
>On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan <[email-masked]> wrote:
>
> >
> > When we talked about this in Vancouver I was thinking there 
> wouldn't be any problem going to/from UUID syntax, because going 
> to/from UUIDs in H.323 was talked about a long, long time ago for 
> session-id.  But I forgot about the bug in the draft-kaplan ABNF...
> >
> > Since version 01 of draft-kaplan-sip-session-id in 2008, which 
> later became draft-kaplan-dispatch-session-id, the rules for 
> generating the session-id always made it lower-case *hex* 
> characters.  I.e., the g-z range wasn't actually possible.  The 
> ABNF for it didn't get fixed until 
> draft-kaplan-dispatch-session-id-01 in April 2010, but that also 
> dropped it to 16 characters of hex because the algorithm changed, 
> and then 3 months later reverted back to 32 characters and the correct ABNF.
> >
> > So that begs the question of *which* version of draft-kaplan we 
> want to be backwards compatible with.  Since 
> draft-kaplan-dispatch-session-id-01 only existed for 3 months, I 
> think we can ignore that one.  And since everything else only used 
> hex characters, except the initial 00-draft which itself only 
> existed for 4 months, I think we can ignore that one too.
> >
> > Therefore, as far as I can tell we shouldn't have a problem 
> converting draft-kaplan session-ids to/from UUIDs for H.323/whatever.
> >
> > -hadriel
> >
> >
> > On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote:
> >
> >> Hi,
> >>
> >> In Vancouver, I expressed a wish to make the INSIPID mechanism 
> backward compatible with the draft-kaplan-session-id one, the 
> reason being that it has been around for a relatively long time, 
> and has been implemented and deployed.
> >>
> >> I compared the suggested draft-jones solution with the 
> draft-kaplan solution, and I think there are ways to achieve 
> backward compability.
> >>
> >>
> >> --------------
> >>
> >>
> >> FIRST, looking purely at the ABNF syntax:
> >>
> >> The jones ABNF is:
> >>
> >>
> >> Session-ID-UUID = "Session-ID-UUID" HCOLON UUID
> >>
> >>
> >>
> >> The kaplan ABNF is:
> >>
> >>
> >>
> >> Session-ID           =  "Session-ID" HCOLON sess-id
> >>
> >>                          *( SEMI generic-param )
> >>
> >> sess-id              =  32(DIGIT / %x61-7A)  ; 32 chars of [0-9a-z]
> >>
> >>
> >>
> >>
> >>
> >> Now, assuming 32 chars is enough to carry ONE UUID, jones 
> applications could put the SECOND UUID in a header field parameter 
> (generic-param), rather than combining it with the received UUID.
> >>
> >>
> >>
> >> Of course, the first UUDI (carried in sess-id) can only contains 
> characters 0-9 and a-z.
> >>
> >>
> >>
> >> A UUID can contain characters 0-9 and a-f and A-F.
> >>
> >>
> >>
> >> So, a jones entity would have to be prepared to receive g-z.
> >>
> >>
> >>
> >> And, as kaplan entity is not prepared to receive capital A-F, a 
> jones entity would have to only use small letters. But, that should 
> not be a problem, afaik, as they have the same meaning as far as 
> UUID is concerned.
> >>
> >>
> >>
> >> --------------
> >>
> >>
> >>
> >> SECOND, looking at it would work functionwise:
> >>
> >>
> >>
> >> There are two main alternatives:
> >>
> >>
> >>
> >>
> >>
> >> 1. Second UUID is added even when one entity is kaplan compliant
> >>
> >> 2. Second UUID is not added when one entity is kaplan compliant
> >>
> >>
> >>
> >>
> >>
> >> Alternative 1:
> >>
> >>
> >>
> >> When a kaplan entity inserts the first UUID (I use that as a 
> general term, eventhough a kaplan entity does not use UUIDs), one 
> must assume that it is prepared to receive a response from a jones 
> entity which has added the second UUID into the header field parameter.
> >>
> >>
> >>
> >> When a jones entity inserts the first UUID, one must assume that 
> it is prepared to receive a response from a kaplan entity where the 
> second UUID has *not* been added.
> >>
> >>
> >>
> >>
> >>
> >> Alternative 2:
> >>
> >>
> >>
> >> When a kaplan entity inserts the first UUID, the jones entity 
> detects (using some identify-a-kaplan-entity mechanism) that it 
> comes from a kaplan entity, so it does not insert a seoncd UUID in 
> the first place.
> >>
> >>
> >>
> >> As in alternative 1, when a jones entity inserts the first UUID, 
> it has to be prepared to receive a response where the second UUID 
> has not been added (the identify-a-kaplan-entity mechanism might 
> also inform the jones entity that the response comes from a kaplan entity.
> >>
> >>
> >>
> >>
> >>
> >> --------------
> >>
> >>
> >>
> >> Now, there will of course be cases, where two UUIDs are 
> required, that won't work. But, kaplan entities would be able to 
> use the session-id for whatever they've used it so far.
> >>
> >>
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> insipid mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/insipid
> >
> > _______________________________________________
> > insipid mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/insipid
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Aug 2013 21:55:13 +0000

I understand this is intentional.

It apparently represents a change of philiosphy on the part of IESG, as relayed to us by Gonzalo, on how to represent this type of document.

Essentially it appears that they would rather use informational with the historical like status represented in the abstract or introduction, rather than use historical.

So Hadriel has merely been following instructions.

If you go listen to the INSIPID audio recording, you'll find we asked Gonzalo to explain this during the agenda bash and status discussion.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James Polk
> Sent: 06 August 2013 20:14
> To: Hadriel Kaplan; [email-masked]
> Subject: Re: [Insipid] publishing draft-kaplan session-id as historic
> 
> Hadriel
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 7 Aug 2013 10:05:30 -0500

On Tue, Aug 6, 2013 at 4:55 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> It apparently represents a change of philiosphy on the part of IESG, as
> relayed to us by Gonzalo, on how to represent this type of document.
>
> Essentially it appears that they would rather use informational with the
> historical like status represented in the abstract or introduction, rather
> than use historical.
>
> If you go listen to the INSIPID audio recording, you'll find we asked
> Gonzalo to explain this during the agenda bash and status discussion.
>
[MB] Probably it would be very helpful to ensure that point is captured in
the official minutes as well. [/MB]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Aug 2013 14:06:15 -0400

The email you cited from me below was when I announced the intention to submit.  I did actually submit it as 'Historic' in that 00 version - see here:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-00

I was then told to change it to Informational, which triggered this:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-01

I was told to put in context for why it's being published, which triggered this:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-02

I was told to fix some I-D nits, which triggered this:
http://tools.ietf.org/html/draft-kaplan-insipid-session-id-03

[I don't mean to imply I was told those separate things at separate times - it just took me several times to grok what I was being told :) ]

As you probably know, but others might not so I'm saying it here, you can view the diff changes between draft versions by clicking on the "diff1" or "diff2" links at the top of the HTML-based draft pages.

-hadriel

On Aug 6, 2013, at 3:13 PM, James Polk <[email-masked]> wrote:

> Hadriel
> 
> https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/ shows an intended status of "informational", not "historic" as you agreed. I believe that needs to be corrected.
> 
> James
> 
>> The difference between draft-kaplan-dispatch-session-id-03 and 02 can be seen here:
>> 
>> It did not change the ABNF nor protocol rules.  Therefore I propose to submit 03 as independent submission to the RFC Editor, for 'Historic' status.  Or 'Epic' status if they have that. :)
>> 
>> -hadriel
>> 
>> 
>>> When we talked about this in Vancouver I was thinking there wouldn't be any problem going to/from UUID syntax, because going to/from UUIDs in H.323 was talked about a long, long time ago for session-id.  But I forgot about the bug in the draft-kaplan ABNF...
>>> 
>>> Since version 01 of draft-kaplan-sip-session-id in 2008, which later became draft-kaplan-dispatch-session-id, the rules for generating the session-id always made it lower-case *hex* characters.  I.e., the g-z range wasn't actually possible.  The ABNF for it didn't get fixed until draft-kaplan-dispatch-session-id-01 in April 2010, but that also dropped it to 16 characters of hex because the algorithm changed, and then 3 months later reverted back to 32 characters and the correct ABNF.
>>> 
>>> So that begs the question of *which* version of draft-kaplan we want to be backwards compatible with.  Since draft-kaplan-dispatch-session-id-01 only existed for 3 months, I think we can ignore that one.  And since everything else only used hex characters, except the initial 00-draft which itself only existed for 4 months, I think we can ignore that one too.
>>> 
>>> Therefore, as far as I can tell we shouldn't have a problem converting draft-kaplan session-ids to/from UUIDs for H.323/whatever.
>>> 
>>> -hadriel
>>> 
>>> 
>>>> In Vancouver, I expressed a wish to make the INSIPID mechanism backward compatible with the draft-kaplan-session-id one, the reason being that it has been around for a relatively long time, and has been implemented and deployed.
>>>> 
>>>> I compared the suggested draft-jones solution with the draft-kaplan solution, and I think there are ways to achieve backward compability.
>>>> 
>>>> 
>>>> --------------
>>>> 
>>>> 
>>>> Now, assuming 32 chars is enough to carry ONE UUID, jones applications could put the SECOND UUID in a header field parameter (generic-param), rather than combining it with the received UUID.
>>>> 
>>>> 
>>>> 
>>>> Of course, the first UUDI (carried in sess-id) can only contains characters 0-9 and a-z.
>>>> 
>>>> 
>>>> 
>>>> And, as kaplan entity is not prepared to receive capital A-F, a jones entity would have to only use small letters. But, that should not be a problem, afaik, as they have the same meaning as far as UUID is concerned.
>>>> 
>>>> 
>>>> 
>>>> --------------
>>>> 
>>>> 
>>>> 
>>>> When a kaplan entity inserts the first UUID (I use that as a general term, eventhough a kaplan entity does not use UUIDs), one must assume that it is prepared to receive a response from a jones entity which has added the second UUID into the header field parameter.
>>>> 
>>>> 
>>>> 
>>>> When a jones entity inserts the first UUID, one must assume that it is prepared to receive a response from a kaplan entity where the second UUID has *not* been added.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Alternative 2:
>>>> 
>>>> 
>>>> 
>>>> When a kaplan entity inserts the first UUID, the jones entity detects (using some identify-a-kaplan-entity mechanism) that it comes from a kaplan entity, so it does not insert a seoncd UUID in the first place.
>>>> 
>>>> 
>>>> 
>>>> As in alternative 1, when a jones entity inserts the first UUID, it has to be prepared to receive a response where the second UUID has not been added (the identify-a-kaplan-entity mechanism might also inform the jones entity that the response comes from a kaplan entity.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --------------
>>>> 
>>>> 
>>>> 
>>>> Now, there will of course be cases, where two UUIDs are required, that won't work. But, kaplan entities would be able to use the session-id for whatever they've used it so far.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> 
>>>> 
>>>> Christer
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>