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

["DRAGE, Keith (Keith)" <[e-mail]>]

The following document has been around since 14th July

https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/ 

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Atle Monrad
> Sent: 30 July 2013 10:22
> To: Hadriel Kaplan; Robert Sparks
> Cc: <[e-mail]>
> Subject: Re: [Insipid] publishing draft-kaplan session-id as historic
> 
> Hadriel
> 
> Will you at some point in the not too far future kindly do the necessary
> edits to gracefully park this draft in the archives as an RFC ??
> 
> Cheers
> 
> /atle
> 
> ________________________________
> 
> 
> Atle Monrad
> 3GPP CT Chairman
> 
> Group Function Technology - Standardization and Technical Regulation
> Ericsson
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Hadriel Kaplan
> Sent: 13. mars 2013 23:44
> To: Robert Sparks
> Cc: <[e-mail]>
> Subject: Re: [Insipid] publishing draft-kaplan session-id as historic
> 
> 
> Yes sorry I should have been clearer - I realize I'll have to edit the doc
> to actually submit, I just meant using 03 as the version vs. 02 or 01 or
> whatever.
> 
> -hadriel
> 
> 
> On Mar 13, 2013, at 5:04 PM, Robert Sparks <[e-mail]> wrote:
> 
> > On 3/13/13 4:36 PM, 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. :)
> > It wouldn't be -03 as is - there needs to be an editing pass explaining
> this document's this is a proprietary something that may be in the wild.
> The text should be touched to make it an exposition (This is what you
> would have seen) vs a specification (this is what you should do).
> >
> > RjS
> >
> >>
> >> -hadriel
> >>
> >>
> >> On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan <[e-mail]>
> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/insipid
> >>> _______________________________________________
> >>> insipid mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/insipid
> >> _______________________________________________
> >> insipid mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/insipid
> >
> > _______________________________________________
> > insipid mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/insipid
> 
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid